implement logic to build genesis state for the sequencer

[rianhughes]

This PR implements the genesis pkg that builds a state diff from declaring classes, deploying contracts and invoking functions. The sequencer can then commit this state diff to 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 devnet

In essence:

1. we load classes, then declare them,
2. execute the constructor functions using the vm, which writes the changes to the pending state
3. execute any functions of interest (eg token transfers) using the vm (where similarly the vm writes the changes to the pending state)
4. extract the state-diff and new classes from the pending state.

[codecov]

Codecov Report

Attention: Patch coverage is 68.35443% with 100 lines in your changes missing coverage. Please review.

Project coverage is 75.08%. Comparing base (19cf1c4) to head (9b7d54c).

Files with missing lines	Patch %	Lines
genesis/genesis.go	65.53%	42 Missing and 19 partials ⚠️
sync/pending.go	60.37%	19 Missing and 2 partials ⚠️
adapters/vm2core/vm2core.go	73.17%	8 Missing and 3 partials ⚠️
core/state_update.go	85.36%	5 Missing and 1 partial ⚠️
node/throttled_vm.go	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2371      +/-   ##
==========================================
- Coverage   75.20%   75.08%   -0.13%     
==========================================
  Files         140      141       +1     
  Lines       16862    17174     +312     
==========================================
+ Hits        12681    12895     +214     
- Misses       3353     3426      +73     
- Partials      828      853      +25     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[AnkushinDaniil]

I have finished reviewing everything except vm logic. Everything is good, just small changes and questions. I'll continue reviewing vm logic.

[cicr99]

Even though the PR is approved, I'm adding the blocked label up until all the changes regarding the new blockifier release are finished. This takes priority and will probably cause conflicts with the changes done to the vm pkg in this PR.

[rianhughes]

Relevant blockifier PR #2397

[rodrigo-pino]

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.

[weiihann]

I don't think this is a good design. The issues are:

• Runtime Type Checking: The code relies on runtime type assertions (context.state.(StateReadWriter)) which can panic if the assertion fails.
• Implicit Behavior: The code's behavior changes based on whether the state implements write methods, but this isn't immediately obvious from function signatures.

I'd suggest changing state core.StateReader to an interface defined directly in the vm package. It's usually a good practice to define interfaces in the consumer package (in this case, vm) rather than the implementor package (in this case, core).

so something like:

package vm

type State interface {
	StateReader
	StateWriter
}

type StateReader interface {
	ContractClassHash(addr *felt.Felt) (*felt.Felt, error)
	ContractNonce(addr *felt.Felt) (*felt.Felt, error)
	ContractStorage(addr, key *felt.Felt) (*felt.Felt, error)
	Class(classHash *felt.Felt) (*DeclaredClass, error)
}

type StateWriter interface {
	SetStorage(contractAddress, storageKey, value *felt.Felt) error
	IncrementNonce(contractAddress *felt.Felt) error
	SetClassHash(contractAddress, classHash *felt.Felt) error
	SetContractClass(classHash *felt.Felt, contractClass core.Class) error
	SetCompiledClassHash(classHash *felt.Felt, compiledClassHash *felt.Felt) error
}

type callContext struct {
	// state that the call is running on
	state State
        ...other fields
}

[rianhughes]

Yup, you're right! After thinking about it a little more, I think we can completely remove the setter functions, and just extract the required state changes by returning the state-diff from blockifier. This simplifies a lot of the code, and saves blockifier having to call Go-code whenever something is set. Also, since vm.Call() is primarily executed when handling RPC requests, I added a flag (returnStateDiff) to indicate that the blockifier should only return the state-diff when requested (ie when we call genesis.GenesisStateDiff(), which is only done when running Juno as a sequencer)