An overview of the cluster mempool proposal

[instagibbs]

@sdaftuar

However, I don’t think we can easily achieve this behavior while maintaining an additional intuitive property:

• Any transactions we evict under this policy should not succeed in re-entering the mempool if immediately resubmitted.

Can you motivate this as a principled objection? Mempool quality increases, just not in the most optimal way possible. The alternative is to not improve the mempool at all?

@sdaftuar

Alternatively, we could find some child transaction to consider evicting; however if there is more than one candidate, then we might be in a difficult situation of trying to pick which one to evaluate, and there’s no obvious way to make that choice.

Again, if our constraint is “we can only pick the optimal evictions”, sure this is intractable, but I am not convinced of that. For now I’d rather focus on the premise of the objection on the simple non-v3 case.

---

Also while we’re here, the other strategy previously discussed to allow cluster limits to be breached, temporarily and in some limited size/count way, linearize, then “prune” until you get back to cluster limits. Accept/reject said linearization based on normal diagram checks. I know you’ve already dismissed this, but good to have alternatives all in one place.

With other objections you’ve had aside, I think this strategy is more limited because you may not be able to practically make the sibling eviction candidates small.