Configure JS VM EIPs

[tynes]

I'd like to be able to configure the underlying Ethereum JS VM with yet to be productionized EIPs to test them. You can see here that it supports EIPs that are not currently deployed to the network: https://github.com/ethereumjs/ethereumjs-monorepo/tree/master/packages/vm#eip-support

An eips: number[] key/value pair would be needed to be added here, where the VM is created: https://github.com/NomicFoundation/hardhat/blob/48df7d37cccc8ce72233d73f2866c159c4212b74/packages/hardhat-core/src/internal/hardhat-network/provider/node.ts#L244 There would also need to be config parsing that is able to get the values and pass them through hardhat to the VM.

I am currently working on EIP 1153 support and have a fork of the Ethereum JS VM that implements it and I'm hoping to upstream it. A lot of smart contract developers are interested in testing out that functionality, and a really easy way to do so would be to allow hardhat to pass through config values that can turn the EIP on. Otherwise I will need to fork hardhat, add a diff, update its dependency of the JS VM to my fork and continue to keep it up to date over time.

We have a guide here on how to use our fork of geth and solc (note that solc is very buggy still). There is also a branch of vyper that supports EIP1153

[alcuadrado]

Hey @tynes,

First, great work on EIP-1153!

We normally try to avoid exposing ethereumjs VM's internals, as we are in the process to migrate parts of Hardhat Network to Rust.

Having said that, I understand the value that Hardhat Network can add to research about future directions of the protocol, so we can make some kind of compromise.

Would an experimental (i.e. may be removed in the future with short-notice) feature for this work for you? Are you willing to send a PR for that?

[tynes]

Thanks @alcuadrado!

Thanks for the quick response. I understand and appreciate your willingness to help out here. If switching to a different backend, it doesn't make sense to add a feature now that the new backend won't fully support. A temporary flag would be very helpful in getting the user feedback we need from application devs to make a case for this EIP being adopted.

This work depends on https://github.com/ethereumjs/ethereumjs-monorepo/pull/1768 being merged and released, so I would be happy to open a PR here once that is the case.

FWIW I'm not sure what Rust EVM implementation you are planning on using in the future, but I could definitely see myself opening a PR that adds EIP 1153 to revm in the future once foundry fully integrates it.

[alcuadrado]

Sorry for the delay, I incorrectly assumed that you needed this published as latest. Moody told me that's not the case so I quickly hacked it.

I just published hardhat@eips. You can use this feature like this:

/**
 * @type import('hardhat/config').HardhatUserConfig
 */
module.exports = {
  solidity: "0.7.3",
  networks: {    
    hardhat: {
      loggingEnabled: true,
      hardfork: "berlin",
      enabledEips: [3541] // comment this out and the script won't fail
    }
  }
};

And a test:

const { network } = require("hardhat");

async function main() {
  await network.provider.send("eth_sendTransaction", [
    { data: "0x60ef60005360016000f3" },
  ]);
}

main().catch(console.error);

[alcuadrado]

FWIW I'm not sure what Rust EVM implementation you are planning on using in the future, but I could definitely see myself opening a PR that adds EIP 1153 to revm in the future once foundry fully integrates it.

We were planning to use Sputnik, but REVM looks more promising every day, so we may also switch

[alcuadrado]

I'm closing this issue as afaik this tag is what you needed. Please let me know here or ping me on tg/twitter/slack if you need something else.

[moodysalem]

I'm closing this issue as afaik this tag is what you needed. Please let me know here or ping me on tg/twitter/slack if you need something else.

~Could you share the tag and how to use it here?~ nevermind found it above 😓 I searched the git tags first and npm packages