Preheating Ovens for Babylon
Babylon2.0 / Babylon2.0.1 is the protocol upgrade undergoing the Tezos on-chain governance process. At the time of writing, with a participation of 80.10% (exceeding quorum requirements) and 86.27% of favourable votes, this proposal will be activated in a few days, as soon as the promotion period concludes.
Babylon is a collection of features developed by Cryptium Labs and Nomadic Labs. This article’s purpose is to provide an overview on how these changes will affect the different groups of stakeholders in the Tezos ecosystem and what each group should take into consideration, in order to make the transition to the new protocol as smooth as possible. The groups I will focus on are bakers, wallet developers/client implementers, and delegators.
Note that 004 refers to Athens or the current Tezos mainnet, whereas 005 refers to Babylon or the upcoming mainnet.
How Babylon Affects Bakers
Transitioning from 004 to 005
Bakers need to pull the latest release of mainnet, which was published a few weeks ago. Note that bakers can already upgrade to the latest mainnet release and are advised to do so before Babylon is activated. If you’re running a custom version of the baker, make sure your version adopts the crucial parts of the latest mainnet release.
Changes to the rewards system
For bakers who are operating public baking services and are in charge of paying rewards to delegators, note that with the introduction of Emmy+, an improved version of Emmy the Tezos consensus algorithm, the rewards system will change for baking rewards.
In 004, block rewards are 16 XTZ, earned by the baker that successfully bakes a block. With 005, baking rewards are calculated as follows: block_reward / (p + 1) * (0.8 + 0.2 * e / 32) where p = baked block priorityand e = number of included endorsements. For example:
# example 1
block_reward = 16
p = 0
e = 32
baking reward = 16 / (0 + 1) * (0.8 + 0.2 * 32 / 32) = 16 XTZ# example 2
block_reward = 16
p = 2
e = 32
baking reward = 16 / (2 + 1) * (0.8 + 0.2 * 32 / 32) = 5.3333 XTZ
The factor e / 32 in the baking reward function is used to incentivise bakers to include all available endorsements.
If you are using a custom script or APIs to calculate how many rewards should be paid to which delegator, make sure you adapt or request the third party API developers to do so.
- Further reading: Emmy+: an improved consensus algorithm by Nomadic Labs
- Further reading: Analysis of Emmy+ by Nomadic Labs
Important note for bakers using the TzScan API
On the 14th of October, the team behind TzScan announced that they will shut down their services. If your baking stack relies on the TzScan APIs, now is a good time to find an alternative, for example:
How Babylon Affects Wallet Developers and Client Implementers
Simplifying the delegation process
The feature in Babylon that wallet developers need to pay special attention to is the simplification of the delegation process by making implicit accounts (tz1, tz2, tz3) delegatable.
In 004, users cannot make delegations directly through their implicit accounts (tz1, tz2, tz3) and have to rely on a multi-step process that involves creating originated accounts (KT1). With 005, implicit accounts will be able to set their delegate directly. Wallet developers can refer to the extensive list of resources below to adapt their wallets to 005:
- Simplifying the delegation process by Cryptium Labs
- Migration guidelines by Adrian Brink from Cryptium Labs
- Migration guidelines by Nomadic Labs
- The road to Babylon, which includes their reference implementation made by AirGap, a Swiss wallet
Note that with 005, wallets and client implementers will no longer be able to create delegations using the old KT1 multi-step process. However, they can use the same default manager.tz smart contract.
How Babylon Affects Delegators
Existing delegations
In addition to the delegation process simplification, Babylon includes a migration strategy for existing delegations, which are script-less smart contracts. The migration script will turn delegations (script-less smart contracts) into scriptful smart contracts, conserving delegation values, parameters, and functionalities.
In other words, with 005 delegators do not need to take any action, what was delegated in 004 will remain delegated after Babylon is activated.
Future delegations
For delegations made post Babylon’s activation, delegators will no longer be able to delegate through the multi-step process. Depending on what wallet(s) you are using, the respective wallet developers might need some time to adapt to 005. This might result in your favourite wallets’ account management and delegation features to be unavailable for some time.
Note on Block Explorers
As TzScan will be shutting down in a few days, here’s a list of existing and upcoming block explorers:
- TzStats: https://tzstats.com
- TezosID: https://tezos.id
- TezBlock: https://mvp.tezblock.io
- Arronax: https://arronax-beta.cryptonomic.tech
- Mininax: https://mininax.cryptonomic.tech/mainnet
