specification

neps/nep-0568.md

@@ -36,6 +36,56 @@ updates.
 
 [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.]
 
+
+Resharding will be scheduled in advance by the NEAR developer team. The new
+shard layout will be hardcoded into the neard binary and linked to the protocol
+version. As the protocol upgrade progresses, resharding will be triggered during
+the post-processing phase of the last block of the epoch. At this point, the
+state of the parent shard will be split between two child shards. From the first
+block of the new protocol version onward, the chain will operate with the new
+shard layout.
+
+There are two key dimensions to consider: state storage and protocol features,
+along with a few additional details.
+
+1) State Storage: Currently, the state of a shard is stored in three distinct
+formats: the state, the flat state, and the mem-trie. Each of these
+representations must be resharded. Logically, resharding is an almost
+instantaneous event that occurs before the first block under the new shard
+layout. However, in practice, some of this work may be deferred to
+post-processing, as long as the chain's view reflects a fully resharded state.
+
+1) Protocol Features: Several protocol features must integrate smoothly with the
+  resharding process, including:
+* Stateless Validation: Resharding must be validated and proven through
+  stateless validation mechanisms.
+* State Sync: Nodes must be able to sync the states of the child
+  shards post-resharding.
+* Cross-Shard Traffic: Receipts sent to the parent shard may need to be
+  reassigned to one of the child shards.
+* Receipt Handling: Delayed, postponed, buffered, and promise-yield receipts
+  must be correctly distributed between the child shards.
+* ShardId Semantics: The shard identifiers will become abstract identifiers
+  where today they are number in the 0..num_shards range.
+
+### State Storage - Mem Trie
+
+### State Storage - Flat State
+
+### State Storage - State
+
+### Stateless Validation
+
+### State Sync
+
+### Cross Shard Traffic
+
+### Receipt Handling - Delayed, Postponed, PromiseYield
+
+### Receipt Handling - Buffered
+
+### ShardId Semantics
+
 ## Reference Implementation
 
 [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:
@@ -60,6 +110,8 @@ The section should return to the examples given in the previous section, and exp
 
 [Describe any natural extensions and evolutions to the NEP proposal, and how they would impact the project. Use this section as a tool to help fully consider all possible interactions with the project in your proposal. This is also a good place to "dump ideas"; if they are out of scope for the NEP but otherwise related. Note that having something written down in the future-possibilities section is not a reason to accept the current or a future NEP. Such notes should be in the section on motivation or rationale in this or subsequent NEPs. The section merely provides additional information.]
 
+
+
 ## 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.]