Create nep-0509.md

initial draft

neps/nep-0509.md

@@ -0,0 +1,121 @@
+---
+NEP: 509
+Title: Stateless validation stage 0
+Authors: Robin Cheng, Anton Puhach, Alex Logunov, Yoon Hong
+Status: Draft
+DiscussionsTo: [Stateless validation - stage 0](https://docs.google.com/document/d/1C-w4FNeXl8ZMd_Z_YxOf30XA1JM6eMDp5Nf3N-zzNWU/edit?usp=sharing), [Stateless validation roadmap](https://docs.google.com/document/d/1TzMENFGYjwc2g5A3Yf4zilvBwuYJufsUQJwRjXGb9Xc/edit?usp=sharing)
+Type: Protocol
+Version: 1.0.0
+Created: 2023-09-19
+LastUpdated: 2023-09-19
+---
+
+## Summary
+
+The NEP proposes an solution to achieve phase 2 of sharding (where none of the validators needs to track all shards), with stateless validation while not relying of the traditional 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, responsibility of a chunk producer extends to package transactions and receipts and annotate them with state witnesses (we will call them with the new role name, chunk proposers).
+* State witness of a chunk is defined to be the state alongside proof of inclusion that is needed to execute a chunk. State witness allows anyone to execute a chunk without having the state of a shard locally. 
+* Then, validators will not store state locally and be randomly assigned to a shard at a given block height. Once a validator receives a chunk, along with its state witnesses, it verifies the state transition of the chunk, signs an approval, and sends it to the next block producer, similar to how it works today.
+
+## Motivation
+
+As phase 1 of sharding requires block producers to track all shards due to underlying security concerns, the team explored potential ways to achieve phase 2 of sharding, where none of the validators has to track all shards.
+
+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.
+
+## Specification
+
+### Assumptions
+
+### High level requirements
+
+### Out of scope
+
+### 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.]
+
+## 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:
+
+- 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.]
+
+## 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.]
+
+## Alternatives
+
+[Explain any alternative designs that were considered and the rationale for not choosing them. Why your design is superior?]
+
+## Future possibilities
+
+[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.]
+
+### Positive
+
+- p1
+
+### Neutral
+
+- n1
+
+### Negative
+
+- n1
+
+### Backwards Compatibility
+
+[All NEPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. Author must explain a proposes to deal with these incompatibilities. Submissions without a sufficient backwards compatibility treatise may be rejected outright.]
+
+## Unresolved Issues (Optional)
+
+[Explain any issues that warrant further discussion. Considerations
+
+- What parts of the design do you expect to resolve through the NEP process before this gets merged?
+- What parts of the design do you expect to resolve through the implementation of this feature before stabilization?
+- What related issues do you consider out of scope for this NEP that could be addressed in the future independently of the solution that comes out of this NEP?]
+
+## Changelog
+
+[The changelog section provides historical context for how the NEP developed over time. Initial NEP submission should start with version 1.0.0, and all subsequent NEP extensions must follow [Semantic Versioning](https://semver.org/). Every version should have the benefits and concerns raised during the review. The author does not need to fill out this section for the initial draft. Instead, the assigned reviewers (Subject Matter Experts) should create the first version during the first technical review. After the final public call, the author should then finalize the last version of the decision context.]
+
+### 1.0.0 - Initial Version
+
+> Placeholder for the context about when and who approved this NEP version.
+
+#### Benefits
+
+> List of benefits filled by the Subject Matter Experts while reviewing this version:
+
+- Benefit 1
+- Benefit 2
+
+#### Concerns
+
+> Template for Subject Matter Experts review for this version:
+> Status: New | Ongoing | Resolved
+
+|   # | Concern | Resolution | Status |
+| --: | :------ | :--------- | -----: |
+|   1 |         |            |        |
+|   2 |         |            |        |
+
+## Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).