Add process for making architectural changes
This commit is contained in:
Greg Fitzgerald
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.
|
||||
* 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
|
||||
|
||||
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
|
||||
|
||||
|
|
@ -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:
|
||||
|
|
@ -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.
|
||||
|
|
@ -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
|
||||
|
||||
Loading…
Reference in New Issue