Part of the Linea stack responsible for extracting data from the execution of an EVM client in order to construct large matrices called execution traces.
MMU tracing is made complex by the possibility of LOG instructions to be reverted. Currently this means that these instructions will not to be traced in RAM at all. To solve this issue of "which RAM instructions should we send to the MMU/MMIO pair" our current solution is to defer all tracing to transaction end.
There are various viable options, though.
Various options
option 1:
change the arithmetization to carry out all LOG operations in RAM
transmit the CONTEXT_WILL_REVERT bit from the HUB to LOG_DATA in one of the 2 following ways
either HUB $\hookrightarrow$ MMU $\hookrightarrow$ MMIO $\hookrightarrow$ LOG_DATA
or HUB $\hookrightarrow$ LOG_INFO $\hookrightarrow$ LOG_DATA + have some ID constancy conditions in LOG_DATA for that bit (the cleanest option which requires no modification of the HUB/MMU interface)
transmit to LOG_DATA $\hookrightarrow$ RLP_TXN_RCPT only the filtered data
if the LOG_STAMP becomes a problem we can have a RAW_LOG_STAMP in the HUB and "recompute" the LOG_STAMP it in the LOG_DATA / LOG_INFO modules by accumulating a bit deduced from CONTEXT_WILL_REVERT + padding
option 2: "create the definitive list of MmuCall's only at the end"
make all memory touching sections carry a pointer to the IMC fragment that would contain the MmuCall + the MmuCall itself, already filled out and include it in the ImcFragment at postTransactionDefer (or whatever it's called) with the caveat that it only gets included for LOGs if the context where it was generated does not revert
option 3: "create a preliminary list of MmuCall's and filter the irrelevant ones out during the tracing"
immediately include the MmuCall's in the ImcFragment in all cases
include a bit for LOGs that is deferred to either transaction end or postRollbackDefer and which records whether the current execution context will be rolled back
use that bit in the tracing of the fragment to cancel tracing of reverted LOGs and to correctly update MMU_STAMP
We can also mention the slightly extreme (but technically feasible) and somewhat slippery
option 4:
we could re-enact RAM at the very end when tracing stuff
we just remember the instructions and their parameters
also: this way we wouldn't have to make (partial) snapshots of memory either;
powerslider
commented
3 months ago
Main point
MMU tracing is made complex by the possibility of LOG instructions to be reverted. Currently this means that these instructions will not to be traced in RAM at all. To solve this issue of "which RAM instructions should we send to the MMU/MMIO pair" our current solution is to defer all tracing to transaction end.
There are various viable options, though.
Various options
MmuCall's only at the end"MmuCall+ theMmuCallitself, already filled out and include it in theImcFragmentat postTransactionDefer (or whatever it's called) with the caveat that it only gets included for LOGs if the context where it was generated does not revertMmuCall's and filter the irrelevant ones out during the tracing"MmuCall's in theImcFragmentin all casesWe can also mention the slightly extreme (but technically feasible) and somewhat slippery