Nomadic Labs
Nomadic Labs
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 selfish baking. This was done by defining the chain fitness as the total number of endorsements (in addition to the chain length).

This post introduces Emmy+, an improvement of Emmy which still guards against selfish baking but also achieves greater efficiency and stability. Emmy+ will be included in our next protocol proposal.

The main difference is that, in Emmy+, the number of endorsements included in a block no longer influences the fitness, but the timing of a block: the fewer endorsements a block carries the longer it takes before it can be considered valid. More precisely, a block is valid only if its timestamp has a minimal delay with respect to the previous block’s timestamp, and this minimal delay depends not only on the block’s priority but also on the number of endorsement operations included in the block.

As for block fitness, in Emmy+, it increases by one unit with each level. In this way, Emmy+ simplifies the optimal baking strategy: the bakers used to have to choose whether to wait for more endorsements to include in their block, or to publish the block immediately, without waiting. The incentive for including more endorsements was to increase the fitness and win against unknown blocks. However, when a block was produced too late in the priority period, there was the risk that the block did not reach endorsers before the block of the next priority. In Emmy+, the baker does not need to take such a decision, because the baker cannot publish a block too early. This should lead to fewer missed blocks and endorsements and therefore faster convergence.

Another advantage of Emmy+ is that chains that have fewer endorsements, signalling a difficulty in reaching consensus, become slower. This brings the algoritm closer to classic BFT consensus algorithms which have deterministic finality.

Finally, the changes lead to a few other simplifications, like simpler endorsement reward policy and shorter times between blocks when blocks at higher priority are missing, as we explain in more detail below.

Main change in detail

In Emmy, the minimal delay for a block with respect to the block at the previous level is given by the following function:

  emmy_delay(p) = 60 + 75 * p

where p is the block’s priority and the values 60 and 75 are given by the time_between_blocks constant, set to [60; 75]. (In the code base, the definition of what we call emmy_delay is implemented by the function Baking.minimum_time; see src/proto_alpha/lib_protocol/baking.ml in the master branch).

In Emmy+, the new delay function depends not only on priority but also on the block’s endorsing power e, that is, the number of slots corresponding to the endorsements included in the block. This new delay function is defined as follows.

  emmy_plus_delay(p, e) =
    if e >= initial_endorsers then
      emmy_delay(p)
    else
      emmy_delay(p) + delay_per_missing_endorsement * (initial_endorsers - e)

where delay_per_missing_endorsement and initial_endorsers are two new constants.

The value of initial_endorsers (init_endo) is set to 18. Recall that the maximum endorsing power of a block is given by the endorsers_per_block constant, set to 32. The rationale behind choosing the value 18 will be explained in a technical blog post and is intended to minimize the ability of a malicious baker to steal slots.

As for delay_per_missing_endorsement, it denotes a time period (Period.t) and it is set to 5 seconds. Therefore, with each missing endorsement with respect to the initial required amount, 5 additional seconds need to pass before the baker can send its block.

In addition, the value of time_between_blocks is changed from [60; 75] to [60; 40]. Thus the time between blocks when the block at priority 0 is missing is shortened.

The new delay function can be visualized on the following graph: delay function for Emmy+

The graph depicts 5 functions: t = emmy_plus_delay(p, e) for 5 values of p. It can be read as follows: a block at priority p and with endorsing power e needs to have a timestamp at least t seconds bigger than the timestamp of the block at the previous level. For instance, a block at priority 0 with endorsement power 12, needs to have at least 60 + 5 * max(0, 18 - 12) = 90 seconds delay, while a block at priority 2 with endorsement power 24 needs to have at least 60 + 2 * 40 + 5 * max(0, 18 - 24) = 140 seconds delay.

Finally, we emphasize that, besides minimizing the timing between blocks, these constants are also chosen such that a baker cannot steal the baking slots of other bakers by withholding its endorsements (unless it controls significantly more than one third of the total stake). We will publish a more tehnical blog post with details of our analysis, which will also show how the constants were chosen. The constants might actually slightly change as we refine our analysis.

Changes to the reward system

The rewards for blocks and endorsements are now dependent on blocks’ priority: for priority 0, the same rewards as in Emmy apply, however, for larger priorities, the block rewards become smaller and endorsement rewards are computed differently.

