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
|
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"
|
1. Propose to a change to the architecture by creating a PR that adds a markdown document called an RFC
|
||||||
(meaning "work-in-progress document" and pronounced "whip dock") to the directory `doc/wip/`. Add
|
(standing for "request for comments") to the directory `rfcs/`. Add at least the maintainer of `doc/`
|
||||||
at least the maintainer of `doc/` as a reviewer.
|
as a reviewer.
|
||||||
2. The PR being merged indicates your proposed change was accepted. The document will remain in `wip/`
|
2. The PR being merged indicates your proposed change was accepted and that the Solana maintainers
|
||||||
while additional PRs are submitted to update the Solana reference design, which is the Rust-only
|
support your plan of attack. Next, create an issue to track its implementation and create a PR
|
||||||
version of this codebase (no `--features` enabled). Be sure to update the wip-doc as the
|
that updates the RFC with a link to the issue. This link allows anyone to quickly check the
|
||||||
implementation reveals the need for tweaks to the architecture.
|
implementation status of any RFC.
|
||||||
3. Once implemented, contact the maintainer of the `doc/` to integrate the wip-doc into `doc/`.
|
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
|
# 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
|
## Definitions
|
||||||
|
|
|
@ -1,6 +1,6 @@
|
||||||
# Consensus
|
# 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
|
## Basic Design Idea
|
|
@ -1,6 +1,6 @@
|
||||||
# Storage
|
# 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
|
# Background
|
||||||
|
|
|
@ -1,6 +1,6 @@
|
||||||
# Leader Rotation
|
# 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.
|
in response.
|
||||||
|
|
||||||
## Leader Seed Generation
|
## Leader Seed Generation
|
Loading…
Reference in New Issue