From c1e72ea76741e1839a45965889de17b5eff6dbf4 Mon Sep 17 00:00:00 2001 From: Jasmina Malicevic Date: Thu, 2 Jun 2022 16:30:59 +0200 Subject: [PATCH] Minor spelling corrections --- spec/blocksync/communication.md | 2 +- spec/blocksync/verification.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/spec/blocksync/communication.md b/spec/blocksync/communication.md index 9c2c8f40c..c3c8d3e1a 100644 --- a/spec/blocksync/communication.md +++ b/spec/blocksync/communication.md @@ -12,7 +12,7 @@ On startup, the reactor fires up four go routines: 3. Handle p2p channel messages 4. Process peer updates -The pool routine picks out blocks form the block pool and processes them. It also checks whether the node should switch to consensus. ToDo - change wording (Remove we, discuss whether the pool routing should be the one checking the condition for consensus). +The pool routine picks out blocks form the block pool and processes them. It also checks whether the node should switch to consensus. All messages that go through the p2p channel are processed within the `processBlockSyncCh` routine. diff --git a/spec/blocksync/verification.md b/spec/blocksync/verification.md index 0b3a1741d..6ee65f453 100644 --- a/spec/blocksync/verification.md +++ b/spec/blocksync/verification.md @@ -21,7 +21,7 @@ Currently there are two possible ways to obtain a trusted state : **Case 1 - blocksync from genesis** -In this case we only verify that the validator hash of the block matches the validator set of the initial state. We will use the initially provided validator set for verification and further verify the block against witnesses. In this scenario, this state is very likely to be outside the trusting period. We will accept this block as a trusted state and store it inside the node's block store. +In this case we only verify that the validator hash of the block matches the validator set of the initial state. We will use the initially provided validator set for verification and further verify the block against witne+sses. In this scenario, this state is very likely to be outside the trusting period. We will accept this block as a trusted state and store it inside the node's block store. It is worth noting that, running block sync from the first height is significantly slower than running statesync first. However, statesync does not keep the entire blockchain history and some operators might opt not to state sync. The reason is that, if sufficiently many nodes state sync and other nodes who have historical data fail or leave the network, we have no history.