mirror of https://github.com/logos-co/roadmap.git
nomos roadmap from Notion
This commit is contained in:
parent
335993a1ea
commit
9d8dd748b6
|
@ -0,0 +1,9 @@
|
||||||
|
---
|
||||||
|
title: "Codex Milestones Overview"
|
||||||
|
date: "2023-08-07"
|
||||||
|
lastmod: "2023-08-07"
|
||||||
|
draft: false
|
||||||
|
tags:
|
||||||
|
- "milestones-overview"
|
||||||
|
---
|
||||||
|
|
|
@ -1,12 +0,0 @@
|
||||||
---
|
|
||||||
title: "Codex Milestones Overview"
|
|
||||||
date: "2023-08-07"
|
|
||||||
lastmod: "2023-08-07"
|
|
||||||
draft: false
|
|
||||||
tags:
|
|
||||||
- "milestones-overview"
|
|
||||||
---
|
|
||||||
|
|
||||||
## Milestones
|
|
||||||
- [Zenhub Tracker](https://app.zenhub.com/workspaces/engineering-62cee4c7a335690012f826fa/roadmap)
|
|
||||||
- [Miro Tracker](https://miro.com/app/board/uXjVNZ03E-c=/?share_link_id=987528411803)
|
|
|
@ -0,0 +1,38 @@
|
||||||
|
---
|
||||||
|
title: Codex Milestones Overview
|
||||||
|
tags:
|
||||||
|
- milestones
|
||||||
|
- codex
|
||||||
|
---
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
## Milestones
|
||||||
|
- Codex Testnet
|
||||||
|
-
|
||||||
|
|
||||||
|
## Technical Milestones
|
||||||
|
- Client
|
||||||
|
- Merkelizing block data
|
||||||
|
- Block discovery and retrieval
|
||||||
|
- Distributed Client Testing
|
||||||
|
- Async Disc Access & Threading Support
|
||||||
|
- Marketplace
|
||||||
|
- L2
|
||||||
|
- Reservations and Slot Management
|
||||||
|
- Milestone Sales
|
||||||
|
- Remote Auditing
|
||||||
|
- Implement Poseidon2
|
||||||
|
- Refine Proving System
|
||||||
|
- Data Availability Sampling (DAS)
|
||||||
|
- DHT Simulations
|
||||||
|
- Infra
|
||||||
|
- Kubernetes Configuration and Management
|
||||||
|
- Continuous Testing and Labeling
|
||||||
|
- CI/CD and Synchronization
|
||||||
|
- Monitoring and Metrics
|
||||||
|
|
||||||
|
## Other Resources
|
||||||
|
- ~~[Zenhub Tracker](https://app.zenhub.com/workspaces/engineering-62cee4c7a335690012f826fa/roadmap)~~ - deprecated
|
||||||
|
- [Miro Tracker](https://miro.com/app/board/uXjVNZ03E-c=/?share_link_id=987528411803)
|
||||||
|
- [Github Projects Milestone Definitions](https://github.com/orgs/codex-storage/projects/3/views/2?filterQuery=has%3Alabel)
|
|
@ -5,5 +5,5 @@ tags:
|
||||||
---
|
---
|
||||||
Welcome to the Codex Roadmap Overview
|
Welcome to the Codex Roadmap Overview
|
||||||
- [[codex/monthly-reports/2023-sept|2023 September Report]]
|
- [[codex/monthly-reports/2023-sept|2023 September Report]]
|
||||||
- [Milestones](codex/milestones-overview.md)
|
- [[codex/milestones/index|2o24 Milestones]]
|
||||||
- [weekly updates](tags/codex-updates)
|
- [weekly updates](tags/codex-updates)
|
|
@ -15,6 +15,4 @@ Every year (starting this year), each project defines its plans in a number a mi
|
||||||
- [[nomos/index|Nomos]]
|
- [[nomos/index|Nomos]]
|
||||||
|
|
||||||
### Services
|
### Services
|
||||||
- [Vac](vac/index.md)
|
- [Vac](vac/index.md)
|
||||||
- [Comms (Acid Info)](acid/index.md)
|
|
||||||
- [[insight/index|Insight]]
|
|
|
@ -11,3 +11,4 @@ description: The Nomos project is an attempt to make a scalable, modular, and pr
|
||||||
The Nomos project building a blockchain for Network States. To learn more about the project, please visit [the website](https://nomos.tech)
|
The Nomos project building a blockchain for Network States. To learn more about the project, please visit [the website](https://nomos.tech)
|
||||||
|
|
||||||
Nomos is currently in its research phase, and actively building a Testnet.
|
Nomos is currently in its research phase, and actively building a Testnet.
|
||||||
|
|
||||||
|
|
|
@ -0,0 +1,23 @@
|
||||||
|
---
|
||||||
|
title: Coordination Layer
|
||||||
|
tags:
|
||||||
|
- nomos-milestone
|
||||||
|
- roadmap-2024
|
||||||
|
---
|
||||||
|
### Core Tasks
|
||||||
|
|
||||||
|
- Define data model (ie UTXO + partial transactions)
|
||||||
|
- Select proving system. This could potentially become a very large project, requiring tooling and compiler development. But we should try by all means using a ZK system with a compiler readily available.
|
||||||
|
- Provide the necessary tools for a ZK engineer to develop the 3 proofs and experimental Zone bridges.
|
||||||
|
|
||||||
|
### Action Plan
|
||||||
|
|
||||||
|
The stages of research and development for the CL are as follow:
|
||||||
|
|
||||||
|
1. **Phase 1: Design CL data model.** We need a simple, expressive transaction system that supports synchronous composability. The output from this phase will be a CL specification focused on supporting one key feature: *private atomic asset transfers between zones*.
|
||||||
|
2. **Phase 2: Choose ZK system.** The single most important task of the research team in this work-stream is to make the fundamental choices that will allow us to build the foundation as fast as possible for a usable CL. This has to be done carefully and considering the specific use case of ZK in the CL, with the requirements that we have.
|
||||||
|
3. **Phase 3: Build the minimal system for protocol dependencies.** After this, we need to put a minimal system in place, so that the 3 proofs of the protocol can be built. This is a big blocker for the network privacy and PPoS protocols, so it needs to be the primary implementation objective.
|
||||||
|
4. **Phase 4 (partially in 2024): Develop the CL tooling and integration to unlock more complex engineering feats.** This will be a larger task, and not assumed to be finished by 2024. These include:
|
||||||
|
1. Zone bridges
|
||||||
|
2. Synchronous composability
|
||||||
|
3. Aggregation/Solving layer
|
|
@ -0,0 +1,31 @@
|
||||||
|
---
|
||||||
|
title: Data Availability
|
||||||
|
tags:
|
||||||
|
- nomos-milestone
|
||||||
|
- roadmap-2024
|
||||||
|
---
|
||||||
|
### Core Tasks
|
||||||
|
|
||||||
|
- **Dispersal.** Design Dispersal algorithm. With current conclusions on the DA requirements of Zones, we can design dispersal given:
|
||||||
|
- Number of chunks
|
||||||
|
- Number of nodes participating in DA
|
||||||
|
- **PoV.** This solution will require gossip-based distribution of Proof of Validator (see below) and public keys, to allow VID without relying on validator registries.
|
||||||
|
- **VID?** Analyze if VID is still a better option than async validator light-node verification (the Danksharding way), given the target design with many more nodes than initially accounted for.
|
||||||
|
- **Dissemination.** Design of an altruistic replication protocol (ie dissemination), to further strengthen the DA, by extending it beyond the Nomos validators to Light Nodes. This could be a DHT or similar solution.
|
||||||
|
Perhaps this turns into “DA starts with a groups of selected validators and then it's further disseminated although without proof in VID” situation, which might actually be more coherent with our vision. Answering this question is very important.
|
||||||
|
|
||||||
|
### Action Plan
|
||||||
|
|
||||||
|
Solving the remaining problems of DA requires mainly knowledge of distributed systems. The only exception is the PoV, which can be designed a researcher with more knowledge of Zk. Note that it's mainly an ZK engineering problem, not a protocol problem.
|
||||||
|
|
||||||
|
The steps to implement Data Availability are the following:
|
||||||
|
|
||||||
|
1. Initial implementation. Pick a number of nodes and disperse the chunks directly to them. This solution is insufficient for production because it lacks two things:
|
||||||
|
1. Even distribution of chunks in the entire validator set.
|
||||||
|
2. A single client cannot disperse the chunks well enough, while at the same time gossiping cannot be used for this (defeats the entire purpose of DA).
|
||||||
|
3. A way to verify that the network has achieved enough dissemination.
|
||||||
|
4. It doesn't scale. If we have 100k nodes, do we select a subset? How's that subset gonna distribute to the rest of the network.
|
||||||
|
2. ASAP, Design a dispersal and dissemination protocol, to solve the above problems. This can be thought of an IPFS kind of protocol. The main difference is that the validators are able to verify DA through sampling to ensure the data is there.
|
||||||
|
3. Implement solution in 2.
|
||||||
|
|
||||||
|
DA is a problem that looks more solved than it actually is. The key aspects that remain to be solved are listed above. Working on solutions for this, while maintaining the design principle of maximizing validator count with low reliability, it's paramount.
|
|
@ -0,0 +1,17 @@
|
||||||
|
---
|
||||||
|
title: Nomos Milestones
|
||||||
|
tags:
|
||||||
|
- milestones
|
||||||
|
- nomos
|
||||||
|
---
|
||||||
|
## Milestones
|
||||||
|
- [[p2p-privacy|P2P Privacy]]
|
||||||
|
- [[data-availability|Data Availability]]
|
||||||
|
- [[ppos-consensus|PPoS / Consensus]]
|
||||||
|
- [[coordination-layer|Coordination Layer]]
|
||||||
|
- [[testnet-insights|Testnet + Insights]]
|
||||||
|
- [[user-tools|User Tools]]
|
||||||
|
|
||||||
|
## Additional Resources
|
||||||
|
- [Notion Milestone Execution Plan](https://www.notion.so/2024-Nomos-Milestone-Execution-Plan-62004acdaa5e4c65bd8c5b10e935e78b)
|
||||||
|
- [Notion Milestone Tracker](https://www.notion.so/Planning-72abffc47cf44a4da7a4d99d22146dde)
|
|
@ -0,0 +1,21 @@
|
||||||
|
---
|
||||||
|
title: P2P Privcay
|
||||||
|
tags:
|
||||||
|
- nomos-milestone
|
||||||
|
- roadmap-2024
|
||||||
|
---
|
||||||
|
### Core Tasks
|
||||||
|
|
||||||
|
- Implement Proof of Leader Election
|
||||||
|
- Implement Proof of Validator (rather employed at other layers, but planning-wise it's better to consider it here)
|
||||||
|
- Full Analysis of Wealth Concentration using game-theoretical node behavior.
|
||||||
|
- Full Analysis of privacy leak due to orphan proofs
|
||||||
|
|
||||||
|
### Action Plan
|
||||||
|
|
||||||
|
The consensus protocol is the best-known piece of our design, given our extensive experience in the matter. However, its guarantees depend largely on the network layer, while all the remaining cryptographic components depend on the CL. These two is where our focus is on. Besides this, most of the deliverables are advanced-stage components, meaning that they are the last pieces remaining.
|
||||||
|
|
||||||
|
The road towards finalization looks as follows:
|
||||||
|
|
||||||
|
1. Implement the 2 proofs. This depends on the Coordination Layer.
|
||||||
|
2. Fully analyze the remaining open questions (wealth concentration and privacy leaks via orphan proofs). The work on wealth concentration is scheduled to start soon.
|
|
@ -0,0 +1,21 @@
|
||||||
|
---
|
||||||
|
title: PPoS / Consensus
|
||||||
|
tags:
|
||||||
|
- nomos-milestone
|
||||||
|
- roadmap-2024
|
||||||
|
---
|
||||||
|
### Core Tasks
|
||||||
|
|
||||||
|
- Implement Proof of Leader Election
|
||||||
|
- Implement Proof of Validator (rather employed at other layers, but planning-wise it's better to consider it here)
|
||||||
|
- Full Analysis of Wealth Concentration using game-theoretical node behavior.
|
||||||
|
- Full Analysis of privacy leak due to orphan proofs
|
||||||
|
|
||||||
|
### Action Plan
|
||||||
|
|
||||||
|
The consensus protocol is the best-known piece of our design, given our extensive experience in the matter. However, its guarantees depend largely on the network layer, while all the remaining cryptographic components depend on the CL. These two is where our focus is on. Besides this, most of the deliverables are advanced-stage components, meaning that they are the last pieces remaining.
|
||||||
|
|
||||||
|
The road towards finalization looks as follows:
|
||||||
|
|
||||||
|
1. Implement the 2 proofs. This depends on the Coordination Layer.
|
||||||
|
2. Fully analyze the remaining open questions (wealth concentration and privacy leaks via orphan proofs). The work on wealth concentration is scheduled to start soon.
|
|
@ -0,0 +1,23 @@
|
||||||
|
---
|
||||||
|
title: Testnet + Insights
|
||||||
|
tags:
|
||||||
|
- nomos-milestone
|
||||||
|
- roadmap-2024
|
||||||
|
---
|
||||||
|
### Core Tasks
|
||||||
|
|
||||||
|
- Testnet Instrumentation. Internal, for debugging pre-releases.
|
||||||
|
- Health Monitoring
|
||||||
|
- Instrumentation for DS debugging
|
||||||
|
- Leader selection and Fork visualization
|
||||||
|
- Network Explorers. Public access, but a critical tool for debugging.
|
||||||
|
- Block and mempool explorers
|
||||||
|
|
||||||
|
### Action Plan
|
||||||
|
|
||||||
|
This work-stream is purely an engineering effort, but with the caveat that introduces user-facing systems like the Network Explorer. Both internal instrumentation and public-facing functionality should be initiated as soon as possible.
|
||||||
|
|
||||||
|
The key in implementing these is to start with a minimal functionality keeping these two primary objectives in mind:
|
||||||
|
|
||||||
|
1. **Help us** develop, debug and understand our network
|
||||||
|
2. **Attract users by exposing visualizations of the blockchain** with cool tools for exploring the chain and the network behavior. This is, in a way, a marketing tool.
|
|
@ -0,0 +1,20 @@
|
||||||
|
---
|
||||||
|
title: User Tools
|
||||||
|
tags:
|
||||||
|
- nomos-milestone
|
||||||
|
- roadmap-2024
|
||||||
|
---
|
||||||
|
### Core Tasks
|
||||||
|
|
||||||
|
- Wallet
|
||||||
|
- Major browser support
|
||||||
|
- Basic functionality: payments, inscriptions, tokens
|
||||||
|
- Ultra-easy to run validator software
|
||||||
|
- Must have GUI and background runner (similar to Dropbox tool)
|
||||||
|
- One-click installation for Windows/OSX/Linux
|
||||||
|
|
||||||
|
### Action Plan
|
||||||
|
|
||||||
|
The priority should be to implement the wallet, since we can have initially a node that is not easy to run. Making it easy is something that can be achieved once we have a functioning system. The wallet is however necessary for any usable Testnet that we want to make public.
|
||||||
|
|
||||||
|
The main problem is that the wallet is highly dependent on the Coordination Layer, so further efforts in this area are blocked until that is solved (at least past Phase 1).
|
|
@ -3,18 +3,11 @@ title: 2024 Milestones
|
||||||
date: 2024-06-04
|
date: 2024-06-04
|
||||||
---
|
---
|
||||||
|
|
||||||
[Milestone Store Service Upgrade](waku/milestones/2024-bandwidth-optimization-and-protocol-review.md)
|
- [Store Service Upgrade](waku/milestones/2024-bandwidth-optimization-and-protocol-review.md)
|
||||||
|
- [Direct Message Reliability](waku/milestones/2024-direct-msg-reliability.md)
|
||||||
[Milestone Direct Message Reliability](waku/milestones/2024-direct-msg-reliability.md)
|
- [End-to-end reliability protocol](waku/milestones/2024-e2e-reliability-protocol.md)
|
||||||
|
- [Static Sharding - dedicated shards](waku/milestones/2024-static-sharding-dedicated-shards.md)
|
||||||
[Milestone End-to-end reliability protocol](waku/milestones/2024-e2e-reliability-protocol.md)
|
- [Bandwidth optimization and protocol review](waku/milestones/2024-bandwidth-optimization-and-protocol-review.md)
|
||||||
|
- [Scale up number of Communities](waku/milestones/2024-scale-one-to-one-chat-poc.md)
|
||||||
[Milestone Static Sharding - dedicated shards](waku/milestones/2024-static-sharding-dedicated-shards.md)
|
- [Nwaku in Status Desktop (Relay, *nix)](waku/milestones/2024-nwaku-in-status-desktop.md)
|
||||||
|
- [Scale 1:1 chat messages PoC](waku/milestones/2024-scale-one-to-one-chat-poc.md)
|
||||||
[Milestone Bandwidth optimization and protocol review](waku/milestones/2024-bandwidth-optimization-and-protocol-review.md)
|
|
||||||
|
|
||||||
[Milestone Scale up number of Communities](waku/milestones/2024-scale-one-to-one-chat-poc.md)
|
|
||||||
|
|
||||||
[Milestone Nwaku in Status Desktop (Relay, *nix)](waku/milestones/2024-nwaku-in-status-desktop.md)
|
|
||||||
|
|
||||||
[Milestone Scale 1:1 chat messages PoC](waku/milestones/2024-scale-one-to-one-chat-poc.md)
|
|
||||||
|
|
Loading…
Reference in New Issue