108 lines
4.3 KiB
Markdown
108 lines
4.3 KiB
Markdown
|
---
|
||
|
|
eip: 6810
|
||
|
|
title: Ex Post Facto Cascading Revert
|
||
|
|
description: Allow transactions to be reversed after confirmation
|
||
|
|
author: William Morriss (@wjmelements)
|
||
|
|
discussions-to: https://ethereum-magicians.org/t/eip-6810-ex-post-facto-cascading-revert/13630
|
||
|
|
status: Draft
|
||
|
|
type: Standards Track
|
||
|
|
category: Core
|
||
|
|
created: 2023-04-01
|
||
|
|
requires: 2718, 2929
|
||
|
|
---
|
||
|
|
|
||
|
|
## 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](./eip-2718.md) transaction is introduced with `TransactionType` `0x5a`.
|
||
|
|
The [EIP-2718](./eip-2718.md) `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](./eip-2718.md) `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](../LICENSE.md).
|