Expland cluster overview, integrate Avalanche chapter
This commit is contained in:
Greg Fitzgerald
Grimes
parent
47ae25eeb9
commit
c242467fdf
|
|
@ -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)
|
||||
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
||||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Reference in New Issue