Includes Emmy+, delegatable tz1 addresses, Michelson upgrades to improve compilation from high-level languages, hardened governance mechanisms, and more. Refines Babylon 1 to ease transition for bakers and developers using custom signers.
Features
After receiving feedback on the Babylon 1 proposal, Nomadic Labs, Cryptium Labs, and the Marigold team proposed a new tweaked version of the proposal: Babylon 2. The tweak should make integration easier for bakers and developers: in particular, the representations for endorsements are less likely to break custom signers.
Otherwise, Babylon 2.0’s changes to Tezos match Babylon 1, including:
A new variant of our consensus algorithm, Emmy+, that is both more robust and simpler to analyze
New Michelson features which assist Tezos smart contract developers and designers of higher-level languages (e.g. SmartPy, LIGO, Lorentz)
The changes made to Michelson in this proposal intend to simplify smart contract development by making the code of complex contracts simpler and cleaner.
An account rehaul that establishes a clear distinction between accounts (tz1, tz2, and tz3) and smart contracts (KT1)
Makes implicit accounts (i.e. tz1, tz2, and tz3 accounts) able to delegate and KT1s are for contracts
Replaces KT1 accounts with formally verified KT1 script (with same semantic)
Refinements to the quorum formula and a new 5% proposal quorum
A Proposal will require 5% support in the Proposal Period to proceed to the Exploration Vote Period
The Quorum floor will be set to 20% and a Quorum cap set to 70%
The account separation is a good move. Although these infrastructure-focused protocol upgrades are a bit boring, they are so crucial for a successful chain. I hope that as more developers come into Tezos, that a standard to package orthogonal upgrades into one will emerge.
In the end it comes down to the integrity of the protocol and how you look at it. In my personal opinion going down the path B makes the most sense as the promotion phase is still ahead of us and quorum needs to be reached in order to activate Babylon2.0.1. More importantly I think it’s important not to loose more than three months and a proposal phase where additional features can be added.
But in general this also raises the question on how security concerns will be addressed in the future where it does not make sense to go through a whole proposal process to fix a security vulnerability and have it exposed during the voting periods. There should be an approach for fast tracking proposals or a different governance approach for such issues.
I support option B, but with reservations. The bottom line for me is that 1) our process should account for these kind of issues arising during the protocol testing phase (rather than hacking the shell to have just-this-once exceptions); and we need a comprehensive suite of regression tests to validate proposals early in the proposal process to catch these kinds of problems (allowing for proposals to update those tests explicitly/publicly as needed).
Yes, we have already applied hotfixes to the protocol, and will likely need to do so in the future too. As said above, perhaps we need an explicit approach for fast-tracking hotfixes, including those to proposals not yet deployed as now.