chore: bump revm to 42.0.1 + EIP-8282 system calls - #396
Conversation
rakita
changed the title
rakita
changed the title
| }; | ||
|
|
||
| /// Address of the EIP-7997 deterministic `CREATE2` factory predeploy. | ||
| pub const FACTORY_ADDRESS: Address = address!("0x0000000000000000000000000000000000000012"); |
There was a problem hiding this comment.
Could we drop this module and the apply_factory_predeploy hook? This implements an obsolete EIP-7997 design. Before this PR opened, the EIP had switched to the existing factory at 0x4e59b44847b379578588920cA78FbF26c0B4956C, different runtime code, and a nonzero nonce. It subsequently removed the fork-boundary lookup/mutation and now says clients MUST NOT check for the factory at the fork boundary. As written, Amsterdam execution writes unrelated code at 0x12, potentially with nonce zero, causing a consensus state-root divergence. The factory should instead be provided by the normal deployment transaction or genesis configuration.
References: current specification, factory change, irregular state transition removal.
There was a problem hiding this comment.
Good catch — removed the module and the apply_factory_predeploy hook in 5464284.
The EIP-7997 design implemented here is obsolete: the EIP now uses the existing factory at 0x4e59b44847b379578588920cA78FbF26c0B4956C with different runtime code and a nonzero nonce, and it removed the fork-boundary irregular state transition entirely (clients MUST NOT check for the factory at the fork boundary). The factory is instead provided via a normal deployment transaction or genesis configuration.
rakita
changed the title
2 participants
Bumps
revmto42.0.1(revm v115) and ports the Amsterdam system calls that were previously only on theglamsterdam-devnet-7branch, with the devnet-7 predeploy addresses.revm bump
No source changes were required for the bump itself.
EIP-8282 builder execution requests
Two post-block system calls, active from Amsterdam, each called as
SYSTEM_ADDRESSwith empty calldata; their output is pushed as EIP-7685 requests:0x03) —0x0000BFF46984E3725691FA540A8C7589300D82820x04) —0x000064D678505AD48F8CCB093BC65613800E8282These are the current devnet-7 predeploy addresses; they match revm (
bins/revme/src/cmd/blockchaintest/post_block.rs) and supersede the earlier…008282/…008282pair. Two matchingBlockValidationErrorvariants were added.EIP-7997 deterministic CREATE2 factoryDropped per review: the implemented design is obsolete — EIP-7997 now uses the existing factory at
0x4e59b44847b379578588920cA78FbF26c0B4956Cand no longer performs a fork-boundary state transition. The factory is provided via a normal deployment transaction or genesis configuration instead.MSRV bump to 1.94.1
Unrelated to revm:
alloy-consensus/alloy-eips/alloy-tx-macros2.2.0were published withrust-version = 1.94.1. Since the workspace requires^2.0.0and no lockfile is committed, CI resolves 2.2.0 and the old 1.91 MSRV jobs fail —mainis affected too. Bumpedrust-versionand the CI matrix to match. Happy to split this into its own PR if preferred.Clippy clean; MSRV build verified against a real 1.94.1 toolchain.