looks ok.
regarding the entries offset (and order): TXTRACE implicitly defines few tables - balances, slots, deployed, events.
The opcode should clearly define the ordering or entries of each of those tables.
ordering can either by by action time or sorted by address+slot.
note that balances and slots can be modified multiple times, so using the action time is tricky (should it be the first change or the last?)
Also, we can’t keep the relative ordering of different events (did an event happened before/after the slot change or contract deploy)
My proposal: sort balances table by address, and slots table by (address, slot).
events should keep their order - which indeed means you can’t easily find all events of a single contract (which is less important: I want all event of my account, not all even of a specific token..)
Due to a mishap, I accidentally deleted that draft. However, the core idea is that you pre-declare specific locations (such as accounts or storage slots), and the sub-frames are restricted to modifying only those areas. This saves gas because it avoids post-execution state checks, instead verifying constraints directly during the execution of state-mutating opcodes (e.g., SSTORE, CALL). I don’t think it needs to be a separate draft; it could simply be integrated into your existing proposal as an additional mode.
While full state access is beneficial, in most cases, we only need to control specific state points to save on costs—rather than iterating through a list of completed state changes. Consequently, adding lightweight state immutability mechanisms ensures safety while offering greater flexibility in contract design. For instance, if you wish to transfer USDC, simply restricting the scope of changes to the balance slots prior to the transaction suffices, eliminating the need for further state access to perform checks.
Yes, that model can do SOME of the work of assertion - namely, prevent specific storage changes. However, you can’t implement relaxed policies (e.g, limit total transferred amount)
The TXDIFF now allows checking modifications to specific contract without iteration, and thus is only slightly less gas-efficient, while being much more powerful.
It seems you have misunderstood my point. I want to allow changes only at specific positions, while the remaining positions must remain unchanged. You are certainly free to monitor the variations at those specific positions, but doing so is not a mandatory requirement.
I do not think EIP-7906 as it currently stands would benefit from adding an additional “pre-declaration” mechanism, but restoring your draft proposal may still be helpful to inform the discussion around transaction assertions.
Right, unfortunately there is no *reasonable* mechanism that would provide information in the form of “slot A changed after event Y was emitted” or so. However, I don’t think such assertions would be a good idea anyways, so I am okay with the proposed sorting of slots and balances, while events remain sequential.
Please note that gas prices are not set for EIP-7906 and my expectation is that they will be very cheap as the opcodes only provide the “hot” data of the EVM during a transaction.
Yes, I admit your idea is more robust; the original purpose of that draft was to patch the gaps in checks that the InvariantGuard library couldn’t cover. InvariantGuard checks for changes at specific locations but cannot prevent state changes occurring outside its monitored scope—which is why that EIP was proposed. However, your ideas seem to have met those expectations. Upon reflection, the only remaining advantage might be the gas cost. If you have a set of declared allowed positions and a set of runtime state changes, you face O(n^2) lookup complexity—or you would need to use persistent storage to leverage randomness, which would incur higher costs. Furthermore, you would have to verify that no unintended changes occurred, whereas preventing them before the transaction begins eliminates the need for such post-execution checks.