-
Notifications
You must be signed in to change notification settings - Fork 142
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Revise the summary and motivation, add high level flow. #527
Conversation
neps/nep-0509.md
Outdated
* 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. | ||
* Under stateless validation, the responsibility of a chunk producer extends to packaging transactions and receipts and annotating them with state witnesses. This extended role will be called "chunk proposers". | ||
* The state witness of a chunk is defined to be a subset of the trie state, alongside its proof of inclusion in the trie, that is needed to execute a chunk. A state witness allows anyone to execute the chunk without having the state of its shard locally. | ||
* Then, at each block height, validators will be randomly assigned to a shard, to validate the state witness for that shard. Once a validator receives a chunk along with its state witness, it verifies the state transition of the chunk, signs a chunk endorsement and sends it to the block producer. This is similar to, but separate from, block approvals and consensus. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* Then, at each block height, validators will be randomly assigned to a shard, to validate the state witness for that shard. Once a validator receives a chunk along with its state witness, it verifies the state transition of the chunk, signs a chunk endorsement and sends it to the block producer. This is similar to, but separate from, block approvals and consensus. | |
* Then, at each block height, validators will be randomly assigned to a shard, to validate the state witness for that shard. Once a validator receives both a chunk and its state witness, it verifies the state transition of the chunk, signs a chunk endorsement and sends it to the block producer. This is similar to, but separate from, block approvals and consensus. |
Technically this is the case currently
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
at each block height, validators will be randomly assigned to a shard
Is this true? I understand this is possible, but is this what we want to do? Wonder if it's better to leave the option open (e.g. mentioning possibility of assigning validators at every N height)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The NEP is titled Stateless Validation Stage 0, and we don't currently have a plan to do every N (not clear there's a real benefit yet), so I think we may as well just be concrete about what exactly we're doing?
neps/nep-0509.md
Outdated
* Under stateless validation, the responsibility of a chunk producer extends to packaging transactions and receipts and annotating them with state witnesses. This extended role will be called "chunk proposers". | ||
* The state witness of a chunk is defined to be a subset of the trie state, alongside its proof of inclusion in the trie, that is needed to execute a chunk. A state witness allows anyone to execute the chunk without having the state of its shard locally. | ||
* Then, at each block height, validators will be randomly assigned to a shard, to validate the state witness for that shard. Once a validator receives a chunk along with its state witness, it verifies the state transition of the chunk, signs a chunk endorsement and sends it to the block producer. This is similar to, but separate from, block approvals and consensus. | ||
* The block producer waits for sufficient chunk endorsements before including a chunk into the block it produces. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* The block producer waits for sufficient chunk endorsements before including a chunk into the block it produces. | |
* The block producer waits for sufficient chunk endorsements before including a chunk into the block it produces and doesn't include a chunk if it is not endorsed enough. |
nit
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we mention what 'sufficient' really means? 2/3?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah that's in the specification section. I wanted to keep the summary section high-level.
* Validator roles are updated accordingly to reflect the necessary changes with stateless validation. | ||
* [TBD] Resharding should work as expected after stateless validation in place. | ||
* Security of protocol must not degrade. | ||
* Validator assignment for both chunk validation and block validation should not create any security vulnerabilities. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the old point "Moreover, majority of undercharging issues should be mitigated." deserves a point here. Because it is not tracking all shards what allows in-memory trie to be used
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any reason we are removing the following statement?
Only chunk producers need to maintain state locally.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These are mostly technicalities :)
I removed the undercharging point because it's not a "high level requirement". It's more of a good-to-have side effect. It's not a requirement for stateless validation to solve "a majority of undercharging issues" (which isn't even well defined).
For "only chunk producers need to maintain state locally", I also don't think this is a requirement. Even if everybody is required to track some state (and it's not all the state because there is already a point saying no validators needs to track all shards), stateless validation is still successful. If we're talking about the desire that chunk validators who don't also act as chunk producers do not need to track any shard at all, I think the motivation there is that they don't need to have beefy machines to track any state, but that is also covered by the point "Any additional load on network and compute should not negatively affect existing functionalities of any node in the blockchain", and that the cost of these should be acceptable. Also, "only chunk producers need to maintain state locally" seems to be a particular solution rather than a requirement, as we're also changing the definition of chunk producers.
@robin-near, let's try to merge this in by Wednesday. |
No description provided.