New RPC endpoint: eth_estimateGasBundle

[epheph]

Rationale

eth_estimateGas is an important RPC endpoint: one that simulates the specified transaction description and returns an estimate for how what gasLimit is required to allow a contract call to finish.

The problem for mev-geth is that it only operates on a single transaction, while bundles operate on a sequential set of transactions that influence gas usage of latter transactions. For example, in the bundle:

[
  approve,
  transferFrom
]

You can call eth_estimateGas(approve), but there's no way to estimate gas on transferFrom, since it requires the state of approve to be applied first.

We should make an API that accepts a bundle of transactions and returns an array of gas estimates.

This is particularly important for whitehat, as we often leave excess ETH in compromised accounts when we are required to overestimate the required gas limits.

Implementation

We already have:

• eth_sendBundle
• eth_callBundle

We should probably call this eth_estimateBundle or eth_estimateGasBundle.

One design consideration is whether we should be using signed transactions (like eth_callBundle) or unsigned transaction descriptions (like eth_estimateGas). I imagine using unsigned transaction descriptions would be more useful and faster to call (skipping a needless signing step on client, and a needless recovery step on server). The bundle being forwarded is going to be re-signed AFTER this call (to apply better gas limits returned), so signing first is a bit wasteful.

[jparyani]

This was added in #102.

NOTE: This differs from eth_estimateGas in that it does not binary search to find an optimal gasLimit. It only reports what the gas used by each tx in the bundle was.

[libevm]

NOTE: This differs from eth_estimateGas in that it does not binary search to find an optimal gasLimit. It only reports what the gas used by each tx in the bundle was.

What does the binary search do in this case? Is it necessary? I can add that in, looks interesting to dissect

[jparyani]

I think I’m fine skipping on it, but I’ll let @epheph have the final say.

I believe the intention is that setting a gasLimit can actually change the execution of the call. The binary search finds the smallest gasLimit where the call succeeds without running out of gas. See https://github.com/ethereum/go-ethereum/blob/master/internal/ethapi/api.go#L1081