Expland cluster overview, integrate Avalanche chapter
This commit is contained in:
parent
47ae25eeb9
commit
c242467fdf
|
@ -12,7 +12,6 @@
|
||||||
- [Synchronization](synchronization.md)
|
- [Synchronization](synchronization.md)
|
||||||
- [Introduction to VDFs](vdf.md)
|
- [Introduction to VDFs](vdf.md)
|
||||||
- [Proof of History](poh.md)
|
- [Proof of History](poh.md)
|
||||||
- [Ledger Broadcasting](avalanche.md)
|
|
||||||
- [Ledger Replication](storage.md)
|
- [Ledger Replication](storage.md)
|
||||||
- [Leader Rotation](leader-scheduler.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)
|
|
||||||
|
|
|
@ -4,7 +4,67 @@ A Solana cluster is a set of fullnodes working together to serve client
|
||||||
transactions and maintain the integrity of the ledger. Many clusters may
|
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.
|
converge. Otherwise, they simply ignore the existence of the other.
|
||||||
Transactions sent to the wrong one are quietly rejected. In this chapter,
|
Transactions sent to the wrong one are quietly rejected. In this chapter, we'll
|
||||||
we'll discuss how a cluster is created, how nodes join the cluster, how
|
discuss how a cluster is created, how nodes join the cluster, how they share
|
||||||
they share the ledger, how they ensure the ledger is replicated, and how
|
the ledger, how they ensure the ledger is replicated, and how they cope with
|
||||||
the cope with buggy and malicious nodes.
|
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.
|
The following list contains words commonly used throughout the Solana architecture.
|
||||||
|
|
||||||
* account - a persistent file addressed by pubkey and with tokens tracking its lifetime
|
* 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
|
* 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
|
* 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
|
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
|
* 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
|
* instruction - the smallest unit of a program that a client can include in a transaction
|
||||||
* keypair - a public and secret key
|
* 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
|
* node count - the number of fullnodes participating in a cluster
|
||||||
* program - the code that interprets instructions
|
* program - the code that interprets instructions
|
||||||
* pubkey - the public key of a keypair
|
* 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 - a ledger entry that estimates wallclock duration
|
||||||
* tick height - the Nth tick in the ledger
|
* tick height - the Nth tick in the ledger
|
||||||
* tps - transactions per second
|
* tps - transactions per second
|
||||||
* transaction - one or more instructions signed by the client and executed atomically
|
* transaction - one or more instructions signed by the client and executed atomically
|
||||||
* transactions entry - a set of transactions that may be executed in parallel
|
* 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
|
### 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
|
The following keywords do not have any functionality but are reserved by Solana
|
||||||
for potential future use.
|
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
|
* 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
|
* mips - millions of instructions per second
|
||||||
* public key - We currently use `pubkey`
|
* public key - We currently use `pubkey`
|
||||||
* slot - the time in which a single leader may produce entries
|
|
||||||
* secret key - Users currently only use `keypair`
|
* 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