nit

neps/nep-0509.md

@@ -70,22 +70,22 @@ The current high-level chunk production flow, if we drop details and edge cases,
 The "induction base" is at genesis height, where genesis block with default chunks is accessible to everyone, so chunk producers can start right away from genesis height + 1.
 
 One can observe that there is no "chunk validation" step here. 
-To simplify explanation, let's say that certain validator considers chunk C(S, H+1) valid iff **post state root** it computed by executing C(S, H) is the same as **pre state root** proposed in `ChunkHeader` field of C(S, H+1).
-BP(H+1), in fact, includes all received chunks in B(H+1). But what helps is that currently **block producers are required to track all shards**, which implies that all chunks are executed. 
-So, each block producer has **post state roots** for all C(S, H) and can check validity of every chunk in B(H+1).
+To simplify explanation, let's say that certain validator considers chunk C(S, H+1) valid iff **post state root** it computed by executing C(S, H) is the same as **pre state root** proposed in `ChunkHeader` `prev_state_root` field of C(S, H+1).
+BP(H+1), in fact, includes all received chunks in B(H+1), even invalid ones. But their rejection still will happen because currently **block producers are required to track all shards**, which implies that they execute all the chunks. 
+So, each block producer locally has **post state roots** for all C(S, H) and can check validity of every chunk in B(H+1).
 If some C(S, H+1) is invalid, the whole B(H+1) is ignored.
 
-As we can see, requirement for block producers to track all shards is crucial for the current design.
-However, to achieve phase 2 of sharding, we want to drop it. To achieve that, we introduce new role of a **chunk validator** and propose the following changes to the flow:
+As we can see, requirement for block producers to track all shards is **crucial** for the current design.
+To achieve phase 2 of sharding, we want to drop it. To achieve that, we introduce new role of a **chunk validator** and propose the following changes to the flow:
 
 * Chunk producer, in addition to producing a chunk, produces new `ChunkStateWitness` message.
   * The `ChunkStateWitness` contains data which is enough to prove validity of the chunk's header what is being produced:
     * As it is today, all fields of the `ShardChunkHeaderInnerV3`, except `tx_root`, are uniquely determined by the blockchain's history based on where the chunk is located (i.e. its parent block and shard ID).
     * The `tx_root` is based on the list of transactions proposed, which is at the discretion of the chunk producer. However, these transactions must be valid (i.e. the sender accounts have enough balance and the correct nonce, etc.).
     * This `ChunkStateWitness` proves to anyone, including those who track only block data and no shards, that this chunk header is correct, meaning that the uniquely determined fields are exactly what should be expected, and the discretionary `tx_root` field corresponds to a valid set of transactions.
   * The `ChunkStateWitness` is not part of the chunk itself; it is distributed separately and is considered transient data.
-* The chunk producer then distributes the `ChunkStateWitness` to a subset of **chunk validators** assigned for this shard. This is in addition to, and independent of, the existing chunk distribution logic (implemented by `ShardsManager`) today.
-  * Chunk Validator selection and assignment is described below.
+* The chunk producer distributes the `ChunkStateWitness` to a subset of **chunk validators** assigned for this shard. This is in addition to, and independent of, the existing chunk distribution logic (implemented by `ShardsManager`) today.
+  * Chunk Validator selection and assignment are described below.
 * A chunk validator, upon receiving a `ChunkStateWitness`, validates the state witness and determines if the chunk header is indeed correctly produced. If so, it sends a `ChunkEndorsement` to the current block producer.
   * A `ChunkEndorsement` contains the chunk hash along with a signature proving the endorsement by the chunk validator. It implicitly carries a weight equal to the amount of the chunk validator's stake that is assigned to this shard for this block. (See Chunk Validator Shuffling).
 * As the existing logic is today, the block producer for this block waits until either all chunks are ready, or a timeout occurs, and then proposes a block containing whatever chunks are ready. Now, the notion of readiness here is expanded to also having more than 2/3 of chunk endorsements by weight.