EIP-1559 Transaction Pool Management

EIP-1559 adds some complexity to how the transaction pool needs to be managed. For example, when replacing a transaction by fee, the naive strategy of replacing any transaction where the FEECAP is higher than the precedent one can lead to DoS attacks, even if there is a minimum "bump", because whatever portion of the FEECAP isn't burnt or sent to miners is refunded to the user. Similarly, a naive transaction sorting strategy by the amount sent to miners can cause the transaction pool to have to be re-sorted at every block for legacy transactions.

This document details the approaches taken by various implementation team for four elements of transaction pool management: replacement, eviction, sorting and gossping. Hopefully, by comparing various approaches, we can suggest a prefered one, or at the very least make explicit the tradeoffs between certain approaches.

Transaction Replacement

How do we decide whether to replace an existing transaction in the transaction pool by another one, likely with a higher "gas price"?

Vulcanize

Besu

Nethermind

Other approaches

• Barnabé's notes from Implementers' Call #3

Transaction Eviction

How do we decide which transactions to evict from the transaction pool and why?

Vulcanize

Besu

Nethermind

Other approaches

Transaction Sorting

How do we decide the order by which transactions are sorted in the transaction pool (and hence included in a block)? Ideally, how do we avoid re-sorting the transaction pool at every block if the base fee has moved?

Vulcanize

Besu

Nethermind

Other approaches

Transaction Gossiping

How do we decide which transaction to gossip, not gossip or use to mark a peer as "bad" and drop it?

Vulcanize

Besu

Nethermind

Other approaches