Nervos Network RFCs
This repository contains proposals, standards and documentations related to Nervos Network.
The RFC (Request for Comments) process is intended to provide an open and community driven path for new protocols, improvements and best practices, so that all stakeholders can be confident about the direction of Nervos network is evolving in.
RFCs publication here does not make it formally accepted standard until its status becomes Standard.
Categories
Not all RFCs are standards, there are 2 categories:
- Standards Track - RFC that is intended to be standard followed by protocols, clients and applications in Nervos network.
- Informational - Anything related to Nervos network.
Process
The RFC process attempts to be as simple as possible at beginning and evolves with the network.
1. Discuss Your Idea with Community
Before submiting a RFC pull request, you should proposal the idea or document to Nervos RFCs Chatroom or Nervos RFCs Mailing List.
2. Propose Your RFC
After discussion, please create a pull request to propose your RFC:
Copy
0000-templateasrfcs/0000-feature-name, wherefeature-nameis the descriptive name of the RFC. Don't assign an number yet.
Nervos RFCs should be written in English, but translated versions can be provided to help understanding. English version is the canonical version, check english version when there's ambiguity.
Nervos RFCs should follow the keyword conventions defined in RFC 2119, RFC 6919.
3. Review / Accept
The maintainers of RFCs and the community will review the PR, and you can update the RFC according to comments left in PR. When the RFC is ready and has enough supports, it will be accepted and merged into this repository.
An Informational RFC will be in Draft status once merged and published. It can be made Final by author at any time, or by RFC maintainers if there's no updates to the draft in 12 months.
4. (Standards Track) Propose Your Standard
A Standards Track RFC can be in 1 of 3 statuses:
- Proposal (Default)
- Standard
- Obsolete
A Standards Track RFC will be in Proposal status intially, it can always be updated and improved by PRs. When you believe it's rigorous and mature enough after more discussions, you should create a PR to propose making it a Standard.
The maintainers of RFCs will review the proposal, ask if there's any objections, and discuss about the PR. The PR will be accepted or closed based on rough consensus in this early stage.
RFCs
| Number | Title | Author | Category | Status |
|---|---|---|---|---|
| 2 | Nervos CKB: A Common Knowledge Base for Crypto-Economy | Jan Xie | Informational | Draft |
| 3 | CKB-VM | Xuejie Xiao | Informational | Draft |
| 4 | CKB Block Synchronization Protocol | Ian Yang | Standards Track | Proposal |
| 5 | Privileged architecture support for CKB VM | Xuejie Xiao | Informational | Draft |
| 6 | Merkle Tree for Static Data | Ke Wang | Standards Track | Proposal |
| 7 | P2P Scoring System And Network Security | Jinyang Jiang | Standards Track | Proposal |
| 8 | Serialization | Ian Yang | Standards Track | Proposal |
| 9 | VM Syscalls | Xuejie Xiao | Standards Track | Proposal |
| 10 | Eaglesong (Proof-of-Work Function for Nervos CKB) | Alan Szepieniec | Standards Track | Proposal |
| 11 | Transaction Filter | Quake Wang | Standards Track | Proposal |
| 12 | Node Discovery | Linfeng Qian, Jinyang Jiang | Standards Track | Proposal |
| 13 | Block Template | Dingwei Zhang | Standards Track | Proposal |
| 14 | VM Cycle Limits | Xuejie Xiao | Standards Track | Proposal |
| 15 | Crypto-Economics of the Nervos Common Knowledge Base | Kevin Wang, Jan Xie, Jiasun Li, David Zou | Informational | Draft |
| 17 | Transaction valid since | Jinyang Jiang | Standards Track | Proposal |
| 19 | Data Structures | Haichao Zhu, Xuejie Xiao | Informational | Draft |
| 20 | CKB Consensus Protocol | Ren Zhang | Informational | Draft |
License
This repository is being licensed under terms of MIT license.