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.