by Nicolas Ochem
In proof-of-stake, putting tokens at stake gives you right to participate in the consensus algorithm. Most PoS blockchains assign at least two cryptographic keys to a validator:
- a withdrawal key that lets you spend the funds you put at stake (perhaps after some unstaking time period),
- a consensus key that lets you sign consensus operations.
A hierarchy always exists between these keys: the withdrawal key can be considered the “parent” while the consensus key is the “child”: the withdrawal key has the right to sign an operation that designates the consensus key. The consensus key may be rotated.
Thus, the withdrawal key is rarely used and may be stored in a cold wallet or kept offline in a hardware wallet; the consensus key, in contrast, is used regularly and automatically.
Now, this possibility is coming to Tezos as well with the Lima protocol update.
We would like to thank G.-B. Fefe (a pseudonymous ecosystem developer) who implemented this feature, as well as the Nomadic Labs reviewers who merged it into Octez.
The Feature
You can designate a new consensus key for your Tezos baker by running the following command:
tezos-client set consensus key for <mgr_alias> to <consensus_key_alias>This command must be signed with the baker’s manager key <mgr_alias>, therefore you must have access to its private key. In contract, only the public key of <consensus_key_alias> must be present on the machine where you run this command.
The change takes effect six cycles later (just like registering a new baker). The consensus key alias should then be passed to the baking command, instead of the baker key alias:
tezos-baker-0XX-Psxxxxxx run with local node ~/.tezos-node <consensus_key_alias>At this point, the baker must be able to sign with the consensus key. It no longer needs access to the baker’s manager key.
The consensus key needs not be funded. The bond is always taken from the baker’s manager key.
Setting a consensus key is optional. By default, the baker’s key will be responsible for signing consensus operations, as is the case today.
More details can be found in the Tezos Agora post and the documentation. Also see the video demo of the consensus key (1 hour long) or a 10-minute video summary.
Use Cases
Rotating keys is considered a good practice in computer security. But a Tezos baker changing their address would lose all their delegations. For a public baker, this is not acceptable. A consensus key can be rotated without loss of delegation.
Moreover, designating a different key as consensus key is useful when access to the baking setup is not ultimately guaranteed:
- the baking setup is in a different country or continent,
- the cryptographic key is managed by a Key Management System (KMS) or Hardware Security Module (HSM), which prohibit key extraction.
In case the baking setup becomes disabled or unreachable, the owner of the baker’s parent key retains control over the baker and can deploy a new setup.
Keeping Up
Tezos was the first working proof-of-stake blockchain, but most of the industry is now using proof-of-stake.
We consider it important that Tezos offer the option to use a consensus key as the competition does.
We could go further. The consensus key is stored in a new table in the Tezos context. We could create another row in the same table to let the baker designate a rewards account: it would then be possible for the baking rewards, endorsing rewards and fees to be credited to a third account instead of the baker’s account. This would remove the requirement to periodically move the rewards to a less-secure payout address. This is a no-brainer improvement and we hope to see it implemented soon.
The Drain Operation
We introduce a new Drain operation that lets the consensus key transfer all the free balance of the baker.
This is in contrast with other blockchains in our study; as we introduce a consensus key, we want to be conservative and not inadvertently change the properties of the Tezos network. The Drain operation ensures that both keys have roughly the same privileges: they ultimately let you spend the baker’s funds.
Restricting the permissions of the consensus key so it no longer can spend the funds offers interesting security advantages but may be an impediment to decentralization and network safety.
We had initially suggested to put this question to a referendum with a governance toggle (similar to the Liquidity Baking toggle). This did not make the cut for Lima, but could be implemented in a future protocol, shall bakers express interest in such a choice.
We are MIDL.dev. We offer Tezos Baking and Tezos RPC services.
