Regression in 2.3.2: Internal Error: unimplemented precompiled contract 0x10 (EIP-2537 BLS12-381) — works in 2.3.1

[aviggiano]

Summary

Echidna 2.3.2 aborts at campaign start with an hevm internal error on a target that Echidna 2.3.1 fuzzes without issue:

echidna: Internal Error: unimplemented precompiled contract 0x0000000000000000000000000000000000000010 -- CallStack (from HasCallStack):
  internalError, called at src/EVM.hs:3088:10 in hevm-0.57.0-...:EVM
CallStack (from HasCallStack):
  error, called at src/EVM/Types.hs:1574:19 in hevm-0.57.0-...:EVM.Types
  internalError, called at src/EVM.hs:3088:10 in hevm-0.57.0-...:EVM

Address 0x0000...0010 (0x10) is one of the EIP-2537 BLS12-381 precompiles (added in the Pectra hardfork; 0x10 is BLS12_MAP_FP_TO_G1 in the final assignment). The target contract reaches that precompile, and hevm 0.57.0 (bundled in the 2.3.2 Linux release) has no implementation for it, so the whole campaign dies immediately — no test cases are ever run.

This looks like a regression in 2.3.2: the exact same target, harness, and command produce a full 4-hour campaign under 2.3.1.

Environment

• Broken: Echidna 2.3.2 (official Linux x86_64 release, echidna-2.3.2-x86_64-linux.tar.gz), bundling hevm-0.57.0.
• Working: Echidna 2.3.1 (official Linux x86_64 release).
• OS: Ubuntu 24.04, x86_64.
• crytic-compile + slither compile the target successfully in both cases; the failure is purely at EVM execution.

Steps to reproduce

Target (public): https://github.com/scfuzzbench/aave-v4-scfuzzbench @ 459b020058f4a65d18eb1481083b75c766340124
Harness entry point: tests/recon/CryticTester.sol (contract CryticTester).

Command (verbatim from our runner):

echidna --config echidna.yaml --contract CryticTester --workers 16 \
  --corpus-dir <corpus> --test-limit 1000000000 --shrink-limit 1 \
  tests/recon/CryticTester.sol +RTS -A1g -RTS

• 2.3.2: compiles, runs slither, then immediately prints the unimplemented precompiled contract 0x10 internal error and exits (~within seconds of starting the campaign).
• 2.3.1: same command, same target — runs the full campaign and finds assertion failures normally.

What we observed

We hit this while running Echidna as part of the scfuzzbench fuzzer benchmark. Across two independent 2.3.1 runs on this target, Echidna fuzzed for the full budget and found ~7–8 canonical assertion failures with no error. After bumping to 2.3.2 (identical target/commit/harness/flags), both instances died at ~88s with the error above and 0 test cases executed.

Public run page for the failing 2.3.2 run (see the Echidna leg warning + logs):
https://scfuzzbench.com/runs/gh-29938127768-1/1e70047c32b1c47c84a1c9b8b7154dba/

Full bootstrap + echidna.log for both the 2.3.1 (working) and 2.3.2 (crashing) runs are available — happy to attach or share.

Hypothesis / questions

A plausible mechanism is a change in the default EVM version / hardfork between 2.3.1 and 2.3.2 (or in the bundled hevm): if 2.3.2 now targets a Pectra-era fork, calls to 0x10 get routed into precompile dispatch, where hevm 0.57.0 lacks an EIP-2537 implementation and calls internalError instead of degrading gracefully. Under an earlier default fork, 0x10 would just be an ordinary (empty) account.

• Is this a known gap in the bundled hevm (no EIP-2537 BLS precompiles), and/or a change in the default evmVersion?
• Is there a recommended workaround today — e.g., pinning an earlier evmVersion in the Echidna config so 0x10 isn't treated as a precompile? (We can try this and report back.)
• Ideally, hevm would implement the EIP-2537 precompiles, or at least not internalError on an unimplemented precompile.

Thanks! Glad to provide a minimal reproducer, additional logs, or to test a candidate fix on the full target.

[aviggiano]

Follow-up: I've traced this to the exact root cause. Summary up front: the crash is in hevm's costOfPrecompile, which is missing entries for the newly-recognized precompile addresses — it fires internalError during gas calculation before hevm's own graceful NonexistentPrecompile fallback can run. Details below.

Root cause chain

1. The hevm bump in 2.3.2 widened precompile recognition without adding implementations.

