EIP-7906: Transaction Assertions via State Diff Opcode

EIPs EIPs core
,
16

Hello @marc, happy to see you here and thank you for your feedback!

Indeed, one of the main points of EIP-7906 is solving this exact threat and finally giving Ethereum users the bulletproof guarantee that their transactions have absolutely zero unintended consequences!

It would also let us cover state we can’t reach from inside the account at all, like a value in another contract that isn’t exposed through a view function.

Exactly, and it even goes one step further than that. Whenever the contract you are interacting with is a proxy, if the attacker was be able to swap the implementation of the contract, then the same view functions the old checkAfterExecution relies on would be lying to the Guard about the contract’s real state.
Exposing the raw storage slots access, while sometimes tricky, removes these limitations and risks entirely.

That would be extremely useful, thank you! We are currently in the process of creating a testnet with EIP-7906 enabled, and I will be happy to get in touch regarding the testing process.
In the meantime, you can track the implementation progress in the Ethrex client here:

Hello @zergity, nice to meet you!
I appreciate your feedback, however EIP-7906 has been written with an assumption that not all security-critical state changes on Ethereum are 100% guaranteed to be wrapped with an informative event emission.
This is especially important in the context of potential DELEGATECALL operations performed by Smart Contract Accounts, as these calls would be able to modify the storage slots directly, circumventing any event-based guards.

One more thing, as a result of a number of discussions of the transaction assertions approach, I have made a number of significant changes to the EIP worth discussing:

  1. Strictly require a new EIP-8141 Frame Transaction mode to access Transaction Assertions opcodes.
    This is done to prevent the ability of executable EVM code from “introspecting” the state of the transaction execution in-flight, that could create a convoluted mess of interdependencies.
  2. Introduce TXDIFF opcode that allows querying the state changes for a specific (address, slot) tuple without iteration over all state changes.
    Enables more efficient assertions that only care about a specific state changes, as opposed to the expected use-case for TXTRACE opcode.

On the side of Clear Signing, I have been working to introduce a format describing the storage layout and its human-readable meaning to the signers (hardware wallets, etc.)
You can read more about it in the following links:

All feedback is greatly appreciated!