Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ability to perform call from contract #235

Closed
Wodann opened this issue Oct 19, 2022 · 3 comments · Fixed by #237
Closed

Ability to perform call from contract #235

Wodann opened this issue Oct 19, 2022 · 3 comments · Fixed by #237

Comments

@Wodann
Copy link
Contributor

Wodann commented Oct 19, 2022

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
Copy link
Member

rakita commented Oct 20, 2022

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:

/// In cases where the gas limit may be extraordinarily high, it is recommended to set this to
/// a sane value to prevent memory allocation panics. Defaults to `2^32 - 1` bytes per
/// EIP-1985.
#[cfg(feature = "memory_limit")]
pub memory_limit: u64,

@Wodann
Copy link
Contributor Author

Wodann commented Oct 20, 2022

Perfect! I can start implementing that 🙂

@Wodann
Copy link
Contributor Author

Wodann commented Oct 21, 2022

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants