Nomadic Labs
Nomadic Labs
Faster finality with Emmy*

Announcing forthcoming upgrade of consensus protocol, giving quicker time to finality (i.e. shorter transaction settlement times)

We are happy to announce that Emmy* is set to be included in the next Tezos protocol proposal Granada,1 replacing the current consensus algorithm Emmy+. If Granada is adopted, Emmy* will generally halve the time between blocks, from 60 seconds to 30 seconds, and allow transactions to achieve significantly faster finality than under the current consensus algorithm, Emmy+.

Specifically, Emmy* updates Emmy+ by:

  • a tweak in the definition of the minimal delay function, and
  • an increase in the number of endorsement slots per block

both of which bring faster times to finality (in other words: shorter transaction settlement times) without compromising security.3 Please see the TZIP for the specification and issue 1027 for the implementation.

Thanks to these changes in Emmy*:

  • a block can be produced with a delay of 30 seconds with respect to the previous block if it has priority 0 and at least 60 percent of the total endorsing power per block;
  • the number of endorsement slots per block is increased from 32 to 256.

With these changes, on a healthy4 chain and for a Byzantine attacker with up to 33% stake for instance, the number of confirmations2 decreases to 2 blocks, therefore 1 minute, a sixfold improvement.

The following plot shows the number of confirmations (in log scale) for Emmy* vs Emmy+ when varying the stake fraction from 0.1 to 0.4. This plot assumes the “forks started in the past” scenario, meaning that we are interested in the finality of a block which already has a number of confirmations on top of it (and therefore, importantly, we know how healthy the chain was in the meanwhile), and we ask ourselves whether this number is sufficient. Here we assume a perfectly healthy chain. In the plot, the highest red point corresponds to 12 confirmations.

Image

To complement the above plot, the following table presents a subset of the data in text form. Each value in the table gives the number of confirmations for a given attacker stake fraction for Emmy* and Emmy+ in a “forks started in the past” scenario.

Attacker stake Emmy* Emmy+
0.1 2 2
0.15 2 3
0.2 2 3
0.25 2 4
0.3 2 5
0.33 2 6
0.35 3 7
0.4 3 12

So the final line above expresses that even if an attacker controls 40% of the stake, in Emmy* we only have to wait three blocks (90 seconds, assuming a good network, because the block time is 30 seconds) to be reasonably sure that our transaction is final, and in Emmy+ we have to wait twelve blocks (12 minutes, because the block time is 60 seconds).

Transaction finality in tezos-indexer

We are also happy to announce that tezos-indexer has a new feature: now it can tell you if your transaction is final in Emmy+.6 For instance: suppose your transaction is included in a block and that the next three blocks get baked in 190 seconds; then the indexer will tell you that your transaction is final with respect to:

  • the security threshold in Emmy+ which is 1e-8 and5
  • an adversary with at most 20% stake.

Note that 190 is just a bit more than 3 * 60 seconds, which is the minimal time needed to bake three blocks.

Now instead suppose that the three blocks get baked in more than 227 seconds: then you will need to check again after one more block/confirmation. Say the fourth block is baked in 60 seconds, so given that 4 blocks have been baked in about 287 seconds, the indexer will tell you that now you can consider your transaction as final.

We are proud to share a web demo for you to experiment for yourself with computing fork probabilities in both Emmy+ and Emmy*. It is based on our previous analysis of Emmy. If you want to dig deeper and are familiar with OCaml and Jupyter notebooks, you are welcome to follow these instructions and let your creativity run free.

Please note our previous disclaimer: Our analysis is based on a certain model of the blockchain and of an attacker. In particular, the model assumes reasonable bounds on the communication delays: that blocks and operations are diffused within 30 seconds. The attacker model is that of a baker not following the rules of the protocol: it may double bake and double endorse as it finds best in order to fork the chain. The attacker model of our analysis does not include a more powerful attacker capable of disturbing the network by blocking or delaying messages between honest participants.

Happy baking!


  1. The Tezos mainnet is currently running the Edo protocol. The Florence protocol is currently being voted on. Assuming all goes well and the Florence upgrade is accepted, the Granada proposal will follow, and Emmy* should be part of that. Subject to this all going well — we add this qualification because this is not something that Nomadic Labs can fully control; the voting process is up to you, our dear Tezos community! — then a further upgrade from Emmy* to Tenderbake is planned for a subsequent H proposal (name not yet fixed). 

  2. A confirmation refers to a block on top of the block with a transaction of interest to the user. 

  3. Emmy* is a Nakamoto-style algorithm (like Bitcoin), which means that its finality is probabilistic. Probabilistic finality means that as time passes we can become “reasonably sure” that a transaction we made is indeed included in the final blockchain (and not on some fork that might die out), where reasonably sure means “with probability of being wrong smaller than some reasonable threshold” — which we quantify as 5 * 1e-9 (five in a trillion). This puts our expectation of being wrong about a block being final at roughly once every two centuries. 

  4. We call a chain healthy over a period of time when in this period blocks have priority 0 and (almost) all endorsement slots are filled. A concrete healthiness measure is the delay of the chain with respect to the ideal chain where each block has a delay of one minute with respect to the previous block. 

  5. In Emmy+ blocks are baked at about 60 seconds, 1e-8 puts our expectation of being wrong about a block being final at the same roughly once every two centuries, which corresponds to the security threshold of 5 * 1e-9 in Emmy*. That is: we use a more rigorous security threshold in Emmy* because it’s faster so we can bake more blocks every two centuries. 

  6. This new feature of tezos-indexer will be updated with respect to Emmy* once Emmy* is adopted. 


