Tenderbake - An Overview

We have recently announced a technical report on Tenderbake, a classical BFT style consensus algorithm inspired by Tendermint and motivated by Tezos. This work is a joint effort with CEA List.

Why a new consensus algorithm?

Our main motivation was to experiment with consensus algorithms offering deterministic finality while relaxing the synchrony** assumption usual in Nakamoto-style consensus algorithms.

Why Tendermint?

At the time we began our experiments, Tendermint was the first adaptation of classical BFT style consensus algorithms to the blockchain context. In particular, Tendermint improved the message complexity of the classical algorithms DLS and PBFT. Tendermint also came with a correctness proof.

What is our contribution?

Our contribution is mostly at a theoretical level: we adapted Tendermint’s system model to Tezos, changed the algorithm accordingly, and provided proofs that the consensus properties still hold.

Concretely, the system model we considered does not include the less standard “gossip communication” assumption used in Tendermint. This assumption states that communication is reliable (messages cannot be lost) even during periods of asynchrony. We dropped this assumption and assume instead that communication is reliable only in the synchronous periods. We further assume that nodes are equipped with loosely synchronised clocks, as is the case in Tezos. Thanks to clocks, we can achieve round synchronization without relying on timers. This in turn implies that message buffers can have a constant size. (This is not the case with Tendermint where message buffers can theoretically grow unboundedly large.) Having constant size buffers is important for security reasons, it makes it difficult for a node to be spammed.

Another consequence of the fact the communication may be unreliable in the asynchronous periods is that we need to attach quorum certificates*** to messages. This means that some consensus messages are larger than in Tendermint. However, the message size can be considerably reduced by using modern cryptography (for instance aggregatable signatures). By resending quorum certificates, Tenderbake can achieve faster finalization than Tendermint.

How about next steps?

Regarding Tenderbake, we are working on a prototype implementation of the algorithm. We are also investigating how to use modern cryptography to reduce both message complexity and message size. Finally, the most challenging part is to have an economic analysis of Tenderbake, that is, answer questions like what are the right incentives in the presence of rational players.

Relaxing the synchrony assumption currently used in Tezos, by using partial synchrony instead, has the consequence that one can only tolerate weaker adversaries, that is, adversaries with up to a third of the stake, while under synchrony one can tolerate adversaries with up to a half of the stake. To tolerate stronger adversaries, one approach would be to take “the best of both worlds” and combine a Nakamoto-style consensus algorithm with a classical BFT style algorithm, like in existing finality gadgets such as Afgjort, Doomslug, Grandpa, Thunderella.

Finally, we remark that we would propose a new consensus algorithm only when there is evidence that it is substantially better than the current algorithm.

** By synchrony we mean that there is an upper bound on message delays. By partial synchrony we mean that periods of asynchrony alternate with periods of synchrony.

*** A quorum certificate is a set of signatures from at least two thirds of the validators for one level.

15 Likes

I understand this mix would give deterministic finality and up to 50% attack resistance.

Would this limit the scalability advantages of tenderbake like the amount of TPS? If so, how?

2 Likes

Finality gadgets should in fact allow for faster block production because, given that there is a finality layer one can be optimistic for the Nakamoto-like part of the mix and reduce block times. However, we can’t be more assertive than this since our focus, for now, has been on resilience. As a side remark, please note that Tenderbake, as other classical BFT-style protocols, would become slower the larger the committee. So there are trade-offs and to carefully analyse them one would also need experimental data.

3 Likes

How has the situation evolved since last year?

1 Like

would also want to know

1 Like

During last year at Nomadic Labs:

  • We have improved the technical report by eliminating the assumption that clocks are synchronized in the asynchrony period and by presenting the algorithm in a more modular way.
  • We have implemented a Tenderbake prototype as a bare “demo protocol”: it consists of just the consensus algorithm running for a fixed set of participants (but no smart contracts for instance).
  • A private testnet is running a modified version of Delphi using Tenderbake instead of Emmy+. After fixing some observed issues, we plan to make this testnet public.

We are now completing the implementation and testing it, and at the same time making it reviewer-friendly.

8 Likes

Appreciate the update any possibility of getting a time frame on the testnet?

Normally that should happen sometime during the next voting cycle.

@slarquie1 This was shared by a Discord user (textrapper) based on Tendermint-related problems at SecretSwap.io. We thought it might be helpful to post here. Maybe it is applicable to your progress.

Speaking of progress – are you able to provide an update on timeline?

Thanks!

1 Like

How does Tenderbake behave under conditions where adversaries control more than 1/3 of the network?

In this blog post: A look ahead to Tenderbake
it is stated that:

*Tenderbake is also fast, in the sense that it has a small (quick) time to finality: under typical good network conditions, and making a standard assumption of an attacker (“byzantine”) stake of at most 33% — meaning that at most 1/3 of the network is trying to undermine correct behaviour:

  • in Tenderbake, one would expect to wait less than 1 minute for a block to be considered final, whereas
  • in Emmy+, one would expect to wait at least 6 minutes.*

There seems to be some real confusion in the community on the impact of Tenderbake on throughput, if any: see this topic

I think it would be great if a more technically proficient user could share his thoughts in that thread.

2 Likes