mirrors/tendermint
1
0
Fork 0
mirror of https://github.com/tendermint/tendermint.git synced 2026-08-19 05:36:15 +00:00
Code Issues Packages Projects Releases Wiki Activity

fixed links

Browse Source
This commit is contained in:
Jasmina Malicevic
2022-05-19 17:14:41 +02:00
parent 76e43df120
commit a56ba48876
3 changed files with 3 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
spec/blocksync/communication.md
+1 -1
View File
@@ -67,6 +67,6 @@ If the checks pass, the `block` field of the requester is populated with the new
`errorsCh chan peerError` : size `maxPeerErrBuffer`
`didProcessCh chan struct{}` : size `1`.
The channel is created within the pool routine of the reactor and is used to signal that the reactor should check the block pool for new blocks. A message is sent to the channel after a fixed timeout (`trySyncTicker`). As we need two blocks to verify one of them (this is more clearly defined in [verification](#./verification.md), if we miss only on of them, we will not wait for the sync timer to time out, but rather try quickly again until we fetch both.
The channel is created within the pool routine of the reactor and is used to signal that the reactor should check the block pool for new blocks. A message is sent to the channel after a fixed timeout (`trySyncTicker`). As we need two blocks to verify one of them (this is more clearly defined in [verification](./verification.md), if we miss only on of them, we will not wait for the sync timer to time out, but rather try quickly again until we fetch both.
`switchToConsensusTicker`. In addition to the sync timeout, in the same routine, the reactor checks periodically whether the conditions to switch to consensus are fullfilled.
spec/blocksync/readme.md
+1 -1
View File
@@ -54,7 +54,7 @@ The Blocksync reactor is organised as a set of concurrent tasks:
This section describes the Blocksync reactor and its internals including:
- [Data structures used](./data_structures.md)
- [Peer to peer communication pattern](./communication.md)
- [Block Verification](./block_verification.md)
- [Block Verification](./verification.md)
More details on how to use the Blocksync reactor and configure it when running Tendermint can be found [here](./../docs/tendermint-core/block-sync/README.md).
spec/blocksync/verificaton.md
+1 -1
View File
@@ -3,7 +3,7 @@
When blocksyncing, a node is not participating in conensus. It is receiving blocks that have already been decided and committed. To avoid being fooled by malicious peers, the node has to verify the received blocks before executing the transactions and storing the block in its store.
The verification in blocksync aims to apply the same logic as the [light client verification](#../light-client/verification.md). The model relies on the existence of an **initial trusted state**.
The verification in blocksync aims to apply the same logic as the [light client verification](../light-client/verification.md). The model relies on the existence of an **initial trusted state**.
Based on this state we verify subsequent blocks.