In one of our previous articles we explained the limitations of the current state of baker keys and its effect on the network. Additionally, as possible ways to address the current limitations, we described enhancing baking accounts and two of its possible design paths that were under exploration in our team: feature design path A) or Baking Accounts, and feature design path B) or Programmable Staking.
This topic was published together with the previous article on the Tezos Agora Forum, through which several community members engaged in discussing this topic. After further analysis and taking the community feedback that we received across multiple channels into consideration, our team has focused our research and engineering efforts in pursuing feature design path A) or Baking Accounts, henceforth referred as Stateful Baking Accounts.
In this article we will describe the specific implementation of Stateful Baking Accounts, which has been further refined from the feature design path A) that was briefly described in the previous article. Moreover, this article details what Stateful Baking Accounts would enable and how it would achieve it.
Recap of the current state of baker accounts and its limitations
If you have not yet, we strongly recommend to read over the background on the current state of baker keys, its limitations, and clarifications on common misconceptions around Liquid Proof-of-Stake. You will find them exhaustively explained and discussed in Enhancing Baking Accounts, particularly in the following sections:
- The Current State of Baker Keys
- Limitations of the Current State of Baker Keys
- Discussing Socio-Economic Concerns
Stateful baking accounts
Simplified description of current baker keys
By leaving out a myriad of complexities, such as how long it takes for a baker to become active, the following is a simplified description of how the current baker keys work under the hood:
Bakers are represented by a single public key. In order to register as a baker the owner of the key has to delegate the key to itself. Once the transaction is executed on-chain, the protocol tracks that specific key as a baker. When a delegator delegates their account to a baker, they submit a transaction that sets the delegate of their account to point to the public key of the baker.
Technical limitations of current baker keys
Note that this section is complimentary to the limitations mentioned in the previous post Enhancing Baking Accounts.
As a quick primer, consensus key rotation describes the ability for a baker to change (or rotate) the key that is used to sign blocks and endorsements. Currently, it is not possible to implement consensus key rotation because the set of delegators for an individual baker is unbounded, since the protocol places no limits on this. However, this means that as long as delegations point directly to the consensus key, this key cannot be changed because it would require iterating and updating a potentially infinite set, which would become a computational attack vector. In permissionless and decentralised networks, it is important to design all operations, taking adversarial environments into account, so that an attacker cannot trigger excessive computation without paying for the full cost.
Furthermore, since bakers are currently stateless, it is not possible to attach additional information to a baker, since there is no structure around bakers as they are simply a public key. An example of desired extra data could be a PVSS key. Adding such a key would allow us to improve the randomness significantly, thereby hardening the LPoS and consensus systems against future attacks.
The design of Stateful Baking Accounts
The design of Stateful Baking Accounts involves the addition of a new structure around bakers. It is a new type of account, that encapsulates extra storage and functionality. Currently there are implicit accounts and contract accounts KT1. This feature adds a third type of account, a baker account with the prefix of SG1, which encapsulates the logic and storage of bakers instead of bolting it into implicit accounts.
The new structure contains three elements:
- a consensus key, which is of type
tz{1,2,3} - a PVSS key, which are secp256k1 group elements with the prefix
GSp - an operator account, which is the same as the formally verified multi-sig script in the Tezos client
The operator account controls the baker and can initiate actions such as changing the consensus or PVSS key or updating the keys within the multi-sig. Furthermore, the operator account is able to authorise spending and governance transactions.
With the introduction of Stateful Baking Accounts, delegations will point to the baker (or SG1 account) instead of directly referencing the consensus key. This is extremely important because it enables capabilities, such as having an operator account or rotating the consensus key.
Note that one of the challenges of Stateful Baking Accounts is remaining as backwards compatible as possible in order to make the upgrade path a smooth experience. Thus, the consensus key will remain capable of authenticating spending as well as governance transactions. This ensures that bakers do not have to change their existing infrastructure.
- For example, reward payment tooling that sends transactions from the baker key will continue to work.
However, all bakers are encouraged to take full advantage of the new features enabled by Stateful Baking Accounts.
Possible future work
This implementation of Stateful Baking Accounts is extensible and in the future new cryptography or data could be added to the baker accounts. For example, a possible future proposal could add a testnet key field to each baker account, which would be used for the testchain, if set by the baker.
Highlight of enabled capabilities
Should Stateful Baking Accounts be adopted by the community, three new capabilities will be enabled. However, in the future the functionalities could be expanded should the community choose to do so.
Consensus key rotation
It will be possible for bakers to change the key, which they are using to sign blocks and endorsements. Note that this key rotation capability does not modify the security argument of LPoS, as the rotation only comes into affect with a delay and can be viewed simply as a movement of rolls from baker A to baker B.
Additional key for PVSS
Bakers will have the ability to generate and set a new GSp key to be used within PVSS (public-verifiable secret sharing), which could be activated in a future upgrade to improve the security of the randomness generation. Randomness is currently generated through a commit-reveal scheme, where each baker commits to the hash of a value, called the seed nonce, and later reveals the original value matching the previously committed hash.
Multi-sig for operators
Bakers will have the ability to use a multi-sig to secure their governance and spending operations, as well as the operations such as rotating their consensus key. This will enable bakers to run more secure bakeries, which will improve the overall security of the network. It will allow bakers of every size to opt for more secure architectures without large resource requirements.
Migration process
Since Tezos is a live network, the migration from the current to the new protocol process is crucial and should be as backwards compatible as possible. With this consideration in mind, the new capabilities of Stateful Baking Accounts are seamless and transparent, meaning that if a baker wishes to maintain status quo of functionalities (single-key for all functionalities), it will still be able to do so even if Stateful Baking Accounts is adopted.
The migration process is designed as follows:
- Generation of SG1 accounts:
SG1accounts will be generated for all active bakers and thoseSG1accounts will be added to the storage. The self-delegations, which currently indicates a baker will be removed from the storage. - Consensus key migration: After the new
SG1accounts are generated their consensus key will be set to the implicit account of the baker, which means that bakers will be able to sign in consensus without having to do anything with their keys. - PVSS key migration: The storage for the PVSS will be initialised but left empty. Bakers can add a new PVSS key in their own time after the migration.
- Operator account: The operator multi-sig will be set to a 1 out of 1 multi-sig with the key being the former implicit account used by the baker. Note that afterwards, should the baker desire so, the multisig can be set to 1 out of n.
Given the above migration mechanism, there will be no action required from bakers nor their keys. If an existing baker wishes to maintain the current single-key-for-all architecture, they will be able to do so. The same is true for newly initiated bakers.
Final remarks
In this article, we have described in-depth the design of Stateful Baking Accounts, which, if adopted, will increase the security and decentralisation of the network. This is due to its ability to enable a more diverse set of people to run high-security bakers, as it introduces three new capabilities (consensus key rotation, PVSS, operator multi-sigs) for bakers.
Noteworthily, the adoption of Stateful Baking Accounts would make Tezos one of the most advanced PoS systems currently in production. Some networks allow consensus key rotation (Kusama), whereas others allow operator multi-sigs (Cosmos). However, at the time of writing, there is no other PoS network in production that supports secure randomness through PVSS and no other PoS network has a validator accounts system that enables all the three capabilities at the same time.
As one of the core development teams of Tezos, we are thrilled to see the progress of the protocol and are looking forward to 007 and beyond.
What’s next?
In order to continue facilitating more community involvement in the protocol development process, Stateful Baking Accounts and other features under development at our team and Nomadic Labs will be available on upcoming public testnets. This way, different user groups can interact with and test the features beforehand.
Additionally, a detailed changelog and documentation describing the modifications introduced by each feature, and migration guides for different user groups, such as wallets, will be released in the upcoming weeks.
Finally, to continue using this article and upcoming ones published on Metastate’s Medium platform as research synthesis and discussion reference, this topic, Stateful Baking Accounts, will be open for discussion on Agora (Link TBA), as well as in an upcoming Core Protocol Development AMA (details TBA).
More resources
Tezos Core
About the team
- Metastate’s Official Website
- Research Blog
For feedback or questions, please do not hesitate to contact us : team@metastate.dev