Echidna 2.3.1 pinned hevm release/0.57.0 (5ec225475d5ba9cda24c5fb303acb76c88412553):

isPrecompileAddr = \case
  LitAddr a -> 0x0 < a && a <= 0x09

Echidna 2.3.2 pins hevm 8da7ea44ebf5524dce65b14e70cee1a4413eb6f0 (the Osaka-changes commit; the binary still reports "hevm-0.57.0" because only the commit moved, not the cabal version):

isPrecompileAddr' :: Addr -> Bool
isPrecompileAddr' 0x100 = True
isPrecompileAddr' x = 0x0 < x && x <= 0x11

So 0x0a (KZG point evaluation), 0x0b–0x11 (EIP-2537 BLS12-381), and 0x100 (P256VERIFY) are now routed into precompile dispatch — but none of them are implemented.

2. The crash site: gas calculation, not execution.

executePrecompile (EVM.hs ~1264 at 8da7ea4) actually anticipates this case — it has a notImplemented branch that produces a graceful, catchable vmError (NonexistentPrecompile preCompileAddr). But it's unreachable: line ~1273 computes

cost = costOfPrecompile fees preCompileAddr input

which is forced by enoughGas cost gasCap before the address dispatch — and costOfPrecompile (EVM.hs:3088) still only implements 0x1–0x9, falling through to:

_ -> internalError $ "unimplemented precompiled contract " ++ show precompileAddr

So the graceful path can never fire for any of the newly-recognized addresses. This mismatch is still present on hevm main today.

3. Why this target hits 0x10: crytic-compile-style library linking at low addresses.

Our harness's echidna.yaml deploys Aave's external libraries at 0x10–0x1d (the long-standing library-linking pattern):

deployContracts: [["0x10", "EIP712Types"], ["0x11", "Roles"], ["0x12", "MathUtils"], ...]
cryticArgs: ["--compile-libraries=(EIP712Types,0x10),(Roles,0x11),..."]

0x10 and 0x11 now collide with the recognized-but-unimplemented BLS addresses, so the first touch of the library at 0x10 (at deploy — exec1 also routes executing at a precompile address into executePrecompile — or on first DELEGATECALL) kills the campaign. Timeline matches our logs exactly: compile ~12s + slither ~72s, then instant death at ~88s. Our other benchmark targets don't use deployContracts at all, which is why only this one crashed.

Correction to my original report

I speculated that pinning an older evmVersion might be a workaround — it is not: isPrecompileAddr' is unconditional, not fork-gated. There is no Echidna-config workaround other than moving deployed contracts/libraries out of 0x01–0x11 and 0x100 (which we'll do on our side regardless — post-Pectra, 0x10/0x11 are real mainnet precompiles, so parking a library there is outdated anyway).

Suggested fixes (hevm side)

1. Make costOfPrecompile total over the recognized range (even 0 or a nominal cost for unimplemented addresses) so executePrecompile's existing NonexistentPrecompile path can fire — turns a fatal internalError into an ordinary VM error the fuzzer can survive. One-line-class fix.
2. Ideally, gate isPrecompileAddr' on the active fork (pre-Cancun/Pectra forks shouldn't treat 0x0a–0x11 as precompiles at all), and/or implement the EIP-2537 precompiles.

Happy to test a candidate fix against the full Aave target. I'll also cross-file this on the hevm tracker since the fix belongs there.

[elopez]

Indeed, not all of the newer precompiles are implemented, but all of them are detected as precompiles now. Previously the newer addresses were just normal, empty addresses as hevm was tracking a previous EVM fork, so they would (silently?) revert if you called them.

Also note that there's no such concept as "evmVersion" in the Echidna config (A LLM hallucination there?). Echidna / hevm just (try to) track the latest version, with varying degrees of compatibility. For example, we now support the new opcode in Osaka and some of the new gas accounting, but e.g. not some of the precompiles.

There's a tests-passing, LLM generated implementation of the precompiles for hevm here if you need them working - argotorg/hevm#1035. Otherwise I'd advise avoiding them; I've yet to encounter a project that needs them. In your case it sounds like it's just a matter of moving the predeployed contracts a bit higher in the address space so they don't clash with precompile addresses -- maybe 0x1000+ is a safer bet now. This PR we merged recently will help surface an error when there's clashes between your deployed contracts and precompiles by the way: #1585

[aviggiano]

Thanks

That 0x10 has always been a hack, it eventually broke hehe

I'll use 0x1000 for simplicity