As presented in the Governance on-chain chapter, the Tezos blockchain is constantly evolving, through new amendments. In this chapter, we will present an overview of past proposals and the reasons for their approval or disapproval.
FIGURE 1: History of Tezos amendments
Of the two proposals, Athens A sought to increase the gas limit and reduce the required roll size for baking from 10,000 tez to 8,000 tez. Athens B only sought to increase the gas limit. Athens A was voted with a Super-majority and was autonomously activated into the protocol in May 2019.
Brest A was the first proposed amendment rejected during the Exploration Period. Submitted in June 2019, it received only 0.35% of the votes during the Proposal Period. But as it had no competition, the system promoted it. The amendment was then rejected in the Exploration Period with only 0.26% of favourable votes. The 80% Super-majority was not reached, neither was the minimum Quorum required to validate it.
This proposal would have fixed a security breach linked to the rehashing push during the Athens protocol change. Moreover, it would have facilitated the amendment's invoice tracking. But the invoice for this proposal, 8,000 tez, was much higher than the usual cost.
The Babylon proposal was composed of two proposals made in July/August 2019: Babylon and Babylon 2. Babylon 2 was built by Nomadic Labs, Cryptium Labs (Metastate), and Marigold, after receiving feedback on the first Babylon proposal. The teams proposed a new tweaked version in the same proposal period.
Notable changes included a new variant of the consensus algorithm (
Emmy+). There were new Michelson features and accounts rehaul to aid smart contract developers. The accounts rehaul enabled a clearer distinction between "tz" and "KT" addresses. Furthermore, there was a refinement of the Quorum formula and the addition of the 5% threshold.
Babylon was autonomously activated into the protocol in October 2019.
Carthage was the first proposal to be rejected during the Proposal Period. Since the Babylon change, it now took a minimum of 5% approval to move to the Exploration Period and Carthage only obtained 3.5%.
The purpose of this proposal was to increase the gas limit per block and per operation by 30% to improve the accuracy of the existing formula used for calculating baking, endorsing rewards, and to fix various minor issues.
Carthage 2.0 (PtCarthav)#
Carthage 2.0 was then proposed and overwhelmingly accepted in December 2019 partly due to the Nomadic Labs and Cryptium Labs (Metastate) contributions.
Notable changes included increasing the gas limit per block and per operation by 30%, improving the accuracy of the formula used to calculate baking and endorsing rewards, as well as several minor improvements to Michelson. The main difference with Carthage was the new and more secure formula to calculate rewards.
Carthage 2.0 was autonomously activated onto the protocol in March 2020.
The Delphi proposal was a Nomadic Labs, Metastate, and Gabriel Alfour contribution, adopted in September 2020.
Notable changes included improving the performance of the Michelson interpreter, improving gas costs by adjusting the gas model, reducing storage costs by 4 times, and various minor fixes.
Delphi was autonomously activated into the protocol in November 2020.
The Edo proposal was adopted in November 2020 with Nomadic Labs, Metastate, and Gabriel Alfour contributions.
Edo added two major features to Tezos smart contracts:
Tickets for native on-chain permissions and assets issuance.
Among other features, Edo also updated the Tezos amendment process by lowering period length to 5 cycles and by adding a 5th Adoption Period. A full changelog is available here.
The Florence proposal was a joint effort from Nomadic Labs, Marigold, DaiLambda, and Tarides.
Florence's notable bug fixes and improvements are the:
Increasing maximum operation size
Improved gas consumption for the execution of more complex smart contracts
The elimination of the test chain activation
Bakings Accounts was also included in the feature set. However, ongoing testing uncovered some important and previously undocumented breaking changes in the proposal with Baking Accounts. Hence, the feature was postponed until a thorough audit of the functionality was completed or that an alternative implementation was produced. The version of Florence without Baking Accounts was considered a safer choice.
In this chapter, we went through the past proposals' history and how and why they were approved or rejected.
In the next chapter, we will see the details of operations costs and various rewards calculations.