Nomadic Labs
Nomadic Labs
Babylon: Proposal Injected!

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.

A Babylonian signing roll

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 | 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


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.


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 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 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. 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 Babylons source code, and detect it the hash as rendered in Base58 starts with baby. If you look in, 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.

Michelson updates in 005

Changes in Michelson As hinted at in a previous blog post, we’ve been working on improving different parts of the protocol, including our favourite smart contract language: Michelson. The changes made to Michelson in this proposal intend to simplify smart contract development by making the code of complex contracts simpler and cleaner. In particular: smart contracts now support entrypoints contracts can now create, store and transmit as many big_maps as they want comparable types are now closed under products (i.e. the pair constructor) a new instruction, CHAIN_ID, allows...

Read More
Analysis of Emmy+

Note: This analysis was done with the help of Arthur Breitman and Bruno Blanchet (Inria). The code used for the analysis can be found at this url. We have recently announced Emmy+ an improvement of Emmy, the current consensus algorithm used by Tezos. In this blog post, we perform a brief analysis of Emmy+. Disclaimer: We emphasize that this is not a complete analysis; in particular, we do not present any security proofs. Also, the...

Read More
An indexer for Tezos

We are happy to announce that the indexer for Tezos we have been working on is ready for beta-testing and available here. But first… What is an indexer, and what is it useful for? Mainly, indexers fill a void by providing information that’s not directly available from the node’s RPC interface. But then why don’t nodes provide these RPCs in the first place? That’s simply because when you design and implement your node, you want to provide just what is necessary, focus...

Read More
Meanwhile at Nomadic Labs #3

Another update on the many projects we have been busy working on. Most of the following topics will be subject of more in-depth posts of their own. Protocol The consensus team is finishing their analysis of selfish baking on Emmy+ and tweaking the constants of the protocol accordingly. At the same time work on our version of Tendermint is progressing to the point of having a proof of concept protocol to play with. The protocol team has been steadily reviewing and testing...

Read More
How to write a Tezos protocol

A Tezos node is parameterized by a software component called an economic protocol (or protocol for short). Different protocol implementations can be used to implement different types of blockchains. This is the first post of a tutorial series on how to implement such a protocol. We will see how to write, compile, register, activate and use an extremely simple protocol. By doing so, we will also start to explore the interface between the protocol and the node (more specifically the shell component of...

Read More
Emmy+: an improved consensus algorithm

Underlying the Tezos network is a consensus algorithm, which, for the ease of reference, we will call Emmy. Consensus ensures that participants agree on the same blockchain and on its state. The ideas behind Emmy are described in the white paper and the specifics to its implementation can be found in the documentation. We recall that Emmy is a PoS based consensus with a use of endorsements to speed-up confirmation times and reduce...

Read More
Release of Mainnet May

Today we are proud to announce a new release of the Tezos node and client. The main features present in this release are: node support for snapshots (boot and synchronize a node in minutes), node support for new history modes (not everyone needs to be an archive), client integration for a multi-signature contract. Remember that besides major features there are always a myriad of smaller improvements, have a look at the changelog. We encourage bakers to switch to history mode “full” using a snapshot before the activation of...

Read More
Athens on the testchain

The quorum for the second voting phase has been reached, with a supermajority of Yays! This means that the voting procedure can proceed to its third stage: the test chain for Athens is going to be launched soon, approximately Friday April 12th. To accompany that, we just released a new version of the Tezos node and its baking daemons. This release includes many improvements, most notably a new --enable-testchain option. Users who want to participate in the test chain should upgrade...

Read More
Meanwhile at Nomadic Labs #2

The last few weeks have been pretty intense at Nomadic with the preparation of the first community voted upgrade! The team has been working hard on some special future improvements to Tezos… Improvements to the consensus layer Tezos has the unique ability to amend itself which allows us to propose state of the art research to the network at any time. This is not a far fetched ideal and will happen sooner rather than later in a series of new efforts...

Read More
  • 1
  • 2

Receive Updates