blockworks-foundation
/
solana
mirror of https://github.com/blockworks-foundation/solana.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Drop mention of CLI tooling 

This is a "how does it work?" chapter, not "how do I do it?"
This commit is contained in:
Greg Fitzgerald 2018-11-28 15:45:43 -07:00 committed by Grimes
parent 3de63570f6
commit 070d6a2faa
1 changed files with 15 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

34
book/src/cluster.md
View File

@ -11,24 +11,20 @@ buggy and malicious nodes.
## Creating a Cluster ## Creating a Cluster
To create a cluster, one needs the fullnode software and a *genesis block*. A Before starting any fullnodes, one first needs to create a *genesis block*.
minimal genesis block can be created using the command-line tools The block contains entries referencing two public keys, a *mint* and a
`solana-keygen`, `solana-fullnode-config` and `solana-genesis`. *bootstrap leader*. The fullnode holding the bootstrap leader's secret key is
`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
responsible for appending the first entries to the ledger. It initializes its 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 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 native tokens defined by the genesis block. The second fullnode then contact
other fullnodes should then contact the Bootstrap Leader and register as a the bootstrap leader to register as a validator or replicator. Additional
validator or replicator. A validator receives all entries from the leader and fullnodes then register with any registered member of the cluster.
is expected to submit votes confirming those entries are valid. After voting,
the validator is expected to store those entries until *replicator* nodes A validator receives all entries from the leader and is expected to submit
submit proofs that they have stored copies of it. Once the validator observes a votes confirming those entries are valid. After voting, the validator is
sufficient number of copies exist, it deletes its copy. 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 ## 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 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 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 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 recorded on the ledger, out to multiple validators on a single gigabit *data
*data plane*. plane*.
In practice, we found that just one level of the Avalanche validator tree is 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 sufficient for at least 150 validators. We anticipate adding the second level