Tezos: in favor of Baking Accounts

UPDATE: based on further analysis by Nomadic Labs, it is no longer recommended to vote for Baking Accounts as proposed during phase 42. See below.
We still believe Baking Accounts is a needed Tezos feature for the reasons explained below. We hope that Nomadic Labs will propose a newer version at a later date that addresses the issues they found.

Tezos is a self-amending blockchain protocol governed by elections by the validators (or bakers). The voting process has three phases:

1. proposal period where bakers upvote to select the best proposal
2. testing period where bakers vote to evaluate the specific proposal selected at phase 1
3. promotion period where bakers vote to migrate the blockchain to the new protocol

Phase 1 has traditionally been a non-event since there was always one serious proposal put forward at a time by the teams working on the Tezos protocol. This time however, the teams at Nomadic Labs, Marigold, DaiLambda, and Tarides have put forward two proposals, which differ in just one feature: whether or not to activate Baking Accounts.

What are baking accounts

Bakers have always been identified by the public key hash of the account where they store their bond (starting with tz). If bakers want to change this key for any reason, they lose all their delegators and have to broadcast the new key to them and get them to delegate to their new key.

Most other delegated proof-of-stake blockchains (for example Polkadot) add one level of indirection in the form of a second key. The “parent key” is the one delegators pick, and the “child key” is responsible for signing consensus operations. This makes it possible to rotate the consensus key. It is useful in case of unplanned incidents (key compromise, forgetting the seed for a hardware wallet) or planned operations (rotating to a new cryptographic protocol).

Baking accounts start with SG1 and this will be the key that bakers advertise to their delegators. All existing bakers and their delegators do not need to do anything, they will keep baking without any disruption. It allows the Baking Account to be collectively managed by a multisignature setup. All details are in the Tezos Improvement Proposal (tzip).

Upvote baking accounts

Protocol 009-PsFLorBA contains baking accounts, and protocol 009-PsFloren does not. The community has until March 14th, 2021 to upvote their proposal of choice.

Baking accounts is a good design, and Tezos needs it. What is more, the proposal is designed for minimum controversy. Problems that were raised in the past were:

• separation of keys makes it theoretically possible to assign different permissions to each key, for example making the consensus key non-spendable. This has implications at the individual baker’s level and at a network-wide level. In Florence, this has not been done, and both baking key and consensus key have the same permissions, preserving the status quo and all its implications in terms of network security,
• separation of keys make it also conceptually possible to add arbitrary computation into the baking process (a.k.a. stateful baking accounts). This also is not allowed in Florence with the exception of the multisig ability. In particular, the ratio of self-bond vs delegated amount remains at 1/8, so this proposal does not change the equilibrium between bakers and their delegators.

Not everyone agrees whether the consensus keys should be spendable, or whether smart contracts should govern the baking process, but nearly everyone agrees that it should be possible to rotate consensus keys. This proposal does only that, and the more controversial changes are left for the community to decide in a future round of voting.

A good reason to vote against Baking Accounts would be that it is disruptive and forces too many breaking changes in the ecosystem (indexers, bakers, smart contracts). However, moving it to a later date does not change this fact, so now is a good time.

How to upvote

UPDATE: this blog post from Nomadic Labs explains why the current baking account proposal is flawed and should not be upvoted as-is.

As a baker, to upvote Florence with baking accounts, run the following:

tezos-client submit proposals for <delegate> PsFLorBArSaXjuy9oP76Qv1v2FRYnUs7TFtteK5GkRBC24JvbdE

To upvote Florence without baking accounts:

tezos-client submit proposals for <delegate> PsFLorenaUUuikDWvMDr6fGBRG8kt3e3D3fHoXK1j1BFRxeSH4i

All details about the voting process are in the Tezos documentation.