clet.xyz

The Ethereum Foundation’s ambitious "Trillion Dollar Security" initiative has pinpointed a critical vulnerability in user experience: blind signing and the inherent uncertainty of transaction outcomes. To address this, the initiative is actively exploring the integration of native transaction assertions, a novel mechanism designed to enforce the final intended outcome of a transaction, complementing existing solutions like Clear Signing. This development promises to significantly enhance user safety by providing a robust layer of protection against unforeseen consequences, even when a signature itself is valid.

The core of the problem lies in the fundamental execution model of the Ethereum Virtual Machine (EVM). A digital signature on the Ethereum network unequivocally authorizes a specific set of instructions. However, the EVM executes these instructions precisely as they are presented, without inherent judgment on whether the eventual result aligns with the user’s intent. The final state of a transaction is a complex interplay between the signed request, the smart contract code it interacts with, and the prevailing state of the blockchain at the moment of execution. This disconnect has historically led to significant financial losses for users, stemming from two primary scenarios: approving an action that differs from their understanding, or authorizing a seemingly innocuous request that, due to network conditions or contract logic, yields an undesirable outcome.

Two Paths to Transactional Disappointment: Intent and Outcome Mismatches

The "Trillion Dollar Security" initiative’s research highlights two distinct categories of failure that underscore the need for enhanced transaction assurance.

1. Intent Mismatch: When the Signature Doesn’t Reflect True Consent

This scenario arises when a user signs a transaction believing it authorizes one action, but malicious interference or a compromised interface substitutes a different, harmful operation. Landmark incidents vividly illustrate this danger.

• The Bybit Incident (May 2023): In this high-profile event, attackers reportedly exploited a vulnerability that allowed them to trick users into signing malicious transactions. Specifically, individuals associated with Bybit’s platform apparently authorized the replacement of a Safe wallet’s implementation contract. This would have granted the attackers control over the compromised wallets, potentially leading to the theft of substantial assets. While Bybit maintained the integrity of its core infrastructure, the incident underscored the risks of compromised frontends presenting deceptive signing requests.

• The BadgerDAO Attack (December 2021): This sophisticated exploit targeted users of the BadgerDAO yield-generating platform. Attackers managed to compromise the platform’s frontend, leading users to approve transactions that granted the attackers permission to drain their tokens. Users believed they were interacting with legitimate platform functions, but the disguised malicious code instructed their wallets to transfer assets to attacker-controlled addresses. The estimated losses exceeded $120 million, emphasizing the critical need for users to verify not just the apparent action but the underlying code being authorized.

In both these cases, the root cause was an "intent mismatch." Users were tricked into signing for actions they did not consciously intend, highlighting the vulnerability of relying solely on the perceived clarity of a transaction request presented by a user interface.

2. Outcome Mismatch: When a Valid Request Leads to Unintended Consequences

The second category of risk, "outcome mismatch," occurs when a user correctly understands and approves the action presented to them, but the transaction’s execution, influenced by external factors or inherent protocol limitations, results in a financial loss or a violation of their intended economic strategy.

• Aave and CoW Collateral Swap (October 2023): This incident involved a user attempting to execute a substantial collateral swap on the Aave lending protocol, facilitated by the CoW Swap (formerly CowSwap) exchange aggregator. The user intended to swap approximately $50.4 million worth of aEthUSDT for aEthAAVE. However, several factors converged to create a problematic outcome:
  • Liquidity Constraints: The available liquidity for such a large trade on Aave was insufficient.
  • Gas Ceiling Limitations: CoW Swap’s gas ceiling mechanism, designed to prevent excessively expensive transactions, rejected more complex or potentially profitable quotes during its verification phase.
  • Unfavorable Quote: This left a single verified quote that, while technically executable, was drastically unfavorable. The interface displayed a stark warning of a 99.9% price impact and required explicit user confirmation that the entire value could be lost.
  • The Result: Despite the extreme warning, the user proceeded and signed the transaction. The ultimate outcome was receiving tokens valued at only around $36,000, a catastrophic loss compared to the intended $50.4 million swap.

