The Technical Evolution of Tezos

Published in

METASTATE

11 min readSep 18, 2020

Last update: 30th of November, 2020.

Almost two years have passed since the release of Tezos (the betanet rolled into a mainnet on the 17th of September, 2018). At Metastate, one of the core development teams of the Tezos protocol, we have developed a website that aims to provide an overview of the technical evolution of the Tezos protocol, from betanet to the present. Additionally, this article complements the Tezos chronicle website, by providing a detailed description of the different protocol versions that Tezos has adopted in the last 2 years. In order to better understand the technical evolution of Tezos (amendment proposals), we will first provide a general overview of Tezos.

Tezos was envisioned to solve one of the issues faced by most public blockchains, which is the inherent difficulty they face with the upgradability of their protocol [1]. Thus, one of the most distinctive characteristics of Tezos compared to other protocol is its on-chain amendment process. Hence, any protocol amendment is up for vote by Tezos token holders [2]. Thus, Tezos can by design upgrade itself without the need of a hard fork or a manual upgrade [3][4]. The way the Tezos amendment process worked (at launch) is described in detail on Jacob Arluck’s article. Note that even the amendment itself can be changed and there has been, in fact, changes since the betanet and mainnet versions to the governance mechanism of Tezos (more details down this article).

Fig. 1: The evolution of Tezos extracted from Metastate’s website

This places Tezos on a powerful position in an ecosystem that is constantly evolving. Tezos can adapt itself endogenously but also exogenously by adopting successful innovations from other protocols. Hence, whatever innovation Tezos stakeholders can think of, could be implemented in Tezos even if this innovation is already implemented in another blockchain. This capacity to rapidly adapt to changing positions allows Tezos to persistently remain on the cutting-edge [2]. As stated by Darwin: “it is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is most adaptable to change”.

Athens

Athens was the first amendment proposal upgrade of Tezos. It was proposed by Nomadic Labs. The community was asked to choose between two proposals:

Athens A: Increase the gas limit (per operation and per block)¹ and reduce the roll (i.e. minimum amount of tokens staked by a baker) from 10'000 tez to 8'000 tez. By decreasing the amount staked by a baker, this reduces the barrier to entry for other potential bakers, increasing the potential amount of bakers (and the reliability of the network as there is less chance from them to collude).
Athens B: Increase the gas limit (per operation and per block)¹.

Besides these two changes, a few secondary fixes are also included (they can be found in the changelog).

Result: As Athens A received more votes (71%) than Athens B (29%) during the proposal period, and hence only Athens A moved to the next phase [7]. Athens A was implemented on the 30th of May, 2019, with the validation of block 458'753 [9]. For more details about the results of the amendment process, please refer to the figure below or tzstats.

Fig. 2: Results of the amendment process for Athens A (extracted from tzstats)

As stated by Nomadic Labs, even though the changes included in the amendment proposal are modest, it is also a way to test and observe how the amendment process works in practice. Thus, this amendment proposal demonstrated that Tezos successfully implemented an update technically and as a community [4]. Nomadic Labs also chose to fund the proposal’s author account by a specified amount of tez in order to foster proposals from new teams [8]. In the case of this proposal, a symbolic value of 100 tez has been chosen (enough so that the developer team can buy themselves a round of drinks) [8]. Athens also enabled the core developers to draw a few lessons learned and possible improvement ideas for the next amendment proposal (see f.i. [7]). As a side note: Nomadic Labs suggested as naming convention that each subsequent upgrade will be a city name following the order of the alphabet [10].

Brest

This proposal has been proposed by OcamlPro. The community was asked to choose for or against one proposal. This amendment focused on solving two problems [11]:

Expand the path length of addresses from 7 to 9 to reduce the chance of attacks [11]. As mentioned by Jun Furuse (see [12]), there is no explanation about why 7 is inadequate but 9 is sufficient. One possible reason proposed by Jun Furuse ([12]) is that a clear explanation of the bug should not be disclosed publicly to avoid potential attacks (at least not before fixing it).
Although the invoice for Athens is not included in a block, the developer team’s address received the invoice [12], stating that “the reward is minted from nothing” [12] . Brest proposed to record this invoice (and the next ones) explicitly in a block to make it more visible (for more details please read [11] and [12]).

Moreover, this amendment entailed giving 8'000 tez as thank you to Brest’s developer team [11].

Result: This proposal has been rejected during the exploration vote (as seen on fig.3 below or on tzstats).

Fig. 3: Results of the amendment process for Brest (extracted from tzstats)

Babylon

Following Nomadic Labs suggestion, this amendment proposal was called Babylon. It was a result of the combined work between Nomadic Labs and Metastate. The community was asked to vote for or against one proposal. This proposal entailed numerous breaking changes, the principal ones were: 􀀀

Enhancement to the consensus algorithm: The consensus algorithm used in Tezos is named Emmy [13]. The several upgrades collectively formed Emmy+ (for more details about the proposed features please consult [14] and [15]).
Newly added features to Michelson (language used to write smart contracts on Tezos): The features included newly added instructions as well as several simplifications for the development of smart contracts (for more details please examine [16]).
Clearer separation between accounts and smart contracts: Please read this post for more details.
Improved Tezos amendment process: During the promotion period any amendment can be proposed. The one with the highest number of votes passes to the next phase (exploration vote). Thus, if there is only one proposal, it will automatically pass to the next phase if it receives at least one vote. Moreover, as any baker can inject a proposal, this opens the door for spam proposals. Thus, a threshold of 5% is introduced to pass from the promotion period to the exploration vote period and prevent spam proposals from proceeding (see [17] for more details). Furthermore, the quorum changes over time depending on past participation rates. This can be problematic for the next proposal, because if there is a drop in participation, the proposal could be rejected even though a large majority approved it. Hence, a minimum and maximum threshold are proposed (respectively 20% and 70%) [13] (for more details, please refer to [18]).

