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

feat(spec): Fork or Reset Protocol for Starknet #170

Closed
wants to merge 1 commit into from

Conversation

cason
Copy link
Contributor

@cason cason commented Mar 8, 2024

Related to #166.

Fork Protocol

Depends on #168. Needs to merged after #168 is merged.


PR author checklist

@cason cason changed the title feat(spec): Fork Protocol in Starknet feat(spec): Fork or Reset Protocol for Starknet Mar 8, 2024
@cason cason added phase2 spec Related to specifications labels Mar 8, 2024
- The validator set for the fork is the last validator set accepted by L1
plus all the "stale registrations", i.e., validator set updates produced by
L1 but not included in Starknet blocks (L2) in due time.
- This is not enough precise yet, for instance, how the validator set
Copy link
Member

Choose a reason for hiding this comment

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

I agree that this point seems a bit unclear.

  • If there is a missed deadline, then the deadline was missed (I assume) mostly by the validators that are in this validator set. So why is there trust that the first validator set of the fork is "better" than the last old one. So the question is what scenarios are solved by this?
  • Wouldn't it make sense to have a more explicit reset protocol on L1: if a deadline is missed, we mark the L2 as stale -> after that a new validator set needs to be set up -> we commit the new validator set on L1 and start the new L2.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

we commit the new validator set on L1

How would we do that?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

So why is there trust that the first validator set of the fork is "better" than the last old one. So the question is what scenarios are solved by this?

The assumption here is that new validators are more trustworthy than the existing ones. The existing ones are probably maintained in the new validator set, but with lower voting power (they call this "dilution").

I think the assumption here is that most of the existing validator set is good, but the <1/3 assumption was broken by a "small amount" of voting power. In this case, adding new "good" validators would make the <1/3 assumption to hold again.

@josef-widder
Copy link
Member

I have copied the information that was only here to #171. So I close this.

ancazamfir added a commit that referenced this pull request Apr 29, 2024
* draft of system overview

* more details

* fix

* a final question for this week

* more questions

* more questions

* the question from slack

* last update before meeting

* typos

* notes from meeting

* Update specs/english/overview.md

Co-authored-by: Daniel <daniel.cason@informal.systems>

* Update specs/english/overview.md

Co-authored-by: Daniel <daniel.cason@informal.systems>

* re-orged english spec folder to accomodate new spec

* cleaned up overview

* added missing information from #170

* spell

* English spec

* ready for review

* Update specs/english/forced-updates/README.md

Co-authored-by: Anca Zamfir <ancazamfir@users.noreply.github.com>

* Update specs/english/forced-updates/README.md

Co-authored-by: Anca Zamfir <ancazamfir@users.noreply.github.com>

* Update specs/english/forced-updates/README.md

Co-authored-by: Anca Zamfir <ancazamfir@users.noreply.github.com>

* Update specs/english/forced-updates/README.md

Co-authored-by: Anca Zamfir <ancazamfir@users.noreply.github.com>

* Update specs/english/forced-updates/README.md

Co-authored-by: Anca Zamfir <ancazamfir@users.noreply.github.com>

* Update specs/english/forced-updates/README.md

Co-authored-by: Anca Zamfir <ancazamfir@users.noreply.github.com>

* Update specs/english/forced-updates/README.md

Co-authored-by: Anca Zamfir <ancazamfir@users.noreply.github.com>

* Update specs/english/forced-updates/README.md

Co-authored-by: Anca Zamfir <ancazamfir@users.noreply.github.com>

* Update specs/english/forced-updates/README.md

Co-authored-by: Anca Zamfir <ancazamfir@users.noreply.github.com>

* Update specs/english/forced-updates/README.md

Co-authored-by: Anca Zamfir <ancazamfir@users.noreply.github.com>

* Update specs/english/forced-updates/README.md

Co-authored-by: Anca Zamfir <ancazamfir@users.noreply.github.com>

* Update specs/english/forced-updates/README.md

Co-authored-by: Anca Zamfir <ancazamfir@users.noreply.github.com>

* working on Anca's comments

* added TODOs so that we can merge

---------

Co-authored-by: Daniel <daniel.cason@informal.systems>
Co-authored-by: Anca Zamfir <ancazamfir@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
spec Related to specifications
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants