EIP-1559 Transaction Pool Management

--- tags: 1559 --- # 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](https://github.com/ethereum/rig/blob/master/eip1559/notes-call3.md#important-client-strategies) ## 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