Extend available rpc calls to improve hardhat compatibility

[bee344]

Hardhat employs certain rpc calls to assert it is a hardhat network, which enables the usage of a wide range of helper tools that are HardhatOnly. It also enables configuration options such as allowUnlimitedContractSize and allowUnlimitedInitCodeSize, which overrides the native limit set by hardhat and can help the tests adapt to the actual size limit of PolkaVM.

The most critical rpc calls that are needed atm are:

• evm_snapshot
• evm_revert
• evm_increaseTime
• evm_mine
• web3_clientVersion
• hardhat_mine
• hardhat_setBalance
• hardhat_impersonateAccount
• hardhat_stopImpersonatingAccount
• hardhat_setStorageAt
• hardhat_reset

A more comprehensive list of these rpc calls can be found in era-test-node's evm, hardhat, eth and web3 namespaces.

These rpc calls (excluding the hardhat_* ones) are also useful for users that are used to using testing frameworks like Ganache.

[athei]

Does HardHat supply their own testing node that expose those endpoints or do they rely on you using something like Ganache? I assume Geth doesn't implement those RPCs.

[bee344]

Hardhat has their own in-memory node that handles the testing. It shares the Ethereum logic, therefore it's not useful for us nor for other non-EVM chains. That's why we have hardhat-revive-node to replace it and others such as zksync have hardhat-zksync-node. In the latter, they have adapted their node to comply with these requirements, therefore they have much more extended testing capabilites than us.

[athei]

Okay I got it thanks. So we need to add them to the node. Can you out which are the most important from your point of view? i.e which are solving the current limitations we have:

1. Can't upload big contracts due to size limits
2. The test suite running slow

Hardhat has their own in-memory node that handles the testing.

What do you mean by in-memory? Where else should it live than in memory? Is not a separate node process or what does this mean?

[bee344]

Priorities should be:

• web3_clientVersion
• evm_snapshot
• evm_revert
• hardhat_mine

This are the most critical ones and are directly tied to 2. The test suite running slow. Regarding limitation 1, there's no full way around it until we get full compatibility, but we may have a patchy workaround if we have these, but won't know for sure until we try.

[bee344]

We will also need to get something like this in, but my guess is that in order for that to fo through we'll need to have most if not all of those RPC calls in.

[pgherveou]

web3_clientVersion
evm_snapshot
evm_revert
hardhat_mine

evm_snapshot and evm_revert might be the most challenging, I wonder if we should build a sandbox around TestExternalities instead of using a real node, not sure how best to add it to the node otherwise

[pgherveou]

fyi @nprt is working on #26 which will add web3_clientVersion

[pgherveou]

maybe what we need here is something like https://use.ink/basics/contract-testing/drink to provide some kind of e2e backend for hardhat and others

[smiasojed]

I see that Hardhat Node also supports forking from another networks.
Additionally, is it worth considering the option to run such a node as WebAssembly (WASM)? If so, it could be used with the Remix project. By the way, as I understand it, the Ethereum Hardhat version uses a JavaScript-based Ethereum node.