This scenario exemplifies an "outcome mismatch." The user understood they were approving a swap, but the interplay of market conditions, protocol limits, and the specific quote presented led to a result far removed from their economic goals. Crucially, in all these instances, there was a lack of a trusted, independent rule governing the transaction’s final state.

The Limitations of Current Defenses

Ethereum currently lacks a generalized mechanism for on-chain code to comprehensively inspect the full spectrum of net state changes and emitted events produced by a transaction. While existing security measures offer some protection, they fall short of addressing these nuanced risks.

• Clear Signing: This approach aims to improve user understanding by translating complex calldata into human-readable language. However, its efficacy hinges on accurate decoding and the user’s ability to correctly interpret the presented information, which can still be challenging in complex DeFi interactions. Moreover, it doesn’t fundamentally alter the EVM’s execution model.

• Simulation: Wallet simulations predict a transaction’s effects based on a chosen chain state. While valuable, this is a snapshot in time. The chain state can change between the simulation and the actual transaction inclusion, and as seen in the Radiant Capital incident (March 2024), malware on a user’s machine can even substitute a malicious payload during the signing process, rendering the simulation moot.

• Contract Checks and Wallet Guards: Protocols like Uniswap implement checks, such as reverting a swap if the output falls below a specified amountOutMinimum. Safe’s checkAfterExecution hook allows for post-execution state inspection. However, these guards are often limited to checking specific, predefined states. They struggle to inspect dynamic aspects of a transaction’s outcome, such as the implementation address of a proxy contract if it’s not exposed via a public function. They lack the ability to query the EVM about all changes, leaving unmonitored side effects potentially unnoticed.

Introducing Native Transaction Assertions: A Paradigm Shift

The "Trillion Dollar Security" initiative’s proposed solution, native transaction assertions, aims to rectify this gap by enabling on-chain code to scrutinize the complete set of net state changes after a transaction has executed. These assertions function as read-only rules, comparing initial and final values against predefined criteria. If these criteria are not met, the transaction’s actions are reverted.

The assertion itself is signed along with the transaction’s actions, meaning any attempt to alter the assertion would invalidate the signature. This rule can encompass a wide range of conditions, including:

• Net Balance Changes: Ensuring that token balances or native ETH holdings change within acceptable parameters.
• Storage Modifications: Verifying that specific storage slots are not altered in unintended ways.
• Code Updates: Preventing unauthorized upgrades or replacements of smart contract implementations.
• Event Emission: Confirming that specific events are emitted or that certain events are not emitted.
• Contract Deployments: Controlling the creation of new contracts.

How Assertions Empower Users:

The power of these assertions lies in their ability to enforce user-defined constraints:

• Minimum Output Guarantees: Similar to existing checks but with broader scope, ensuring a minimum amount of tokens is received in a swap.
• Spending Caps: Preventing a transaction from exceeding a predetermined expenditure limit.
• Blocking New Approvals: Preventing a transaction from granting new token approvals to arbitrary contracts, mitigating the risk of future token drains.
• Preserving Control Logic: Ensuring that critical governance or administrative functions of a contract remain under the user’s control.
• Allowing Specific Changes: Permitting only a predefined set of state modifications, offering granular control.

A crucial aspect of this design is the origin of the assertion rule. A compromised frontend could, in theory, craft a malicious assertion. Therefore, for assertions to be effective, they must originate from independently approved user intent, a standing account policy, or protocol logic that cannot be altered by a compromised component.

Design Considerations and EIP-7906: A Potential Pathway

Developing a robust system for native transaction assertions involves several key design choices:

• Information Exposure: What granular data about transaction outcomes should the EVM expose? This could include all state changes, all emitted events, or a combination.
• Access Mechanisms: How will assertion code access this information? Options range from enumerating entries, looking up specific values, or copying the entire set of changes into memory.
• Execution Context: Where and when should assertion opcodes be permitted to run? Restrictions could apply to specific transaction types or execution phases.

