search

flashbots / mev-geth

Go implementation of MEV-Auction for Ethereum
GNU Lesser General Public License v3.0
786 stars 197 forks source link

New RPC endpoint: eth_estimateGasBundle #100

Closed epheph closed 2 years ago

epheph commented 2 years ago

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:

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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