This proposal is to modify to the Ethereum consensus for an opt-in transaction flag to define reverted transactions as invalid (cannot be included in a block). Consideration is made for default mempool DoS mitigation and an attempt at minimizing implementation complexity.
The goal is to make it so that Ethereum can have more decentralized transaction propagation of transactions with “intents” (currently these types of services are usually centralized with a trusted server), more decentralization in block building and transaction propagation, increased market formation directly via publicly gossiped transactions on mempools using tx gas tips, and more decentralized bundling in Account Abstraction transactions.
Pretty cool idea. Not sure why there was no discussion whatsoever regarding the topic. I have several comments though:
Let’s imagine a scenario when a user sends a swap transaction on some dex. Currently, if the prices change beyond the acceptable slippage, the transaction reverts and the user understands that the swap wasn’t successful. However, if the revert_protect was to be set, the user would not be notified that they need to try to swap again. Probably, there needs to be some mechanism incorporated for dapps to be able to track those “dropped” transactions.
It would be great to have a better understanding (probably the rational section extended) of how this proposal would co-exist with ePBS (EIP-7732) and FOCIL (EIP-7805), which will likely be included in the Glamsterdam fork.
There is a very good benefit to the revert_protect approach. It would free up block space (up to ~10% of all the transactions on Ethereum are reverted transactions) and achieve 10% L1 scalability basically for free. It would be amazing to see some numbers on that matter.
It increases UX but at the same time it ALSO increases network CPU usage without any compensation for it. It’s a bad implementation that do not fit in the network itself but as a separate layer(Like flashbots for example).
This is not the case. The EIP explicitly ordains that
[as] a policy rule, [revert-protected transactions are] neither propagated nor accepted on the default Ethereum mempool p2p network.
Thus the network, understood here as honest nodes that maintain a mempool, is not forced to deal with revert-protected transactions in any way. Specific actors, in particular block builders, can opt-in to process said transactions if they see a benefit in it. (e.g. private order flow)
Observe that flashbots, in the way it currently operates, relies on trusted parties (in-part through TEEs) that could include reverting transactions and collect the transaction fee if they were compromised. This EIP removes this possibility. Although it does not, on its own, replace flashbots, it make it more trust-minimized.
By allowing only certain actors to see specific transactions, we massively increase centralization, as some builders will opt in, some won’t, and the rest of the network won’t see these transactions. Now we’re not just centralizing block production, we are centralizing the visibility of them as well.
There’s a big fragmentation risk, as this proposal wants to create two separate mempools.
This is already happening and is not a problem. We already have non-transparent routes for transactions to land on-chain like flashbots and other such services. This is an inherent feature of having a block proposer: we give them the right to put anything they want in the block, with no requirement to disclose it beforehand. At the same time, the public mempool operates just fine: you can distribute your transactions to any prospective block proposer or builder through it, and it is censorship resistant. It will soon become even more powerful with inclusion lists, and that doesn’t require banning non-public transaction flows at all.
There’s a huge difference between optional private routing and protocol enforced exclusion.
Flashbots is optional → I can choose to use it or just use the public mempool
EIP 7640 → makes this fallback impossible for these specific transactions.
The problem isn’t that private routing exists it’s that we want to enforce it, bottom line, it’s more centralization for Ethereum.
The fact that a transaction with the revert protection flag set is excluded from the mempool is a feature. It is the point of the flag. If you want to use the public mempool, you reset the flag and re-sign what is an equivalent and otherwise identical transaction. This is not centralization, it is an additional opt-in feature that helps Ethereum better serve concrete use cases, in particular out-of-protocol account abstraction (no revert for bundlers) MEV auctions (no reverts for auction losers) and MEV extraction (no revert if your block gets reorged) based rollups (no reverts in case of conflicting batches) etc. Taiko Labs and some bundlers on Polygon have already lost money on this, and the network didn’t really benefit: there’s better uses for gas than reverts that do nothing.
You’re saying this is an optional feature, but it’s only optional for the people who control the infrastructure. A user can unset the revert protection flag, but that just reintroduces the same issues we are trying to avoid, it doesn’t solve the main problem. It’s like a bad hotfix.
The point of revert protection is to not pay gas fees for failed transactions. If we tell them to just unset the flag, they now have 2 choices:
Use revert protection → protocol enforced exclusion