One promising approach currently under consideration is EIP-7906 (Transaction Assertions via State Diff Opcode). This Ethereum Improvement Proposal builds upon the concept of "frame transactions" introduced in EIP-8141. Frame transactions allow for a structured sequence of validation and action steps within a single transaction. EIP-7906 proposes adding a read-only POST_TX frame at the end of such a transaction. This frame would execute as a static call, meaning it can read the transaction’s final state without modifying it.

EIP-7906 in Detail:

• State Diff Reporting: EIP-7906 aims to expose state changes as net differences in native ETH balances and storage slots, alongside newly deployed contracts and their code hashes. A storage slot modified multiple times would be reported as a single entry detailing its initial and final values. If a slot reverts to its original value, it would not appear in the diff.
• New Opcodes: The proposal introduces three new EVM opcodes:
  • TXTRACE: Enumerates net state changes and events.
  • TXDIFF: Retrieves initial and final values for specific addresses and storage slots.
  • EVENTDATACOPY: Copies event data into memory for inspection.
• Static Call Execution: These opcodes would only function within the POST_TX frame, ensuring that assertions are purely observational and cannot alter the transaction’s outcome directly.
• Reversion Mechanism: If an assertion rule defined within the POST_TX frame is violated, the entire transaction execution would revert. However, the transaction would still be included in the block with a failed status, and the gas payer would be charged for the gas consumed. This prevents attackers from repeatedly submitting failing transactions to disrupt network operations or exploit block builders.

While EIP-8141 is slated for the "Hegot" upgrade, EIP-7906 has advanced to the "Considered for Inclusion" stage, indicating its significant potential to enhance Ethereum’s security infrastructure.

The Imperative of Required Assertions

A critical aspect of implementing effective transaction assertions is ensuring they are required when necessary. EIP-7906, in its current form, does not mandate the inclusion of an assertion. This means that transaction builders could omit them, potentially reintroducing vulnerabilities.

• User-Directed Assertions: For individual user transactions, wallets would need to be responsible for embedding the appropriate assertions. These assertions could be derived from simulations performed by the wallet or from pre-defined, standing security policies associated with the user’s account.
• Protocol-Level Enforcement: Protected functions within protocols could enforce the use of frame transactions containing specific, required assertions. This would mean rejecting standard transactions or frame transactions with missing or incorrect assertions, compelling users and integrations to adopt compatible transaction structures. This poses a challenge for already deployed, immutable contracts, which would be unable to retroactively add such checks.

Broader Implications and Future Use Cases

The implications of native transaction assertions extend beyond immediate security enhancements for individual users and protocols.

• Strengthened Delegation: Assertions could significantly bolster the security of delegation mechanisms. When users grant agents the authority to act on their behalf, they could impose precise constraints on which contracts the agent can interact with, the maximum amount they can spend, and the duration of their permissions. Each transaction executed by the agent could then be subject to an assertion, limiting not only what the agent can do but also what its actions produce.

• Protocol-Defined Security Standards: Protocols could establish their own mandatory safety checks for all callers using frame transactions. This would create a baseline level of security assurance for the protocol’s functions.

• Optimized Solver Execution: In decentralized exchange (DEX) environments leveraging solvers, protocols could specify the required outcome of a trade while allowing solvers the flexibility to find the most efficient route. The assertion would guarantee the intended outcome within a single transaction on a specific network, though it would not inherently cover cross-chain workflows.

• Workflow Integrity: Assertions could be used to verify that complex workflows reach their intended final state, ensuring that unused tokens are returned to the user and that any lingering token approvals are revoked upon completion.

The Ethereum Foundation’s "Trillion Dollar Security" initiative is actively seeking collaboration with wallet and protocol teams to refine these designs. By engaging with developers who would be the primary users of these assertion mechanisms, the initiative aims to shape research and development to best meet the evolving needs of the Ethereum ecosystem. Discussions are ongoing on platforms like Ethereum Magicians, and further information on risk controls and priority work can be found at trilliondollarsecurity.org. The development of native transaction assertions represents a significant step towards a more secure and predictable future for decentralized applications.