Ability to perform call from contract

[Wodann]

At hardhat we support the ability to call contracts from another contract when developing your own smart contract. So far we've been using ethereumjs, which supports this behaviour.

We're rewriting part of our stack in Rust and using revm to do so. However, revm strictly adheres to EIP-3607 to "Reject transactions from senders with deployed code": https://github.com/bluealloy/revm/blob/main/crates/revm/src/evm_impl.rs#L90

        // EIP-3607: Reject transactions from senders with deployed code
        // This EIP is introduced after london but there was no colision in past
        // so we can leave it enabled always
        if self.data.journaled_state.account(caller).info.code_hash != KECCAK_EMPTY {
            return exit(Return::RejectCallerWithCode);
        }

In development, the security concern does not apply, so it would be nice to still be allowed to call contracts from a contract address. Is this something that you'd be willing to accept a PR for? If so, do you have a preference for how it should be implemented?

One option would be to use a dev feature flag that would disable that check.

[rakita]

I like a lot idea of having dev feature flag.

memory_limit flag does something similar, it is needed for tooling but it "breaks" consensus, i didn't really like it as it is specific but dev flag makes a lot more sense.

dev could enable env.cfg config disable_eip3607 or something in that sense, similar to what memory_limit is doing: https://github.com/bluealloy/revm/blob/88c72a7c8352a3d2b5b6842bc7d9922d800405e1/crates/revm/src/models.rs#L238-L242

[Wodann]

Perfect! I can start implementing that 🙂

[Wodann]

I realised something. We can also have individual feature flags for the features and bundle then together in a feature flag dev = ["optional_eip3607", "memory_limit"].

What do you prefer?