Main Ideas Behind the Tezos Protocol - Change and Evolution

Reading Time: 27 min

Implementing change, avoiding hard forks

A blockchain can be understood as a ledger. This ledger is immutable and transparent to the network participants. How the network is conceptualized influences its implementation, the benefits it brings, and the challenges it faces.

Because data is validated and stored decentralized, unless both the protocol and the data itself have some immutability property, there is no certainty that the data has not been tampered with and the protocol has not been modified to benefit any one actor disproportionately. Immutability is a central attribute of blockchains to ensure trust in the system and integrity of the data. There might be situations where the rule of immutability needs to be flexible, where the protocol or the data do need to be changed.

Upgrades to blockchains are particularly difficult to execute in decentralized consensus-based systems as the need for agreement among a distributed set of participants is implied and always includes an element of overturning previous agreements. It is also very difficult to remedy such a situation in an environment where change can be considered a bug and where breaking changes may harm software that is already deployed. For example, in informal terms, Ethereum does what it does the way it does it but developers have little assurance about platform invariants. Invariants are not well-defined. The same community resistance that stands as a bulwark against breaking changes is also, arguably, an impediment to progress. The same can be said of Bitcoin. Both networks, Bitcoin and Ethereum, have suffered disagreements about what is progress and what is an anti-feature. Bitter disputes have split their communities and as a result disrupted their network effects, which disrupts their value.

Upgrades are especially challenging absent previously agreed on governance processes that define how upgrades are to be achieved. Without clearly defined governance mechanisms, upgrades can be disorderly, inefficient, and damaging to communities. The Tezos governance process is designed to address this problem. Tezos offers a pre-defined governance mechanism to upgrade the protocol.

Tezos addresses this public blockchain dilemma by providing an on-chain governance mechanism, which reduces the coordination costs for upgrades immensely. Public blockchains often conduct their "governance process" off-chain. This entails coordinating communication across different platforms to make an upgrade more probable of being accepted by all network participants. The coordination required leads to high coordination costs. Additionally, on-chain governance helps avoid hard forks caused by some stakeholders objecting to an upgrade and continuing on an older protocol version. Hard forks are especially painful when it comes to holding a stake in tokens - A hard fork leads to two competing states of the "true state", which makes all related to assets with financial value very complicated.

Tezos was designed to solve this "fork-based governance" model of early blockchain implementations. As the value of a blockchain is largely determined by its network effects, the Tezos governance mechanism is meant to disincentivize forking so that network effects are better retained over time.

Tezos was envisioned to include the possibility of upgrades and self-governance mechanisms. The Tezos Governance Mechanism was developed for this purpose. With it, protocol upgrades (including upgrade propositions, selection and testing, as well as activation) can be conducted without having to create a hard fork.

In addition to an on-chain governance mechanism, Tezos also has the ability to self-amend. Node operators of other blockchain implementations must manually upgrade the software of their nodes when conducting a network upgrade. Even if non-contentious, coordinating and executing a network upgrade can be extremely difficult and becomes increasingly difficult as a network grows and becomes more decentralized. Self-amendment in Tezos is designed to solve this coordination and execution problem of conducting upgrades in a decentralized network. If an amendment (upgrade) to Tezos is approved by its stakeholders via the governance mechanism, then all nodes are automatically upgraded, no manual intervention is needed.

Both the governance mechanism and self-amendment are built in at the protocol level. Restrictions about what can and cannot be changed at the protocol level may be implemented via the governance mechanism. For example, if stakeholders wanted to cap the total supply of tez, they could do so or set a requirement stating that 80% of all stakeholders must approve such a proposal for it to be implemented. This is to ensure that more sensitive or controversial changes to the protocol require stronger consensus or must meet predefined rules before being enacted. This is a form of constitutionalism at the protocol level and can govern how future rules can be adopted.

The Tezos amendment process

The Tezos amendment process consists of five different stages:

The proposal period,
The exploration period,
The cooldown period,
The promotion period, and
The adoption period.

All the above-mentioned periods last for five baking cycles - the length of the amendment process was reduced from eight to five cycles by the Edo upgrade.

Cycles are used as a term in Tezos to indicate time measurements. One cycle equals to a total of 4,096 blocks. As the time between the creation of two blocks is fixed to one minute, a cycle lasts approximately 4096 minutes, i.e. two days, 20 hours, and 16 minutes. Remember that the time between two blocks can vary.

When a period is successful, the amendment process is finalized. In case it is not, the proposal period begins again, the process restarts so to say.

Operations for voting

There are three instances, in which bakers vote on-chain: at the end of the proposal, testing_vote, and promotion vote period. The first is conducted with the proposals operation, and the latter two with the ballot operation. Let's take a brief look at these two operations.

The proposal operation:


Proposals : {
  source: Signature.Public_key_hash.t ;
  period: Voting_period_repr.t ;
  proposals: Protocol_hash.t list ; }

As you can see in line:


source: Signature.Public_key_hash.t ;

the source is the public key hash.

The unique identifier of each voting period is indicated with:


period: Voting_period_repr.t ;

and the proposals, which are being upvoted, are communicated with a non-empty list of a maximum 20 protocol hashes, as you can see in line:


proposals: Protocol_hash.t list ; }

This operation can be submitted more than once. The only limitation is that the cumulative length of the proposals list has to be less than 20.

Now, let's take a look at the ballot operation:


Ballot : {
  source: Signature.Public_key_hash.t ;
  period: Voting_period_repr.t ;
  proposal: Protocol_hash.t ;
  ballot: Vote_repr.ballot ; }

