EIP-5081

Expirable Transaction

First Feedback Requested

Zainan Victor Zhou (xinbenlv@github)

2022-05-13 for Ethereum Core Devs Meeting

EIP-5081 Expirable Transaction, Zainan Victor Zhou (xinbenlv@)

General Proposal

• Add a field `expire_by`
• Add block valid requirement
• blocknum <= expire_by

EIP-5081 Expirable Transaction, Zainan Victor Zhou (xinbenlv@)

Problem: Potential Denial of Service Attack

Need to be solved in network level

Attacker

Send a TX called “TXa” w/

soon to expire_by

​

propagate through network but expired

EIP-5081 Expirable Transaction, Zainan Victor Zhou (xinbenlv@)

Question 1: is it really a problem?

EIP-5081 Expirable Transaction, Zainan Victor Zhou (xinbenlv@)

Solution proposals (suggestion but not requirement)

Network layer solutions

1. An early-stop client parameter “early_stop”
2. A network parameter of TTL when propagating a cluster of nodes

EIP-5081 Expirable Transaction, Zainan Victor Zhou (xinbenlv@)

Question 2: Are nodes incentivised to adopt a counter-DoS approach?

• Guts feeling is that for any nodes that received a TXa and is mining a valid blocknum, shall be able to continue to execute the TXa, at this moment, TXa is no different than other regular TX: attracker gets charged
• if it sets a low priority fee, it just gets push down in the priorities.

EIP-5081 Expirable Transaction, Zainan Victor Zhou (xinbenlv@)

Question 3: Is TX propagation incentivized?

• As opposed to Block Propagation, which clients are incentivized to do so they can become are the longest chain
• it seems currently nodes is neither incentivized to propagate NOR not propagate the TXs
• E.g. If a node becomes aware of a super high priority fee of TX, the best interest to itself is to withhold the information of existence such TX to get best chance to
• Even though in the reference implementation all TXs in one’s mempool is queryable, but it seems there is nothing stops a nodes from withholding TXs.
• At the end of day, it seems an implementation can secretly drop that TX from mempool and keep it on the side, but use that TX at the time of mining

​

EIP-5081 Expirable Transaction, Zainan Victor Zhou (xinbenlv@)

Question 3: Worst Case:

What happen if we have compromised / adversary node?

EIP-5081 Expirable Transaction, Zainan Victor Zhou (xinbenlv@)

Q4: Example of other DoS-able TXs?

TX1: Account0 send 1ETH to Account1�TX2: Account2 send 0.5ETH with gas fee 0.5ETH to Acct0

​

Before TX1, the TX2 has no chance to execute, nor does TX2 can incur any cost but since TX2 still has a chance to execute when TX1, is a normal node incentivized to maintain the TX2 in its mempool?

If so, an adversary node can launch DoS attack by issuing many TX2 type of transactions from empty accounts?

EIP-5081 Expirable Transaction, Zainan Victor Zhou (xinbenlv@)

Q4: (Continued) Example of other DoS-able TXs?

​

• Adversary can send many TXs with low gas price but increasing nonces
• Other invalid TXs

​

EIP-5081 Expirable Transaction, Zainan Victor Zhou (xinbenlv@)

Per Ethereum Wire Protocol

​

“Unless noted otherwise, implementations must not disconnect peers for sending invalid transactions, and should simply discard them instead. This is because the peer might be operating under slightly different validation rules.”

EIP-5081 Expirable Transaction, Zainan Victor Zhou (xinbenlv@)

Q5 Can we leave the DoS to be solved at Network layer?

Miners running mining cluster are naturally incentivized to

• Propagate the TXs across nodes
• Restrict soon to expiring TXs in the propagation

So we assume that miner has incentive to adopt DoS implementations

And it should also be up-to-them to find the optimal solutions

​

EIP-5081 Expirable Transaction, Zainan Victor Zhou (xinbenlv@)