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
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
Edo, the latest Tezos upgrade, is LIVE

This is a joint announcement from Nomadic Labs, Marigold, and DaiLambda. On 13 February 2021, the Tezos blockchain successfully upgraded by adopting Edo at block 1,343,489. Jointly developed by Nomadic Labs, Marigold, DaiLambda, and Metastate, Edo is the fifth Tezos upgrade in the span of two years, and follows the Delphi upgrade of three months ago. The Tezos blockchain currently allows protocol upgrades every several months, and we intend for the foreseeable future to take advantage of...

Read More
IMPORTANT: Critical Patch to Tickets in Edo

We have discovered a critical bug within the new Tickets functionality in Edo. Several mechanisms were considered to mitigate this problem; none were ultimately found to be satisfactory. We have therefore taken the step of producing and releasing version 8.2 of the Tezos node that includes a patched version of the Edo protocol that differs by only a few lines of code. Nodes running 8.2 will automatically adopt the patched version rather than the original version of Edo when it activates on February 13th, 2021, around...

Read More
A look ahead to Tenderbake

We’re working on changing the Tezos consensus algorithm from the current Emmy+ algorithm, to a new algorithm called Tenderbake. We’d like to discuss this development, and explain why we’re considering it, and what advantages it will bring. Tenderbake and Emmy+ belong to different algorithm families: Emmy+ is a Nakamoto style algorithm, whereas Tenderbake is a BFT-style algorithm. So moving to Tenderbake would be a significant development on the Tezos network. We made every effort to keep this blog post self-contained, but just in...

Read More
  • 1
  • 2