Update nep-0509.md

Add specifications

neps/nep-0509.md

@@ -25,15 +25,38 @@ As phase 1 of sharding requires block producers to track all shards due to under
 
 Initial design of phase 2 relied on the security assumption that as long as there is one honest validator or fisherman tracking a shard, the shard is secure; by doing so, it naturally relied on protocol's ability to challenge (when an honest validator or fisherman detects a malicious behavior), rollback (when validators agree that the submitted challenge is valid), slashing (to punish the malicious validator), and rewarding (for chllenger). While it sounds straigtforward and simple on paper, the detailed implication and implementation of these features turned out to be extremely complicated.
 
-As a result, the team sought alternative approach and concluded that stateless validation is the most realistic and promising approach among candidates; the stateless validation approach does not assume the existence of fishermen and assumes that a shard is secure if every single chunk in that shard is validated by a randomly sampled subset of all validators.
+As a result, the team sought alternative approach and concluded that stateless validation is the most realistic and promising one; stateless validation approach does not assume the existence of fishermen and assumes that a shard is secure if every single chunk in that shard is validated by a randomly sampled subset of all validators.
 
 ## Specification
 
 ### Assumptions
+* Post state root is enabled - [NEP-507](https://github.com/near/NEPs/pull/507)
+* In memory trie is enabled - [REF](https://docs.google.com/document/d/1_X2z6CZbIsL68PiFvyrasjRdvKA_uucyIaDURziiH2U/edit?usp=sharing)
+* State sync is enabled
+* Merkle Patricia Trie is underlying data structure
+* TBD
 
 ### High level requirements
+* Block processing time should not take more than what it takes today.
+* Additional load on network and node should not affect other functionalities.
+* Security of protocol must not degrade.
+  * Validator assignment for both chunk validation and block validation should not create any security vulnerability.
+* Validators should be rewarded with the same amount as they are now.
+* No validator needs to track all shards.
+* Only chunk producers need to maintain state locally.
+* State witness size should be small enough to delivered over network.
+* Majority of undercharging issues should be mitigated.
+* [TBD] Resharding should work as expected after stateless validation in place.
+* TBD
 
 ### Out of scope
+* Data compression of both chunk data and state witness
+* Separation of consensus and execution: we can run consensus independently from execution and let chunk producers to provide state witnesses to validators once every X blocks. This helps reduce both the amortized size of state witness and pressure on the p2p network. Validators send attestations to the state witness they receive and attestations are aggregated onchain as a finality gadget for state.
+* More shards
+* ZK integration
+* Underlying data structure change (e.g. verkle tree)
+* Validator structure change (e.g. block only producer, Infertile validator (validator which does not produce any chunk or block))
+* TBD
 
 ### High level flow