Skip to main content

History of amendments

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.

Athens (Pt24m4xiP)

Athens was the first proposed protocol-amendment for Tezos. Two proposals - Athens A and Athens B - were proposed by Nomadic Labs in February 2019.

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.

For a full list of changes, be sure to read this corresponding blog post from Nomadic Labs and reflections by Jacob Arluck, and the reference documentation.

Brest A (PtdRxBHv)

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, 6,000 tez, was much higher than the usual cost.

Babylon (PsBABY5HQ)

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.

For a full list of changes, be sure to read the corresponding blog posts from Nomadic Labs, and Cryptium Labs (Metastate), and the reference documentation.

Carthage (PtCarthav)

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 (PsCARTHAG)

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.

For a full list of changes be sure to read the corresponding changelog and blog posts from Nomadic Labs and Cryptium Labs (Metastate). You may also check the reference documentation.

Delphi (PsDELPH1K)

The Delphi proposal was a Nomadic Labs, Metastate, and Gabriel Alfour contribution, presented 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.

For a full list of changes, be sure to read the corresponding changelog and blog post from Nomadic Labs. You may also check the reference documentation.

Edo (PtEdo2Zk)

The Edo proposal was presented in November 2020 with Nomadic Labs, Metastate, and Gabriel Alfour contributions.

Edo added two major features to Tezos smart contracts:

  • Sapling[1] and BLS12-381[2] to enable privacy-preserving smart contracts

  • Tickets[3] 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.

Edo was autonomously activated into the protocol in February 2021.

For more information check the reference documentation.

Florence (PsFLorena)

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

  • Changing inter-contract calls to a depth-first search[4] ordering, as opposed to breadth-first search[5] ordering

  • The elimination of the test chain activation

Bakings Accounts[6] 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 [7].

Florence was autonomously activated into the protocol in May 2021.

For more information, see the blog post from Nomadic Labs and Tarides, as well as the reference documentation.

Granada (PtGRANAD)

The Granada proposal was a joint effort from Nomadic Labs, Marigold, Oxhead Alpha, Tarides, and DaiLambda

Granada's main changes are:

  • Emmy*, a new consensus algorithm with reduced time between blocks (30s), and faster finality.

  • Liquidity Baking, increasing the liquidity of tez by minting some at every block into a CPMM (Constant Product Market Making smart-contract).

  • The reduction of gas consumption of smart contracts by a factor of three to six, through a number of performance improvements.

Granada was autonomously activated in August 2021.

For more information, see the blog post from Nomadic Labs and the reference documentation.

Hangzhou (PtHangz2)

The Hangzhou proposal was a joint effort from Nomadic Labs, Marigold, Oxhead Alpha, Tarides, and DaiLambda.

Hangzhou's main changes are:

  • Timelock[8] encryption, a feature that helps smart contracts protect against Block Producer Extractable Value

  • Views, a new kind of entrypoints that gives easy access to some internal data to other smart contracts.

  • Caching of regularly accessed data, to lower the associated gas cost.

  • A global table of constants, where constant michelson expressions can be registered and made available to all contracts.

  • Context flattening, an optimized rewrite of the protocol's database internals.

Hanghzou was autonomsously activated in December 2021.

For more information, see the blog post from Marigold and the reference documentation.

Ithaca (Psithaca2)

The Ithaca proposal was a joint effort from TriliTech, Nomadic Labs, Marigold, Oxhead Alpha, Tarides, DaiLambda, Functori and Tweag.

Along with numerous minor improvements, Ithaca contained two major updates to the protocol:

  • Tenderbake, a major update to the Tezos consensus algorithm, that brings fast deterministic finality to the Tezos protocol. It also includes important changes:

    • bakers now receive rewards depending on their current stake instead of the number of rolls they own
    • the minimum number of tokens required to be selected as a validator is reduced from 8,000 tez to 6,000 tez
    • a rework of baking and endorsements rewards
    • a new security deposit mechanism requiring delegates to freeze 10% of their stake in advance, to obtain baking and endorsement rights.
    • an increase of the number of endorsement slots per block from 256 to 7,000
  • Precheck of operations: a new set of features that can be used by any Tezos shell, to avoid having to fully execute manager operations before gossiping them through the network

  • Adding approximately ten months to the liquidity baking sunset level.

