Update nep-0509.md

fix lint errors

neps/nep-0509.md

@@ -15,9 +15,10 @@ LastUpdated: 2023-09-19
 The NEP proposes an solution to achieve phase 2 of sharding (where none of the validators needs to track all shards), with stateless validation, instead of the traditionally proposed approach of fraud proof and state rollback.
 
 The fundamental idea is that validators do not need to have state locally to validate chunks. 
+
 * Under stateless validation, the responsibility of a chunk producer extends to packaging transactions and receipts and annotating them with state witnesses. This extended role will be called "chunk proposers".
 * The state witness of a chunk is defined to be a subset of the trie state, alongside its proof of inclusion in the trie, that is needed to execute a chunk. A state witness allows anyone to execute the chunk without having the state of its shard locally. 
-* * Then, at each block height, validators will be randomly assigned to a shard, to validate the state witness for that shard. Once a validator receives both a chunk and its state witness, it verifies the state transition of the chunk, signs a chunk endorsement and sends it to the block producer. This is similar to, but separate from, block approvals and consensus.
+* Then, at each block height, validators will be randomly assigned to a shard, to validate the state witness for that shard. Once a validator receives both a chunk and its state witness, it verifies the state transition of the chunk, signs a chunk endorsement and sends it to the block producer. This is similar to, but separate from, block approvals and consensus.
 * The block producer waits for sufficient chunk endorsements before including a chunk into the block it produces, or omits the chunk if not enough endorsements arrive in time.
 
 ## Motivation
@@ -31,12 +32,14 @@ As a result, the team sought alternative approaches and concluded that stateless
 ## Specification
 
 ### Assumptions
+
 * In memory trie is enabled - [REF](https://docs.google.com/document/d/1_X2z6CZbIsL68PiFvyrasjRdvKA_uucyIaDURziiH2U/edit?usp=sharing)
 * State sync is enabled (so that nodes can track different shards across epochs)
 * Merkle Patricia Trie continues to be the state trie implementation
 * TBD
 
 ### High level requirements
+
 * No validator needs to track all shards.
 * Security of protocol must not degrade.
   * Validator assignment for both chunk validation and block validation should not create any security vulnerabilities.
@@ -48,6 +51,7 @@ As a result, the team sought alternative approaches and concluded that stateless
 * TBD
 
 ### Out of scope
+
 * Data size optimizations such as compression, for both chunk data and state witnesses, except basic optimizations that are practically necessary.
 * Separation of consensus and execution, where consensus runs independently from execution, and validators asynchronously perform state transitions after the transactions are proposed on the consensus layer, for the purpose of amortizing the computation and network transfer time.
 * More shards - this is covered in the resharding project.
@@ -103,6 +107,7 @@ We also propose a change to the validator roles and responsibilities. This is th
 See the Validator Role Change section for more details.
 
 ## Chunk Validator Shuffling
+
 Chunk validators will be randomly assigned to validate shards, for each block (or as we may decide later, for multiple blocks in a row, if required for performance reasons). A chunk validator may be assigned multiple shards at once, if it has sufficient stake.
 
 Each chunk validator's stake is divided into "mandates". There are full and partial mandates. The amount of stake for a full mandate is a fixed parameter determined by the stake distribution of all validators, and any remaining amount smaller than a full mandate is a partial mandate. A chunk validator therefore has zero or more full mandates plus up to one partial mandate. The list of full mandates and the list of partial mandates are then separately shuffled and partitioned equally (as in, no more than one mandate in difference between any two shards) across the shards. Any mandate assigned to a shard means that the chunk validator who owns the mandate is assigned to validate that shard. Because a chunk validator may have multiple mandates, it may be assigned multiple shards to validate.
@@ -115,11 +120,11 @@ TODO: This is essentially going to be describing the exact structure of `ChunkSt
 
 [This technical section is required for Protocol proposals but optional for other categories. A draft implementation should demonstrate a minimal implementation that assists in understanding or implementing this proposal. Explain the design in sufficient detail that:
 
-- Its interaction with other features is clear.
-- Where possible, include a Minimum Viable Interface subsection expressing the required behavior and types in a target programming language. (ie. traits and structs for rust, interfaces and classes for javascript, function signatures and structs for c, etc.)
-- It is reasonably clear how the feature would be implemented.
-- Corner cases are dissected by example.
-- For protocol changes: A link to a draft PR on nearcore that shows how it can be integrated in the current code. It should at least solve the key technical challenges.
+* Its interaction with other features is clear.
+* Where possible, include a Minimum Viable Interface subsection expressing the required behavior and types in a target programming language. (ie. traits and structs for rust, interfaces and classes for javascript, function signatures and structs for c, etc.)
+* It is reasonably clear how the feature would be implemented.
+* Corner cases are dissected by example.
+* For protocol changes: A link to a draft PR on nearcore that shows how it can be integrated in the current code. It should at least solve the key technical challenges.
 
 The section should return to the examples given in the previous section, and explain more fully how the detailed proposal makes those examples work.]