Introducing the Burebrot Protocol Upgrade
The Burebrot Upgrade (Schwyzerdütsch) [Pain Paysan in French, Farmers’ Bread in English] is Cryptium Labs’ upcoming protocol upgrade aiming to improve the current Tezos account system. Among many ideas on improving Tezos[1][2], we have decided to prioritise this one due to its impact on the network and bakers’ security, as well as its potential to simplify future protocol upgrades.
State of Art
In the current Tezos account system, there are two types of accounts: implicit accounts (tz1) and originated accounts (KT1). An implicit account is characterised by its private key’s ability to spend funds, participate in consensus (by the delegatable parameter), and vote on proposals via the governance mechanism. As implicit accounts are required for baking, bakers, especially public bakers who accept delegations, are subject to operational constraints and cannot commit to particular governance policies or payout schedules enforced by the protocol.
A Closer Look into a Baker’s Life
The operations that a baker manages go beyond transferring funds to other implicit accounts and executing the Tezos software. Generally speaking, due to the penalties of committing safety faults[2, 3], all bakers are incentivised to dedicate resources to improving the security of their validating nodes, which encompasses networking, physical and operational security.
Considering that the tasks of consensus (signing blocks and making endorsements), spending funds, and voting are performed at different frequencies and for different reasons, there is no need for the same key to be used for all of them. Additionally, the current design of implicit accounts limits the degrees of freedom that bakers have when designing and implementing security measures and processes.
- For example, a baker cannot make the payouts of rewards and fees permissionless or accept security deposits through an on-chain process with specific guarantees enforced by a Michelson smart contract.
Things That Keep Bakers Awake at Night
Becoming Targets for Extortion
Due to the public nature of validating nodes and the current account system, bakers are or will inevitably become targets of nefarious agents, as gaining access to the keys enables them to withdraw a portion or the entirety of funds deposited in the baker’s account, as well as vote in governance and create forks by intentionally committing safety faults.
Tradeoff Between Safety & Liveness
Given that signing blocks and endorsements require the signatures to be available at all times (as missing endorsements or blocks results in a loss of rewards), bakers will naturally choose security architectures that rely on physical key protection. However, this would mean that the baker would not be able to spend funds (e.g. in order to pay out rewards) or participate in governance without revisiting the facilities, which increases operational costs — an alternative would be to duplicate the keys, one dedicated to consensus and the other one to spending and voting, but this would increase the likelihood of one of the keys being exfiltrated.
Limited Organisational Flexibility
Another limitation that the current accounts impose is that whoever operates the validating node would, by default, maintain access to spending and governance. This exposes baking organisations to the risk of losing their funds or voting in a way they did not intend if the validation node is compromised.
Similarly, should the organisation choose to distribute the task of voting to another member, the one in charge of voting would by default be able to participate in network consensus. In this case, the organisation would be exposed to the risk of committing safety faults.
Inability to Upgrade Accounts
Finally, the current account system prevents bakers from changing implicit accounts without risking many if not all of their delegators, as it requires a manual off-chain process to communicate and coordinate about the change in tz1 address (since the delegators must redelegate). Likewise, bakers are not be able to update their accounts, should there be an exploit that compromises the security of their existing accounts or a new development in the system that improves the existing ones.
The Goals of Burebrot Protocol Upgrade
First, this proposal presents an upgraded design and implementation with the main purpose of providing higher flexibility to bakers, be it for increasing the degrees of freedom regarding operational security or empowering them to engineer more advanced products around baking. Moreover the current account system is confusing and bothersome for delegators, as they always have to instantiate KT1 accounts without code in order to delegate their tokens. With the Burebrot upgrade delegators will no longer need to create separate KT1 accounts, but can rather delegate directly from their tz1 accounts. Some examples are:
- Enabling multi-signature accounts
- Moving payments of rewards on-chain
- Separating spending, consensus, and governance keys
- Change or upgrade their consensus keys without affecting their existing delegations
- Reducing the complexity for delegators
Second, in addition to the security benefits, this proposal will pave the way for bakers to improve existing services, such as:
- Self-bond requirements[5], by removing the custody requirement and enabling implementation of the contract on-chain
- Implement and offer additional products around baking rewards, such as derivatives or options
- Broadly speaking, the upgrade will allow bakers to differentiate their offerings and experiment with new products, which may improve the security and usability of proof-of-stake
Finally, this proposal will encourage bakers and developers to leverage smart contracts on Tezos (with Michelson, Liquidity or others), in order to build more competitive products around baking. The usage of smart contracts (for enhancing the security, improving or diversifying the product of bakers) is likely to be a popular use case for bakers and delegators, currently the most active users, and will help bootstrap the smart contract development environment and community by increasing the demand for formally verified Michelson smart contracts.
Upcoming Articles
- Specifying the Burebrot Protocol Upgrade
Complimentary Reads
[3] Half-Baked is Always Better than Double-Baked — What is at Stake in the Tezos Protocol?
[4] Half-Baked is Always Better than Double-Baked — What is Double-Baking? What Causes Double-Baking?
[5] Is Your Favourite Baker Overdelegated? Understanding Self-Bond Requirements in Tezos
