The Granada protocol amendment was activated at block 1589248 on Friday 6 August 2021 at 11:36 AM CEST. Nomadic Labs would like to thank the community, bakers, and development partners for their diligent assistence in developing and adopting this proposal.
On May 31st, Nomadic Labs proposed together with Marigold, Oxhead Alpha, Tarides, and DaiLambda an amendment to the Tezos protocol named Granada. Tezos’ on-chain governance procedure enabled the adoption of the proposal by the community and the subssequent activation of Granada.
Granada introduced three important upgrades:
- Liquidity Baking: 2.5 tez are minted at each block to incentivize liquidity providers of a tzBTC/tez pair
- Emmy*: a change in the consensus algorithm making blocks up to twice more frequent
- Gas improvements coming from a refactoring of the Michelson interpreter and an optimization of data serialization.
Since August 10, 2021 23:19 CEST, the Granada protocol has run on Tezos mainnet for a complete cycle (8192 blocks). Below, Nomadic Labs is pleased to share data from the first complete cycle and an analysis of the impact of these three features.
Liquidity Baking
Liquidity baking is a primary example of the utility of Tezos’ on-chain governance to provide for public goods that go beyond securing the network.
The liquidity baking proposal is an experiment to see if a decentralised protocol can use incentives to create liquidity around them. As of publication, over 980,000 tez and 72.3 tzBTC (about $6.8M worth) were deposited in the liquidity baking contract, demonstrating a successful deployment of the contract and concept.
During the first cycle of Granada, total value locked in the liquidity baking contract steadily increased. In the first few hours after going live, over 2 million USD worth of coins (24.19 tzBTC + 331,000 tez) were deposited.
Graph of the so-called “TVL”, courtesy of liquidity-baking.com
Community members can track live statistics on liquidity baking on the statistics page developed by Tessellated Geometry — liquidity-baking.com.
Emmy*
Emmy consensus algorithm is one of the most important changes to the core protocol of Tezos in Granada. Emmy tweaked the block delay formula to allow blocks to be produced more frequently.
Emmy* is the culmination of multiple updates to the consensus algorithm. In a recent survey we have detailed the various flavours of the Emmy family of consensus algorithms.
Before Granada, the minimum delay between blocks on Tezos mainnet was set to 60 seconds. When the network was perfectly healthy (with all bakers and endorsers online and able to quickly produce, validate, and transmit blocks and endorsements), the chain advanced at the speed of one block every minute. When network health dropped however, the chain reacted to maintain consensus. This works based on the number of endorsements that a baker includes in a given block; each block contained 32 endorsement slots and if less than 2/3 of these slots were filled, the baker had to wait before publishing its block (the fewer slots are filled, the longer the delay).
Emmy* does not fundamentally change this behavior, but it changes the parameters in order to decrease the latency of the chain. In Granada, each block contains 256 endorsing slots (instead of 32), the minimal delay between blocks is 30 seconds (instead of 60), and the required proportion of endorsement slots needed to publish a block after 30 seconds is 60%.
Figure 1 shows the level of each block of the last cycle of Florence (cycle 387) and the first cycle of Granada (cycle 388) in function of the time the block was produced.
Block Times
Activation of Granada and Emmy* caused a temporary slow down in the chain. Blocks were produced on average every 2 minutes and 11 seconds with a maximum time between blocks of roughly 15 minutes.
Our investigations uncovered several issues. First, blocks that arrived too late were not endorsed at all, causing the next block to be produced after the maximal block delay (almost 15 minutes for a block baked at priority 0). Version 9.6 of Octez was released on Friday at about 5PM CEST to mitigate the delay. The update increased the delay after which the endorser gives up on endorsing to 1200 seconds (previously 110 seconds).
Version 9.6 of Octez ensured no blocks were baked completely without endorsements, solving a key aspect of the slow down. After further research, we noticed numerous computations took place during the handling of pending consensus operations. Fixes for this problem were included in version 9.7 of Octez, released on Saturday August 7 at about 10 PM CEST.
Bakers reacted quickly and updated to the new versions of Octez. This time, the rate at which blocks are produced and propagated on Mainnet was significantly improved: quickly after the version 9.7 of Octez release the chain average delay between blocks decreased to almost 30 seconds.
If we take as reference the block production frequency of mainnet until the activation of Granada (one block per minute), it took 3 days, 6 hours, and 51 minutes for the chain to catch up at block 1593978 (the 4731 first blocks of Granada were produced in 4731 minutes).
Remaining Issues
For the rest of the cycle, the chain has run at the expected speed but problems remain: endorsements are still being missed more often than expected. We are continuing to monitor the situation and to investigate the potential causes of the missing endorsements.
At the moment, we are leaning towards the conclusion that with Emmy* block propagation itself may be reaching the limits of what some bakers are capable to sustain. We are thus investigating several ways to improve block propagation, with possible optimizations such as only validating block headers before propagating blocks.
We would like to thank the community for their continuous support. We are especially grateful to everyone that promptly upgraded their nodes, tested patches and provided feedback. The collaboration and communication of the community and bakers contributed to our ability to identify and mitigate the network issues.
If you are running a node and haven’t upgraded it to version 9.7 yet, we strongly advise you to do so.
Gas improvements
As we explained in a recent post, Granada includes two important gas optimizations: a refactoring of the Michelson interpreter and memoization of the serialization function for recursive types.
In order to evaluate the impact of these gas improvements we have measured the gas consumption of all contract calls in the last cycle of Florence (cycle 387) and in the first cycle of Granada (cycle 388). There is lot of variation between the gas consumed in the smart contract calls because the called contracts can be very different. To make the result smoother and more readable, we have averaged these gas consumption measured over a span of 1000 smart contract calls.
The result can be seen in the figure below:
Overall, average gas per smart contract call has been decreased by a factor of 5; from 43197 gas units per call in cycle 387 to 8591 gas units per call in cycle 388.
Conclusion
Thanks to the activation of the Granada amendment, more than 5 million USD worth of liquidity have been provided to the newly deployed Liquidity Baking contract, the Tezos chain is moving almost twice as fast as before, and the gas consumption for smart contract calls has been reduced by a factor of 5.
We acknowledge the migration was not as smooth as usual. All Tezos dev teams understand the inconvenience that results from slowing down of the chain and missed endorsements. This was caused by a combination of issues, some of which still require investigation. We would like to thank the responsiveness of community members and bakers who applied emergency Octez updates.