Update nep-0508.md

Additional changes

neps/nep-0508.md

@@ -25,13 +25,15 @@ Currently, NEAR protocol has four shards. With more partners onboarding, we star
 ## Specification
 
 ### High level assumptions
+
 * Some form of State sync (centralized or decentralized) is enabled.
 * Flat state is enabled.
 * Shard split boundary is predetermined. In other words, necessity of shard splitting is manually decided.
 * Merkle Patricia Trie is undelying data structure for the protocol.
 * Minimal epoch gap between two resharding events is X.
 
 ### High level requirements
+
 * Resharding should work even when validators stop tracking all shards.
 * Resharding should work after stateless validation is enabled.
 * Resharding should be fast enough so that both state sync and resharding can happen within one epoch.
@@ -42,6 +44,12 @@ Currently, NEAR protocol has four shards. With more partners onboarding, we star
 * No transaction or receipt should be lost during resharding.
 * Resharding should work regardless of number of existing shards.
 
+### Out of scope
+
+* Dynamic resharding
+* Shard determination logic (shard boundary is still determined by string value)
+* TBD
+
 ### Required protocol changes
 
 TBD. e.g. configuration changes we have to introduce
@@ -64,7 +72,12 @@ TBD
 
 ## Alternatives
 
-[Explain any alternative designs that were considered and the rationale for not choosing them. Why your design is superior?]
+* Why is this design the best in the space of possible designs?
+  * TBD
+* What other designs have been considered and what is the rationale for not choosing them?
+  * TBD
+* What is the impact of not doing this?
+  * TBD
 
 ## Future possibilities
 
@@ -78,19 +91,23 @@ Other useful features that can be considered as a follow up:
 
 ## Consequences
 
-[This section describes the consequences, after applying the decision. All consequences should be summarized here, not just the "positive" ones. Record any concerns raised throughout the NEP discussion.]
-
 ### Positive
 
-- p1
+* Workload across shards will be more evenly distributed.
+* Required space to maintain state (either in memory or in persistent disk) will be smaller.
+* State sync overhead will be smaller.
+* TBD
 
 ### Neutral
 
-- n1
+* Number of shards is expected to increase.
+* Underlying trie structure and data structure are not going to change.
+* Resharding will create dependency on flat storage and state sync.
 
 ### Negative
 
-- n1
+* The resharding process is still not fully automated. Analyzing shard data, determining the split boundary, and triggering an actual shard split all need to be manually curated by a person.
+* During resharding, a node is expected to do more work as it will have to apply changes twice (for the current shard and future shard).
 
 ### Backwards Compatibility