A successful transition to the Tenderbake consensus mechanism relies on the Tezos ecosystem making sure the infrastructure is prepared for the changes. Here is a checklist of the necessary steps.
The Ithaca2 protocol proposal contains the perhaps most significant upgrade of the Tezos protocol to date.
Replacing the consensus mechanism is in itself a major undertaking, as it defines the rules by which Tezos bakers decide the state of the ledger – a core function of a blockchain.
Performing such an upgrade on a live, global blockchain network further complicates things. It is essentially like replacing the engine of a car while it is running, and it is important to note that for certain types of existing infrastructure Tenderbake introduces breaking changes.
A decentralized network is dependent on its constituent actors doing their part, and in the Tezos ecosystem that means keeping on top of necessary changes as the protocol evolves.
After the Granada upgrade in August, the network experienced longer block times and many missed endorsements, temporarily lowering network “health”. After the Hangzhou upgrade in November, context flattening caused some low-spec nodes to run out of memory.
In both cases the network stayed online and the issues were resolved, but there is no denying that protocol upgrades can get bumpy.
Despite increased testing efforts on our part, it is not possible to fully model the complexities of the mainnet, and this is where preparation becomes important.
To increase the likelihood of a smooth transition, we call on all ecosystem participants to make sure they are prepared for Ithaca2 activation, which will happen around March 31st, provided that the upgrade is voted in by the community.
This includes bakers, block explorers, wallet providers, exchanges, indexing service providers, node-as-a-service providers, dapp maintainers, and everyone else involved in providing tooling or services in the Tezos ecosystem.
Generally, we encourage the ecosystem to join the
ithacanet testnet to make
sure their setup and infrastructure works with the upcoming protocol version.
As a minimum, the following should be completed by the time of activation:
Bakers using a Ledger hardware wallet for secure signing need to update the Tezos Baking app on their device to
v2.2.15. Earlier versions will NOT work after Ithaca2 activation.
Remote signing software for baking will need to be significantly updated1.
Block explorers and other indexing software will need to be significantly updated.
Dapp maintainers are highly encouraged to test their dapps on the testnet.
Given the scope and complexity of the upcoming upgrade, we find it important to remind the community that the Tenderbake consensus mechanism marks a shift to favoring the network being safe over being live.
The current Emmy* consensus mechanism allows for multiple versions of the network, forks, to run in parallel during a major network split. This could be due to global internet disruptions or a software bug. Similar to how Bitcoin and Ethereum work.
When connection between different forks is re-established, the version with the largest stake (or for Proof-of-Work networks, the most hash-power) will define the state of the ledger. Smaller forks are abandoned.
This keeps the network running, live, at all times, but carries the possibility of transactions being reverted if they are on a smaller fork.
With Tenderbake this changes. As a so-called classical BFT-style consensus algorithm, it operates on the assumption that at least 2/3 of the total stake is honest.
As long as this is the case, there can be no parallel block production that suddenly replaces or reverts transactions following a network split. Any small fork will halt2. The network is safe.
The trade-off is that if more than 1/3 of the total stake is isolated or offline, the entire network will halt until connection between at least 2/3 of the total stake is re-established, rather than staying live as separate networks.
This is by design. Intended behavior. But it can be triggered by a bug — or by a large enough number of unprepared network participants, which this blog post aims to prevent.
As Tezos continues to gain adoption and will need to offer higher throughput, questions have arisen whether hardware requirements for bakers will increase.
We do not see the current upgrade to Tenderbake consensus making this necessary. We expect current hardware setups to remain sufficient, provided they live up to the generally recommended specifications.
Upcoming Layer 2 scaling initiatives, such as optimistic roll-ups, are expected to greatly alleviate the pressure on the main chain, Layer 1.
However, Tenderbake is a first step towards tweaking the network to increase throughput on Layer 1. It is possible that increased adoption, resulting in fuller blocks, combined with tweaks of certain network parameters can lead to the lowest-powered baking systems eventually needing to be upgraded.
Should it become relevant, it is important to note that a slight upgrade of the lowest-powered systems — e.g. from a Raspberry Pi to a sufficiently powered Intel NUC — would not affect Tezos’ highly energy-efficient profile in any significant way.
As the recent PwC report assessing Tezos’ carbon footprint shows, 10% of respondent bakers reported using a Raspberry Pi, each drawing about 9 watts. Switching to an Intel NUC would increase the energy consumption of these bakers’ systems to about 12 watts.
Tenderbake is a major milestone for Tezos and its community. We are excited to be a part of this major protocol transformation and eager to see what new opportunities it will bring.
The change of consensus algorithm introduces new operations (pre-endorsements), new concepts (such as rounds), and changes the semantics of existing software components. This changes the byte payload of the consensus operations signed by bakers, and the rules to prevent double (pre)endorsing/baking. Hence, a new version of the signer software is required. Read more here. ↩
Assuming the split is unintended. If more than 1/3 of the total stake is held by bad actors intentionally performing a coordinated attack, the network can indeed fork. ↩