TL;DR
- Amendments to the Tezos protocol brought about by the on-chain governance are activated immediately after their promotion.
- This poses a problem for bakers and third-party applications built on top of Tezos whose functionality might be broken by an amendment.
- Preemptive developments of required modifications on application-level can only mitigate the risks to a limited extent and might turn out to be wasted if the amendment is not promoted.
- The Babylon amendment that only reached quorum last-minute demonstrated the distress caused by unprepared activations.
- We propose to amend the amendment process by adding a fifth period that allows for bakers and third-party applications to adapt: the Adoption Period .
Tezos is a public and permissionless blockchain. Its distinguishing key features that set Tezos apart from other blockchains are:
- An on-chain governance mechanism that allows to upgrade the protocol without the need to fork
- A Sybil control mechanism called Liquid Proof-of-Stake (LPoS) that protects the consensus protocol against Sybil attacks without consuming insane amounts of energy
- Formally verifiable smart contracts that avoid bugs and unintended contract semantics
Arguably the most important one is the on-chain governance mechanism which we want to focus on in this article.
The on-chain governance mechanism solves the intrinsic dilemma of blockchains so far: the claim of being a structure “ built for eternity ” conflicting with the fact that it’s a very young and immature technology that still advances in “ quantum leaps ”.
While most blockchain projects pick one or two weaknesses of existing protocols, find a solution to fix them and are then stuck with their own weaknesses, leaving forks as the only way to subsequently amend their protocol, Tezos’ on-chain governance mechanism allows for a controlled and consensus driven protocol evolution without the need to fork. So far, with Athens, Babylon and Carthage, there have been three successful amendments and it is this feature that makes Tezos future proof and thus attractive for (industrial) third parties to build value creating applications on top of the protocol!
The current version of the amendment process consists of four periods that each last eight baking cycles consisting of 4,096 blocks. With a lower bound of one minute on blocktime, this means that a period takes at least approximately 23 days and a (complete) governance cycle about three months.
Figure 1: Overview of the current amendment process in Tezos’ on-chain governance [Image - CC BY 4.0]
The first period is called the Proposal Period and it serves the collection of amendment proposals and the selection of one of these proposals to proceed through the entailing periods. There is a vote on submitted proposals and the one that gains the most support is selected. In case of a tie or if no proposal has been submitted, the process reverts to its outset.
The second period is called the Exploration Vote Period and its purpose is to filter out proposals that are not supported by a supermajority. For the selected proposal to proceed to the next period, a quorum defined by a dynamic formula that depends on previous quorums and actual participation rates must be met and 80% or more of the votes have to be cast in favor of the proposal. Otherwise the proposal gets dropped and another Proposal Period is initiated.
The third period is called the Testing Period and allows the community to test and explore the proposal and its effects. A testnet fork adhering to the potential new rules is maintained for 48 hours and the remaining period can be used to analyze the results and conduct further tests.
The fourth – and in the current version final – period is called the Promotion Vote Period which ends with the communities’ final decision on whether to adopt the proposed amendment. Just like the Exploration Vote Period, it requires the quorum to be met and a supermajority of 80% to vote in favor. If so, the proposed amendment is activated immediately after the votes are counted at the end of the period . Either way, the next government cycle starts with the Proposal Period.
The Babylon amendment reached quorum only last-minute, taking many bakers by surprise und leading to adoption problems.
Now although the on-chain governance as such constitutes an argument in favor of Tezos, the immediate activation poses a problem for third party applications built on top of the protocol :
Applications built on top of Tezos use the protocol as a building block for a comprehensive solution to their problem. As a consequence, they can define additional rules to govern themselves by, but always need to be compatible with Tezos’ rules defined by on-chain governance. As depicted in Figure 2, the rules adhered to by third party applications are thus more restrictive, making the applications’ compliant spaces subsets of Tezos’ compliant space – or in other words: they add another governance layer on top of the Tezos on-chain governance.
Application-level updates are always possible as long as they do not break compatibility with the active protocol. However, protocol updates that break compatibility with the application require an immediate application update , that is activated synchronously with the protocol amendment for the application to seamlessly continue working.
Figure 2: The relation between Tezos on-chain governance and applications’ off-chain governance and their impact on update requirements.
While this is already a big challenge for all bakers (i.e. validators) it also poses a high risk and a liability – especially for commercial applications – that acts as an obstacle to mass adoption of Tezos : Modifications to the application have to be developed (producing costs) at a stage when it is not yet sure, whether the amendments making the application-level updates necessary will ever be activated in the first place.
To mitigate the risk, third party applications would have to preventively assess every Tezos proposal when it is made concerning possible application-level implications, i.e. required off-chain updates and estimate the trade-off between the risk of developing modifications that will never be needed and the risk of an activated proposal breaking the application (at least temporarily).
However, the exemplary process (as depicted in Figure 3) to assess the trade-off between these risks and act accordingly can only mitigate the risks to a certain level. For industrial players to rely on Tezos as the blockchain backbone for their large-scale applications, a greater level of certainty will be needed.
Figure 3: Exemplary risk mitigation process for third party applications to assess the trade-off between the development of application-level modifications that will never be needed and the risk of an activated amendment temporarily breaking the application.
We thus follow Jacob Arluck’s suggestion in “ Amending Tezos ” to delay the activation of the amended protocol after the conclusion of a successful Promotion Vote Period. As depicted in Figure 4, our specific proposition is to amend the amendment process by adding a fifth period of equal length which we would call the Adoption Period. This would allow both bakers and providers of third-party applications to adapt to the new conditions and ensure an uninterrupted operation.
Figure 4: The proposal - amend the amendment process with an Adoption Period
This work has been published by the work order of BMW AG and been contributed to the open source ecosystem through the ASC(S e.V. ENVITED Working Group with the goal of enabling virtually enhanced homologation processes.
