implement nomos with docusaurus

This commit is contained in:
jinhojang6 2023-06-01 19:15:43 +09:00
commit 48a367aeae
28 changed files with 14748 additions and 0 deletions

26
.gitignore vendored Normal file
View File

@ -0,0 +1,26 @@
# Dependencies
/node_modules
# Production
/build
# Generated files
.docusaurus
.cache-loader
# Misc
.DS_Store
.env
.env.local
.env.development.local
.env.test.local
.env.production.local
npm-debug.log*
yarn-debug.log*
yarn-error.log*
.yalc
yalc.lock
.idea
static/search-index.json

2
.husky/commit-msg Executable file
View File

@ -0,0 +1,2 @@
#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"

5
.husky/pre-commit Executable file
View File

@ -0,0 +1,5 @@
#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"
# yarn prettier:staged
# yarn typecheck

2
.prettierignore Normal file
View File

@ -0,0 +1,2 @@
*.mdx
*.md

6
.prettierrc Normal file
View File

@ -0,0 +1,6 @@
{
"tabWidth": 2,
"semi": false,
"singleQuote": true,
"trailingComma": "all"
}

46
README.md Normal file
View File

@ -0,0 +1,46 @@
- [Description](#description)
- [How to Run Locally](#how-to-run-locally)
- [Configuration](#configuration)
- [Customization](#customization)
## Description
This repository contains the content of your documentation website.
## How to Run Locally
1. Clone this repository.
2. Install the dependencies:
```bash
$ yarn
```
3. Start and open the website in your browser:
```bash
$ yarn start
```
## Configuration
Edit the `docusaurus.config.js` file in the repository's root directory, and update the value of the `businessUnit` field in presets section; below is a list of valid values:
- Logos
- Codex
- Waku
Example:
```js
presets: [
[
'@acid-info/logos-docusaurus-preset',
{
businessUnit: 'Codex',
},
],
],
```
This is probably enough in most cases, as the Logos plugins will fill in other configurations related to the specified business unit. If you find any error in the information coming from Logos Plugins, please head over to [Logos Docusaurus Plugins](https://github.com/acid-info/logos-docusaurus-plugins) and create an issue.
## Customization
You can find the instructions on adding more documentation sections, localization, and versioning on the [Docusaurus](https://docusaurus.io/docs) website.
> Note that theme customization is limited; for further instructions on customizing your theme, head over to [Logos Docusaurus Theme](https://github.com/acid-info/logos-docusaurus-plugins/tree/main/packages/logos-docusaurus-theme/).

3
babel.config.js Normal file
View File

@ -0,0 +1,3 @@
module.exports = {
presets: [require.resolve("@docusaurus/core/lib/babel/preset")],
};

92
docs/architect.md Normal file
View File

@ -0,0 +1,92 @@
---
title: Description and architecture
sidebar_position: 2
---
Nomos was designed to serve as the infrastructure for emerging network states. We believe that such a network must maintain the following properties:
- **Maximum decentralization:** Nomos is designed to place minimum resource demands on validators, ensuring that those without access to powerful hardware can participate. With the network maximally accessible, greater numbers of users can join as full peers, strengthening Nomos from a security perspective.
- **Multi-chain ecosystem:** Nomos' multi-chain architecture is designed to support multiple heterogeneous network states with their own rules and, possibly, desires for independence. In addition to extending greater sovereignty to the network states on Nomos, this approach enables unlimited horizontal scaling.
- **Isolated performance trade-offs:** Nomos will provide a means for customizable execution environments in which trade-offs can be made to achieve performance enhancements such as high transaction throughput.
- **Privacy-centric:** We believe privacy to be essential for the self-determination and sovereignty of aspiring network states. Consequently, Nomos has been designed to protect user privacy at the network level and in such a way as to enable the integration of new privacy techniques as they become available.
To achieve the above, Nomos develops an underexplored area in the design space between Ethereum, Cosmos, Polkadot and newer systems like Celestia and Anoma.
Ethereum pioneered the concept of a blockchain network capable of smart contract execution ushering in an ongoing era of monetary and organizational experimentation. Yet, it is vulnerable to various centralizing forces. Furthermore, while its rollup-centric approach to scaling has the potential for decentralization, most rollups today rely on centralized sequencers and inter-rollup communication presents its own complications. Inspirational to Nomos in many ways, these shortcomings make Ethereum ill-suited for our vision of a network of network states.
App-chain ecosystems—like Cosmos and Polkadot—offer an alternative architecture but introduce their own challenges. For example, bootstrapping sufficient participants to ensure the economic security of multiple independent chains and addressing the asynchronous nature of cross-chain protocols. While Polkadot's shared security model offers something of a solution, the network fails to enable easy, permissionless participation and its parachains cannot be considered fully sovereign.
Meanwhile, Anoma's fractal approach to scaling maintains decentralization while providing flexibility and customizability closer to our vision for Nomos. However, the approach is still to be tested widely by real-world applications, which will surely produce its own challenges. Finally, Nomos implements insights from Celestia's architecture in its approach to communication, sovereignty and scalability.
<br />
### Network architecture
Nomos consists of three layers—the Base Layer, Coordination Layer and Execution Zones. Each has a specific role that contributes to the system's functionality and performance.
<br />
**Base Layer**
Nomos' Base Layer focuses exclusively on consensus, data availability and decentralization, with the goal of ensuring stability, security and scalability for the rest of the network. No execution or validation is performed at the Base Layer as functions requiring access to state cannot be as reliably decentralized as consensus and data availability.
The Carnot consensus protocol is crucial to ensuring high performance as the network scales from a few validators to tens of thousands. A forthcoming paper covers Carnot in greater detail.
Alongside ensuring maximum decentralization, the Base Layer also strives to make data availability scalable. It achieves this by:
- Reducing the amount of computation validators need to do by minimizing or eliminating block execution or verification on the Base Layer.
- Reducing the amount of data light clients need to download through Data Availability Sampling.
- Reducing data redundancy in the network via sharding techniques that decouple data stored on the blockchain from the data that a single node needs to process and store.
<br />
**Coordination Layer**
Above the Base Layer is the Coordination Layer. The Coordination Layer's aim is to support functions common across all Execution Zones. To ensure maximum decentralization, these functions are kept to the bare minimum, since everything on the Coordination Layer must be downloaded and verified by all validators.
The Coordination Layer provides the following functions only:
- **Verification of ZK proofs:** The Coordination Layer's ability to verify ZK proofs facilitates powerful bridging capabilities, including private deposits and withdrawals between the Coordination Layer and Execution Zones, inter-Execution Zone private transfers and generalized use cases.
- **Message passing between Execution Zones:** The Coordination Layer enables Execution Zones to communicate asynchronously with each other. Such messaging is a powerful feature but not entirely trustless—as detailed in the forthcoming Nomos whitepaper.
- **Special operations, such as those relating to the creation of new Execution Zones:** Initially, these special operations are limited to initiating new Execution Zones and the creation of a new zone's genesis block.
- **Censorship resistance:** Censorship resistance is an emergent property of the above features, enabling any user to "exit" an execution zone by submitting transactions to the Coordination Layer directly. This is particularly powerful in the event that an Execution Zone attempts to censor a user's actions.
Coordination Layer directly. This is particularly powerful in the event that an Execution Zone attempts to censor a user's actions.
<br />
**Execution Zones**
The Base and Coordination Layers support a third layer of Execution Zones. Execution Zones provide the following properties:
- Share liquidity with the entire Nomos network
- Configurable latency reduction
- Configurable throughput increases
- Adaptability to specific applications and use cases
Execution Zones are most easily thought of as virtual sidechains that share the same global data availability space. Transactions associated with an Execution Zone are only processed by that zone's validators. However, unlike traditional sidechains, all applications on Nomos share the same blockchain, and data availability is uniformly ensured by the global Nomos network.
This architecture makes Execution Zones more powerful than traditional sidechains as they:
- Use trust-minimized bridging for communication.
- Can access each other's transactions securely.
- Share liquidity across the network.
- Enable improved security via staking.
Execution Zones exist to satisfy a wide range of application requirements that may demand far greater performance characteristics than what a highly decentralized, monolithic blockchain can achieve before hitting scaling limits. Such applications are often willing to make compromises in terms of security or decentralization to achieve such performance. By combining the elastic consensus algorithm Carnot with a staking mechanism and flexible execution models, Nomos grants a high degree of Execution Zone adaptability.
![architect.png](/subpages/architect.png)

33
docs/index.md Normal file
View File

@ -0,0 +1,33 @@
---
title: About
sidebar_position: 1
---
Nomos is an innovative blockchain platform designed to address the critical requirements of the network state. It aims to provide developers with secure, flexible and scalable infrastructure for building a wide range of applications while respecting the privacy and sovereignty of its users.
We believe that blockchain technology has the potential to lay the foundations of a fairer, less corruptible and, ultimately, freer world. However, its most successful implementations to date fall way short of achieving this.
<br/>
### Network-level privacy, network-level sovereignty
Bitcoin and Ethereum emerged from the cypherpunk tradition. As Eric Hughes wrote in his seminal 1993 essay, "A Cypherpunk's Manifesto":
> "Privacy is necessary for an open society in the electronic age."
Yet, neither network protects the right to privacy by default. Without network-level privacy, these supposedly disruptive technologies are, in fact, the perfect tool for surveillance because every on-chain interaction is recorded publicly forever.
We believe that such absolute transparency massively limits the scope of the technology's adoption and, therefore, its revolutionary potential. We cannot expect individuals to voluntarily exit the current system into one in which their every interaction with all financial and social institutions is forever available for the entire world to see. When we buy a coffee, for example, there is no absolutely no need for the seller to see our salary, other purchase history or political leanings.
Furthermore, we believe consent to be a critical element of any governance system. We find the nation-state's claims of governance via implied consent to be extremely contrived and believe blockchain-based systems represent an improvement because every on-chain action is voluntary and requires an individual to digitally sign, therefore, providing explicit consent.
While this is certainly a step in the right direction, it does not go far enough. If an individual no longer aligns with the on-chain institutions of which they were once apart, today's blockchains offer a means of exiting the system to recreate something new. However, the cost to do so successfully can be prohibitively expensive.
There have been numerous occasions in history where an on-chain community has been divided on some issue, resulting in a hard fork that creates two independent chains. In such situations, both networks suffer in terms of their overall security, making them more vulnerable to external attacks.
Nomos leverages a novel architecture to avoid this situation. We believe that a simple disagreement over a community's path forward should not threaten the existence of either party. The Nomos network enables the creation of numerous semi-autonomous execution zones that share the main network's security while retaining the freedom to create their own rulesets and, eventually, become fully independent if they so choose.
<br/>
### History
Work on Nomos began among a small subgroup of Status core contributors in 2022. The network takes its name from the ancient Greek concept of law

8
docs/roadmap.md Normal file
View File

@ -0,0 +1,8 @@
---
title: Development roadmap
sidebar_position: 4
---
At this early stage of Nomos' development, the team is primarily focused on implementing the network's consensus protocol, Carnot. As the consensus protocol is so foundational to the rest of the project, it must precede other development areas. Alongside Carnot, Nomos' contributors are working on defining the network architecture, which will also influence future roadmap items.
After defining the network architecture and implementing the consensus protocol, we can establish further milestones both above and below the consensus protocol. Above the consensus layer will be the network's data model and execution environments, which will enable advanced functionality. Below will be P2P networking and peer discovery, which must be built or integrated while maintaining privacy and performance.

12
docs/team.md Normal file
View File

@ -0,0 +1,12 @@
---
title: Team structure
sidebar_position: 3
---
Building Nomos is a team of passionate and experienced blockchain developers and researchers. Leading the effort is Álvaro Castro-Castilla who previously held the position of Head of Blockchain Infrastructure at Status and takes responsibility for coordinating research and development, defining the network's architecture, and establishing its vision, values and mission.
Alongside Nomos' project lead is a team of three researchers and developers with experience as software engineers both within and beyond the web3 ecosystem, and in academia. As of June 2023, there are two Rust developers (one senior) and a mathematical analyst that contribute to the project.
At this stage of development, the group of contributors working on Nomos is small, meaning it has a loose, fluid structure. As more contributors join to work on the network, we expect to revise the structure detailed here.
Nomos is keen to work with other contributors. If you share our passion for decentralization, individual sovereignty and privacy, we'd love to hear from you.

130
docusaurus.config.js Normal file
View File

@ -0,0 +1,130 @@
// @ts-check
// Note: type annotations allow type checking and IDEs autocompletion
require('dotenv').config()
/** @type {import('@docusaurus/types').Config} */
const config = {
title: 'Nomos',
url: 'https://url',
baseUrl: '/',
customFields: {
ghostAPiKey: process.env.GHOST_API_KEY,
},
markdown: {
mermaid: true,
},
// Even if you don't use internalization, you can use this field to set useful
// metadata like html lang. For example, if your site is Chinese, you may want
// to replace "en" with "zh-Hans".
i18n: {
defaultLocale: 'en',
locales: ['en'],
},
presets: [
[
'@acid-info/logos-docusaurus-preset',
/** @type {import('@acid-info/logos-docusaurus-preset').PluginOptions} */
({
businessUnit: 'Nomos',
theme: {
name: 'default',
options: {
customCss: [require.resolve('./src/css/custom.scss')],
},
},
docs: {
routeBasePath: '/about',
versions: {
current: {
label: 'current',
},
},
lastVersion: 'current',
},
}),
],
],
themes: ['@docusaurus/theme-mermaid'],
themeConfig:
/** @type {import('@acid-info/logos-docusaurus-preset').ThemeConfig} */
({
colorMode: {
defaultMode: 'dark',
disableSwitch: false,
},
navbar: {
items: [
{
type: 'search',
},
{
label: 'About',
to: '/about',
},
{
label: 'Blog',
href: '/',
},
{
label: 'Github',
href: '/',
},
{
type: 'localeDropdown',
position: 'right',
},
],
},
footer: {
copyright: 'Nomos @2023<br/>All Rights Reserved.',
links: [
{
items: [
{
href: '/',
label: 'Twitter',
},
{
href: '/',
label: 'Discord',
},
{
href: '/',
label: 'Docs',
},
{
href: '/',
label: 'Github',
},
],
},
{
items: [
{
href: '/',
label: 'Contact us',
},
{
href: 'https://jobs.status.im/',
label: 'Work with us',
},
{
href: '/',
label: 'Privacy policy',
},
{
href: '/',
label: 'Temrs & conditions',
},
],
},
],
},
}),
}
module.exports = config

53
package.json Normal file
View File

@ -0,0 +1,53 @@
{
"name": "nomos-docusaurus-template",
"version": "0.0.0",
"private": true,
"scripts": {
"docusaurus": "docusaurus",
"start": "docusaurus start",
"build": "docusaurus build",
"swizzle": "docusaurus swizzle",
"deploy": "docusaurus deploy",
"clear": "docusaurus clear",
"serve": "docusaurus serve",
"write-translations": "docusaurus write-translations",
"write-heading-ids": "docusaurus write-heading-ids",
"typecheck": "tsc"
},
"dependencies": {
"@acid-info/logos-docusaurus-preset": "^1.0.0-alpha.1",
"@docusaurus/core": "2.4.1",
"@docusaurus/preset-classic": "2.4.1",
"@docusaurus/theme-mermaid": "^2.4.1",
"@emotion/react": "^11.11.0",
"@emotion/styled": "^11.11.0",
"@mdx-js/react": "^1.6.22",
"clsx": "^1.2.1",
"dotenv": "^16.0.3",
"prism-react-renderer": "^1.3.5",
"react": "^17.0.2",
"react-dom": "^17.0.2",
"sass": "^1.62.1",
"tsdx": "^0.14.1"
},
"devDependencies": {
"@docusaurus/module-type-aliases": "2.4.1",
"@tsconfig/docusaurus": "^1.0.5",
"typescript": "^4.7.4"
},
"browserslist": {
"production": [
">0.5%",
"not dead",
"not op_mini all"
],
"development": [
"last 1 chrome version",
"last 1 firefox version",
"last 1 safari version"
]
},
"engines": {
"node": ">=16.14"
}
}

View File

@ -0,0 +1 @@
export * from '@acid-info/logos-docusaurus-theme/lib/client/components/mdx'

7
src/css/custom.scss Normal file
View File

@ -0,0 +1,7 @@
:root {
}
body,
html {
overflow-x: hidden;
}

108
src/pages/index.mdx Normal file
View File

@ -0,0 +1,108 @@
import {
Hero,
HeroTitle,
HeroDescription,
HeroActions,
HeroAction,
CallToActionSection,
FeatureList,
Showcase,
HeroModel,
HeroInfo,
} from '../components/mdx'
<Hero size="large">
<HeroInfo>
<HeroTitle>The web3 managing standard</HeroTitle>
{/*
<HeroDescription>
Waku is a decentralized communications network that enables private, censorship-resistant messaging for web3 applications.
</HeroDescription>
* */}
<HeroDescription>
WAKU IS A DECENTRALIZED COMMUNICATIONS NETWORK.
</HeroDescription>
<HeroActions>
<HeroAction href="https://docs.waku.org" target="_blank">
Build on Waku
</HeroAction>
<HeroAction variant="filled" href="https://docs.waku.org" target="_blank">
Run Waku
</HeroAction>
</HeroActions>
</HeroInfo>
<HeroModel
modelUrl="/hero/bulanding-generic-hand-01.glb"
layout="floating"
renderer="ascii"
initialX={-0.9831336272264352}
initialY={-0.14592188008227222}
rotateSpeed={0.1}
asciiConfig={{
characters: ' .,:;ox%# ||| ||| waku @',
}}
/>
</Hero>
<FeatureList
id="features"
features={[
{
title: 'Private',
description:
'Waku leverages cutting-edge zero-knowledge encryption to ensure all messages and associated metadata benefit from rock-solid privacy guarantees.',
},
{
title: 'Runs anywhere',
description:
"Waku's modularity enables developers to integrate Waku protocols according to their use case and users' hardware restraints",
},
{
title: 'Scalable',
description:
'Waku aims to scale to support millions of users by dividing the flow of messages into shards—not every node needs to forward every message—while discovery protocols ensure users connect to the nodes serving relevant messages.',
},
{
title: 'Secure',
description:
"Waku's native incentivization mechanisms ensure a wide node distribution, making it highly secure and strengthening its privacy assurances.",
},
]}
/>
<CallToActionSection
title="User adoptions"
description="Waku has brought private, censorship-resistant communications to several notable web3 DApps, decentralizing their messaging components:"
label="Decentralize your DApp"
href="/join"
/>
<Showcase
id="showcase"
items={[
{
name: 'XMTP',
logo: '/showcase/xmtp-mark-white.svg',
description:
"Inter-blockchain account messaging protocol XMTP uses Waku's Go implementation to facilitate communication between nodes in its currently permissioned network.",
},
{
name: 'Status',
logo: '/showcase/status-mark-white.svg',
description:
"Waku powers many of the Status super app's features, including its private messaging.",
},
{
name: 'Railgun',
logo: '/showcase/railgun-mark-white.svg',
description:
'The privacy-focused DeFi protocol Railgun anonymizes Ethereum transactions with Waku. ',
},
]}
/>
<CallToActionSection
title="Join the community to discover what Waku can bring to your DApp"
label="Decentralize your DApp"
href="/join"
/>

Binary file not shown.

Binary file not shown.

Binary file not shown.

BIN
static/hero/bust-hi.glb Normal file

Binary file not shown.

Binary file not shown.

BIN
static/hero/logos.glb Normal file

Binary file not shown.

View File

@ -0,0 +1,4 @@
<svg width="58" height="58" viewBox="0 0 58 58" fill="none" xmlns="http://www.w3.org/2000/svg">
<rect width="58" height="58" rx="29" fill="white"/>
<path d="M23 39V19H29.737C31.2013 19 32.4164 19.2669 33.3823 19.8008C34.3544 20.3346 35.0804 21.0736 35.5603 22.0176C36.0402 22.9551 36.2802 24.0391 36.2802 25.2695C36.2802 26.4935 36.0371 27.571 35.5511 28.502C35.0712 29.4264 34.3452 30.1458 33.3731 30.6602C32.4072 31.1745 31.192 31.4316 29.7278 31.4316H24.6243V28.834H29.4693C30.3922 28.834 31.1428 28.694 31.7212 28.4141C32.3056 28.1341 32.7332 27.7272 33.004 27.1934C33.2747 26.6595 33.41 26.0182 33.41 25.2695C33.41 24.5143 33.2716 23.86 32.9947 23.3066C32.724 22.7533 32.2964 22.3301 31.7119 22.0371C31.1336 21.7376 30.3738 21.5879 29.4324 21.5879H25.8517V39H23ZM32.3303 29.9766L37 39H33.7515L29.174 29.9766H32.3303Z" fill="black"/>
</svg>

After

Width:  |  Height:  |  Size: 845 B

View File

@ -0,0 +1,3 @@
<svg width="58" height="58" viewBox="0 0 58 58" fill="none" xmlns="http://www.w3.org/2000/svg">
<path fill-rule="evenodd" clip-rule="evenodd" d="M33.6479 28.7455C30.3452 28.9358 28.2754 28.1665 24.9723 28.3573C24.1531 28.4033 23.3396 28.522 22.5412 28.7121C23.0288 22.6037 27.3519 17.2602 33.2306 16.9205C36.8381 16.7123 40.4439 18.9397 40.6394 22.5555C40.8319 26.1094 38.1221 28.487 33.6483 28.7451L33.6479 28.7455ZM24.779 41.24C21.323 41.4352 17.8692 39.3501 17.6817 35.9665C17.4972 32.6404 20.0937 30.4152 24.3794 30.1736C27.543 29.9953 29.5261 30.7157 32.6897 30.5369C33.4741 30.4939 34.2533 30.3828 35.0186 30.2048C34.5523 35.9214 30.411 40.9226 24.779 41.24ZM28.9999 1.4449C13.7812 1.44446 1.44434 13.7812 1.44434 29C1.44434 44.2189 13.7812 56.5556 28.9999 56.5556C44.2186 56.5556 56.5554 44.2184 56.5554 29C56.5554 13.7816 44.2186 1.44446 28.9999 1.44446" fill="white"/>
</svg>

After

Width:  |  Height:  |  Size: 885 B

View File

@ -0,0 +1,10 @@
<svg width="57" height="58" viewBox="0 0 57 58" fill="none" xmlns="http://www.w3.org/2000/svg">
<g clip-path="url(#clip0_603_7836)">
<path d="M0 29C0 12.9837 12.8112 0 28.6147 0C44.4079 0 56.61 12.7424 56.9815 28.8744C56.9815 34.0217 55.2473 38.3527 50.9119 42.4328C47.2482 45.8808 41.0019 46.3874 36.4191 43.8139C33.1479 41.9015 30.627 37.8289 28.4908 34.8377L24.5268 40.9892H15.9796L24.0314 28.8739L16.2274 16.948H25.0223L28.5528 23.0996L32.0211 16.948H40.8782L32.8265 28.8744C32.8265 28.8744 36.6665 34.8377 38.7722 37.1602C40.8782 39.4828 44.7182 39.5455 47.1955 37.0346C49.9195 34.274 50.5292 32.0759 50.5403 28.8744C50.5828 16.4828 40.8709 6.52813 28.6147 6.52813C16.3687 6.52813 6.44139 16.5891 6.44139 29C6.44139 41.4108 16.3687 51.472 28.6147 51.472C30.3085 51.472 31.932 51.3277 33.5077 50.9696L34.8704 57.3096C32.6282 57.819 30.8169 58 28.6147 58C12.8112 58 0 45.0162 0 29Z" fill="white"/>
</g>
<defs>
<clipPath id="clip0_603_7836">
<rect width="57" height="58" fill="white"/>
</clipPath>
</defs>
</svg>

After

Width:  |  Height:  |  Size: 1015 B

Binary file not shown.

After

Width:  |  Height:  |  Size: 70 KiB

4
tsconfig.json Normal file
View File

@ -0,0 +1,4 @@
{
// This file is not used in compilation. It is here just for a nice editor experience.
"extends": "@tsconfig/docusaurus/tsconfig.json"
}

14193
yarn.lock Normal file

File diff suppressed because it is too large Load Diff