mirror of
https://github.com/tendermint/tendermint.git
synced 2026-01-06 21:36:26 +00:00
This commit should be one of the first to land as part of the v0.36 cycle *after* cutting the 0.35 branch. The blocksync/v2 reactor was originally implemented as an experiement to produce an implementation of the blockstack protocol that would be easier to test and validate, but it was never appropriately operationalized and this implementation was never fully debugged. When the p2p layer was refactored as part of the 0.35 cycle, the v2 implementation was not refactored and it was left in the codebase but not removed. This commit just removes all references to it.
32 lines
1.6 KiB
Go
32 lines
1.6 KiB
Go
/*
|
|
Package blocksync implements two versions of a reactor Service that are
|
|
responsible for block propagation and gossip between peers. This mechanism was
|
|
formerly known as fast-sync.
|
|
|
|
In order for a full node to successfully participate in consensus, it must have
|
|
the latest view of state. The blocksync protocol is a mechanism in which peers
|
|
may exchange and gossip entire blocks with one another, in a request/response
|
|
type model, until they've successfully synced to the latest head block. Once
|
|
succussfully synced, the full node can switch to an active role in consensus and
|
|
will no longer blocksync and thus no longer run the blocksync process.
|
|
|
|
Note, the blocksync reactor Service gossips entire block and relevant data such
|
|
that each receiving peer may construct the entire view of the blocksync state.
|
|
|
|
There is currently only one version of the blocksync reactor Service
|
|
that is battle-tested, but whose test coverage is lacking and is not
|
|
formally verified.
|
|
|
|
The v0 blocksync reactor Service has one p2p channel, BlockchainChannel. This
|
|
channel is responsible for handling messages that both request blocks and respond
|
|
to block requests from peers. For every block request from a peer, the reactor
|
|
will execute respondToPeer which will fetch the block from the node's state store
|
|
and respond to the peer. For every block response, the node will add the block
|
|
to its pool via AddBlock.
|
|
|
|
Internally, v0 runs a poolRoutine that constantly checks for what blocks it needs
|
|
and requests them. The poolRoutine is also responsible for taking blocks from the
|
|
pool, saving and executing each block.
|
|
*/
|
|
package blocksync
|