EIP-7756 EOF/EVM Trace Specification

EIPs EIPs interfaces
1

Discussion topic for EIP-7756

Update Log

  • 2024-08-14: initial draft PR

External Reviews

None as of 2024-08-14.

Outstanding Issues

2024-08-14: member name for CALLF retrun stack - fdepth or something else?

3 Likes
2

There are a small number of additions to EIp-3155, other than that it is the same as the older trace spec.

  • The immediate member was added to support the large number of instructions that contain immediate operations.
    Without this change, users would need bytes of the contracts being executed to rationalize the traces.
  • The section and fdepth members were added to support EIP-4750 EOF Functions.
  • Added clarification around where pc indexes when run in an EOF container (start of section is PC=0).
3

First some minor comments:

  • why returnData is not required anymore? also it’s inconsistent with the note below saying it can be left out when empty
  • I would not omit functionDepth if it’s zero (only when legacy EVM), to be consistent with section
  • for RJUMPV I would enforce the entire table (and for PUSHx the entire value) in the immediate field, otherwise the immediate field would need to be likely left out of fuzzing etc., as it is expected that client implementations of tracing will diverge if given the chance. Also for pure consistency sake; otherwise someone looking at a trace with PUSH1 and without the immediate might be confused.

We should specify whether stack for EOF is for the entire message call or for the current code section (i.e. the latter would start with only code_section.inputs top items at the start of a code section execution). I have no preference on which option is better, but this should be specified. Also we should now describe stack as “operand stack” in the “Explanation”.

A general remark I’d like to make is that while this improves trace-fuzzing for EOF, it should not be seen as a blocker. I suppose 90% of EVM/EOF runtime features will still be successfully fuzzed with the original 3155 traces. Even if there’s any inconsistencies in tracing fields like pc, that can be rather safely left out until made consistent.

Two last comments reflecting more on EIP-3155, so I guess by now it’s way too late to change. But I’m interested anyway in the rationale of the decisions made in EIP-3155

  • I never understood why we use Hex-Number for things like gas. I understand we cannot use a JSON-number (too large values), but why not a Dec-Number string? In all spec I can think of gas is formatted in decimal
  • OTOH, I would prefer op to be Hex-Number, this is how those are usually formatted.
4

For the 3155 traces to be usefule in EOF we either need to add code section or have PC be indexed from a common point (container start, or code section start).

The mandatory GoEVMLAB fields appear to be

  • Depth (message frame stack size)
  • PC
  • Gas Remaining
  • Operation (number only, as name differences look to be ignored)
  • stack (only top 6 items)
  • error

Optional is

  • gasCost (different clients have different interpretations)
  • memory size (nethermind has quirks about when it is measured)
  • refunds (nethermind doesn’t provide it)
  • returnData (nethermind doesn’t provide it)
5

I updated the spec with the following changes that will land as soon as eth-bot merges:

  • change gas, gasCost, gasUsed to Number
  • change opcod to Hex-Number
  • Allow Numbers and Hex-Numbers to be used interchangeably.
  • remove required column in favor of multiple sections
  • editing cleanup

This doesn’t address all he issues above, but gets the essential ones that I feel improve the spec.

I consider the other issues open, and will review them prior to last call (when EOF ships). However these were important to get the Fuzzing working IMHO.