In a recent post, we discussed Tezos’ abstract blockchains.
In short, by making system components loosely coupled, you can make changes to one part of the system without breaking anything in a completely unrelated section of the code.
This strategy allowed Tezos developers to build a highly modular system where you can instantiate any kind of blockchain. Making changes to the physical blockchain does not incur in any penalties elsewhere in the system.
Abstract Protocol
Tezos architects went a step beyond abstracting the blockchain implementation. In fact, it was a giant leap beyond what the previously available cryptocurrencies were doing at the time (circa 2014).
Tezos also abstracted away the rules of the game.
The Tezos protocol isn’t hard coded into the core system! It’s executable code that is linked to on the blockchain itself. Which means the system itself can be changed and those changes can be committed back on the blockchain.
Different protocols can be voted on by the community of Tezos bakers. The actual stakeholders, those who hold Tezos coins, get to decide whether a change to the system is desirable or not. With this, Tezos also decentralized the development decision process.
The physical blockchain can be changed, the business logic can be changed and all this gets voted on by the stakeholders.
Motivation
To understand how these concepts are a major advance on the staet of the art, let’s take a look at how cryptocurrencies were being developed when the Tezos whitepaper was published in 2014.
In mid 2013 through early in 2014 I was mining Litecoin and Dogecoin using GPU’s. Which led me to investigate how those two cryptocurrencies worked.
To my surprise, they were made of 99% Satoshi Nakamoto code from Bitcoin Core. I then discovered that, to create a cryptocurrency like LTC or DOGE, all you had to do was change the blockchain parameters and the hashing function.
What blockchain parameters?
Things like block time, maximum circulating coins, halving calendar, difficulty adjustment period, block size and so on.
Changing any of these parameters requires a hard fork. Once you change fundamental aspects of the blockchain, your previous blocks will not validate and clients will reject them. So, to make changes to systems forked from Bitcoin Core you need to :
- Get the group of developers to agree on which changes to make
- The developers tell the community they’re making changes
- The community may or may not shout out against it on social media
- If the backlash is acceptable, implement those changes in code
- Commit the code and package a release
- Every miner and every full node must download the new release, run it and announce that they’re running it
- When a certain number of blocks has passed and enough network nodes are reporting that they’ve upgraded, the upgrade is considered finished
Forks often led to serious infighting.
Developers often disagree on some aspect of the new proposed system. If the differences are irreconcilable, devs will probably fork the system and launch a new cryptocurrency.
Several cryptos were created this way, simply because of disagreements in the development process.
Worse yet: everything gets decided in a “developer Vatican” style decision process.
Developers decide, everyone else adapts.
There is no popular vote on critical system changes and investors with high amounts of stake do not get a say, except through social media and political influence.
In this kind of system, developers are benevolent dictators (a term coined by the Linux kernel development community).
Developers listen to the community, but there’s nothing actually stopping them from making unpopular changes to the code.
As you can see, this is a byzantine process.
A better system was required, and that’s what motivated the Tezos architects to publish the 2014 whitepaper.
The Tezos Solution
Tezos solved most of the problems from early cryptocurrency development process.
- Any stakeholder (baker), not just developers, can propose changes to any part of the Tezos system
- The proposal is announced on the blockchain
- Anyone who holds XTZ tokens can vote on the process.
- The decision is based on a majority of votes from stakeholders, all registered on the blockchain, with no subjective calls anywhere.
- No central location required for the code. Only the binary code’s hash is stored on the blockchain.
- Once agreed upon everyone receives the correct hash and refuses to run code that does not match
- Upgrade completion depends solely on the above process, not requiring nodes to announce that they either agree or disagree with the changes
Sounds good! But how does this actually work? How is it implemented?
Let’s take a look at the details.
Tezos Self Amendment Process
Making changes to the Tezos system is called the amendment process.
This process takes place during 32 cycles, where each cycle takes roughly 3 days. A complete amendment takes around 3 months from start to finish.
The process is divided into 4 periods of 8 cycles each:
- Proposal period
- Exploration vote period
- Testing period
- Promotion vote period
Period 1 : Proposal Period
Any baker can submit an amendment proposal.
A baker will develop some OCaml code, hash it and submit the hash for exploration.
Bakers start to vote on the submitted proposals.
The most voted proposal on this period advances to the exploration vote stage.
Period 2 : Exploration Vote Period
This is a “filter” period.
Here, a qualified majority of votes is required to let the proposal move onto the next stage.
Bakers holding at least 80% of rolls must vote to allow the proposal through.
The bar is set very high on purpose. A vast, nearly unanimous, majority of stakeholders must approve the change.
Period 3 : Testing Period
Here, Tezos automatically forks the previous blockchain.
A new testnet is created automatically where bakers can test the system at will.
Bakers analyze the new system for 8 cycles (~24 days).
Period 4 : Promotion Vote Period
After testing the new fork, bakers start voting once more.
Again, 80% of the total wealth holders must agree on the change in order for it to get accepted.
At the end of this stage, if the 80% is reached, the new system automatically becomes the mainnet. The previous mainnet is discarded.
The hash for the source code submitted on Period 1 becomes the new law of the land.
Tezos has now upgraded itself, without developer infighting, no social media flame wars and no external political influence.
Every step of the amendment process was committed on the blockchain.
Major stakeholders, with most skin in the game, decided on everything through transparent voting.
Conclusion
As you can see, Tezos’ self amendment system is revolutionary.
Especially considering that it was first published in 2014, when first generation cryptocurrencies were simply forking the Bitcoin Core code and making slight changes to it in order to rush new cryptocurrencies out.
The Tezos amendment system allows those with skin in the game to decide whether changes can be committed. It eliminates the need for benevolent dictators coordinating the open source project.
The network automatically forks and updates itself when votes indicate approval. There is no need for miners and nodes to signal approval or not.
A hash representing the accepted source code is stored on the blockchain, linking an actual executable with the blockchain. Code that compiles to the binary which generates this hash is made available on a public repository, but it can be stored anywhere. As long as the hash matches, it’s accepted.
You can view Tezos amendments using an explorer. For example, TezTracker. At the time of this writing you can see 5 amendments have been completed: Athens, Brest, Babylon, Carthage 1 and 2.