Model the process after Rust's RFC process
This commit is contained in:
parent
b7545b08fa
commit
a8481215fa
|
@ -56,13 +56,18 @@ Proposing architectural changes
|
|||
---
|
||||
|
||||
Solana's architecture is described by markdown files in the `doc/` directory, currently maintained
|
||||
by @garious. Changing the architecture is a three step process:
|
||||
by @garious. To change the architecture, you'll need to at least propose a change with an RFC document,
|
||||
and create an issue to track its implementation. Here's the full process:
|
||||
|
||||
1. Propose to a change to the architecture by creating a PR that adds a markdown file called a "wip-doc"
|
||||
(meaning "work-in-progress document" and pronounced "whip dock") to the directory `doc/wip/`. Add
|
||||
at least the maintainer of `doc/` as a reviewer.
|
||||
2. The PR being merged indicates your proposed change was accepted. The document will remain in `wip/`
|
||||
while additional PRs are submitted to update the Solana reference design, which is the Rust-only
|
||||
version of this codebase (no `--features` enabled). Be sure to update the wip-doc as the
|
||||
implementation reveals the need for tweaks to the architecture.
|
||||
3. Once implemented, contact the maintainer of the `doc/` to integrate the wip-doc into `doc/`.
|
||||
1. Propose to a change to the architecture by creating a PR that adds a markdown document called an RFC
|
||||
(standing for "request for comments") to the directory `rfcs/`. Add at least the maintainer of `doc/`
|
||||
as a reviewer.
|
||||
2. The PR being merged indicates your proposed change was accepted and that the Solana maintainers
|
||||
support your plan of attack. Next, create an issue to track its implementation and create a PR
|
||||
that updates the RFC with a link to the issue. This link allows anyone to quickly check the
|
||||
implementation status of any RFC.
|
||||
3. Submit PRs that implement the RFC. Be sure to reference the issue created above in your PR description.
|
||||
Feel free to update the RFC as the implementation reveals the need for tweaks to the architecture,
|
||||
but if you do, be sure to add the maintainer of `doc/` as a reviewer to your PR.
|
||||
4. Once the implementation is complete, close the issue. Depending on the scope of the RFC, the maintainer
|
||||
of `doc/` may then create a separate ticket to integrate the RFC into `doc/`.
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
# Smart Contracts Engine
|
||||
|
||||
The goal of this document is to define a set of constraints for APIs and smart contracts runtime such that we can execute our contracts safely on massively parallel hardware such as a GPU.
|
||||
The goal of this RFC is to define a set of constraints for APIs and smart contracts runtime such that we can execute our contracts safely on massively parallel hardware such as a GPU.
|
||||
|
||||
## Definitions
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
# Consensus
|
||||
|
||||
The goal of this document is to define the consensus algorithm used in Solana. This proposal covers a Proof of Stake (PoS) algorithm that leverages Proof of History (PoH). PoH is a permissionless clock for blockchain that is available before consensus. This PoS approach leverages PoH to make strong assumptions about time among partitions.
|
||||
The goal of this RFC is to define the consensus algorithm used in Solana. This proposal covers a Proof of Stake (PoS) algorithm that leverages Proof of History (PoH). PoH is a permissionless clock for blockchain that is available before consensus. This PoS approach leverages PoH to make strong assumptions about time among partitions.
|
||||
|
||||
|
||||
## Basic Design Idea
|
|
@ -1,6 +1,6 @@
|
|||
# Storage
|
||||
|
||||
The goal of this document is to define a protocol for storing a very large ledger over a p2p network that is verified by solana validators. At full capacity on a 1gbps network solana will generate 4 petabytes of data per year. To prevent the network from centralizing around full nodes that have to store the full data set this protocol proposes a way for mining nodes to provide storage capacity for pieces of the network.
|
||||
The goal of this RFC is to define a protocol for storing a very large ledger over a p2p network that is verified by solana validators. At full capacity on a 1gbps network solana will generate 4 petabytes of data per year. To prevent the network from centralizing around full nodes that have to store the full data set this protocol proposes a way for mining nodes to provide storage capacity for pieces of the network.
|
||||
|
||||
# Background
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
# Leader Rotation
|
||||
|
||||
The goal of this document is to define how leader nodes are rotated in Solana, how rotation may cause forks to arise, and how the converges
|
||||
The goal of this RFC is to define how leader nodes are rotated in Solana, how rotation may cause forks to arise, and how the converges
|
||||
in response.
|
||||
|
||||
## Leader Seed Generation
|
Loading…
Reference in New Issue