As usage of the Ethereum network for DeFi has increased, more and more transactions are time sensitive. That is, there are transactions for which, if they are not executed in a timely manner users would prefer that they not be executed at all.
For example, consider a simple trade on UNIv3 ETH/USDC. If it executes quickly, then users get a reasonable price and they are happy. If it executes slowly however, it may become stale, users may get a worse price or get sandwiched because their slippage tolerance is no longer set correctly. If is not executed quickly, users might prefer it be automatically canceled so they can submit another transaction.
It is possible to get this kind of behavior currently; however, it requires costly on chain operations, and the transaction may be included on chain anyway, meaning that even though the transaction has been killed, the user still pays gas.
To accommodate these preferences, I suggest adding a new field to ethereum transactions fillBy. fillBy is an optional field where a user can choose a slot which if specified would make a transaction invalid after a certain slot has passed in the same way it would be invalid if the signature didn’t check out or if a transaction with the same nonce from the same user had already landed on chain.
This would be extremely useful for searchers particularly in preventing low carb crusader attacks over multiple blocks, which could eliminate the attack even without single slot finality.
Deadline as a tx parameter already exists and is used by default for txs for uniswap/sushiswap
The problem is conceptual: every transaction is time sensitive in general. Users always want it executed as quickly as possible and this does not improve UX from their perspective: they now have to “track” the tx and confirm that it was executed. The coupling of submission to settlement in their minds is now even moreso.
On a sidenote I think in general this is a good idea as this is how we sort our mempool for txs, LIFO. Makes no sense to waste compute on txs that may not be viable for inclusion.
It can be a feature of whatever, whenever need it.
Changing “execution logic” is overkill for something that is already possible.
If the benefits outweigh the costs, account providers will do it first. They haven’t.
(Currently used in delegation frameworks.)
Wouldn’t this 1 trillion x the mempool size? Potential good L2 differentiator.
reading through the comments, the DDOS line of argument makes negative sense, you can already spam the chain with txs with the same nonce and only one can execute on chain.
All current clients will ignore any transactions that that have the same nonce but do not have a significantly higher fee (I think 12.5% is normal). This ensures that each transaction that is broadcast across the network has to pay at least 12.5% of the bottom of the mempool. With expiration, you can construct a transaction that will almost certainly not be included ever and will eventually leave the mempool without ever paying anything.
Note: This can be mitigated to some extent by requiring that any transaction with a deadline be in the top 1 block of transactions in the mempool (sorted by max_priority_fee) and have a max_fee that is substantially higher than current base fee, and have a deadline that is at least n blocks in the future. This way the chance of not getting included is near zero, so the chance for DOS is near zero.
This design has been proposed in the past, and I think it stands the best chance of inclusion.
I presume that restriction would only apply to propagating transactions and not to confirming transactions? It seems fine if nodes are free to join alternative networks (such as BDN) and for those networks to choose to relay with different criteria, and for nodes in that network to propose transactions that wouldn’t have been propagated in the “official” mempool.
Yes. The DoS vector is around propagation of transactions in the mempool, not around propagation or inclusion in blocks. We want to make sure that any transaction that is propagated must pay something for that propagation to happen.
Wonder if that would help with the use case you mentioned here. I’m suggesting that the priority fee should be burned instead of given to validators for reverted transactions. In your example, txs that will revert due to being past deadline would be most likely ignored by proposers. However, if a malicious user tries to spam the network, they would still have to put funds at risk. While it may not benefit a proposer economically, they could still include the txns to unclog the network.
Hmm, this is an interesting idea, after all, the priority fee should be for priority. But I think having the tx not pay a fee at all if it’s delayed might be a better way to deal with it from a user’s perspective, I also second @barnabe 's point about side contract proofs.
