Add process for making architectural changes
This commit is contained in:
parent
cf8f3bcbed
commit
b7545b08fa
|
@ -51,3 +51,18 @@ Some terms we currently use regularly in the codebase:
|
||||||
* pubkey: n. The public key of a Ed25519 key-pair.
|
* pubkey: n. The public key of a Ed25519 key-pair.
|
||||||
* sigverify: v. To verify a Ed25519 digital signature.
|
* 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/`.
|
||||||
|
|
|
@ -1,10 +1,6 @@
|
||||||
# Smart Contracts Engine
|
# 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.
|
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.
|
||||||
|
|
||||||
## Version
|
|
||||||
|
|
||||||
Version 0.3
|
|
||||||
|
|
||||||
## Definitions
|
## Definitions
|
||||||
|
|
|
@ -1,12 +1,8 @@
|
||||||
# Leader Rotation
|
# 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.
|
in response.
|
||||||
|
|
||||||
## Version
|
|
||||||
|
|
||||||
version 0.1
|
|
||||||
|
|
||||||
## Leader Seed Generation
|
## Leader Seed Generation
|
||||||
|
|
||||||
Leader selection is decided via a random seed. The process is as follows:
|
Leader selection is decided via a random seed. The process is as follows:
|
|
@ -1,12 +1,8 @@
|
||||||
# Consensus
|
# 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
|
## 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.
|
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.
|
|
@ -1,10 +1,6 @@
|
||||||
# Storage
|
# 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.
|
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.
|
||||||
|
|
||||||
# Version
|
|
||||||
|
|
||||||
version 0.1
|
|
||||||
|
|
||||||
# Background
|
# Background
|
||||||
|
|
Loading…
Reference in New Issue