MIP-16: JSON-RPC Query Methods (Review)

[typedarray]

Continued from #88, this PR moves the MIP from Draft to Review and includes further revisions.

[DanielVF]

@typedarray Maybe it should be explicit about how eth_queryTransfers handles being in a reverted call set.

For example:

a -> b
        b->c (transfers 10 eth)
        b->d (reverts)

Would seem to have no way to know from the contents of eth_queryTransfers that the transfer did not in fact occur - it would look like the call was successful.

[kyscott18]

@DanielVF Yes, it's important to highlight there are two key revert questions for a trace:

• Did the call trace have an error that caused it to revert (including child call traces with errors that propogated)
• Was the result of the call trace eventually reverted because of an error in a parent trace (note that this is not as simple as checking transaction.status)



I think reverted for a trace and transfer should refer the latter.







It's also an open question whether or not to filter out reverted transfers (writing this out convinced me that, yes, it should be filtered out).

[DanielVF]

@kyscott18 so when the status field is set to reverted then the call was reverted, either from itself, or because something else in the tree reverted? That's good.

Might need a clearer description that that is what status means in the spec then.

And yes, I think it makes sense for ETH transfers to act like logs and not show things that ended up not happening.

[kyscott18]

I did some more research into trace error fields for geth vs parity.

Fields

	geth callTracer	parity trace_*
Frame failed	error is present	error is present
Decoded reason	revertReason (Error(string) and Panic(uint256) only)	none
Revert data	output (absent if empty)	result.output ("0x" if empty)
Rolled back by an ancestor	no field	no field

Observed values (Ethereum mainnet)

Case	geth	parity (Erigon 3.6.1)
Revert with reason	error: "execution reverted", revertReason: "ERC20: transfer amount exceeds balance", output: "0x08c379a0…"	error: "Reverted", result.output: "0x08c379a0…"
Panic	error: "execution reverted", revertReason: "arithmetic underflow or overflow", output: "0x4e487b71…11"	error: "Reverted", result.output: "0x4e487b71…11"
Custom error	error: "execution reverted", no revertReason, output: "0x22611167"	error: "Reverted", result.output: "0x22611167"
Empty revert	error: "execution reverted", no output	error: "Reverted", result.output: "0x"
Invalid opcode	error: "invalid opcode: INVALID", no output	error: "invalid opcode: INVALID", result: null
Out of gas	(18 frames in scan)	error: "out of gas"
Insufficient balance	error: "insufficient balance for transfer"	error: "insufficient balance for transfer", result: null
Transfer rolled back in a successful tx	no error on the frame; ancestor 0.1.4 has error	no error; ancestor 0.1.3 has error

trace_filter

This means that trace_filter has a logical gap because it's impossible to tell whether the result of a trace was eventually reverted by a parent trace.

What does this mean for eth_query

I think we should add a new trace field to communicate whether the result of a trace was eventually reverted by a parent trace and therefore did not contribute any state diffs. In the current proposal, I called that field status. That name is unclear and confusing because it actually means something slightly different than transaction.status.

persisted might be a more applicable name. There should also be a filter added to traces and transfers that by default filters out persisted: false results.

[DanielVF]

I like the clarity with having reverted and error on traces / transfers, and removing status. includeReverted is good too.

[DZakh]

Hey, I'm from Envio. We run HyperSync, which indexes 90+ EVM chains and traces for some of them, including Monad. Some notes after mapping the spec to our data:

1. Transfers include DELEGATECALL

"Any call frame whose value is greater than zero" matches DELEGATECALL frames. They carry the parent's value, but nothing moves.

• Monad (100 blocks): 354 of 1,399 frames with value > 0 are DELEGATECALL (25%)
• Ethereum (30 blocks): 447 of 9,641 (4.6%)

Transfers should be CALL, CREATE and CREATE2 with value > 0, plus SELFDESTRUCT with a non-zero balance. CALLCODE should be excluded too, it sends value to the caller itself.

2. SELFDESTRUCT has no input, gas or gasUsed

These are Required for all traces. Should be Type-dependent. For SELFDESTRUCT, to is the beneficiary and value is the balance.

3. Precompile calls

callTracer includes them, parity-style trace_block doesn't. This changes traceAddress, so the same call has a different address depending on the provider. The spec should pick one. Most archives skip them, HyperSync too.

4. Missing fields

• blocks: mixHash, requestsHash
• transactions: authorizationList (EIP-7702)

5. Always return join keys

You can request blocks without blockNumber on logs, and then you can't match them. The server reads these keys anyway, so it should return them.

[DanielVF]

On Monad, staking is a precompile, and it would fairly useful to have it in both Traces and in Transfers.

[DZakh]

By the way, we are very close to releasing the first implementation of the standard at ENVIO. I'm already excited to share it with you 😉

It's an amazing job, and big thanks for making this standard. I believe it'll drive the whole industry forward. 🙏