Drop mention of CLI tooling
This is a "how does it work?" chapter, not "how do I do it?"
This commit is contained in:
parent
3de63570f6
commit
070d6a2faa
|
@ -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
|
||||
|
|
Loading…
Reference in New Issue