add eth_simulateV1

[KillariDev]

eth_simulateV1

This PR is a cleaned up version from #383. The #383 is based heavily on #312 from @s1na (eth_batchCall). This spec encompasses some of the ideas presented by @MicahZoltu @OlegJakushkin, @LukaszRozmej, @KillariDev, @epheph and others.

Summary

This introduces a new RPC method eth_multicallV1 allows users to make complex RPC calls to Ethereum nodes. Compared to eth_call, eth_multicallV1 has following extra features:

• You can encapsulate multiple dependent calls in a single call
• The calls happen inside blocks. You can simulate multiple blocks that can be arbitrary far from each other
• Block variables can be overridden (e.g. time)
• Account state can be overridden for every block (e.g. code and balance)
• It is possible to override precompiles (e.g. ecrecover) with arbitrary EVM code
• ETH transfers produce logs similar to ERC20 logs
• Validation mode. You can choose to do very strict simulation or more relaxed one similar to eth_call

Motivation

The features of eth_multicallV1 allow many interesting simulation use cases such as:

• To simulate simple erc20 approval & swap feature in a wallet, we need to be able to send multiple transactions
• Searchers need to trigger oracle update and wait a number of blocks
• Researchers need to trigger a price change and wait a number of blocks for a TWAP adjustment
• Wallets are beginning to provide advanced simulation to the user
• Block builders are beginning to explore multi-block MEV
• Fake Permit2 or other EIP-712 approvals

This blog post also explains motivation around eth_simulate: https://mirror.xyz/killaridev.eth/NXR9v4r8b4SWl-hbqJqRQyIAcE4GACobzMObREvL0fo and a PEEPanEIP episode: https://www.youtube.com/watch?v=4uZyQQ6qz4U

Implementation

Geth: https://github.com/s1na/go-ethereum/tree/multicall
Nethermind: https://github.com/NethermindEth/nethermind

[KillariDev]

Here's slides for multicall presentation: https://docs.google.com/presentation/d/1lEaqHTY3ud8pe6VAFwLkb-jdoHpTMBfuF1K9OKy-azs

[jochem-brouwer]

Got some comments :) I love this idea, this will make UX so much better!

[jochem-brouwer]

These default values will crash, since baseFeePerGas is always 7 or higher. These default values will be rejected by blockchain spec, since tx is not willing to pay base fee. Note that the default block baseFeePerGas is calculated according to spec, so this will be 7 or higher always.

[jochem-brouwer]

Suggestion: change maxFeePerGas and gasPrice (in case of tx type 0/1) to baseFeePerGas of the block and keep maxPriorityFeePerGas 0.

[KillariDev]

These default values will crash, since baseFeePerGas is always 7 or higher. These default values will be rejected by blockchain spec, since tx is not willing to pay base fee. Note that the default block baseFeePerGas is calculated according to spec, so this will be 7 or higher always.

yeah, this will crash on validation mode. On non-validation mode, we will allow you to make transactions that have zero basefee (similar to eth_call)

[jochem-brouwer]

Slight nit: for completeness, withdrawals should also be able to be overridden (to simulate withdrawals).

[jochem-brouwer]

I am not entirely sure what this would remove/add. If I turn this on, in what situation would this be useful, and what would change if I would have kept it off? 🤔

[jochem-brouwer]

For instance, if validation is set to off, are tx gas limits not checked? (So I can include a tx with gas limit higher than the block gas limit?).

[jochem-brouwer]

Never mind, it is in execute.yaml

    validation:
      title: Validation
      description: |-
        When true, the multicall does all validations that a normal EVM would do, except contract sender and signature checks. When false, multicall behaves like eth_call.

[KillariDev]

This is bit ill defined (as discussed in todays call). Because Nethermind and Geth behave bit differently with eth_call and we have been trying to figure out the differences so we could document them. The intention that is that when validation is enabled, the clients would behave exactly the same, while not fixing the issue that with non-validation, the validation rules might differ a bit.

[jochem-brouwer]

