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.
This feature addresses these issues and more, ending all regret.
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.
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 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:
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.
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.