Extend Tracing for zk EVMs

[daniellehrner]

Description

Currently the tracing does not provide all the necessary information necessary to create zk-proofs for the transaction executing. Specifically the following two cases are currently not covered by tracing:

• when doing a CREATE(2) / CALL-type instruction we would like to defer an action to the point in time right after the child context re-enters the current context before the execution of the next opcode in the current context
• for many opcodes that can change the state σ and/or the accrued state A we would need to hook into the point in time right after acting upon a REVERT instruction or an exceptional halt (so that the rollback has already happened at that point in time, but the next opcode, if any, hasn't started)

Open questions:

• Which data should be provided by the tracer. Is the MessageFrame enough?
• How can we best test the 2. case, as the revert can happen within nested calls?

[OlivierBBB]

Which data should be provided by the tracer. Is the MessageFrame enough?

We will need

• accrued state (account and storage warmths, maybe selfDestructSet at that point) post rollback i.e. if a REVERT or exception causes some warmth to go back to being cold we need this updated warmth
• the machine state (gas, stack , ...) which is in the MessageFrame
• the current world state (nonces, balances, codes, storage etc ....)
• execution context data (likely available through the MessageFrame or the Hub)

Note. The world state may be available through messageFrame.getWorldUpdater() though I'm not really clear on whether the updater only contains the relevant (currently valid) state deltas associated with the current state of the execution or if it contains the whole (currently valid) updated state.

WRT the hooks

We've implemented a rollbackDefer mechanism that allows us to schedule actions now for later execution (and modifying the relevant trace section). What we haven't done is to connect it to a Besu hook so far. Ideally I would like to request some time from someone on the Besu team to go over the existing hooks. In particular any hook that activates at context "re-entry" such as traceContextReEntry to see if that hook already fulfils the requirements (all changes that may be rolled back were already rolled back.) And similarly for hooks triggering just before exiting a context (traceContextExit).

I'll add a quote from issue #816

The TraceRollback hook should be triggered on rollbacks at the precise point in time when Besu finishes the rollback (in particular of the state (balances, nonces, storage ...) and accrued state variables such as address/storage warmth ...) and before any potential new opcode is acted upon in the parent context. For the root context, Besu hook should be triggered also at transaction end in case it exits with status code 0, similarly: when all rollbacks were acted upon, though before gas/value reimbursement to the sender/recipient and coinbase reward. These "transaction finalization" actions are a separate thing and this hook should appear before them.