[BUG] Pooling plots not usable for pooling on other chains without breaking consensus protocol changes

In the current iteration, the official pooling protocol on the pools.testnet9 branch works as follows:

1. Users create a “Plot NFT” which is a “singleton” on the Chia mainnet chain. What this (roughly) means is that a coin is sent to the special singleton_launcher contract (which acquires a coin ID subsequently referred to as the launcher_id) which subsequently creates the singleton, which comprises singleton_top_layer that wraps an inner puzzle (like pool_member_innerpuz if you intend to farm to a specific pool). The singleton_top_layer contract enforces certain security guarantees about the lineage of that coin, for example that it’s a direct descendant of the launcher with the curried in launcher_id. As a pool member, the pool_member_innerpuz contract grants the pool owner the right to claim any pool rewards by asking the inner puzzle to signal by creating a puzzle announcement (see below).
2. Once the Plot NFT singleton is created on the Chia mainnet chain, the user will use the address of a p2_singleton_or_delayed_puzhash contract with the specific launcher_id baked in, as the target puzzle hash for plotting. This target puzzle hash (with the launcher_id) is then baked in and lives forever in the plots (though the singleton may morph).
3. When the pool member earns a reward, the pool_member_innerpuz contract signals via a puzzle announcement, which is asserted by the coin with the p2_singleton_or_delayed_puzhash puzzle before being disbursed to the pool operator. This process requires the exact singleton with the same launcher_id to be used to signal.

Now, note that this protocol relies on the launcher_id being present as the coin ID of the launcher coin, and this can’t be changed because it is baked into the plots. Under existing consensus rules, because any non-farmed coins have their coin IDs generated as some hash of its parent coin info and amount, a singleton with this launcher_id can only exist on the Chia mainnet chain. This means for example, that under the current consensus rules and pooling protocol, no Plot NFTs can be portable between testnet and mainnet (so that plots created with this new scheme, under current consensus rules, can only ever work on Chia mainnet). For other chains, the only feasible way to support pooling for these new plots (as I understand it) is to change the consensus rules and add a limited mechanism for importing a “foreign” Chia-mainnet-chain singleton at its existing launcher_id address.

I’m not an expert here so this is sort of schematic, but one could imagine an approach here that could be more portable across chains. For example, instead of committing to the launcher_id in the puzzle baked into the plots, we could instead commit to a puzzle with some public key. The corresponding private key could be used to create (potentially many) singletons that track the user’s pooling state. It’s likely this could be done in a way that it’s possible to enumerate all the singletons that derive from the public key, and the pool operator in this case could be expected to follow the first-created valid singleton for the public key as authoritative. The pool operator could require all other valid singletons be set to an invalid inner puzzle (disallowing pool reward claims) with a waiting room before exiting. This should be secure in the same way because to exit a pool, the user needs to first transition to the waiting room, before the authoritative singleton is either changed or melted. This has the advantage of being more “symmetric” with respect to the network in which the Plot NFT is created, and naturally allows Plot NFTs to be portable across chains, for example only requiring a registration for moving between testnet and mainnet. This also more naturally handles the case where the singleton is melted: the handling right now disallows these plots from ever being used for pooling again.

In recent announcements, it was declared that the pooling plots were going to be designed with “cofarming” in mind, so that they could be used across chains, in order to promote usage of a single set of plots for PoST chains. However as described above, this is not actually possible under current consensus rules / CLVM semantics, so a protocol hard fork would be needed to allow for cofarming on other chains. Is it intentional that breaking changes to consensus rules will be needed to cofarm with pooling on chains other than Chia mainnet, and would a more portable approach like the one described above be considered instead for the pooled farming puzzle?

@mariano54 @richardkiss @hoffmang9 @bramcohen

[altendky]

The recent messages here look like Flax support questions, not a continuation of the completed discussion above. Could this newer discussion please be moved to a Flax support venue?

[diomark]

Sorry just adding my input here. NFT plots don’t appear to work. Not even for the smaller 0.25 reward.