Skip to content
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

Merged
merged 2 commits into from
Jan 26, 2024

Conversation

robin-near
Copy link
Contributor

No description provided.

@robin-near robin-near requested a review from a team as a code owner January 11, 2024 17:45
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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* 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

Copy link
Contributor

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)

Copy link
Contributor Author

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* 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

Copy link
Contributor

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?

Copy link
Contributor Author

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.
Copy link
Member

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

Copy link
Contributor

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.

Copy link
Contributor Author

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.

neps/nep-0509.md Show resolved Hide resolved
neps/nep-0509.md Outdated Show resolved Hide resolved
neps/nep-0509.md Outdated Show resolved Hide resolved
neps/nep-0509.md Outdated Show resolved Hide resolved
@walnut-the-cat
Copy link
Contributor

@robin-near, let's try to merge this in by Wednesday.

@walnut-the-cat walnut-the-cat merged commit 5627ced into state-validation Jan 26, 2024
1 check passed
@walnut-the-cat walnut-the-cat deleted the state-validation-2 branch January 26, 2024 15:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: APPROVED FIXES
Development

Successfully merging this pull request may close these issues.

4 participants