Result: Approved and successfully activated on block 655'361 (18th of October, 2019) [19].

Fig. 4: Results of the amendment process for Babylon (extracted from tzstats)

Babylon also highlighted that different developer teams successfully collaborated together which is an encouraging result towards the decentralization of the core development of Tezos [19]. Unlike Athens (which demonstrated the proper functioning of the amendment process), Babylon demonstrated that a large set of improvements to the code base can successfully be implemented [19]. Babylon also highlighted a few issues from which different lessons learned and possible improvements have been concluded (for more details, please consult [19] or [20]). In particular, a bug was found by Nomadic Labs during the testing period. Although this bug was not critical, it hindered the performance of new smart contracts and triggered an incorrect behaviour for the previous ones using big maps [21]. The problem with this issue was that the proposal was already injected. Thus, to solve it, two possible solutions were proposed [22]: 􀀀

Reject the current proposal. This is in alignment with the purpose of the promotion vote period (can serve as a kill switch if a critical issue is found during the testing period). Unfortunately, this will postpone the upgrade by approximately 3 months (Babylon 2.0.1) [22].
Deploy Babylon 2.0.1 as a governance-conditional hotfix [22]. This presents the advantage that it will still dependent on the results of the promotion period votes and that the upgrade is not delayed by 3 months. It requires, however, a bit of extra off-band coordination.

The second solution was chosen by the community. This issue highlighted the importance of allowing enough time to test and investigate all the different features [22]. Overall, Babylon proved that Tezos has been true to its promises by being able to substantially amend its protocol [19].

Carthage

Carthage is another collaboration between Nomadic Labs and Metastate. This protocol upgrade is referred to as a housekeeping proposal [23]. It also built upon lessons learned from previous protocol amendments. Thus, a carthagenet test network was introduced before the proposal injection to allow more time for testing [24]. Moreover, a second version of Carthage has been injected (Carthage 2.0) with more refinements in comparison to Carthage 1.0. As with Babylon, Tezos stakeholders were asked to vote for or against one proposal. The main changes were: 􀀀

Increase the gas limit (per operation and per block) by 30% [25].
Several minor improvements to Michelson [25].
Enhancement to the formula used to compute baking and endorsing rewards [25].

Result: Approved, the upgrade happened on block 851'969 (5th of March, 2020) [26].

Fig. 5: Results of the amendment process for Carthage (extracted from tzstats)

Although it introduced an increase in the gas limit, it mostly targeted: code clean-up, optimization, and fixing minor issues here and there [20]. Carthage exhibited the wish to mix feature proposals (1–2 a year) with housekeeping proposals (2–3 a year).

Delphi

Delphi is an interim proposal produced jointly between Nomadic Labs, Metastate and Gabriel Alfour [27]. Following the lessons learned from Babylon and Carthage, delphinet (a test network) had been created to ensure proper testing time. As usual, the community is asked to vote for or against this proposal. This protocol upgrade focuses on performance:

Improvements to the Michelson interpreter [27] [28].
Improvements to the gas model: Enhancing gas costs and reducing storage costs by a factor of four [29]. This answers the need exposed in the town hall of August, 2020, to receive gas improvements soon (rather than to wait for the next feature proposal). Thus, it should allow Tezos smart contracts to implement richer features and enable Tezos to facilitate the implementation of DeFi (decentralized finance), gaming, and collectibles [27] [29].
Minor bugs fix (for more details please consult the changelog).

Result: Approved and successfully activated on block 1,212,417 (12th of November, 2020) [30].

Fig. 6: Current results as of 24th of November, 2020, of the amendment process for Delphi (extracted from tzstats)

Features under R&D

Many features are currently under research and development, among which: Governance improvements (5th adoption period and the shorter voting periods), Sapling integration, Stateful baking accounts, New Michelson opcodes, Publicly verifiable secret sharing (PVSS) scheme for randomness generation or Delegation toggle (more details here). Moreover, a new Tezos testnet (named dalphanet) has been created to test many of those new features. Dalphanet was released on the 31st of July, 2020, and has been running steadily. Keep in mind that it is not a test network for a protocol proposal. Please feel free to interact with it and experience many of the diverse features.

Conclusion

In this article we provide an overview of the technical evolution of the Tezos protocol. Athens proved that the amendment process functions properly. Babylon demonstrated that a large set of improvements can successfully be implemented. It also showed the importance of having enough testing time. Carthage displayed the wish to separate feature proposals from housekeeping proposals. Delphi focused on performance improvements.

In addition to the proposals above, there are many features under R&D by Nomadic Labs, Metastate, and others.

For feedback or questions, please do not hesitate to contact us: team@metastate.dev

Follow us on Medium and Twitter to Stay Tuned! 🐫

¹In most smart contract platforms, the gas is a way to pay for the computational cost of doing an operation (transaction, interacting with a smart contract, etc.). Hence, the more computational incentive the more gas a user will pay. The gas limit is the maximum amount a user is willing to spend for an operation. However, the system has a gas limit threshold that cannot be exceeded. Thus, by increasing this threshold, it allows users to execute more complex operations [5]. Moreover, each block also has a gas limit, this value helps establish the number of transactions that can fit into a block [6]. By increasing this value, it allows a block to include more transactions (it also increases the fees collected by a baker [5]). The gas limit value was chosen conservatively at launch in order to preserve the network [7] (with the possibility to change it thereafter if needed). The new value was chosen by Nomadic Labs after carefully measuring the network in real situations [8]