From 070d6a2faa8ca6e5cecad04436f0b7bc8fd7f37f Mon Sep 17 00:00:00 2001 From: Greg Fitzgerald Date: Wed, 28 Nov 2018 15:45:43 -0700 Subject: [PATCH] Drop mention of CLI tooling This is a "how does it work?" chapter, not "how do I do it?" --- book/src/cluster.md | 34 +++++++++++++++------------------- 1 file changed, 15 insertions(+), 19 deletions(-) diff --git a/book/src/cluster.md b/book/src/cluster.md index 2b5798bd80..0b8d34e513 100644 --- a/book/src/cluster.md +++ b/book/src/cluster.md @@ -11,24 +11,20 @@ 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 secret key is +Before starting any fullnodes, one first needs to create a *genesis block*. +The block contains entries referencing two public keys, a *mint* and a +*bootstrap leader*. The fullnode holding the bootstrap leader's secret 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. +internal state with the mint's account. That account will hold the number of +native tokens defined by the genesis block. The second fullnode then contact +the bootstrap leader to register as a validator or replicator. Additional +fullnodes then register with any registered member of the cluster. + +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 @@ -47,8 +43,8 @@ censored by any one node. 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 -*data plane*. +recorded on the ledger, out to multiple validators on a single gigabit *data +plane*. 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