bump(revm: step 1): bump revm to 21.0.0 release

[zerosnacks]

Stacked PRs:

• bump(revm: step 2): bump alloy + revm + alloy-evm + other deps to latest #10454
• bump(revm: step 3): reintroduce precompile injection #10508

Benchmarks forge test

Project	Before (v1.2.0-rc)	After (revm 23 @ ec4ffd3)	Change %
uniswap v4-core	5.21s	4.43s	–14.97%
spark-psm	17.48s	14.76s	–15.56%
morpho-blue	1.81s	1.67s	–7.73%
morpho-blue (invariant)	1.66s	1.57s	–5.42%
morpho-blue (integration)	0.67s	0.62s	–7.46%
sablier lockup	20.44s	17.45s	–14.63%
solady	4.31s	3.37s	–21.80%
euler evc	16.05s	13.65s	–14.95%

Conclusion: on average at least 12% faster!

Notes:

• Benchmarks only measure running of tests and are pre-build
• Solady fuzz runs has been bumped to 1024 from 256 for all tests
• Sablier lockup excludes forked fuzz tests for all cases due to RPC unavailability
• Euler EVC tests were patched to constrain deadline to type(uint64).max - 1 on all cases, now enforced (see breaking changes)

Benchmarks anvil

mem and cpu

ref #7940 (comment)

Nightly 1.2.0-nightly Commit SHA: 58297d3	Pr

https://github.com/PhilippLgh/anvil-perf

ref #4399 (comment)

Chunk	v1.1 (ms)	v1.2 (ms)	new revm (ms)	Speedup
1	0	0	0	x0.00
2	39	39	36	x1.08
3	63	64	58	x1.10
4	86	87	77	x1.12
5	107	108	95	x1.13
6	128	129	114	x1.13
7	148	148	132	x1.12
8	168	169	149	x1.13
9	189	189	166	x1.13
10	208	209	184	x1.13
11	226	230	201	x1.14
12	245	250	219	x1.14
13	266	270	236	x1.14
14	288	290	253	x1.14
15	308	310	270	x1.14
20	423	428	368	x1.16
25	516	524	451	x1.16
30	606	621	533	x1.16
35	698	717	614	x1.16
40	795	812	692	x1.17
50	984	1003	855	x1.17
65	1263	1292	1113	x1.16

https://github.com/mshakeg/anvil-backtester

ref #6017 (comment)) - blocksToMine: 10, nullSwapsPerBlock: 2000, totalTxs: 40000, 3 runs

metric	Nightly 1.2.0-nightly Commit SHA: 58297d3	Pr
executionTime	run1: 4.67 run2: 4.605 run3: 4.626	run1: 4.667 run2: 4.672 run3: 4.676
averageTPS (more is better)	run1: 8565.310492505354 run2: 8686.210640608035 run3: 8646.779074794638	run1: 8570.816370259268 run2: 8561.643835616438 run3: 8554.31993156544
averageTimePerTx (less is better)	run1: 0.11674999999999999 run2: 0.115125 run3: 0.11565	run1: 0.116748 run2: 0.1168 run3: 0.1169

https://github.com/xmtp/xmtpd

ref #10122 (comment)

Nightly 1.2.0-nightly Commit SHA: 58297d3	Pr
29.361s 29.907s 29.856s 29.867s 29.890s	29.807s 29.988s 29.771s 30.017s 29.769s

Known breaking changes ❗ ⚠️

Revm now operates on u64 for the following fields:

• chain id
• tx.gas_price
• block.basefee
• block.number
• block.timestamp

Thereforce we must constrain the input we accept to up u64::max for the following cheatcodes:

• vm.chainId
• vm.fee
• vm.roll
• vm.txGasPrice
• vm.warp
• vm.setBlockhash

These cheatcodes will raise an error if a value > u64::max is passed.

Because of these Revm fields changing the Anvil state files are known to currently break, this can possibly be handled in a follow-up where we flexibly read from old state files but write in the new form. This is not currently handled in this PR.

Closes

Closes: #10367

Follow ups that will become unlocked, to check

• Verify bug(cast): trace printer returns "broken" gas value around 0x1 precompile #10276 has been fixed
• chore: switch from CustomPrintTracer to use Revm's TracerEip3155 #10329
• bug(forge bind): generated contract bindings are incompatible with alloy-rs 0.14.0 + serde is not added as dependency #10321
• feat(forge): truncate large data in execution traces #10305
• bug(prague hardfork): add support for EIP-2935, currently missing #10357 (relies on alloy-evm)

PR Checklist

• Added Tests
• Added Documentation
• Breaking changes

[mattsse]

okiee,

some things required workarounds but overall this lgtm even though the total diff is quite large

[grandizzy]

that's great, left couple of nits and some questions if we could decouple more from op?

stale

[mattsse]

this lgtm now

[grandizzy]

lgtm, will re approve if we decide to use new revm / foundry-fork-db release instead patched but not a blocker

[jflatow]

I think this is problematic, its now effectively impossible to write tests with foundry that hit valid states in the EVM due to e.g. u64 timestamps. What is the proposed solution for this? This is actually a very significant breaking change that reduces functionality

[zerosnacks]

I think this is problematic, its now effectively impossible to write tests with foundry that hit valid states in the EVM due to e.g. u64 timestamps. What is the proposed solution for this? This is actually a very significant breaking change that reduces functionality

Given that Revm now operates on u64 for these fields it would lead to incorrect assumptions if we permit U256 inputs (#10367). In Foundry tests, if you are using U256 fuzz inputs you should bound them to u64 using vm.bound() or make the fuzz input be u64.

If this is not satisfactory please expand on your use case, preferably with an example.

cc @rakita @grandizzy

[jflatow]

I think this is problematic, its now effectively impossible to write tests with foundry that hit valid states in the EVM due to e.g. u64 timestamps. What is the proposed solution for this? This is actually a very significant breaking change that reduces functionality

Given that Revm now operates on u64 for these fields it would lead to incorrect assumptions if we permit U256 inputs (#10367). In Foundry tests, if you are using U256 fuzz inputs you should bound them to u64 using vm.bound() or make the fuzz input be u64.

If this is not satisfactory please expand on your use case, preferably with an example.

cc @rakita @grandizzy

This is not good because we have contracts that use uint256 timestamps and we want to test for correctness throughout the entire range. We wouldn't want to bound the tests (with fuzzing or not) because even if we can't trigger these states from foundry they can exist on chain. Isn't it kind of broken to not support this?

[rakita]

We wouldn't want to bound the tests (with fuzzing or not) because even if we can't trigger these states from foundry they can exist on chain

The reason why we shrunk to u64 is that it is impossible to trigger this on chain. So if you use timestamp more than u64 you are testing an impossible flow here.