Pools in Chia

Update: Check the Pooling FAQ for more updates.

As the launch of Chia’s mainnet approaches I want to go over the current status of farmer pools in Chia and what the plans for pooling are in the future.

TL;DR We don’t have pooling fully implemented yet but are building in hooks to make two approaches to farmer pools work well in the future.

We’re approaching pooling support in Chia with caution because they’re a large potential source of centralization in a system which we’re designing to be as decentralized as possible. That said, there are some real benefits to pools: They smooth out farming rewards, especially for small farmers, and they can ensure that good timelord infrastructure is being run. Even so, we recommend that farmers self-pool and have taken steps to make self-pooling as painless as possible. Additionally, in our new consensus algorithm there are 32 times as many reward events per day as there are in Bitcoin. With 4608 chances to win 2 chia each day, we think that even small farmers with self pools will be able to win rewards over reasonable time frames in the early months of mainnet. (Updated February 2021 to modify that it will be 4608 chances to win 2 chia each day.)

That said, it does make sense to use pools in some circumstances so we’re building in hooks for them with certain intended protocols in mind. First and foremost, even when a winning farmer is using a pool, they themselves are the ones who make the transaction block – not the pool. The decentralization benefits of this policy are obvious. To maximize the attractiveness and stability of this method, all the transaction fees generated by a block go to the farmer who found it and not to the pool.

Trying to split the transaction fees with the pool could result in transaction fees being paid ‘under the table’ either by making them go directly to the farmer or making an anyone can spend output which the farmer would then pay to themselves. Circumventing the pool would take up space on the blockchain. It could also encourage the emergence of alternative pooling protocols where the pool makes the transaction block which is a form of centralization we wish to avoid. This method has the downside of reducing the smoothing benefits of pools if transaction fees come to dominate fixed block rewards. That’s never been a major issue in Bitcoin and our block reward schedule is set to only halve three times and continue at a fixed amount forever after. There will alway be block rewards to pay to the pool while transaction fees go to the individual farmers.

Possibly the most debatable part of our planned pooling protocol is that fixed block rewards are set to go 7/8 to the pool and 1/8 to the farmer. This seems to be a sweet spot where it doesn’t reduce smoothing all that much but also wipes out potential selfish mining attacks where someone joins a competing pool and takes their partials but doesn’t upload actual blocks when they find them. Those sort of attacks can become profitable when the fraction of the split is smaller than the size of the pool relative to the whole system. We have the option to change this split before mainnet launch and are open to feedback and opinions about it – which I’m sure people will have. Please be polite.

When farmers make the blocks there is an auditing problem for pools. The pools need to be able to ensure that a farmer doesn’t claim partials from multiple pools or steal whole block rewards when they find them. The simplest way to do this is to have separate pool keys in plot files which sign where the rewards go. This was the first thing we built in the interests of being able to guarantee that current plot files would work on mainnet as early as possible.

This approach allows anyone to join a pool without having prior interaction with either the pool or the blockchain. The downside of this approach is that once you start using a pool you can’t switch without redoing your plots. Our testnet farming community has explained that it’s highly desirable to also have a pooling protocol which allows for switching pools without having to redo plots. I’ve come up with a plan for how to support that.

The new hook for supporting pool switching is an alternative plot format which contains a puzzle hash. A puzzle hash determines how a coin can be spent. It’s the Chia equivalent of what’s called a scriptpubkey in Bitcoin. Pool block rewards are sent to that puzzle instead of there being a pool public key which signs where each reward goes. You might be wondering what this has to do with pool switching. A common theme with Chialisp, our on-chain programming environment, is that the tools look insufficient for doing what you want but are actually capable of doing it in a much more robust and versatile way than more specialized tools could. The next paragraph explains this, but is a bit technical, so feel free to skip.

In order to support pool switching there needs to be some kind of on chain state which determines where a given farmer’s rewards are going which is both auditable by the pool and changeable by the farmer. We have a policy that the only on chain state is the current coin set. Using the combined tricks of backwards pointing covenants as capabilities and hiding state in puzzle hashes we can implement singletons. A given farmer’s singleton needs to have a puzzle which follows a standard template so that the pool can verify that it’s there and can use it to claim farming rewards. That singleton can also have functionality to change what pool it’s pointed at but there needs to be a grace period before the change takes effect during which the old pool can still use it to claim block rewards to keep the farmer from stealing.

This sounds like a complicated bunch of different technologies but we’ve already built several smart transactions which use these primitives in much more sophisticated ways. This approach allows full flexibility for pools to set the parameters for when and how pool switching is done.

The downside of this approach is that it requires posting transactions to the blockchain in order to start using a pool or to switch pools. This incurs transaction fees and is a privacy leak. Our original, and simpler approach also has extra privacy benefits if pool keys are aggregated between the pool and the farmer.

Fleshing out the details of both pooling protocols is beyond the scope of this post and will require real work to complete. We’re planning on supporting both in the future but releasing mainnet is a higher priority right now so please be understanding of our choice to keep our resources focused on launch.

It is always possible for an existing pool to start supporting new protocols and smooth out rewards across all of the protocols so there’s a clean upgrade path for them to support simpler protocols now and expand to more sophisticated protocols later.

It’s impossible to be all things to all people. In this case we’ve made the decision to support pooling in ways which are consistent with how everything else in Chia is done and doesn’t cause ongoing difficulties for a single use case. The downside is that plots being made today won’t be able to switch pools in the future without replotting. For that we are sorry. But we promise that plots of k=32 or larger made today will work on mainnet and continue to do so well into the future.

original source – www.chia.net/2020/11/10/pools-in-chia/