Cluster mempool partitioning attacks

The process of relaying transactions within a blockchain network faces significant complications, especially when considering the dynamics of transaction clusters and mempool management. These challenges become particularly pronounced in scenarios involving the processing of blocks that affect clustered transactions, whether by including mempool transactions or by introducing conflicts through included transactions. The necessity of relinearizing clusters after processing such blocks introduces complexity, further compounded by the occurrence of blockchain reorganizations (reorgs) which reintroduce previously disconnected transactions back into the mempool. This situation can temporarily breach cluster count and size constraints, presenting a problem that requires a best-effort approach to resolve due to the sheer volume of transactions involved.

Transaction relay is hindered by several factors that make it non-confluent, meaning that transactions might not be consistently relayed or accepted across the network. Factors contributing to this non-confluence include DoS protection measures that go beyond mere incentive compatibility, encompassing policy rules related to resource limitations and efforts to prevent free relay. Specifically, Replace-By-Fee (RBF) transactions are expected to incur a marginal fee on top of normal fees to account for the relay of evicted transactions. Moreover, the introduction of transaction replacements complicates the determination of an optimal transaction order within a set, as considering both dependencies and conflicts does not yield a well-defined problem with a clear solution. This complexity suggests that even the concept of achieving an optimal choice or sequence among conflicting transactions is inherently flawed without a definitive algorithm to guide selection.

The potential implementation of cluster mempool rules for RBF transactions raises additional concerns. While it aims to ensure transactions eventually relay and confirm once their fee rate aligns with incentive compatibility, requiring senders to generate effective linearizations for their transactions relative to potential cluster attachments introduces an undue burden. This not only demands that wallets and nodes make decisions on their own behalf but also necessitates consideration for the broader network, complicating the transaction relay process.

For further reading on the future implications of cluster mempool management and RBF mechanisms, a detailed exploration is provided in a document discussing post-cluster mempool package RBF and per-chunk processing, accessible here. This write-up delves into the intricacies of managing transaction packages within a post-cluster mempool context, highlighting the added layers of complexity and the considerations necessary for effectively processing transactions within such a framework.