feat: add network-specific pre-state execution in decoder

[Nashtare]

• adds pre-execution rule specific to cdk-erigon
• fix precompile range
• couple tweaks in KERNEL constants module (state keys are hashes of addresses, not the addresses themselves, etc..)

What I haven't done:

• including the scalable / GER touched slots into prefetching for native tracer. Will we even care about using native tracer with CDK-erigon, or always rely on the Zero tracer? cc @muursh
• sanity checks based on target network in the decoder entrypoint. Should we assume the data being fed to be valid or do we want those? (i.e. no withdrawals for non-eth mainnet, no GER data for non-cdk-erigon, etc..) cc @0xaatif

closes #604

[Nashtare]

only because of the hanging ger_data when not targeting cdk-erigon

[0xaatif]

I think we could make this tighter, but I'd prefer a different approach

[Nashtare]

Note that with the latest suggestion on your discuss PR, the lint isn't triggered anymore because both conditional blocks would be living in the same binary

[LindaGuiga]

This is a first pass (almost complete, but I'd like to check again quickly). It generally looks good, I just have a couple of questions

[LindaGuiga]

In the link, the slot number seems to be 1|blockNumber. But this implementation seems to differ? Or am I missing something?

[Nashtare]

Hmm I'm not sure. In cdk_erigon, we call:

		//save prev block hash
		sdb.scalableSetBlockHash(blockNumber-1, prevBlockHash)

with function definition:

func (sdb *IntraBlockState) scalableSetBlockHash(blockNum uint64, blockHash *libcommon.Hash) {
	// create mapping with keccak256(blockNum,position) -> smt root
	d1 := common.LeftPadBytes(uint256.NewInt(blockNum).Bytes(), 32)
	d2 := common.LeftPadBytes(STATE_ROOT_STORAGE_POS.Bytes(), 32)
	mapKey := keccak256.Hash(d1, d2)
	mkh := libcommon.BytesToHash(mapKey)

	hashAsBigU := uint256.NewInt(0).SetBytes(blockHash.Bytes())

	sdb.SetState(ADDRESS_SCALABLE_L2, &mkh, *hashAsBigU)
}

i.e. this line: mapKey := keccak256.Hash(d1, d2) is hashing the concatenation blockNum || STATE_ROOT_STORAGE_POS i.e. with initial inputs: blockNumber-1 || 0x01.
Unless I am also missing something

[LindaGuiga]

Are you also storing the BLOCK_INFO_ROOT?

[Nashtare]

I believe this is only during post_state_execution, not pre, and following discussions of this morning we may actually not need to write this BLOCK_INFO_ROOT (pending design decisions)

[0xaatif]

How do you feel about phrasing this as a runtime rather than compile time idea?
I've sketched this in #643

I'm dubious of any significant performance delta, and the code would be:

• easier to reason about
• get all the affordances of development with no feature gating (better IDE experience etc...)

[atanmarko]

OK from the zero side.

[0xaatif]

I don't think I should keep blocking this review on wider architectural decisions. The code is good as is, any arch refactors after the fact are trivial :)

[Nashtare]

@LindaGuiga let me know if you still need clarifications on the items above

@0xaatif would you want me to apply the last suggestion of #643 here or should we keep exploring options?

[0xaatif]

I think it's a great suggestion :) happy for it to be included