-
Notifications
You must be signed in to change notification settings - Fork 222
implement logic to build genesis state for the sequencer #2371
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
Conversation
wip - fix test fix stuff
fb11e07 to
459db5d
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2371 +/- ##
==========================================
- Coverage 75.29% 75.11% -0.18%
==========================================
Files 140 141 +1
Lines 16848 17186 +338
==========================================
+ Hits 12686 12910 +224
- Misses 3336 3416 +80
- Partials 826 860 +34 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
AnkushinDaniil
left a comment
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 have finished reviewing everything except vm logic. Everything is good, just small changes and questions. I'll continue reviewing vm logic.
|
Even though the PR is approved, I'm adding the |
|
Relevant blockifier PR #2397 |
rodrodros
left a comment
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.
Just putting a blocking comment here to make sure it doesn't get merged by accident during this release process.
I would also like to give a final review before moving ahead with the PR.
|
Failing test fixed by #2645 |
This PR implements the
genesispkg that builds astate difffrom declaring classes, deploying contracts and invoking functions. The sequencer can then commit thisstate diffto state, so that upon startup, a set of account contracts have already been deployed and funded (it is not possible to achieve this from an empty state by submitting transactions, since Starknet requires accounts to be funded to perform any actions on the state - originally this wasn't a requirement in Starknet). This is particularly useful as it allows users to start the sequencer with any number of accounts pre-deployed, and pre-funded, etc, and opens up the possibility of using Juno as a devnetIn essence: