Summary:

EDIT (August 2, 2019): The updated Babylon proposal has been injected by Cryptium Labs. Its hash is PsBABY5HQTSkA4297zNHfsZNKtxULfL18y95qb3m53QJiXGmrbU. The instructions contained in this post have been updated accordingly.

Cryptium Labs just injected the hash of our new joint proposal: Babylon. This triggers the beginning of the third on-chain vote to amend Tezos. This process could end in the successful migration from current protocol Athens in about three months, if the participants decide so.

This update is joint work with Cryptium Labs, with contributions from the Marigold team, and it is much more significant than Athens in terms of features.

Its main changes to Tezos are:

• a new variant of our consensus algorithm, Emmy+, that is both more robust and simpler to analyse,
• many new Michelson features which have been eagerly awaited by Tezos smart contract developers and designers of higher level languages,
• an account rehaul that establishes a clear distinction between accounts (tz1, tz2 and tz3) and smart contracts (KT1),
• refinements to the quorum formula and a new 5% proposal quorum.

This time, we made only one proposal, as we believe that all features in it are necessary improvements for the future of Tezos.

Like last time, this proposal includes a symbolic invoice of ꜩ500. For a twist, we credited an instance of our verified multisig shared among the contributors to this proposal to pay for drinks.

This post includes instructions to download and observe the code, to recompute the hash by yourself, and to examine the differences with the current protocol. It then gives the method we recommend to bakers if they wish to upvote the proposal.

Beyond these on-chain administrative details, the post summarises the main changes, giving simple high level explanations and pointers to more detailed articles on our blog or Cryptium Labs’.

We also provide a reference documentation page for the proposal which contains information on breaking changes for node administrators and application developers (to be completed soon). This page also contains a curated subset of the changelog that everybody is strongly encouraged to read carefully.

Finally, bear with us until the end for a geeky bonus.

Getting the source code of the proposals

The source code of this proposal is available in this tar archive.

To compute the hash, you can use the tezos-protocol-compiler as follows. The result should be PsBABY5HQTSkA4297zNHfsZNKtxULfL18y95qb3m53QJiXGmrbU.

mkdir proposal && cd proposal
curl https://research-development.nomadic-labs.com/files/babylon_005_PsBABY5H.tar | tar -x
tezos-protocol-compiler -hash-only babylon_005_PsBABY5H/lib_protocol

If you want to directly investigate how Babylon differs from the current protocol, you can use diff against folder proto_004_Pt24m4xi of the mainnet source code. All the changes should be the ones detailed in the changes section, except for the removal of the single use migration code from the previous upgrade (from 003_PsddFKi3 to proto_004_Pt24m4xi).

How to upvote the proposal

The easiest way to create and sign a voting operation today is to use the command line Tezos client, as follows, and as detailed in the online documentation.

If you choose to upvote the proposal:

tezos-client submit proposals for <delegate> PsBABY5HQTSkA4297zNHfsZNKtxULfL18y95qb3m53QJiXGmrbU

Detailed list of changes

Emmy+

Protocol 004 implements a consensus algorithm nick-named Emmy. Protocol 005 introduces several improvements to this algorithm, regrouped under the name Emmy+. In particular:

• the fewer endorsements a block carries the longer it takes before it can be considered valid,
• the fitness of a block is simply its height in the chain,
• changes to the rewards for block and endorsement of priority greater than 0.

Detailed informations can be found in the blog announcement and analysis.

Merge requests 1 and 2.

Michelson

Protocol 005 contains several improvements to the Michelson smart contract language. More details are provided later in the changelog and in the Michelson update blog post.

A summary of the main changes:

• smart contracts now support entrypoints (MR),
• contracts can now create, store and transmit as many big_maps as they want (MR),
• comparable types are now closed under products (i.e. the pair constructor),
• a new instruction, CHAIN_ID, allows contracts to differentiate between the test chain and the main network (MR),
• a gas cost overhaul has been integrated, and STEPS_TO_QUOTA has been disabled until a more robust semantics is found (MR).

