ZIP 401: consider increasing the minimum eviction cost
@teor2345 wrote on Discord:
Do we need to increase the mempool eviction cost threshold for Orchard? https://zips.z.cash/zip-0401#rationale
Based on this blog post, I'm guessing that 4000 bytes will get us 3-4 actions?
Transactions with a single proof will be roughly a couple of kilobytes, but the marginal size of additional proof material is much smaller
https://electriccoin.co/blog/technical-explainer-halo-on-zcash/
I replied:
We decided not to, I think But Orchard proofs have turned out a little larger than we estimated, so perhaps we should revisit that
A fully shielded Orchard transaction with 2 actions is 9165 bytes. I recommend increasing the minimum cost to 10000, to avoid penalizing fully shielded Orchard transactions too much. In that case I also recommend increasing the low fee penalty to 40000. This preserves the property that a transaction paying less than the conventional (ZIP 317) fee is deprioritized relative to a min-cost, conventional-fee transaction by a factor of 5, as in the original design. Since we also intend to change the conventional fee, those changes should be coordinated. The total cost limit should also be reconsidered.
This would still result in Orchard transactions having a greater cost for extra shielded components relative to 2-in 2-out (3156 per extra Action as compared to 1300 per extra Sapling Spend+Output). An alternative approach would be to make the cost a function of the number of shielded inputs and outputs plus the size of the transparent part; that would avoid penalizing Orchard relative to other pools or transparent.
In zcashd, the minimum cost and the low-fee penalty are set here: https://github.com/zcash/zcash/blob/92b21576e09e2d6a6f7665dfca4ef7fd447e78ec/src/mempool_limit.h#L23-L24
Zebra is also following ZIP 401 closely.
Another idea is to make the mempool cost exactly the conventional fee based on the number of inputs and outputs, as changed by the proposal in #631. This would have the effect of allowing proportionally more shielded transactions in the mempool.
In a ZIP sync meeting with me, @arya2, @teor2345, and @sellout (@nuttycom was also present but had to leave before these decisions were made), we decided that:
- The minimum cost should be changed to 10000.
- low_fee_penalty should be changed to 40000.
- The recommended default for
mempooltxcostlimitshould remain at 80000000.- Rationale: 80000000 was chosen so that the worst-case size of the mempool would be equal to the worst-case size of 40 blocks, which is the current default transaction expiry delta. That reasoning still holds even with the above changes.
-
eviction_memory_entriesremains at 40000.- It could be lowered given that there will now be at most 80000000/10000 = 8000 transactions "in-flight", but it doesn't need to be because the rationale that "40000 [RecentlyEvicted queue] entries can be stored in ~1.6 MB, which is small compared to other node memory usage" still holds.