The Odyssey of Tezos: Updates from Athens to Ithaca

Tezos’ (XTZ) innovation is the result of the work of Kathleen and Arthur Breitman, culminating in a 230 million ICO in July 2017. However, the roadmap was slowed down by legal disputes with Johann Gevers, which damaged the project’s image. Thus, Tezos failed to establish itself immediately in the nascent DeFi ecosystem.

However, thanks to its Self-amending property, Tezos has been able to adapt nimbly to every demand of the crypto ecosystem. Let’s find out, then, about Tezos’ update process and the path that led to Ithaca 2, the 1 April 2022 update.

How Tezos works: Liquid Proof of Stake and FA2

The nature of the Tezos blockchain is changeable, but not unstable! In fact, the functioning of each native smart contract is extremely reliable because it is verifiable: it is possible to subject each code to the ‘test of 9’, so as to be mathematically certain of its correctness.

However, what makes the Tezos (XTZ) protocol extremely lively is first and foremost the Liquid Proof of Stake: each stake-holder can delegate his tokens without necessarily locking them in a certain address, so that they can move them freely without having to wait for the ‘unfreezing’.

This consensus protocol (Liquid PoS) supports a system of decentralised services: the Tezos FA2 (Financial Application 2) standard token allows for the creation of utility tokens to be exchanged through the decentralised Dexter exchange, as well as for the creation of NFTs. In fact, the FA2 standard supports a wide range of tokens, managed through a single smart contract interface; unlike Ethereum, which instead has several token standards. Furthermore, it is possible to create autonomous decentralised organisations (DAOs), or to intervene in them, with the Homebase project, again powered by Tezos technology.

The vitality of Tezos has convinced many projects to choose its blockchain, also promoted by the portability of all forms of value: wrapping allows any technologically incompatible financial standard to be ‘translated’ into the correct language, as if it were wrapped in a code recognisable by Tezos.

However, the most cutting-edge property of Tezos is the self-amending mode with which it implements updates. In fact, the Tezos protocol can be easily modified, based on proposals voted by the community, without the need to ‘fork‘ the code. This process, thanks also to an on-chain governance, allows Tezos’ security to be preserved: let us therefore discover the succession of updates that led us to Ithaca.

Self-amending: from Athens to Hangzhou

A cutting-edge project needs to evolve: how is it possible to be flexible but integral, to change without causing fragility?

We know that a proposed change, if too radical, can result in a hard fork: a new blockchain, incompatible with the previous one. Although innovation is necessary, this event brings with it certain risks: ‘splitting’ a blockchain leads to a reduction in participation in the network, resulting in less security due to the lowering of computing power (hash rate).

Updating Tezos, on the other hand, is done without splitting: it is possible to add functionality, approved by an on-chain governance system, without sacrificing security. The possibility of unlimited improvement, supported by the super-majority (80%) of the community, has seen the Breitman blockchain renew itself 8 times before Ithaca 2: this is ‘Self-amending’, the dynamic system of amendments that updates the Tezos code.

The changes followed in alphabetical order with city names: Athens, Babylon, Carthage, Delphi, Edo, Florence, Granada, Hangzhou and Ithaca 2. A convention proposed by Nomadic Lab, the main developers of the Tezos protocol, subsidised by the Tezos Foundation. Let’s take a look at the most important Tezos updates.

Athens, the first update, went through the 5-stage amendment process (proposal, exploration, test/cooldown, promotion and adoption) in May 2019. On Tezos Agora, it is possible to discuss and inform yourself about the proposals and, with regard to the Greek city, it shows us these novelties: increase of the ‘gas limit’ (maximum commission per transaction), thus increasing the maximum number of transactions per block, and reduction of the minimum stake (called ‘roll size’) to be a baker, i.e. a validator, from 10 thousand to 8 thousand.

Babylon (October 2019), was revolutionary. First, it inserted new conditions into the consensus algorithm, at this stage called Emmy+, such as increasing the validation time for blocks with less endorsement. Furthermore, he added functions to the Michelson smart contract language, such as the CHAIN_ID to distinguish between the main network and the testnet. Finally, it made changes to quorums, i.e. the voting percentages required for the proposal and testing phases of the amendment.

Delphi came into force in September 2020: it improved the performance and security of Michelson, optimised the amount of calculation per unit of gas, and reduced the cost of storing data by a factor of 4.

