Allow transactions to be reversed after confirmation
|Authors||William Morriss (@wjmelements)|
Table of Contents
A new transaction type reverts one of a sender’s prior transactions, and other transactions dependent on that state, recursively.
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.
A new EIP-2718 transaction is introduced with
TransactionPayload for this transaction is
rlp([chainId, nonce, revertNonce, budget, signatureYParity, signatureR, signatureS]).
signatureYParity, signatureR, signatureS elements of this transaction represent a secp256k1 signature over
keccak256(0x5a || rlp([chainId, nonce, revertNonce, budget])).
ReceiptPayload for this transaction is
rlp([status, budgetUsed, removedLogsBloom, [newReceiptPayloads]]), where
newReceiptPayloads is a sequential array of the updated receipts of all reverted transactions.
A transaction of type
0x5a shall be the only transaction in its block.
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
The state is rolled back to the start of the transaction specified by
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.
- ether balance
- contract code
- account nonce
- storage keys
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.
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.
If we find any backwards compatibility issue we can maybe reverse those transactions. If that doesn’t work idk maybe need another hard fork.
- 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.
Seems simple enough. TODO this later; should only take a few hours, tops.
This specification has been audited by Illinois Senator Robert Peters. No exploits were found.
Copyright and related rights waived via CC0.
Please cite this document as:
William Morriss (@wjmelements), "EIP-6810: Ex Post Facto Cascading Revert [DRAFT]," Ethereum Improvement Proposals, no. 6810, April 2023. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-6810.