This article was originally posted here on Cryptium’s Tezos Medium blog.
Meanwhile at Cryptium Labs #2 Part 1: Enhancing Baking Accounts
In May 2019, we published the first chapter of the Meanwhile at Cryptium Labs series. The purpose of this series is to share details with the Tezos community on features that are being explored by our team (see for example, Chapter #1 Part II on Quorum Caps). This article marks the beginning of the second chapter. This time, we will dive deep into one of the features we are exploring: enhancing baking accounts .
It starts with a recap of the current state of baker keys. It is followed by the description of some limitations that it presents, which range from security to socio-economic limitations, illustrated with practical examples and references to real-life events. This is followed by a recap of the current design of baker keys, sharing the rationale of its design. Afterwards, we introduce two possible feature design paths that could mitigate the limitations of the current baker keys, together with an analysis of their technical advantages and disadvantages. Then, we discuss in-depth socio-economic concerns surrounding both feature design paths and provide corrections to misconceptions, in addition to methods to mitigate the concerns when applicable.
Enhancing baking accounts is still in internal exploration and we would like to gather feedback from the community by opening the topic for discussion on multiple platforms.
The Current State of Baker Keys
In the current Tezos account system, in order to participate in baking, entities need to generate an implicit account (tz{1, 2, 3}) and self-delegate it, in order to indicate that they would like to bake. The baker’s implicit account is characterised by its private key’s ability to carry out three activities: spend funds (transfers), participate in consensus signing (baking and endorsements), and cast votes on proposals and ballots undergoing Tezos on-chain governance.
One could draw the similarities between the current baker key with a Swiss Army knife — a One-Tool Wonder , as one key allows the baker to fulfill all three functions of transfer, signing in consensus, and voting in governance. Nonetheless, a Swiss Army Knife with too many blades weights down the soldier .
Recap of The Current Baker Keys Design
In this section, we will take a look at the current design and provide background on its rationale. The current design of baker keys has the following benefits:
First, it is conceptually simple, which makes it easy for bakers and users to understand and interact with, and technically easy for core protocol developers to implement, which was paramount in the first version of the Tezos protocol.
Second, by forcing all baker functions to be performed by the same key, it makes it more difficult for bakers to, for instance, trade their governance vote, as it would require the baker to carry out off-band manual coordination. Similarly, by coupling all functionalities into a single key, it discourages a market of borrowing stake because it forces the lender to trust the baker.
Additionally, as baker keys are relatively easier to steal than ASICs (especially when they are file-based and stored in the cloud), by coupling the ability to spend with baking and endorsing, it creates additional incentive for bakers to invest in security and op-sec.
Lastly, an attribute of the current design is that voting transactions do not compete for priority with regular transactions (e.g. transfers), thus making them harder to censor via Denial-of-Service attacks (DoS).
Limitations of the Current State of Baker Keys
1. Inability to Update or Change Accounts
With the current baker keys, bakers are unable to change or update their key without out-of-band coordination with their delegators. Should there be an exploit, vulnerability or limitations in the cryptographic libraries or protocols that were used to generate the key or should the baker wish to make changes and improve their infrastructure setup, they would have to convince all their delegators to manually move their delegations. Some examples are:
- A baker, which has improved their account setup for a more secure one, has to off-band coordinate with delegators to re-delegate from their old tz1 to their new tz3 account.
- The case of a baker that started with file-based key and later on wanted to upgrade to a Hardware Security Module (HSM).
2. Security
While having a one-key-for-all seems convenient at first, it turns every baker into an attractive target for attackers and extortionists, which are not unusual in the realm of public decentralised networks. In the past years, malicious agents mainly targeted exchanges and wallets (see this Chainalysis 2019 article).
The issue comes from the fact that an attacker that successfully gains access to a baker’s key would also be able to steal the funds. With the emergence of Proof-of-Stake networks such as Tezos and staking businesses, it would not be a surprise to see an increasing amount of the latter being targeted by malicious agents (see the recent case of Norn Tezos Delegate).
Due to the current baker key’s design, access to the consensus key also results in access to spending the funds. Thus, one could argue that there is globally more funds at stake that come from the liquid assets residing in the baker key in addition to the security deposits. However, in practice, strategic bakers will try to minimise the amount of funds, so that it is just enough to fulfill the security deposit requirements. Furthermore, liquid funds tend to be proportionally much smaller than the amount in security deposits at stake. Moreover, forcing all bakers to use one key increases the risk of an attacker gaining unauthorised access to the key which reduces the overall network security.
3. Constraints in Security Architecture & Op-sec Policies
In Tezos the level of security of the network is as high as the security of its bakers. For illustration, a malicious attacker with access to the keys of ~1/3 of the global consensus power can fool light clients and, in the worst case, can weaken the security of the network. As such, it is in the interest of the network to enable bakers to run highly secure operations, by allowing bakers to deploy more resilient key-management systems that provide extremely high security for consensus-critical keys.
Nonetheless, with the current baker key’s design, the functions of spending, signing in consensus (baking and endorsements), and voting in governance are coupled into a single key, even when they require very different availability schemes– resulting in strong constraints for the baker to implement more resilient key-management systems, thereby potentially undermining the overall security of the network.
For illustration, let’s consider a fictional baker TEZcacohuatzin :
- TEZcacohuatzin spends funds every ~3 days to send rewards to its delegators;
- has the baking key active at all time to avoid missing a baking or endorsement slot;
- votes every ~3 weeks in governance.
Although each of these functions demand very different availability, with their current baker key, TEZcacohuatzin cannot limit the exposure or attack surface of their key while carrying out the different functions. In other words, every time TEZcacohuatzin votes in governance, they are exposing the key to attackers who could exfiltrate it in order to attack the network by causing forks and fooling light clients. The only way of limiting this exposure would be to decrease the frequency or forfeit the functions completely outside of signing in consensus (for baking or endorsements).
4. Constraints on Innovation around Baking Services
With the current baker keys, every baker has limited degrees of freedom to design and offer differentiated baking services without relying on out-of-band operations. Some examples of ways and areas where a baker in the Tezos ecosystem could want to innovate:
- Sharing of baking rewards : currently bakers receive the inflationary rewards from the protocol. Most bakers agree to manually share a portion of their rewards with their delegators. One side effect of this is that delegators must trust that the baker will: 1) share the rewards, 2) do it on time, and 3) share the correct amount. From the delegators’ side this requires constant attention and due-dilligence to check basic things like whether they are receiving the correct amount.
- Provide more optionality for delegators : for example enable the delegator to choose when to withdraw the funds, which could be beneficial depending on their respective tax environment.
- Funding of public goods : such as committing a portion of the baking service fees to a DAO or donation account for open-source software.
It could be argued that by forcing delegators to manually check, whether they received the correct rewards on time, it encourages them to actively engage with the system and carry out due-dilligence. However, the downside is that it limits the type of baker that users are willing to use, since most users will not have enough bandwidth to constantly check a triviality. An analogy to this type of delegators could be the following:
- A car owner does not want to check every three days their car’s oil levels but would either not use such car or pay a trusted mechanic to do it on their behalf.
The current baker’s design requires an non-trivial amount of resources and commitment from Tezos delegators, as they are required to check a number of things, such as whether their baker is over-delegated, has paid out, done so correctly and on time*. Due to this, well-established entities such as exchanges or custodians, who are well-known and trusted, have in recent months seen a substantial inflow of delegations.
*This topic is being explored by many members of the Tezos community, see for example this topic of discussion on “Baker’s Reward Automatic Distribution" on Tezos Reddit.
5. Centralisation
Another limitation with the current baker keys can be illustrated with the following cases. Ever since the launch of Tezos in summer 2018, there have been bakers that decided to stop their bakeries. Even though the reasons of the majority’s decision to stop the bakery remain unclear, TzDutch (located in the Netherlands) publicly shared some of their concerns surrounding the economic unfeasibility of continuing their operations due to lack of resources for:
- Day-to-day operations, such as payment of rewards, maintenance of infrastructure and security improvements.
- Regulatory uncertainty on taxes, compliance, licenses*, such as AML or risk assumed due to the custody requirements of rewards and security deposits.
- Limited options to raise capital for their security deposits, which is more severe for small to medium public bakers, as larger bakers or established organisations, such as exchanges, custodians, and VCs, have access to more resources, such as existing relationships with investors, established legal department, strong branding, etc to raise capital from contributors.
Should the above items turn into obligations for all bakers, it will drastically increase the resources required for anyone to operate a bakery in their respective jurisdiction, which will lead to more bakers stopping their bakeries. Additionally, it would enhance a limited type of organisations’ suitability to offer public baking services on Tezos, such as banks, exchanges, funds and businesses alike, with high access levels to capital and other resources to conduct jurisdictional arbitrage.
Moreover, currently small bakers have a hard time competing with larger bakers due to the fact that larger bakers are generally not limited by access to capital, but rather by access to public on-chain delegation. However smaller bakers have a hard time accessing capital which is limiting their potential growth leading to more centralisation over time.
*Note that, although regulations around staking businesses remain unspecified in most jurisdictions, there are initiatives such as EBA in the European Union and POSA in the United States with active working groups.
Exploring Possible Feature Design Paths
In the previous section we examined some of the limitations that the current baker keys design has. Now, we will describe two possible feature design paths that could address the limitations of the current design and describe their advantages and disadvantages.
Note that should either feature design path be adopted, they would be implemented in an opt-in manner, the default behaviour will conserve the status quo.
Feature Design Path A) Baking Accounts
The main idea behind this feature path is to decouple the functions of spending, baking/endorsing, and voting in governance from a single key — and rather split the functions across more than one key, depending on the security architecture or op-sec policy preferences of each individual baker.
For illustration, our fictional baker TEZcacohuatzin could substitute the current one-key-for-all account to:
- have one consensus key, which is only able to bake and endorse;
- have a 2/3 multisig for spending;
- have a 1/3 multisig for voting in governance.
Baking Accounts add a new structure around a baker that can be used when delegations refer to a baker, which would enable bakers to address the inability to update or change accounts ( limitation #1 ), reduce its attack surface to malicious agents that want to steal the funds or attack the network ( limitation #2 ), and gain higher flexibility for improving their security architecture and / or op-sec policies ( limitation #3 ). Additionally, Baking Accounts is conceptually closer to the current baker account system (than Feature Design Path B, described below), therefore simpler to understand.
On the other hand, this feature design path is characterised for being static, which requires to specify ahead of time which use cases should be enabled. Furthermore, should this feature design path be adopted by the community and later on new use cases be discovered and requested, it would require an additional protocol upgrade to be adopted.
A more in-depth discussion about socio-economic considerations can be found below under “ Discussing Socio-Economic Concerns of Feature Design Path A & B ”.
Feature Path B) Programmable Staking
The main idea behind this feature path is to provide the option for bakers to design, implement, and enforce their behaviour and services through a Tezos smart contract. For illustration, our fictional baker TEZcacohuatzin could:
- Automate the payment of rewards by moving the task to a smart contract, instead of receiving the rewards and being in charge of administrating them afterwards to the delegators*.
- Remove the custody requirement of the funds of an external contributor to the security deposits, instead of requiring the interested contributors to lose control over their funds when they transfer them to TEZcacohuatzin’s baking account**.
- Automate the transfer of a portion of the bakery services fees to a DAO account that funds open-source software, instead of the ambiguity that out-of-band commitments entail.
*Note that this is also possible with the current system. However, it requires the baker to take full custody and control over the rewards. A baker could deploy a reward contract to which they pay all rewards and then delegators could withdraw their share of the rewards from said contract at their convenience. However, this may not be possible due to the constraints of the current gas limits. Nonetheless, we do encourage developers to explore these kind of contracts further.
**Note that should TEZcacohuatzin (following this example) double-bake or double-endorse, the funds from external contributions to the security deposits of TEZcacohuatzin’s baker would also be subject to the corresponding penalties. The only difference with the out-of-band contributions is that TEZcacohuatzin would not be able to steal the external contributors’ funds since the baking contract could be designed in such a way to only allow the contributor to withdraw his own contributions.
Programmable Staking would enable bakers to address not only the security-related limitations ( limitations #1–3 ), but also empower them to innovate around baking by leveraging Tezos as a smart contract platform ( limitation #4 ). Moreover, Programmable Staking could foster decentralisation of the network by lowering the overall cost of operating bakers, which is critical for small to medium bakers that have limited access to resources ( limitation #5 ). For illustration, Programmable Staking could make more secure setups accessible, lower the cost of day-to-day operations by automating them on-chain, or remove the ability of bakers to run away with external security deposits.
From the technical perspective, Programmable Staking ’s design is more elegant as it is a more generic approach with higher flexibility –it would not require to statically program use cases in the protocol. Unlike in the case of Baking Accounts , should there novel use cases discovered over time, they can be supported as smart contract standard, without the need for an additional protocol upgrade.
On the contrary, in order to leverage the increase in flexibility and exploration of innovative services around baking, the baker must learn about smart contracts development and have knowledge in Michelson or other languages, and development tools relevant to smart contract development –which, about a year ago, was a big constraint as there were not that many tools nor documentation available to make smart contract development accessible. Similarly, the delegators and end-users would also need some knowledge about smart contract development to check that the baker’s contract does what the baker claims.
Nowadays, this issue is mitigated by the increasing amount of tools, languages, and educational content for smart contract development (see a comprehensive list of developer resources on Tezos’ Developer Portal page and a collection of smart contract standards. Another downside of Programmable Staking is that some logic might not be feasible at the time of writing due to technical limitations on Tezos smart contracts, such as gas limits.
Additional Consideration for Feature Design Path B: Programmable Staking
Should this feature design path be chosen, our team would work on a set of example smart contracts: one that replicates the current baker key’s logic (so after the upgrade the current status will be preserved) and some that showcase a set of use cases, which will be open-source and could be used as references by the community. Which smart contracts we would work on is yet to be determined — we welcome suggestions from the community on use cases that could be interesting (below how to voice them through the venues listed under “ What’s Next? ”).
Discussing Socio-Economic Concerns
Censorship of Baker Transactions
Unlike the current baker governance and spending transactions, Programmable Staking voting and spending transactions will be indistinguishable from any other smart contract call, resulting in these transactions competing with other regular transactions and smart contract calls for space in a block. Thus, an adversary could fill blocks with nonesense transactions in order to censor baking transactions, which is a form of Denial-of-Service (DoS) attack.
The possibility of censorship through DoS can be mitigated by adding the baker transactions into their own list which has its own gas limit thereby giving them priority. Furthermore an honest baker implementation would always include baking transactions first even if blocks are full, which makes censorship impossible with an honest majority.
Another potential attack is for a group of bakers to form a cartel and decide to never include a governance transaction from baker X. In the current system this is relatively easy to implement since an attack baker only has to check whether a transaction is coming from a specific private key instead of fully executing a smart contract call.
With both Baking Accounts (A) and Programmable Staking (B), governance transactions would be emmited by a baker smart contract. Due to that a baker could always chain smart contract calls, thereby requiring a censoring attacker to execute the entire transaction in order to determine whether it is trying to send a governance transaction.
Overall the current design of baker keys is resilient against simple transaction DoS attacks, but not resilient against targeted censorship attacks from cartels. Programmable Staking not only would provide a similar level of resilience against transaction DoS, but would also increase significantly the difficulty of carrying out a targeted and coordinated censorship attacks.
On-chain Vote Buying / Selling
Another concern with Programmable Staking is that it could enable on-chain trading of governance votes (for more information, see Vote Buying, On-Chain Governance, and Quadratic Plutocracy), without the need for off-band coordination. Nonetheless, on-chain trading of governance votes would be recorded on the Tezos ledger and therefore be public and subject to strong scrutiny.
Vote buying/selling is a large unsolved problem in electronic governance systems. The current key system makes selling/buying votes cumbersome, but it does not prevent it– any baker can offer their vote and sell it to the highest bidder via off-band coordination and agreement. Furthermore, it is currently feasible to do this even trustlessly by generating the baker key in an SGX enclave and sell access to that enclave in a smart contract.
In practice, vote buying/selling is subject to strong public scrutiny and strong social norms, which would be much easier to enforce if all the data is recorded on the ledger and accessible by everyone. For illustration, consider the following scenario:
- Baker X decides to sell their vote on-chain. This event is recorded on the Tezos ledger and without Baker X’s ability to plausibly deny it. This data, available to the public, could cause severe reputational damage for Baker X and delegators would be encouraged to react immediately by undelegating from them.
On-chain Security Deposit Pools Benefit Larger Bakers
Even if Programmable Staking lowers the cost for bakers who have limited access to capital to, for instance, continue operating their baker or to scale their security deposits, a concern is that it also lowers the costs for well established bakers or institutions, this way facilitating centralisation of the network.
Nevertheless, well-established bakers tend to have an easier time triggering network effects to access and/or raise resources, not to mention the fact that the growth of well-established bakers does not rely on constraints on security deposits, but rather is constrained by regular on-chain delegations–as, generally, contributors to security deposits are only willing to do so when they have a higher reward ratio to compensate the risk of losing the security deposits. In other words, the current baker key system favours larger and well-established bakers that have accumulated enough trust to carry out agreements off-band.
The status quo of baker keys is favouring larger and well-established bakers over smaller ones, due to the fact that they currently have a large competitive advantage that derives from already established relationships, trust and exclusive access to resources.
The Nothing-at-Stake Baker Problem
On-chain security deposit contributions could allow a baker that initially did not own any security deposits to raise security deposits and successfully grow –resulting in an entity operating a baker with “nothing-at-stake”. This statement is false:
First, even if the baker did not initially own any of the tokens used in security deposits, the contributions to security deposits from third parties are still subject to loss should this baker double-bake or double-endorse. It is important to note that the Tezos protocol only considers tokens as valid security deposits if they are effectively subject to loss in case of baker misbehaviour –the protocol is agnostic to the “real-life” ownership of these tokens.
In addition, should this baker intentionally or accidentally cause the security deposits to be lost, it would be recorded on the Tezos ledger with full accountability, their contributors would suffer the corresponding losses, and their reputation would be damaged –making it unlikely that they can again convince more contributors to provide more tokens as security deposits.
Second, the current baker key design does not prevent bakers from baking on behalf of third parties, even if they initially did not own any of the security deposits. However, due to the current baker key design, this is only possible via off-band agreements and, thus, there is little to no transparency about the security deposit ownership structures of every baker.
In other words, Programmable Staking does not enable entities to become bakers with “nothing-at-stake”. It only removes the ability for a malicious baker to steal the funds from security deposit contributors (lenders)– which is a big risk that current security deposit contributors are exposed to due to the current baker keys system. Thus, the skin in the game is still present, but it is the lender’s skin, who has the same (if not larger) incentive to make sure that the baker is operating securely.
Final Remarks
In this article article we dived deep into one of the features that our team has been researching and exploring: enhancing baking accounts . The current baker key system presents issues ranging from security to socio-economic limitations. We explore two possible feature design paths A) Baking Accounts and B) Programmable Staking , which could address the aforementioned issues*. Besides describing the advantages and disadvantages, we discuss socio-economic concerns in-depth that should be taken into consideration in both feature design paths. While discussing the socio-economic considerations, we describe how the concerns can be mitigated and we provide clarifications on misconceptions surrounding both feature design paths.
*Note that should either feature design path be adopted, they would be implemented in an opt-in manner, the default behaviour will conserve the status quo.
What’s Next?
In this article we have a summary of our research and discussion notes on the topic enhancing baking accounts . Nonetheless, before realising any implementation (be it A, B, a variation of them or none), we would like to gather more feedback from the Tezos community.
In order to facilitate more community involvement in the protocol development process, we would like to use this article and the Meanwhile series as research synthesis and discussion reference, in addition to opening this topic for discussion on multiple platforms. To discuss on the topic enhancing baking accounts you are encouraged to participate in any of the following:
- Tezos Agora Forum : Enhancing Baking Accounts
- Core Protocol Development AMA on the 13th of February 2020, from 18:00 to 20:00 CET, with members from DaiLambda, Nomadic Labs, Cryptium Labs, and other more participating. (Thanks Tezos Commons and TQ Tezos for hosting!)
- Cryptium Labs Reddit AMA : during week 8 (17–21st of February)
We look forward to hearing your thoughts!
