-
Notifications
You must be signed in to change notification settings - Fork 0
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
[ProjectTracking]: Stateless validation MVP #5
Labels
Comments
|
12/18 status update
|
Jan 16th Status update
|
Feb 2nd update:
If there are no major issues with StatelessNet, I anticipate this to be closed as completed soon and we switch to #46. |
January update from myself:
|
2024 January update from myself:
|
Stateless was running for a week with some simple loadtesting. Closing as completed. |
github-project-automation
bot
moved this from In Progress
to Done
in Near One project tracking
Feb 7, 2024
This was referenced Feb 7, 2024
52 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Goals
Horizontally scalable blockchain is what makes NEAR unique in the field. Currently, we have phase 1 of sharding in mainnet which is not a true form of sharding. With recent collaboration with various partners such as SWEAT and Kaiching, NEAR protocol has seen massive increase in daily txn volume and expect the number to grow beyond our current capacity in 2024. This naturally brings criticality of introducing the next phase of sharding in mainnet, so we can keep up with our growth.
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 one; 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.
The fundamental idea is that validators do not need to have state locally to validate chunks.
Links to external documentations and discussions
Estimated effort
The project started with three engineers, Alex, Anton, and Robin, and we plan to onboard more engineers. For now, the newly boarded engineers won't work on MVP, but building foundation for the next step.
We target all the necessary components to be landed by
end of 2023early January, and connect the dots together and complete MVP in mid January for a demo-able MVP.Assumptions
Tasks
Major tasks (for MVP)
The text was updated successfully, but these errors were encountered: