[Anvil] Genesis customisation

[alindima]

Some genesis values can be customised directly from the cmdline (--balance, --timestamp, --number). Anvil also supports reading a genesis JSON file (--init). Not everything that can be configured in the genesis is used by anvil. Only these items are (double-check):

• Genesis block timestamp. Can be queried from within the smart contract with block.timestamp. This ends up in a hostcall going to the Config::Time on pallet revive, which ends up calling into the timestamp pallet. We need to modify the node-side InherentDataProvider to take this genesis timestamp and pass it in.
• Genesis block number. Let’s leave this for later and see if it’s actually useful. It can be tricky, substrate does not support this by default. Pallets may be making assumptions about the genesis block being 0 so we may break everything.
• ChainID. A constant part of the pallet-revive Config trait. We can only modify this when building the runtime. Smart contracts can query the value by block.chainid. anvil_setChainId should also be implemented. We need to turn the constant in pallet-revive into a storage item (using frame parameters). We need support from the smart contract team in order to upstream this. Let’s also try to make this configurable at genesis, using GenesisConfig.
• Coinbase (address of the miner, part of the standard ethereum Block information), can be queried by the smart contract via block.coinbase. Can be modified by rpcs (anvil_setCoinbase, also implement this). This is determined in pallet-revive by the FindAuthor trait impl which by default returns None (translating into a zeroed address). We need to implement FindAuthor properly (needs a runtime modification, to change the FindAuthor implementation and a node-side change for supplying the accountid in the consensus_data_provider inside ManualSealParams).
• Base_fee_per_gas (not in standard ethereum genesis, it is used in testing). Corresponds to GAS_PRICE constant in pallet-revive. Is returned as part of every block. I don’t think it can be easily overwritten without rebuilding the runtime. It can also be overwritten at runtime (only for the next block) with SetNextBlockBaseFeePerGas. We need a bit more investigation into how gas is used in pallet revive
• Alloc (accounts): The initial state of accounts in the genesis block. They can also come from the accounts configured in the cmdline (via --accounts, --balance, which can only be basic accounts derived from one mnemonic. The accounts configured in JSON can also be smart contract accounts. Balances we can easily add via GenesisConfig of the balances and revive pallets. They can also configure signers through the privateKey option. Smart contracts cannot currently be registered at genesis in pallet-revive. We could add smart contracts to the genesis config of the pallet (needs upstreaming). We need to also add a CREATE2 deployer contract at genesis (which can be disabled via cmdline). We could get this for free with Add a create2 precompile for deterministic deployments contract-issues#99

[iulianbarbu]

hey @alindima ! I think we can approach the above genesis customisation items in the order from the issue description (pushing back the bullets which are not as straight forward to later - e.g. Genesis block number, Base_fee_per_gas, the smart contract accounts in genesis blocks). WDYT?

[alindima]

Let's first focus on the items that need some support from pallet-revive, which will likely be more work and take more time:

• chainID
• alloc (accounts and smart contracts)

Then, focus on the easier ones:

• Genesis block timestamp
• Coinbase

Leave these ones out for now:

• Genesis block number. I hope it's not going to be needed.
• Base fee per gas is a special one, it's complicated but will be needed. However, the gas pricing mechanism is currently being reworked in pallet-revive, so let's wait until that's settled.

[iulianbarbu]

FYI, opened a draft for making pallet revive chain id configurable: paritytech/polkadot-sdk#9551. Next up is (please correct me if I am wrong):

1. to confirm I am on the right path with #9551. @alindima maybe that's useful for your upcoming discussion with SCC
2. forward the AnvilNodeConfig chain id to anvil substrate runtime somehow (through a genesis patch maybe? not sure, have to see)
3. investigate what's needed to be able to implement the anvil_setChainId RPC (maybe some little steps towards [Anvil] State injector #240?)

LMK in case of any feedback. For now building/running anvil-polkadot based on #9551 works. I am not seeing the genesis config set chain id yet in the logs due to some hardcoding from AnvilNodeConfig where a default value is printed in the logs. As mentioned in 2, if I'll do it I should be able to validate #9551.

[alindima]

2. forward the AnvilNodeConfig chain id to anvil substrate runtime somehow (through a genesis patch maybe? not sure, have to see)
3. investigate what's needed to be able to implement the anvil_setChainId RPC (maybe some little steps towards [Anvil] State injector #240?)

in order to implement 3, indeed we need the state injector. We can use the same mechanism for injecting the genesis value as well

[alindima]

So let's first focus on making the required changes in pallet-revive.
For adding smart contracts via GenesisConfig I think it's generally useful to add directly in the pallet. Seems like useful functionality to have outside of the anvil use case. Especially since adding a smart contract account modifying many storage items in the pallet, which would be cumbersome to do in the state injector (not impossible, just a lot of meddling with raw keys)

[iulianbarbu]

FYI, opened a draft for making pallet revive chain id configurable: paritytech/polkadot-sdk#9551. Next up is (please correct me if I am wrong):

1. to confirm I am on the right path with [#9551](https://github.com/paritytech/polkadot-sdk/pull/9551). [@alindima](https://github.com/alindima)  maybe that's useful for your upcoming discussion with SCC

2. forward the AnvilNodeConfig `chain id` to anvil substrate runtime somehow (through a genesis patch maybe? not sure, have to see)

3. investigate what's needed to be able to implement the `anvil_setChainId` RPC (maybe some little steps towards [[Anvil] State injector #240](https://github.com/paritytech/foundry-polkadot/issues/240)?)

LMK in case of any feedback. For now building/running anvil-polkadot based on #9551 works. I am not seeing the genesis config set chain id yet in the logs due to some hardcoding from AnvilNodeConfig where a default value is printed in the logs. As mentioned in 2, if I'll do it I should be able to validate #9551.

The plan is to drop the 9551 PR from polkadot-sdk. As it stands, we can enable configurable chain id in our anvil substrate runtime easily by creating a frame_support::parameter_types! storage type that we'll assign to the ChainId assoc type of the pallet_revive::Config trait implementation, and that means we can set a default ChainId in anvil substrate runtime, and modify it as wanted, but we'd not be able to really use this for the forking case, where we'll supposedly use the on-chain runtime from the forked state, which will not have support to modify the chain id given it is set for AH case to a ConstU64. At the same time, we find the usecase of modifying the chain id of a forked chain quite exotic, so we deprioritise it until further notice.

My focus next up is:

1. genesis block timestamp
2. coinbase address
3. add storage item for ChainId in anvil substrate runtime, and use it for pallet revive config (it should be modifiable at the moment the anvil_setChainId rpc is a thing, and state injector can modify the storage at the node startup, based on the chain id given through CLI)

[iulianbarbu]

1. PR for genesis block timestmap opened here, waiting for some feedback: anvil-polkadot(service): add support for genesis timestamp customization #260. I will follow up with an integration test in the meantime - should be useful whichever the feedback.
2. FYI, there is already a ChainId storage item in the anvil substrate runtime, hooked to the pallet_revive::Config::ChainId type. It is just a matter of updating it accordingly based on the chain id set via CLI or via a future anvil_setChainId RPC, but that's for later, once we have a state injector. I'd declare it as done for the scope of this issue. LMK if you disagree.

[alindima]

For accounts and smart contracts: paritytech/polkadot-sdk#9557 was merged and we can use it if we bump the polkadot-sdk version

[alindima]

related: paritytech/polkadot-sdk#9601

[alindima]

And to not need the state injector (and unblock ourselves until I manage to finish that), let's implement this instead: #260 (comment)