Ex Post Facto Cascading Revert

Abstract

A new transaction type reverts one of a sender's prior transactions, and other transactions dependent on that state, recursively.

Motivation

While Ethereum has the capability of reversible transactions through smart contracts, instant settlement is the default. But sometimes users make mistakes. Most mistakes are discovered quickly. However, once the transaction is confirmed, it is settled. There are many use cases for reverting settled transactions. Some of the most-common mistakes are listed below.

• Wrong recipient
• Unintended consequences
• Got scammed

This feature addresses these issues and more, ending all regret.

Specification

Parameters

A new EIP-2718 transaction is introduced with TransactionType 0x5a. The EIP-2718 TransactionPayload for this transaction is rlp([chainId, nonce, revertNonce, budget, signatureYParity, signatureR, signatureS]). The signatureYParity, signatureR, signatureS elements of this transaction represent a secp256k1 signature over keccak256(0x5a || rlp([chainId, nonce, revertNonce, budget])). The EIP-2718 ReceiptPayload for this transaction is rlp([status, budgetUsed, removedLogsBloom, [newReceiptPayloads]]), where newReceiptPayloads is a sequential array of the updated receipts of all reverted transactions.

Block gas limit

A transaction of type 0x5a shall be the only transaction in its block.

Cascading revert operation

A transaction fee budget is initialized to the value specified by budget, denominated in ether. This budget is the transaction fee for this type of transaction. Reverted transaction fees are refunded from this budget. Should the budget be insufficient, the Ex Post Facto Cascading Revert transaction fails and the entire budget is paid to the COINBASE specified in the block header. Otherwise, the remainder of the budget after all transactions are reverted is paid to the COINBASE account.

The state is rolled back to the start of the transaction specified by revertNonce. An access list is initialized empty. Any state previously modified by a reverted transaction is added to the access list. Any subsequent transaction reading or using state included in the access list must also be reverted. This operation cascades forward until the current block.

State includes:

• ether balance
• contract code
• account nonce
• storage keys

Snap sync

Due to the large amount of state that may be modified by such a transaction, slower clients should use snap sync to load the new state.

Rationale

The transaction must fill the entire block to prevent MEV attacks.

While some cascading reverts are highly consequential, others are considerably simpler. The budget ensures the full network cost of the operation is paid. For example, reversing a token transfer to the wrong recipient would be relatively cheap. On the other hand, it would be prohibitively expensive to revert all deposits to a custodial exchange.

Transaction fees must be refunded from this budget rather than the prior block reward in order to protect the security of the consensus protocol.

Snap sync should be safe because if the state root is invalid then the block producer could get slashed.

Backwards Compatibility

If we find any backwards compatibility issue we can maybe reverse those transactions. If that doesn't work idk maybe need another hard fork.

Test Cases

• Reverting a transaction that ever funded an account reverts all of that account's subsequent transactions.
• Reverting the transaction that deploys a contract reverts all transactions interacting with that contract.
• Reverting a transfer to a new account does not revert other transactions.

Reference Implementation

Seems simple enough. TODO this later; should only take a few hours, tops.

Security Considerations

This specification has been audited by Illinois Senator Robert Peters. No exploits were found.

Copyright

Copyright and related rights waived via CC0.