A Consensus Key for Tezos Bakers

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 next protocol proposal (Lima).

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

Assuming the proposal is accepted, you will soon be able to 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 consensus key needs not be funded. The change takes effect six cycles later (just like registering a new baker). The consensus key alias should the 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.

Setting a consensus key is optional. No action will be needed when Lima activates: by default, the baker’s key will be responsible for signing consensus operations, as is the case today.

It is possible to try out the feature today on Limanet, the test network for the Lima proposal.

More details can be found in the Tezos Agora post and the proposed documentation. Also see the video demo of the consensus key.

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.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store