So, what is the plot public key shown in the previous section? The plot public key can technically be any BLS public key. As long as the correct signatures are included in the block, full nodes will allow it. However, BLS allows us to combine many public keys into one, which allows native N-of-N signatures without full nodes noticing that a multi-signature is used. In the current versions of
chia-blockchain, we use this to our advantage to increase security. Please note that these schemes are not consensus critical, and therefore some farmers might use different strategies for generating their public keys.
The plot public key is usually generated in one of two ways, the first for OG Plots, and the second for pooled plots.
- The plot public key is a 2/2 BLS aggregate public key, which is generated by combining the farmer public key with the local public key.
- The local public key is a random key that is created for each plot, and put into the plot. They are not children of any BLS keys, and therefore are totally independent between plots.
- The farmer key is a key that the farmer machine stores.
For plots which are generated for use with the Plot NFT pooling protocol, an additional "taproot" secret key is used, making the aggregate key a 3-of-3. This 3rd key can be derived from public information of the other 2 keys, and it ensures that an attacker cannot create two new keys k1 and k2 such that they both add up to the original aggregate key.
The taproot private key is defined as:
taproot_sk = BLSKeyGen(sha256(bytes(local_pk + farmer_pk) + bytes(local_pk) + bytes(farmer_pk)))
Each block requires a signature from the plot key. This means that we need to combine two (or three) signatures:
- from the local secret key (generated by the harvester)
- from the farmer secret key (generated by the farmer)
- (optional) from the taproot key (generated by the farmer)
The farmer combines all the signatures to generate the plot signature, which will look like a normal 1-of-1 BLS signature to the rest of the network.
Note that signatures from both the local secret key and the farmer secret key are required for the block to be valid. A pool operator cannot derive the farmer secret key if they gain access to the local secret key.
The plot format depends on whether "farm to public key" or "farm to contract address" is being used. If farming to a contract address, the puzzle hash (address) is directly encoded into the plot. Otherwise, the pool public key is directly encoded into the plot.
This is not the exact plot format, there are a few more details that are left out here.
The important thing is that the harvester is only storing their local key in the plot, but no other keys are required from the harvester. This key alone is not enough to do anything, since it must be combined with the farmer's key. Therefore, compromising the harvester does not allow an attacker to redirect rewards.