diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 0be6f9bb21..6ec05cb6f1 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -51,3 +51,18 @@ Some terms we currently use regularly in the codebase: * pubkey: n. The public key of a Ed25519 key-pair. * sigverify: v. To verify a Ed25519 digital signature. + +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: + +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/`. diff --git a/rfcs/rfc-005-branches-tags-and-channels.md b/doc/wip/branches-tags-and-channels.md similarity index 100% rename from rfcs/rfc-005-branches-tags-and-channels.md rename to doc/wip/branches-tags-and-channels.md diff --git a/rfcs/rfc-006-budget-contract-language.md b/doc/wip/budget-contract-language.md similarity index 100% rename from rfcs/rfc-006-budget-contract-language.md rename to doc/wip/budget-contract-language.md diff --git a/rfcs/rfc-001-smart-contracts-engine.md b/doc/wip/concurrent-smart-contracts.md similarity index 97% rename from rfcs/rfc-001-smart-contracts-engine.md rename to doc/wip/concurrent-smart-contracts.md index 2c03a32db8..70a7dd6d8a 100644 --- a/rfcs/rfc-001-smart-contracts-engine.md +++ b/doc/wip/concurrent-smart-contracts.md @@ -1,10 +1,6 @@ # Smart Contracts Engine -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. - -## Version - -Version 0.3 +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. ## Definitions diff --git a/rfcs/rfc-004-leader-rotation.md b/doc/wip/poh-based-leader-rotation.md similarity index 97% rename from rfcs/rfc-004-leader-rotation.md rename to doc/wip/poh-based-leader-rotation.md index e5558cf018..d56fc6e8f6 100644 --- a/rfcs/rfc-004-leader-rotation.md +++ b/doc/wip/poh-based-leader-rotation.md @@ -1,12 +1,8 @@ # Leader Rotation -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 +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 in response. -## Version - -version 0.1 - ## Leader Seed Generation Leader selection is decided via a random seed. The process is as follows: diff --git a/rfcs/rfc-002-consensus.md b/doc/wip/poh-based-pos-consensus.md similarity index 92% rename from rfcs/rfc-002-consensus.md rename to doc/wip/poh-based-pos-consensus.md index 321e64aa55..69599e83bd 100644 --- a/rfcs/rfc-002-consensus.md +++ b/doc/wip/poh-based-pos-consensus.md @@ -1,12 +1,8 @@ # Consensus -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. +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. -## Version - -version 0.4 - ## Basic Design Idea Nodes on the network can be "up" or "down". A node indicates it is up either by voting as a validator or by generating a PoH stream as the designated leader. Consensus is reached when a supermajority + 1 of the staked nodes have voted on the state of the network at a particular PoH tick count. diff --git a/rfcs/rfc-003-storage.md b/doc/wip/poh-based-storage.md similarity index 93% rename from rfcs/rfc-003-storage.md rename to doc/wip/poh-based-storage.md index 7afc9af23a..df03697d43 100644 --- a/rfcs/rfc-003-storage.md +++ b/doc/wip/poh-based-storage.md @@ -1,10 +1,6 @@ # Storage -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. - -# Version - -version 0.1 +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. # Background