Call to precompile crashes echidna even when the compiler should prevent the call

[GalloDaSballo]

Impact

I'd like to report an issue I'm running into when using Echidna with HEVM

When a precompile is the target to a call, HEVM reverts, even when Echidna should not be calling the precompile, but it's just getting the precompile size

POC

The template uses Chimera so you can run any Fuzzer / FV tool

https://github.com/Recon-Fuzz/hevm-precompile-crash-unexpected

Run with Foundry -> Reverts as the compiler protects us from calling the precompile
Run with Echidna -> Crashes HEVM even though I would expect the compiler to prevent the call to the precompile

Call 1

    function doACall() public {
        uint256 size = address(0x0a).code.length;
        size + 1;
    }

The crash here is expected, we're calling the precompile directly and it's unimplemented

Call 2

    function doACall() public {
        uint256 res = IERC20(address(0x0a)).balanceOf(address(this));
        res + 1;
    }

The crash here is unexpected, shouldn't the compiler inserted check cause a revert before we call the precompile?

Call 3

    function doACall() public {
        uint256 size = address(0x0a).code.length;
        size + 1;
    }

Surprisingly, the call here doesn't revert

Conclusion

Maybe I'm missing something, but I would expect the compiler to prevent Echidna from calling the precompile hence prevent the crash, however, that's not the case

What would you advise to allow me to use echidna with a set of contracts that allow arbitrary inputs and calls?

[elopez]

For further context on call # 2, the compiler no longer inserts an extcodesize check if the function returns data, so it's also expected as in case # 1 - ethereum/solidity#12204. The last version with the check was solc 0.8.9

[msooseth]

@elopez do you wanna take a look at this? I think I'm not enough of an expert (yet) at these. Otherwise, I'll try to take a shot at it later :)

[elopez]

@msooseth I think the problem is that the 0xa precompile is unimplemented. Currently that triggers an internalError https://github.com/ethereum/hevm/blob/main/src/EVM.hs#L1202

When I looked at the precompile, it didn't seem like something straightforward to implement; it mentions blobs https://www.evm.codes/precompiled?fork=cancun#0x0a

Maybe providing a placeholder implementation that always reverts would be enough for most users here? Or maybe we can relax the internalError to a revert?

[msooseth]

Right, this is for (proto-)danksharding. Unfortunately, not not a very high priority right now, as most contracts rarely use them. The hardness of implementing it is likely to do with running external code, as these precompiles tend to be some C/Rust/etc. code and building them and liking them in can be very painful. I wish we already had EVMMAX, then this could be quite easy...