An overview of the cluster mempool proposal

An overview of the cluster mempool proposal

Original Postby instagibbs

Posted on: February 8, 2024 14:15 UTC

The blog post discusses a strategy for handling large proposed chunks within a transaction cluster that may exceed the cluster's capacity in terms of size and count.

To manage this, the algorithm initially adds all existing chunks to a minheap prioritized by their Cumulative Fee Rate (CFR). It then iteratively processes transactions from the chunk with the lowest CFR, evaluating them in reverse topological order. Transactions that are part of the proposed chunk's ancestor set are ignored, while others are marked for eviction. The algorithm continues to mark transactions until the remaining size and count thresholds are met.

If any transactions are marked for eviction, a subsequent diagram check is recommended. This step ensures that transaction clusters have not been inadvertently split during the eviction process. However, specific details regarding the checks on the remaining size or count are omitted intentionally as they're deemed unnecessary for this validation.

To make the eviction process more efficient, it could be narrowed down to transactions more closely related to the proposed chunk—specifically, those that are descendants of the chunk's ancestors, excluding the ancestors themselves. This localized approach aims to ensure evictions can still occur when the new chunk has sufficiently high fees while also minimizing the broader impact on the transaction pool.

The described method promises enhancements to the mempool's management with an O(nlogn) processing complexity and eliminates the need for resubmitting transactions. The approach, however, does not address the issue of incremental relay pins.

For additional reference and context, readers can follow this link which may provide further insights into the topic discussed.