Update nep-0509.md

Add validator role change section

neps/nep-0509.md

@@ -30,7 +30,6 @@ As a result, the team sought alternative approach and concluded that stateless v
 ## 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
@@ -46,6 +45,7 @@ As a result, the team sought alternative approach and concluded that stateless v
 * 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.
+* Validator roles are updated accordingly to reflect the necessary changes with stateless validation.
 * [TBD] Resharding should work as expected after stateless validation in place.
 * TBD
 
@@ -55,10 +55,10 @@ As a result, the team sought alternative approach and concluded that stateless v
 * 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))
+* Validator reward change
 * TBD
 
-### High level flow
+## High level flow
 
 TBD. [Explain the proposal as if you were teaching it to another developer. This generally means describing the syntax and semantics, naming new concepts, and providing clear examples. The specification needs to include sufficient detail to allow interoperable implementations getting built by following only the provided specification. In cases where it is infeasible to specify all implementation details upfront, broadly describe what they are.]
 
@@ -74,6 +74,39 @@ TBD. [Explain the proposal as if you were teaching it to another developer. This
 
 The section should return to the examples given in the previous section, and explain more fully how the detailed proposal makes those examples work.]
 
+## Validatior role change
+Currently, there are two different types of validators and their responsibilities are as follows:
+|  | Top ~50% validators | Remaining validatiors (Chunk only producers) |
+|-----|:-----:|:----:|
+| block production | Y | N |
+| chunk production | Y | Y |
+| block validation | Y | N |
+
+With stateless validation, this structure does not make sense anymore for several reasons:
+* Chunk production is the most resource consuming activity.
+* (Only) chunk production needs state in memory while other responsibilities can be completed via acquiring state witness
+* Chunk production does not have to be performed by all validators. 
+
+Hence, the most simple proposal is to change Chunk-only producers to Chunk-only validators as follows:
+| | Top ~50% validators | Remaining validatiors (Chunk-only validators) |
+|-----|:-----:|:----:|
+| block production | Y | N |
+| chunk production | Y | N |
+| block validation | Y | N |
+| chunk validation | Y | Y |
+
+Block production and validation remain as responsibility of validators with more stake to maintain the same level of security.
+
+This approach is the most straight forward as it maintains the same grouping as we have today.
+
+Potential improvement to which can lower hardware requirement for more validators is limiting the responsibility of chunk production to top N validators, who are often equipped with powerful machines already.
+|  | Top N validatiors (Chunk proposers) | Top ~50% - N validators | Remaining validators (Chunk-only validators) |
+|-----|:-----:|:----:|:----:|
+| block production | Y | Y | N |
+| chunk production | Y | N | N |
+| block validation | Y | Y | N |
+| chunk validation | Y | Y | N |
+
 ## Security Implications
 
 [Explicitly outline any security concerns in relation to the NEP, and potential ways to resolve or mitigate them. At the very least, well-known relevant threats must be covered, e.g. person-in-the-middle, double-spend, XSS, CSRF, etc.]