Future Chia Pooling Protocol Enhancements

Getting plans ready before implementation begins

At Chia we aspire to have plans for how to do a project put together well in advance. Unfortunately due to it being needed the minute we launched we had to scramble to get original pooling protocol out. Since then we haven’t had an immediate compelling need or the available resources to work on a new revision. On the plus side this means that we can plan out what to do in the future, and this post is thoughts on that. There will also have to be some enhancements to the pool protocol to support the upcoming hard fork including supporting the new proof of space format and doing a better job of negotiating each farmer’s difficulty threshold but those are much less ambitious than the enhancements discussed here and can be rolled out independently.

With Chia pooling protocol you currently have to make a choice up front: Do you start plotting immediately with no requirement to do anything on chain, or do you get a singleton set up so you can join pools later? As a practical matter right now it’s a no-brainer to set up the singleton: It only takes a few minutes and transaction fees are extremely low. But fees might be much higher in the future and people may want greater flexibility so it would be good to have a protocol which allows both.

‘Chia pooling protocol’ is composed of several things: The consensus-level hook for specifying a puzzle hash which (most of) the farming rewards go to, the puzzles which are encoded for that hook, and the network protocol spoken between farmers and pools. The consensus layer hook isn’t going to be changed, because the Chia way (really the Bitcoin way but Chia has more functionality) is to work based off extremely simple primitives and build everything at a higher layer.

The way current pooling protocol works is that the payout puzzle for plots is a pay to singleton for the singleton which the farmer made up front. This can then be put in a state where its rewards are temporarily but revocably delegated to a pool. One thing which can be improved and is one step further removed from this is that that delegation is to a paying out to a public key owned by a pool. It would be more flexible for it to be to a pay to singleton owned by the pool. That would allow pools to temporarily do profit sharing and for ownership of a pool to be properly transferred. This is an idea we’ve had for a while but also aren’t working on yet.

Anyway, on to the new idea. What’s needed is to be able to pre-specify a singleton to pay to when the singleton when the singleton doesn’t exist yet. The can be done with a modification of Yakuhito’s trick for single issuance. That characterization of the trick is about reserving words where what’s needed for this is reserving public keys and getting singletons issued. What’s needed is a doubly linked list of nodes each represented by a coin and all having the capability that they came from the original issuance. Each node knows the public keys of the previous and next nodes but isn’t committed to their whole identities because those can change as new issuances happen. Whenever a new public key is claimed a new node corresponding to that public key is issued and the nodes before and after it are spent and reissued with that new coin as their neighbor. The most elegant way of implementing this is for there to be a singleton pre-launcher which enforces the logic of coming from a proper issuer and makes a singleton. That way the slightly more complex version of pay to singleton specifies the pre-launcher puzzle hash and needs to be given a reveal of a bit more info to verify that but that’s only a modest increase in costs and is immaterial when you’re claiming a farming reward. This approach nicely hides all the complex validation logic behind the pre-launcher puzzle hash and only has to run it once on issuance keeping the verification logic on payment to a minimum.