Mempool is not Consensus: Ideas to Empower Farmers

One of the most innovative aspects of Chia is it’s pooling protocol. This protocol allows farmers to join pools to smooth out farming rewards while still maintaining the important autonomy of forming blocks — that is, selecting which transactions to include from the mempool when they win a block (and it happens to be a transaction block).

How to select transactions from the mempool, block size, and even local options like mempool size are *not* part of the consensus. As long as the winning farmer creates a valid block, the rest of the network will accept it.

“Customizing transaction selection rules is currently not trivial, and in many cases not possible for farmers using centralized pools.”

Fee maximalism

The default logic when selecting transactions is to maximize for fees. Specifically, transactions are selected from the mempool in descending order of fee-per-cost as not every transaction is of equal size/cost (e.g. NFT transactions are bigger than XCH transactions).

This logic makes economic sense and is what rational miners should be doing. In fact long term economic security of the chain relies on this logic to ensure farmers are appropriately rewarded.

However, it doesn’t need to be this way and there could be some good reasons not to do so!

Ideas to consider

Mock up of a block formation and mempool settings page in the Chia reference full node software.

Here are some ideas that individual farmers that may wish to optimize for:

  • Prioritize own transactions: Make sure your own transactions are included. This is the same as paying yourself the fee.
  • Prioritize new farmer transactions: Help new farmers onboarding into Chia by always including pool plot NFT creation, pool joins, and even payouts from the Official Chia faucet.
  • Prioritize stuck transactions: help users that forgot to add a fee and don’t know how to bump fees by prioritizing transactions that have been in the mempool the longest
  • Prioritize NFT transactions: Choose to support the NFT ecosystem and creators by prioritizing NFT mints, transfers, offers, DID creation, etc.
  • Prioritize Chia Network customers: Choose to prioritize the paying enterprise partners and organizations working with Chia Network such as CAD Trust DataLayer transactions.
  • Ignore certain transactions: While blockchains are about censorship resistance, it is also a permissionless system and farmers have the ability to ignore whatever transactions they wish. Don’t like NFTs? Ignore them. Don’t like inscriptions? Ignore them. Want to adhere to a denylist of sanctioned addresses? Ignore them. Just recognize that you’ll be sacrificing fees and that the next farmer may not have the same rules, thereby delaying but not outright censoring these types of transactions.
  • Ignore transactions with no fees: Some centralized pools already to this as a means to both reduce the computation load in block validation as well as artificially encouraging the onset of a fee market.

All this can also come with certain caveats, such as ignoring some (or all) of the custom rules when the fee is above a certain amount. I may choose to optimize for altruism and give up block transaction fees of 0.005 XCH, but maybe not if the block transaction fee were 3 XCH.

Not every farmer has this power

Customizing transaction selection rules is currently not trivial, and in many cases not possible for farmers using centralized pools like NoSSD or even closed source binaries like Gigahorse. This should be a point of consideration for farmers that care about autonomy in block formation and wish to be more altruistic/creative in their transaction selection.

I’d like to see a GUI implementation (or at least config.yaml options) to make these customizations more accessible.

Would you use this?

I imagine most farmers either won’t care or are content sticking to the default logic.

Would you use this? What other options would you like to see?

Share the alpha
Avatar photo
Slowest Timelord
Articles: 99

Leave a Reply

Your email address will not be published. Required fields are marked *