Then I think this spec should explicitly state what should be not be validated if the validation is off. For instance, currently it only seems that you can override the sender (so you can create unsigned txs). But, it also seems that it is possible to set base fee to zero (so do not validate this as well). It should be clearly defined what should be validated and what not. (And this is non-trivial since there is a huge ruleset of what should be validated in transactions/blocks)

[MicahZoltu]

For validation mode, I'm fine with base fee not being allowed to go below 7.

[KillariDev]

I don't think it makes sense that much to validate base fee in validation mode if the user specifically sets the base fee to something. Otherwise we could remove all overrides for validation mode, as none of them can happen on mainnet.

[s1na]

possibly also create multiple validation modes / flags if necessary?

Please no! In fact I want to argue that we should remove validation flag and default to relax-mode. My argument is that this is easy to add in later since we have designed the API param to be an object. It will be a backwards-compatible change. I'd personally like to hear from some people to say they need this first.

That said, we should still define exactly what is not validated in relax-mode. So I think that convo is important to have. And I will share here exactly what geth is validating:

For block validation, only these fields are validated:

• Only block number and timestamp are validated to be incremental.

As for tx validation, these are NOT validated:

• Signature is not validated
• Nonce too high, too low, out of bounds are not validated
• Sender is EoA is not validated
• If gas price fields are 0, then sender doesn't need to have enough balance for gas (only value)
• If blobGasFeeCap is 0, then blob gas requirement is skipped

[s1na]

I'd like to add that these relaxations are all cause for a transaction not to go through. I.e. if I have a call that works in the relax-mode, sign it and submit it to a node, it will not be gossiped to the network at all.

I'd argue if there is any danger to a user it's from all of the flexibility we're providing through state and precompile overrides. E.g. they assume in the simulation to be in a certain condition by using overrides, and submit the transaction when that is not met. That tx will be mined and will revert (most probably).

[MicahZoltu]

I'd personally like to hear from some people to say they need this first.

Our team would like it because it allows us to verify that the transaction is properly constructed and will execute against mainnet without error. In some cases we ship a set of transactions as a "bundle" to searchers, and they need to all execute properly in sequence (including things like balance checks), and in other cases we ship a single transaction to a signer and we want a high degree of confidence that it will execute on-chain just like it did during simulation.

[mds1]

I'd suggest using 0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE as the sending contract, since that's become a de facto approach for representing ETH as a token address within contracts.

Here's a simple sourcegraph search showing usage: https://sourcegraph.com/search?q=0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE&groupBy=repo

[MicahZoltu]

I suspect if you were to do a similar search of 0x000... you would get even more results. "A lot of people use X" is quite different from "Most people use X".

If we ignore any past precedence, I feel like 0x000... makes it a tad more explicit that this is special, and not some precompile or something. For parameters, 0xEee... makes a bit of sense because 0 is the default value for a lot of stuff (e.g., null, missing, etc.) and thus often passed on accident, so using nonzero helps protect against a class of bugs. In the case of event sourcing, 0x000... isn't provided by user/developer so they cannot get it wrong.

That being said, I don't have a strong argument against 0xEeee..., only that I think 0x000... is marginally better and I suspect more widely used.

[mds1]

I agree a search for the zero address would yield more results, but only because the zero address is used for a much wider range of cases, whereas 0xEee... seems to only be used to represent ETH. This is anecdotal and it's hard to know concretely, but in my experience 0xEee... is more common for representing ETH than the zero address.

Personally, if I didn't know about the special ETH logs, seeing 0xEee... would make the log's meaning more intuitive and apparent than seeing 0x000....

[MicahZoltu]

I agree a search for the zero address would yield more results, but only because the zero address is used for a much wider range of cases

Sorry, I meant if you could somehow limit the search of 0x0000... to only places where it was being used as a representation of ETH I suspect it would be more/bigger. That being said, perhaps the searchability of 0xEeee... is a significant selling point.

Personally, if I didn't know about the special ETH logs, seeing 0xEee... would make the log's meaning more intuitive and apparent than seeing 0x000....

