Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New RPC endpoint: eth_balanceDeltaBundle #101

Open
epheph opened this issue Dec 15, 2021 · 3 comments
Open

New RPC endpoint: eth_balanceDeltaBundle #101

epheph opened this issue Dec 15, 2021 · 3 comments

Comments

@epheph
Copy link

epheph commented Dec 15, 2021

Rationale

We should find a better name for this, but the idea is that a bundle often changes token balances (ETH, ERC20, NFT's, etc) and while it's possible to "sandwich" your bundle with balanceOf calls for specific tokens you expect to transfer within a bundle, for a specific account, we could automatically figure out which tokens were moved. We should create an RPC endpoint that returns a report of all token balances that were modified as a result of this bundle running in simulation.

When conducting whitehat rescues, especially for a brand new rescue type, this is one of the most sensitive issues: your custom code worked enough to rescue assets, but has a bug that locks assets or transfers to the wrong place. Having bundle execution distilled to a set of balance changes would help prevent accidental fund loss by providing positive confirmation of token flow.

If this could be combined with Flashbots protect RPC endpoint, we could easily prevent certain behaviors from propagating through our RPC (like TokenOops).

Implementation

I think this would be a separate endpoint from callBundle, as that should be as fast as possible, and this implementation would require at LEAST two simulation passes and many extraneous storage lookups.

Would be fine to either use signed or unsigned transactions

@libevm
Copy link

libevm commented Dec 22, 2021

It would be great to make this as generic as possible and not limit it to certain standards i.e. ERC20 / ERC721.

My API proposal would be something like:

method: 'eth_balanceDeltaBundle'

params: [{
    balanceDelta: [
        // This should return a uint256, for a future PR, we could add a "formatter" akin to the debug_trace*
        // JavaScript runtime environment
        { address: '0x0...', data: '0x0....' } 
    ],
    txs: [ ], // signed or unsigned txs, same as callBundle
    stateBlockNumber: 1,
    blockNumber: 1
}]

For now we can just assume all balances is uint256, and the response should be roughly:

result: {
    balanceDelta: [
        { delta: 100 }
    ],
    txs: [ ... ] // normal callBundle tx return
}

Let me know your thoughts

@thegostep
Copy link

For now we can just assume all balances is uint256

I like the simplicity of this api. By convention we can deem a null data field to return the ETH balance.

Care must be taken for the result to be an array of signed 256 bit integers.

@thegostep
Copy link

thegostep commented Dec 22, 2021

An even more generalized api would be a pre-flight and post-flight multicall. Though this is probably overkill.

Something like this:

method: 'eth_balanceDeltaBundle'

params: [{
    preCheck: [
        { address: '0x0...', data: '0x0....' } 
    ],
    postCheck: [
        { address: '0x0...', data: '0x0....' } 
    ],
    txs: [ ], // signed or unsigned txs, same as callBundle
    stateBlockNumber: 1,
    blockNumber: 1
}]

result: {
    preCheck: [
        { result: '0x0....' }
    ],
    postCheck: [
        { result: '0x0....' }
    ],
    txs: [ ... ] // normal callBundle tx return
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants