Babylon 2.0 (PsBABY5HQ)

Deprecated in favor of Babylon 2.0.1 (PsBabyM1)

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%

Explanation Posts

Migration Resources

Invoice

500 ęś© to a multisig at KT1DUfaMfTRZZkvZAYQT5b3byXnvqoAykc43

Proposal archive

View this proposal on Agora

3 Likes

Ok people, let’s discuss this proposal. What do you like what you don’t like, cons and pros.

5 Likes

I like that you can now delegate with implicit accounts, makes it much easier for new users to delegate rather than create a KT1 account

8 Likes

Yes, it does. I’m a baker, I just hope it’s not going to interfere with my payment software.

1 Like

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.

2 Likes

What was the reason for making tz accounts non-delagatable in the first place ?

1 Like

Updating this thread with details about Babylon 2.0.1:

1 Like

cross posting from reddit:

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.

1 Like

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.

6 Likes

Good option is
*New Option C: fix, revert to test phase, repeat until perfect, then vote promote. Also update official #Tezos amendment workflow.

1 Like

leaning towards option B…

1 Like

I do like the sound of bva’s proposal for option C. I missed much and would like to learn as Tezos Develops. Still option B is my vote.