Summary:
This is a joint announcement from Nomadic Labs, Marigold, and Metastate.
A couple of weeks ago, we were proud to see the “Delphi” upgrade to the Tezos protocol go live. This week, we are proud to announce our latest protocol upgrade proposal, “Edo”. As usual, Edo’s true name is its hash, which is PtEdoTezd3RHSC31mpxxo1npxFjoWWcFgQtxapi51Z8TLu6v6Uq.
Why is Edo being proposed when Delphi has only been in place for a short while? Although Delphi went live on November 12th, it was proposed on September 3rd. In the intervening months, we’ve been hard at work on the core Tezos software, and we’ve made significant improvements that we want to share with the users of the network. In particular, we have now completed a number of improvements that were in progress at the time that the interim Delphi update was proposed.
The Tezos protocol currently provides windows for new proposals every several months; one such window is now open. As we explain in this blog post, we intend for the foreseeable future to take advantage of every such opportunity, proposing upgrades that incorporate the improvements that have been completed in the intervening months since the last proposal.
Most cryptocurrency networks cannot be updated on a regular basis; they have no mechanism that overcomes the high coordination costs associated with protocol changes. Tezos, however, possesses an on-chain self-governance mechanism, as well as a mechanism for self-amendment without forks, and so we can propose updates to the chain which, if adopted by its users, are then automatically implemented. We intend to take full advantage of that mechanism going forward to make Tezos better and better with every proposal.
As for Edo itself: a full list of the changes can be found on this documentation page. In summary, however, the proposal contains some minor bug fixes, some additional improvements to performance and gas costs (albeit not as extreme as the ones in Delphi), the addition of a so-called “adoption period” to the voting schedule, and two important new features that we have been working on for some time: Sapling, and Tickets.
Sapling is a protocol originally developed by the Electric Coin Company for the Zcash project which implements shielded transactions. Our proposal allows smart contract developers to easily integrate Sapling in their smart contracts and create privacy-conscious applications. Because Tezos can be amended, it was possible for us to add this exciting new feature directly to Tezos itself.
Since our initial announcement of Sapling, the integration with Tezos has seen extensive testing and has been enhanced in numerous ways; we have also improved the performance.
Tickets are a convenient mechanism for smart contracts to grant portable permissions to other smart contracts or to issue tokens. While it’s possible to achieve this with existing programming patterns, tickets make it much easier for developers to write secure and composable contracts.
The “adoption period” (sometimes referred to as the “fifth period”) is an important improvement we have wanted to make to the governance mechanism for some time. Just like any other feature of the protocol, Tezos protocol amendments may make changes to the amendment process itself. Up until now, new versions of the protocol have gone live (that is, have been “activated”) one block after voting has been completed, which in practice is only sixty seconds. This has made it difficult for some Tezos bakers, indexers, and other users of the network to assure seamless upgrades of their nodes. We have also seen instances where the lack of certainty about whether an upgrade would be adopted caused some users to delay preparations until the last moment.
Under the new system, instead of four periods of eight cycles during voting, we propose to have five periods of five cycles. The new fifth period, the adoption period, will be a five cycle (approximately two weeks) gap between the adoption of the new protocol and the time when it is activated. This will aid in assuring seamless protocol transitions. (We anticipate some additional minor tweaks to the voting schedule may occur in coming protocol proposals.)
Some readers may notice that Baking Accounts, a feature that has been in the works for some time, is not included in Edo. Although the core Baking Accounts software is complete and reliable, we are not yet satisfied that the migration mechanisms needed to update the chain when Baking Accounts are activated are as seamless as we can make them. In the past, some migrations have caused delays to on-chain transactions occurring around the time of an upgrade, and our tests of the Baking Accounts migration indicate that it could take a considerable period of time. Going forward, as we will be upgrading the protocol quite frequently, we intend to minimize these migration times and any disruption to the network. We are thus working on optimizing our migration mechanisms.
Following our current policy of not slowing down deployment of completed features for ones that are not yet finished, we have held Baking Accounts back for the moment. We hope that Baking Accounts will be a feature of the next protocol proposal, which, if Edo is adopted, should occur in about three months.