Concretely, the baking reward becomes block_reward / (p+1) and the reward per endorsement becomes endorsement_reward / (p+1) where p is the baked block priority or the priority of the block which contains the endorsement, respectively. Note that in Emmy, for endorsements, p was the priority of the endorsed block, not of the block which includes the endorsement. The constants block_reward and endorsement_reward do not change, they are still set to 16 and 2 tezzies. Security deposits also do not change.

This change makes selfish baking attempts much less profitable: a baker with a slot at priority 1 who might attempt to steal the block at priority 0 by withholding his endorsements would be better off having his endorsements included in the block of priority 0.

Other changes

RPC additions

There are three additional RPC services:

  • POST chains/<chain>/blocks/<block>/endorsing_power returns the endorsement power (i.e number of slots) of a given endorsement operation.

  • GET chains/<chain>/blocks/<block>/required_endorsements?[block_delay=<int64>] takes a block delay which represents the delay of a block’s timestamp with respect to the minimum time to bake at the block’s priority (as returned by Baking.minimum_time or emmy_delay above). It returns the minimum number of endorsements that the block has to contain to be valid.

  • GET chains/<chain>/blocks/<block>/minimal_valid_time?[priority=<int>]&[endorsing_power=<int>] takes two arguments, a priority and an endorsing power, and it returns the minimum time at which the next block can be baked. This is the dual of the previous service. It corresponds to the emmy_plus_delay function given above.

Improvements to the baker

The --await_endorsements argument to the baker was removed, as it becomes unnecessary. Indeed, the baker is forced to wait for a minimal amount of endorsements, it does not have a choice any longer.

New field in endorsement operations

Now an endorsement operation also includes a slot field, whose value is the first slot of the endorser. This is done in order to determine the endorser more quickly. Previously, the endorser was determined by iterating through all slot owners and checking which public key matched the endorsement’s signature; which was not an efficient method.

Emmy+ in the next protocol proposal

Emmy+ will be part of the next proposal of a protocol amendement. The mentioned changes appear in this merge request.


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
Athens: Second Voting Period

As we approach the completion of the first active voting period, the proposal period, we would like to describe what’s to come during the second voting period. The first voting period saw the Athens protocols injection and bakers upvoted Athens A and/or Athens B, with Athens A, the most popular proposal, promoted for the second voting phase: the test voting period. In this new period, participants are asked to vote on whether to advance Athens A to the next stage: the...

Read More
Athens: Proposals Injected!

Today marks an important milestone for Tezos. We just triggered the beginning of the first on-chain vote for self amendment. This process could end in the successful migration from current protocol alpha to Athens in about three months, if the participants decide so. As advertised in the last meanwhile at Nomadic and as detailed in our previous post, we injected the hashes of two proposals. Both include the same enhancements except for one: the decreased amount in the number of tokens needed to...

Read More
Athens: Our Proposals for the First Voted Amendment

This blog post is a preview of Athens: our protocol proposal for the first voted upgrade of Tezos. As announced in the last meanwhile at Nomadic, we shall propose two upgrades: one lowers the roll size to 8,000 tez, the other leaves it unchanged at 10,000 tez. Both alternatives will include an increase of the gas limit. The hashes of both versions will be proposed on mainnet later this week, now that a new proposal period has begun. Later this week, we will publish a...

Read More
Amendments at Work in Tezos

We are now on the verge of submitting a protocol upgrade to a vote, and it seems like a good opportunity to explain in details the way in which Tezos node handles amendment in practice. Brace yourselves, this article is quite technical, as are all articles in our in-depth category. Still, as we did in the previous one on snapshots, we’ll try to explain the stakes and announcements and give a brief summary in a short foreword understandable even by non-programmers. The original whitepaper...

Read More
Introducing Snapshots and History Modes for the Tezos Node

In this article, we introduce two new features for the Tezos node: snapshots and history modes. A snapshot is a file that contains everything necessary to restore the state of a node at a given block. A node restored via a snapshot can synchronise and help other nodes synchronise in the existing network. The only difference is that you cannot query the chain context (balances, baking rights, etc.) before the restoration point, but you can still get the full chain history. In conjunction, we also...

Read More
Nomadic Labs at Fosdem 2019

Fosdem is of the largest gatherings of Free and Open Source Developers in Europe. It’s held every year in Brussels during the first weekend of February. This year Nomadic Labs is involved in the organization of the “Blockchain and Crypto-currencies devroom”, a one day workshop to present Blockchain projects to the FOSS community. We strongly believe in open source and we want to share our work with the FOSS community at large. We will also present our work on the Tezos project,...

Read More
  • 1
  • 2

Receive Updates

ATOM

Contacts