New instructions to facilitate compilation to Michelson - Marigold

Some new instructions have been added in order to make Michelson a better compilation target for high level languages.

The new instructions DIG n, DUG n, DIP n { code }, DROP n allow to simplify commonly used patterns (MR).

The new instruction APPLY allows to perform the partial application of an argument to a lambda (MR).

Changes for compatibility with the accounts rehaul

A few changes are needed as a consequence of the accounts simplification.

• the instruction CREATE_ACCOUNT disappears,
• the type of CREATE_CONTRACT changes.

Proposal quorum - Cryptium Labs

During the first period of a voting procedure, proposals can be submitted and the one with the largest number of upvotes is promoted to the testing vote period. In 004 the promoted proposal can have any number of upvotes, even 1, as long as the others proposals, if any, have less. Protocol 005 introduces a quorum of 5% (constant min_proposal_quorum) for proposals to be promoted to the testing vote period, if there is less than 5% of the stake supporting them, the protocol goes back to a proposal period.

Cryptium’s blog post.

Merge request.

Quorum caps - Cryptium Labs

During the test phases the participation needs to reach a quorum for a vote to be successful. The quorum adapts over time based on the participation of past votes. In 004 the quorum can reach very high values which would make passing new proposals very difficult even if there is large acceptance. On the other hand the quorum could reach very low levels if there is little participation. Protocol 005 introduces caps to limit the maximum and minimum values that the quorum can reach. The values proposed for minimum quorum cap is set to 20% and the maximum to 70%, these values can be changed in future updates. Additionally the formula to update the quorum uses an exponential moving average of the participation.

Cryptium’s blog post.

Merge Request.

Make implicit accounts delegatable - Cryptium Labs

In protocol 004 only KT1 addresses, representing an account for delegation or a smart contract, can be delegated and only tz accounts can register as delegate. In protocol 005, tz accounts which are not registered as delegate can be delegated towards a tz account registered as delegate. This change does not affect existing delegations of KT accounts.

One restriction remains that may be lifted in the future: once a tz account is registered as delegate it cannot be un-registered. This in turn means that a registered delegate that wants to stop being one, cannot delegate to somebody else. The only solution for now is to move the funds to a newly created tz account and delegate from there.

Cryptium’s blog posts 1 and 2.

Merge request.

Replace KT1 accounts with manager.tz script - Cryptium Labs

In 004 an address KT1 can refer to a scriptless account used for delegation or to a smart contract with code. Given that in 005 it is possible to delegate from tz accounts, scriptless KT1 accounts are deprecated. Existing KT1 accounts are replaced with a smart contract manager.tz which implements the same semantics. The smart contract has been formally verified in Mi-Cho-Coq.

While the migrated accounts preserve all their features, this will change the way wallets and other applications interact with them. Detailed instructions for migrating such applications will be provided in the coming days in the documentation page.

Cryptium’s blog posts 1 and 2.

manager.tz script and proof.

Merge requests 1 and 2.

Bonus section: how did we get this pretty protocol hash ?

The hash of the protocol is a unique identifier computed from its source code. Each time we modify a character in the source code, the hash changes. To obtain a specific hash, or a hash with a specific form, the only solution is to generate a lot of source codes until the hash matches.

This is what we did, by tweaking the Tezos compiler to include a small (non significant) random part in Babylon‘s source code, and detect it the hash as rendered in Base58 starts with baby. If you look in main.ml, you will see a comment line (* Vanity nonce: 1260059503 *).

This cool trick is actually useful, as it will allow humans to quickly identify the protocol from the hash when looking at RPC results.

You can do a similar thing with your Tezos addresses with the command line client, by running command gen vanity keys <new> matching [<words>...] --prefix. Of course this generates an encoded key on your disk, which is not as secure as using a hardware wallet. Creating a vanity key on such a device, is an exercise left to the reader.