diff --git a/book/src/SUMMARY.md b/book/src/SUMMARY.md index 346955820c..3bbeb230ce 100644 --- a/book/src/SUMMARY.md +++ b/book/src/SUMMARY.md @@ -12,7 +12,6 @@ - [Synchronization](synchronization.md) - [Introduction to VDFs](vdf.md) - [Proof of History](poh.md) - - [Ledger Broadcasting](avalanche.md) - [Ledger Replication](storage.md) - [Leader Rotation](leader-scheduler.md) diff --git a/book/src/avalanche.md b/book/src/avalanche.md deleted file mode 100644 index 73d3c5b5cc..0000000000 --- a/book/src/avalanche.md +++ /dev/null @@ -1,22 +0,0 @@ -# Ledger Broadcasting - -The [Avalance explainer video](https://www.youtube.com/watch?v=qt_gDRXHrHQ) is -a conceptual overview of how a Solana leader can continuously process a gigabit -of transaction data per second and then get that same data, after being -recorded on the ledger, out to multiple validators on a single gigabit -backplane. - -In practice, we found that just one level of the Avalanche validator tree is -sufficient for at least 150 validators. We anticipate adding the second level -to solve one of two problems: - -1. To transmit ledger segments to slower "replicator" nodes. -2. To scale up the number of validators nodes. - -Both problems justify the additional level, but you won't find it implemented -in the reference design just yet, because Solana's gossip implementation is -currently the bottleneck on the number of nodes per Solana cluster. That work -is being actively developed here: - -[Scalable Gossip](https://github.com/solana-labs/solana/pull/1546) - diff --git a/book/src/cluster.md b/book/src/cluster.md index bf8ef3bc41..ff28f70155 100644 --- a/book/src/cluster.md +++ b/book/src/cluster.md @@ -2,9 +2,69 @@ A Solana cluster is a set of fullnodes working together to serve client transactions and maintain the integrity of the ledger. Many clusters may -coexist. When two clusters share a common genesis block, they attempt to +coexist. When two clusters share a common genesis block, they attempt to converge. Otherwise, they simply ignore the existence of the other. -Transactions sent to the wrong one are quietly rejected. In this chapter, -we'll discuss how a cluster is created, how nodes join the cluster, how -they share the ledger, how they ensure the ledger is replicated, and how -the cope with buggy and malicious nodes. +Transactions sent to the wrong one are quietly rejected. In this chapter, we'll +discuss how a cluster is created, how nodes join the cluster, how they share +the ledger, how they ensure the ledger is replicated, and how they cope with +buggy and malicious nodes. + +## Creating a cluster + +To create a cluster, one needs the fullnode software and a *genesis block*. A +minimal genesis block can be created using the command-line tools +`solana-keygen`, `solana-fullnode-config` and `solana-genesis`. +`solana-keygen` is used to generate two keypairs, one for the *Mint* and one +for the *Bootstrap Leader*. `solana-fullnode-config` is used to pin down what +IP addresses and ports other nodes should use to contact it. Next, the +information from the first two tools are passed to `solana-genesis` to create +the genesis block. The genesis block is then be passed to all initial +fullnodes. The fullnode holding the Bootstrap Leader's private key is +responsible for appending the first entries to the ledger. It initializes its +internal state with the Mint's account. That account will hold the number of +fractional native tokens (called lamports) defined in the genesis block. All +other fullnodes should then contact the Bootstrap Leader and register as a +validator or replicator. A validator receives all entries from the leader and +is expected to submit votes confirming those entries are valid. After voting, +the validator is expected to store those entries until *replicator* nodes +submit proofs that they have stored copies of it. Once the validator observes a +sufficient number of copies exist, it deletes its copy. + +## Joining a cluster + +Fullnodes and replicators enter the cluster via registration messages sent to +its *control plane*. The control plane is implemented using a *gossip* +protocol, meaning that a node may register with any existing node, and expect +its registeration to propogate to all nodes in the cluster. The time it takes +for all nodes to synchonize is proportional to the square of the number of +nodes particating in the cluster. Algorithmically, that's considered very slow, +but in exchange for that time, a node is assured that it eventually has all the +same information as every other node, and that that information cannot be +censored by any one node. + +## Ledger Broadcasting + +The [Avalance explainer video](https://www.youtube.com/watch?v=qt_gDRXHrHQ) is +a conceptual overview of how a Solana leader can continuously process a gigabit +of transaction data per second and then get that same data, after being +recorded on the ledger, out to multiple validators on a single gigabit +backplane. + +In practice, we found that just one level of the Avalanche validator tree is +sufficient for at least 150 validators. We anticipate adding the second level +to solve one of two problems: + +1. To transmit ledger segments to slower "replicator" nodes. +2. To scale up the number of validators nodes. + +Both problems justify the additional level, but you won't find it implemented +in the reference design just yet, because Solana's gossip implementation is +currently the bottleneck on the number of nodes per Solana cluster. + +## Malicious nodes + +Solana is a *permissionless* blockchain, meaning that anyone wanting to +participate in the network may do so. They need only *stake* some +cluster-defined number of tokens and be willing to lose that stake if the +cluster observes the node acting maliciously. The process is called *Proof of +Stake* consensus, which defines rules to *slash* the stakes of malicious nodes. diff --git a/book/src/terminology.md b/book/src/terminology.md index 718b9d05ba..bad5905b6b 100644 --- a/book/src/terminology.md +++ b/book/src/terminology.md @@ -5,21 +5,28 @@ The following list contains words commonly used throughout the Solana architecture. * account - a persistent file addressed by pubkey and with tokens tracking its lifetime +* bootstrap leader - the first fullnode to take the leader role +* control plane - a gossip network connecting all nodes of a cluster * cluster - a set of fullnodes maintaining a single ledger +* data plane - a multicast network used to efficiently validate entries and gain consensus +* entry - an entry on the ledger - either a tick or a transactions entry * finality - the wallclock duration between a leader creating a tick entry and recoginizing a supermajority of validator votes with a ledger interpretation that matches the leader's * fullnode - a full participant in the cluster - either a leader or validator node -* entry - an entry on the ledger - either a tick or a transactions entry +* genesis block - the first entries of the ledger * instruction - the smallest unit of a program that a client can include in a transaction * keypair - a public and secret key +* leader - the role of a fullnode when it is appending entries to the ledger * node count - the number of fullnodes participating in a cluster * program - the code that interprets instructions * pubkey - the public key of a keypair +* replicator - a type of client that stores copies of segments of the ledger * tick - a ledger entry that estimates wallclock duration * tick height - the Nth tick in the ledger * tps - transactions per second * transaction - one or more instructions signed by the client and executed atomically * transactions entry - a set of transactions that may be executed in parallel +* validator - the role of a fullnode when it is validating the leader's latest entries ### Terminology Reserved for Future Use @@ -27,8 +34,12 @@ The following list contains words commonly used throughout the Solana architectu The following keywords do not have any functionality but are reserved by Solana for potential future use. +* blob - a fraction of a block; the smallest unit sent between validators +* block - the entries generated within a slot * epoch - the time in which a leader schedule is valid +* light client - a type of client that can verify it's pointing to a valid cluster * mips - millions of instructions per second * public key - We currently use `pubkey` -* slot - the time in which a single leader may produce entries * secret key - Users currently only use `keypair` +* slot - the time in which a single leader may produce entries +* thin client - a type of client that trusts it is communicating with a valid cluster