This operation also uses the public key hash as a source (i.e. source: Signature.Public_key_hash.t ;) and the voting period as a unique identifier (i.e. period: Voting_period_repr.t ;).

The proposal:


proposal: Protocol_hash.t ;

refers to the proposal that is under consideration.

In addition, the ballot:


ballot: Vote_repr.ballot ; }

can be either Yea, Nay, or Pass. Whereas Pass allows for not influencing the vote's result while allowing for a quorum.

The ballot operation can only be submitted once during a voting period.

In case you want to check out more details on Tezos operations, we recommend this source.

Improved PoS consensus: Liquid Proof-of-Stake

In an LPoS-based blockchain, a baker, i.e. validator node, is randomly selected to generate blocks based on its funds staked and those that are delegated to it by other stakeholders. Whereas, the stake is measured in Tezos tokens (XTZ), also called tez.

Block creation rights are randomly selected proportional to a baker’s stake, for performance reasons measured in "rolls". Currently, one roll is equal to 8,000 tez, rounded down (e.g. 15,999 tez equals one roll) - This constant may be changed via the Tezos governance mechanism. The rolls available to a baker consist of the baker's own staked tez and the delegated tez from originated accounts. Bakers are required to put up a security deposit to disincentivize malicious behavior. The size of a baker's deposit depends on the number of blocks a baker is selected to produce and/or endorse.

Bakers earn rewards for securing the network through the generation and endorsement of blocks. Rewards are currently dynamically calculated and were initially calibrated for a target inflation rate of approximately 5.5%.

As rewards are fixed, the inflation rate is expected to decrease over time. However, these constants may also be changed by stakeholders via the Tezos governance mechanism.

As mentioned, stakeholders that do not bake themselves (via an implicit account) can delegate their stakes to bakers. This allows stakeholders of any size to participate in LPoS and earn associated rewards for securing the network. The rewards paid by bakers to delegates are outside the protocol's scope. Thus, it is up to bakers to distribute their rewards to delegates. It is expected that bakers will compete for delegated tez based on reliability, fees, security, and other factors like contributions to the Tezos ecosystem.

At the time of writing (February 2021), there are over 400 participants in Tezos PoS.

Tezos' consensus mechanism can be described as "proof of stake with delegation". Stakeholders can fluidly switch between participating themselves or delegating, and can also easily switch delegators. For these reasons, LPoS has gained traction when describing Tezos’ consensus mechanism.

If you want to continue exploring LPoS, we can recommend Liquid Proof-of-Stake by Jacob Arluck and Proof-of-stake in Tezos.

Making smart contract development safer

Smart contract development is challenging. One main reason is that contracts are self-executing, self-enforcing, and self-verifying contracts while not being upgradable after deployment. The contract you deploy is the contract that will be executed, enforced, and verified. This means that deployment is a risky business.

Tezos makes smart contract development safer by providing a public blockchain platform that runs smart contracts, which can be upgraded and introducing a functional language tailored to smart contract development, Michelson.

Reliability of both the network platform and the contracts that run on it is always a concern. After all, if platforms do not behave as expected, or if contracts don't behave as the authors intended, the consequences can be quite serious. Incidents of defects diminish trust in smart contracts, the system, and even cast doubt upon the very workability of smart contracts and blockchain technology in general.

Tezos' design aims for reliability, security, and modularity. How so? Smart contracts in Tezos are more reliable because they more easily facilitate formal verification.

Formal verification is a much-discussed topic. There is some resistance from the developer communities; to developers who are accustomed to fast development turnaround methodologies such as Agile, the very idea of formal verification may seem like a foreign concept. It's easy to lose sight of the existence of more disciplined approaches that are more common in mission-critical settings like nuclear and aeronautical engineering.

For Tezos, more easily supporting formal verification allows one to prove smart contract code correctness, and with it contracts become more secure and reliable. The Tezos ecosystem contains several specialized tools focused on secure DApp development and at the same time the opportunity to analyze smart contract code more easily.

These aspects of reliability and security make Tezos an attractive public blockchain and smart contracts platform for developers to build on.

Even though these positive aspects add real value, the question remains: Why not use languages based on JavaScript, Python, or other popular choices? These languages can be used to write smart contracts on Tezos, however, as higher-level languages. Language choice is a Darwinian process. Consider your favorite language today. Did it exist in its present form, say, ten years ago?

To write smart contracts on Tezos, a domain-specific language called Michelson is used. It is stack-based, with high-level data types and primitives and strict static type checking. On the first encounter, it seems to be an odd language choice as it does not have features like polymorphism or named functions. Dealing with the stack is complicated and there is no standard library to rely on. Even though it appears underpowered when compared to languages such as Haskell or OCaml, the language's restrictions are a result of its design goals.

Michelson is designed as a readable compilation target to make the compiler's output understandable. The idea behind it is to empower developers to build analysis tools and compilers by using a language that is simple enough to do so.

Here it becomes evident that Michelson follows a different theoretical assumption: Instead of building on bytecode like with the EVM, which requires confidence in the program and compiler toolchain, using a human-readable bytecode allows to more easily check and verify properties of programs and their compiled outputs.

The development and characteristics of Michelson follow the idea to create a simple core language, which can be amended with features as they are needed. This is different from attempting to create a more overarching language in the beginning, which then breaks backward compatibility. The goals are to provide a platform:

Inclusive of business logic,
With readable bytecode, and
Using a small language that can be expanded depending on its use cases.

Michelson follows the line of the general Tezos design that aims to resolve the issues public blockchains typically have with reliability and security, upgradeability, and performance.

We will intensively deal with Michelson at a later point.

Discuss on Slack

Rate this Page