Edo, in February 2021, added two new functions: Sapling and Tickets. The former protects the privacy of transactions on Tezos, while the latter creates smart contract architectures capable of exchanging permissions. The fifth period of the amendments, that of ‘adoption‘, was introduced here: this phase allows nodes to update themselves following the proposal.

Passing Florence, we come to the Granada update, ready in August 2021. Emmy+, the consensus algorithm, has evolved into Emmy*: it has halved the time per block (from 1 minute to 30 seconds), thus speeding up transactions. In addition, Liquidity Baking was implemented: with each block, a small amount of Tezos is deposited in a decentralised smart contract market maker, thus adding liquidity to the XTZ-BTCtz pair (wrapped bitcoin on Tezos). This incentivised users to provide additional liquidity to the contract, so as to obtain constant rewards. This feature caused a great deal of debate at the time of the switch to Ithaca, as we shall see.

Back to the East: Hangzhou introduces Timelock cryptography, which prevents miners from choosing and ordering transactions to be included in a block to take advantage of them (a fraud called Block Producer Extractable Value). A number of functions and tools have also been added to facilitate the development of smart contracts.

Ithaca 2: Tezos’ democratic update

We touch the shores of Ithaca, home of Odysseus, to learn a curious fact: the original version of the Ithaca update was rejected by on-chain governance, but this was not the first rejection in the history of Tezos’ self-amending protocol. In fact, the Carthage proposal was the first to fail the Proposal Period, while Brest A was blocked from the exploration period for having received only 0.26% votes in favour, far from the 80% required by the supermajority.

Is the failure of the super-majority agreement a failure? Absolutely not, the democratic model of on-chain governance worked, proving that decentralised voting really does matter. A victory for blockchain technology: the user is at the centre of the debate and makes decisions that benefit the network.

So why was the Ithaca update initially rejected? The first factor is Liquidity Baking, remember? With Granada, an automatic incentive was added to the liquidity pool of XTZ-BTCtz. This pair was criticised for several reasons: no centralised exchange supports it, it is expensive to convert BTC to BTCtz, and it is often impossible to wrap if one does not have a certain amount of tokens available. In addition, many would have liked to replace BTCtz with another token: one proposal was USDtz, Tezos’ stablecoin.

However, this may not be the real background: in fact, many bakers, and delegating users, felt unrepresented in the governance process. We said that Nomadic Labs works in the interests of the Tezos Foundation, so alternative Tezos update proposals have to be formulated by the community. This, however, has some limitations: an update needs a lot of technical expertise to be written, so the popular proposal will come later for voting and with lower reputation. In addition, each update proposed by Nomadic Labs is a unique prototype, with no choice.

Thus, the first version of Ithaca, proposed by Nomadic Labs, did not reach a quorum: black smoke, but democracy still won. The frustration of an under-represented community communicated its disappointment, achieving a great result.

Thus Ithaca 2 was born from the ashes of the first rejection, but without any substantial changes. This time, agreement was reached, proving that it was not technical issues that deterred the community, but the approach to governance.

The first among the changes brought about by Ithaca 2 is Tenderbake: a new consensus algorithm, based on the BFT (Byzantine Fault Tolerance) mechanism, which replaces Emmy*. In addition, the validation rewards, distributed to bakers, from Ithaca 2 will be directly proportional to the actual stake size, thus no longer based on “roll size” (1 roll=8000 XTZ). In this regard, the minimum number of tokens to be selected as a validator will decrease to 6000 XTZ. Baking rewards will be credited instantly and not frozen for 5 cycles (approx. 15 days) as in Emmy*. Finally, a new level of security is introduced: delegates must block, at least, 10% of their stake in order to obtain validation rights (this, however, does not affect delegators, given the Liquid PoS).

Ithaca 2 also addressed the Liquidity Baking (LB) controversy, but not with the result critics had hoped for: the protocol will continue to add liquidity to the XTZ-BTCtz pair for approximately another 10 months. On the other hand, Ithaca 2 ruled that if in the future even 33% of the bakers are against it, the LB will be discontinued. Before this update, the minimum number of negative votes was 50%: a small victory.

The Jakarta 2 update of June 2022 added the Liquidity Baking Toggle Vote precisely to facilitate this vote: each baker will be able to vote in favour of stopping the programme, continuing it or restarting it. But that is another chapter in the Tezos story.

Will it be enough to resolve the internal community dispute? Will future upgrade proposals have more choice? Perhaps what one really needs to ask, by changing perspective, is which other blockchain allows one to actively participate in the innovation of its protocol.