For what it is worth, this feature is disabled by default and you need to set a flag to turn it on. I'm not sure that is a meaningful argument though.

[mmsaki]

I agree a search for the zero address would yield more results, but only because the zero address is used for a much wider range of cases, whereas 0xEee... seems to only be used to represent ETH. This is anecdotal and it's hard to know concretely, but in my experience 0xEee... is more common for representing ETH than the zero address.

I agree with @mds1 that 0xEee.. seems more appropriate for Eth transfer logs

[MicahZoltu]

I believe the spec has since been updated to use 0xEee.....

[ryanschneider]

The notes still mentions 0x0 here: https://github.com/ethereum/execution-apis/pull/484/files#diff-1e4727bbfb75c5cc85054abbf972a1cd472e9e512a9d8bbc8152210a0062182bR116

Aside: It still feels "unclean" to me using a specific non-reserved address, but in researching this I was surprised to learn that EIP-1352 was never officially adopted.

[sambacha]

0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE is not correct if you're using EIP-1191, the correct chainId encoded address would be 0xeeeEEEeEEeeeEeEeEEEeEeeeeEEEEeEEeEeeeeeE

having it as 0x00... would be agnostic to chainId encoding.

Edit: this is a purely aesthetic choice, though I would find it helpful

[MicahZoltu]

I and others have argued against EIP-1191 in the discussion for it: ethereum/EIPs#1121

My position is still largely the same. It is backward incompatible with EIP-55 checksumming, so I generally don't recommend apps checksum to 1191 until long after almost all tooling supports reading 1191 checksums.

[mattsse]

This endpoint sounds very useful. I believe this is very similar to eth_callMany that some clients support: erigontech/erigon#4471

imo it makes sense to introduce a standardized endpoint.
If I understood this currently, then the calls in the batch are treated as separate transactions.
I think multicall could potentially be confusing because "mutlicall" is already widely used as

Multicall allows multiple smart contract constant function calls to be grouped into a single call and the results aggregated into a single result.

https://github.com/joshstevens19/ethereum-multicall#readme

[MicahZoltu]

You are correct, this allows you to run multiple calls against one or more blocks in sequence (all building up the same state). Maybe eth_simulateTransactions or eth_simulateBlocks would be better?

[mds1]

I'm mostly indifferent to the name, but eth_batchCall or eth_simulateCalls are other alternatives that don't overload the multicall usage.

On this topic, why is the method proposed as eth_multicallV1 instead of eth_multicall? Most RPC methods do not have versioning in their name so this seems to deviate from convention. eth_signTypedData_v4 is the only one I know of with versioning

[MicahZoltu]

On this topic, why is the method proposed as eth_multicallV1 instead of eth_multicall? Most RPC methods do not have versioning in their name so this seems to deviate from convention. eth_signTypedData_v4 is the only one I know of with versioning

The lack of versioning in existing JSON-RPC methods has been a thorn in the side of people wanting to make changes to them since essentially the beginning of Ethereum. Rather than continue to cause our future selves suffering to maintain a naming convention, we felt it would be wise to break the cycle and introduce versioning.

As for the naming convention, it follows the Engine API's naming convention (the communication channel between execution and consensus clients).

[mattsse]

but eth_batchCall or eth_simulateCalls

these are great alternative suggestions, would lean towards eth_simulateCalls, because batchCalls could be mistaken as batched eth_call

Using versioning for this sgtm!

[KillariDev]

but eth_batchCall or eth_simulateCalls

these are great alternative suggestions, would lean towards eth_simulateCalls, because batchCalls could be mistaken as batched eth_call

Using versioning for this sgtm!

I think eth_simulateTransactionsV1 would the best. As you can simulate more than just calls, you can simulate transactions

[fjl]

Since almost all clients have this implemented on their default branch now, and the effort to add this feature has been ongoing for a long time, I am merging the PR. The test generator has also been updated and tests will be added in a subsequent commit.

[Hardikgosai1]

Tq

[Hardikgosai1]

Hardikgosai1