Chia Keys Architecture
In this post, I will explain the different types of keys in the Chia network, how they are generated, stored, and used.
All Chia keys are BLS-12381 private keys, following the IETF spec, and the EIP-2333 spec for key derivation. Private keys are 32 bytes, public keys 48 bytes, and signatures 96 bytes. Private keys can be generated by using a 24 word mnemonic phrase. Users can back up only these 24 words, and use these wherever they want.
As you can see, the 24 words can be converted to and from a BLS private key. The BLS master private key is stored in the OS keychain, which usually requires password authentication and is encrypted. The master private key can be used to derive child keys, which can further be used to derive child keys, etc. Each time the wallet generates a new address to receive funds, it makes a new bls private key. The farmer and pool only use the first key so far, but they can be updated to generate a new key every time a block is won, for additional privacy.
When it comes to getting paid, a chialisp program is created that uses one of the wallet BLS public keys, and this program, or puzzle, is hashes into a puzzle hash. The puzzle hash is then converted to an address in bech32m format, for easy error correction and usability. So an address is analogous to a wallet child BLS public key, the private key which can be derived from the master seed.
A plot id is a 32 byte value that is used as a deterministic seed to create an entire plot. Two plots with the same plot id will create byte-identical plot files. Plot IDs are public values that get put into proof of space objects.
A plot id can be generated in one of two ways, depending on the desired farming method of the plot.
-
Farm to pool public key. This method of farming is desirable if either solo farming (no pools), or starting to farm without any chia. To farm a plot like this, we hash together the plot public key (explained later), and the pool public key. When successfully farming a block, the pool private key must sign the reward address. The drawback of this method is that if using a pool, the pool cannot be changed, and the plot is tied to the pool forever.
-
Farm to pool contract address. This method of farming is suitable for users who want to farm to a pool, but also be able to change the pool that they belong to in the future. Instead of requiring a signature by the pool, rewards go straight into the puzzle hash (or address), that is encoded into the plot. This address is a smart contract controlled by the user, which specifies the user's current pool. The user can switch the pool, with a certain 24 hour time delay, which will re-route all new rewards to the new pool (not implemented yet). The drawback of this approach is that it requires creating a blockchain transaction before farming. Therefore a user must have chia before starting to farm.
So, what is the plot public key shown in the above image? The plot public key is a 2/2 BLS aggreagate public key, which is generated by combining the farmer public key with the local public key. The local public key is a totally random key that is created for each plot, and put into the plot. They are not children of any BLS keys, and therefore totally independent between plots. The farmer key is a key that the farmer machine stores.
Each block requires a signature from the plot key. What this means, is that we need to combine two signatures: one from the local secret key, which is generated by the harvester, and one from the farmer sk, which is generated by the farmer. The farmer combines both signatures to generate the plot signature.
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.
