Update book for Turbine (#4583)
This commit is contained in:
committed by
GitHub
parent
8e46c44f3e
commit
53deb7919c
@ -16,7 +16,7 @@
|
|||||||
- [Leader Rotation](leader-rotation.md)
|
- [Leader Rotation](leader-rotation.md)
|
||||||
- [Fork Generation](fork-generation.md)
|
- [Fork Generation](fork-generation.md)
|
||||||
- [Managing Forks](managing-forks.md)
|
- [Managing Forks](managing-forks.md)
|
||||||
- [Data Plane Fanout](data-plane-fanout.md)
|
- [Turbine Block Propagation](turbine-block-propagation.md)
|
||||||
- [Ledger Replication](ledger-replication.md)
|
- [Ledger Replication](ledger-replication.md)
|
||||||
- [Secure Vote Signing](vote-signing.md)
|
- [Secure Vote Signing](vote-signing.md)
|
||||||
- [Stake Delegation and Rewards](stake-delegation-and-rewards.md)
|
- [Stake Delegation and Rewards](stake-delegation-and-rewards.md)
|
||||||
|
@ -1,12 +1,12 @@
|
|||||||
# Data Plane Fanout
|
# Turbine Block Propagation
|
||||||
|
|
||||||
A Solana cluster uses a multi-layer mechanism called *data plane fanout* to
|
A Solana cluster uses a multi-layer block propagation mechanism called *Turbine*
|
||||||
broadcast transaction blobs to all nodes in a very quick and efficient manner.
|
to broadcast transaction blobs to all nodes with minimal amount of duplicate
|
||||||
In order to establish the fanout, the cluster divides itself into small
|
messages. The cluster divides itself into small collections of nodes, called
|
||||||
collections of nodes, called *neighborhoods*. Each node is responsible for
|
*neighborhoods*. Each node is responsible for sharing any data it receives with
|
||||||
sharing any data it receives with the other nodes in its neighborhood, as well
|
the other nodes in its neighborhood, as well as propagating the data on to a
|
||||||
as propagating the data on to a small set of nodes in other neighborhoods.
|
small set of nodes in other neighborhoods. This way each node only has to
|
||||||
This way each node only has to communicate with a small number of nodes.
|
communicate with a small number of nodes.
|
||||||
|
|
||||||
During its slot, the leader node distributes blobs between the validator nodes
|
During its slot, the leader node distributes blobs between the validator nodes
|
||||||
in the first neighborhood (layer 0). Each validator shares its data within its
|
in the first neighborhood (layer 0). Each validator shares its data within its
|
||||||
@ -26,6 +26,14 @@ make up layer 0. These will automatically be the highest stake holders, allowing
|
|||||||
the heaviest votes to come back to the leader first. Layer-0 and lower-layer
|
the heaviest votes to come back to the leader first. Layer-0 and lower-layer
|
||||||
nodes use the same logic to find their neighbors and next layer peers.
|
nodes use the same logic to find their neighbors and next layer peers.
|
||||||
|
|
||||||
|
To reduce the possibility of attack vectors, each blob is transmitted over a
|
||||||
|
random tree of neighborhoods. Each node uses the same set of nodes representing
|
||||||
|
the cluster. A random tree is generated from the set for each blob using
|
||||||
|
randomness derived from the blob itself. Since the random seed is not known in
|
||||||
|
advance, attacks that try to eclipse neighborhoods from certain leaders or
|
||||||
|
blocks become very difficult, and should require almost complete control of the
|
||||||
|
stake in the cluster.
|
||||||
|
|
||||||
## Layer and Neighborhood Structure
|
## Layer and Neighborhood Structure
|
||||||
|
|
||||||
The current leader makes its initial broadcasts to at most `DATA_PLANE_FANOUT`
|
The current leader makes its initial broadcasts to at most `DATA_PLANE_FANOUT`
|
Reference in New Issue
Block a user