Ithaca was autonomsously activated in April 2022.

For more information, see the blog post from Nomadic Labs and the reference documentation.

Jakarta (PtJakart2)

The Jakarta proposal was a joint effort from Nomadic Labs, Marigold, TriliTech, Oxhead Alpha, Tarides, DaiLambda, Functori and Tweag.

Jakarta's main changes are:

  • Transactional optimistic rollups (or TORU), an experimental implementation of optimistic rollups on Tezos. TORU provide a way to enable higher throughput (TPS) of transactions by moving their validation away from the main chain, to 'Layer 2'.

  • A new improved design for the integration of Sapling transactions into Smart Contracts. The Sapling protocol uses advanced cryptography to enable the protection of user's privacy and transparency with regard to regulators.

  • A redesign and renaming of the Liquidity Baking Escape Hatch mechanism, now called "Liquidity Baking Toggle Vote".

  • Various improvements to type safety and performance of the Michelson interpreter, including decreasing gas costs for parsing and unparsing scripts. Furthermore, Michelson now ignores annotations.

  • A new mechanism was introduced to explicitly track ownership of tickets in the protocol. This adds extra protection against attempts to forge tickets, and facilitates Layer 2 solutions that use tickets to represent assets that can be exchanged with the main chain.

  • The voting power of delegates is now defined directly by their stake expressed in mutez, and no more in terms of rolls. The minimal stake required to be assigned voting rights is kept at 6000 tez.

Jakarta was autonomsously activated in June 2022.

For more information, see the blog post from Nomadic Labs and the reference documentation.

Kathmandu (PtKathman)

The Kathmandu proposal was a joint effort from Nomadic Labs, Marigold, TriliTech, Oxhead Alpha, Tarides, DaiLambda, Functori, Tweag and and G.-B. Fefe (an anonymous contributor).

Kathmandu's main changes are:

  • Smart contract optimistic rollups (SCORU) enabled on bleeding edge testnets (Mondaynet and Dailynet).

  • Pipelined validation of manager operations, increasing throughput, without compromising the network’s safety. This ongoing project reduces the need to fully execute time-expensive operations (like smart contract calls), before they reach a baker, resulting in a faster propagation of new blocks and operations across the network.

  • Improved randomness with integration of Verifiable Delay Functions (VDF) into the protocol’s random seed generation, reinforcing the security of the rights allocation mechanism.

  • Support for tailored governance for permanent testnets will reduce the need for user-activated upgrades in Ghostnet. After a protocol proposal is elected in the Promotion period on Mainnet, the Oxhead Alpha team will be able to centrally upgrade Ghostnet.

  • Event logging in Michelson smart contracts enabling DApps developers to send on-chain custom messages in order to trigger effects in off-chain applications (wallets, explorers, etc.).

  • A new operation for increasing paid storage of a smart contract allowing DApps developers to pay the storage fees on behalf of their users.

Kathmandu was autonomsously activated in September 2022.

For more information, see the blog post from Nomadic Labs and the reference documentation.

What have we learned so far?

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.

References

[1] https://z.cash/upgrade/sapling/

[2] https://electriccoin.co/blog/new-snark-curve/

[3] https://medium.com/tqtezos/tickets-on-tezos-part-1-a7cad8cc71cd

[4] https://en.wikipedia.org/wiki/Depth-first_search

[5] https://en.wikipedia.org/wiki/Breadth-first_search

[6] https://midl-dev.medium.com/tezos-in-favor-of-baking-accounts-3886effa370c

[7] https://research-development.nomadic-labs.com/baking-accounts-proposal-contains-unexpected-breaking-changes.html

[8] https://research-development.nomadic-labs.com/timelock-a-solution-to-minerblock-producer-extractable-value.html

https://wiki.tezosagora.org/learn/governance/past-tezos-amendments