Announcing the report “Possible evolutions of the voting system in Tezos”

Announcing a report on possible evolutions of the voting system in Tezos

Nomadic labs has an ongoing research relationship with INRIA (a French national technology research agency). In the context of this relationship, Nomadic Labs commissioned a short report to explore what a privacy-preserving amendment procedure might look like on Tezos, authored by three experts in voting protocols and cryptography: Véronique Cortier, Pierrick Gaudry and Stéphane Glondu. There is no plan to implement the contents of the report for now, but we welcome and...

Read More
Meanwhile at Nomadic Labs #11

A summary of Nomadic Labs activities in the first quarter of 2021

Welcome to our meanwhile series, the ongoing story of Nomadic Labs’ amazing adventures in the Tezos blockchain space. This post is a recap of our activities in the first quarter of 2021, following on from our 2020 recap. As always, you can find out more about us here: Twitter @LabosNomades ~ Website ~ LinkedIn ~ Technical blog ~ GitLab repo So here’s what we’ve been up to these past three months: Edo protocol upgrade and Florence...

Read More
Sound and fast gas monitoring with saturation arithmetic

Fast calculation of gas costs using saturation arithmetic. With speed comes some theoretical loss of safety, but in practice it works well.

Sound and fast gas monitoring? Let’s use saturation arithmetic! Introduction: we got gas In Tezos, as with most smart contract platforms, on-chain operations cost gas — a theoretical resource intended to reflect (and so limit) the on-chain computational cost of running a smart contract. The gas model allocates gas costs to atomic computation steps. When a computation starts it receives some finite allocation of gas, from which the gas cost of each of its atomic computations is deducted...

Read More
Tezos calling convention migrating from Breadth-First to Depth-First Order (BFS to DFS)

Summary: If the Florence proposal is adopted, we recommend you do not deploy new Michelson contracts that are dependent on the BFS calling convention. We do not expect this to be a problem in practice. However, those planning on deploying contracts in the near term should check that their contract’s correctness is unaffected by the change in calling convention. The current calling convention for intercontract calls in Tezos is that they are added to a “first-in,...

Read More
Baking Accounts proposal contains unexpected breaking changes

Summary Ongoing testing and review of baking accounts has uncovered some important and previously undocumented breaking changes (see the section on breaking changes in the TZIP for Baking Accounts) in the baking account proposal. These issues are significant, and affect the functionality of both existing and future smart contracts; they are detailed below. Bakers should please these carefully when casting their vote. We believe Baking Accounts should be postponed until a thorough audit of functionality is...

Read More
Florence: Our Next Protocol Upgrade Proposal

Announcing Florence Proposal

UPDATE: We believe that the baking accounts implementation is significantly flawed. See: Baking Accounts proposal contains unexpected breaking changes This is a joint announcement from Nomadic Labs, Marigold, DaiLambda, and Tarides. As we described in this post, several development organizations in the Tezos ecosystem are now collaborating to submit protocol upgrade proposals every few months, which is the interval permitted by the Tezos on-chain governance process. When the Edo upgrade went live on February 13,...

Read More
A technical description of the Dexter flaw

In this technical blog post, we detail the flaw found in the Dexter contract and the exploit used to “white-knight” the funds in those contracts. Background The Dexter contract contains several entrypoints allowing users to perform various operations, such as adding and removing liquidity, or converting tokens to tez back and forth. The exact interface is given by the type of the contract’s parameter: parameter (or...

Read More
Dexter Flaw Discovered; Funds are Safe

TL;DR: A flaw was found in the camlCase’s Dexter contract. The funds have been removed from the contract and returned to their original holders. A high level explanation follows; technical details of the Dexter flaw will be described in a separate post to come. As many of you know, we have been working on a new Tezos upgrade proposal. This proposal, if accepted, will change the calling convention from breadth first ordering to depth first ordering. In...

Read More
The Protocol: from High-level Command Line to Low-level Operations

Understanding the source code of Tezos may take much time for fresh contributors. This gentle note gives a global presentation of the control flow of a simple transaction example, going from the high-level command line call to the low-level account operations.

This note explains and illustrates flow of control in Tezos using the example of carrying out a simple transaction. We will go from the high-level command line call to the low-level account operations. To guide you through the codebase, we give line numbers based on release 8.2 (commit 6102c808). Where do I start? Our scenario. Imagine that Alice and Bob have one account each, and Alice wants to send ꜩ10 from her account...

Read More
  • 1
  • 2