I am trying to understand why Ethereum decided to create Gasper, instead of using an established algorithm like Tendermint. It seems like Ethereum is now trying to gain single-slot finality (like that in Tendermint). Vitalik states that

We cannot quite take Tendermint or another existing BFT algorithm as-is, because we highly value maintaining liveness even if >1/3 of validators go offline (which traditional BFT does not provide)

If liveness is the sole problem, why didn't Ethereum just implement solutions on top of Tendermint? It seems to me the cost of inventing a new algorithm is way higher.

2 Answers 2


Well, well, well... Sensitive topic you're bringing here. The question is perfectly legitimate and the answer isn't clear. I will give the explanation I would give if I tried to defend Gasper and then what I think.

Gasper Defense

In distributed systems, there is a famous dilemma called the CAP theorem. Apply to blockchains, it states that it is impossible to guarantee both consistency and availability in case of a network partition¹. Consistency means that you don't have conflicting blocks and availability means that new blocks can constantly be added.

Thus, when building your protocol features you must favor one over the other. For instance, Bitcoin has chosen to be available at the expense of safety. This makes Bitcoin prone to forks, and indeed it happens frequently that two miners propose a block at the same height leading to one of the blocks becoming an orphan block.

Ethereum also made the choice to favor availability. Coming from a previously Proof-of-Work setting this makes sense. On the contrary, Tendermint and other blockchains have chosen to have a BFT-like consensus (Byzantine Fault Tolerant) which typically favors safety over availability. This difference makes a protocol like Tendermint not usable for Ethereum. The choice is to favor availability for Ethereum, but they also try to ensure safety (when there is no network partition). To do so, Vitalik came up with an interesting method called Casper, which as you can see goes back to 2017. Gasper is the next step of that which includes Casper directly in the protocol, providing the benefits of safety in times of synchrony (when there is no network partition) while keeping the benefits of availability.


The first problem with Gasper is that it is way too complicated. Vitalik admitted it himself:

the final output was pretty complex.

One could even argue that several interesting propositions were better alternatives for solving Ethereum's goal. These two propositions were at least in part inspired by Casper. But in my opinion, Vitalik pushed for his own ideas. It is true that it is weird to now mention single-slot finality as a new objectify when several blockchains have a protocol doing exactly that. And those protocols are not so complicated and could have been twisted to fit Ethereums needs.

I think there is also the fact that at the beginning the goal was to have every single validator involved in each epoch. This is something that BFT usually don't do, they have a restricted quorum that changes from time to time. No other protocol has that many validators participating as much, that in itself was a challenge to accomplish.

In the end, the fact is that Ethereum managed to go through the Merge and is still working. Now Vitalik realizes that its goal to have every validator equally involved is not compatible with single-slot finality and expressed it. It is not the next priority but surely people are working on it, you can't help but be excited about Ethereum's future always evolving.

  1. If you look at the CAP theorem definition you will see they don't talk about blockchain because it is older than that. The terms can change a bit when specifically talking about blockchain. For blockchains, you often talk about safety or liveness, but you can basically transpose safety with consistency and liveness with availability.

On top of what upavloff said above, here are some of my own conclusions:

Ethereum invented Gasper instead of adopting other PoS consensus algorithms (not just Tendermint) because “it tries to accomplish much more than [existing PoS at the time] do”, and patching the issue in existing algorithms was deemed insufficient.

Specifically why not Tendermint, though, was (partly) due to these explicit preferences

  • Support for very high validator count. ETH PoS supports ~450k validators, whereas Cosmos Hub ~175. This is tied to the desire of high decentralisation. Tendermint chose fast finality and high overhead (a feature common to BFT consensus, think 3 msgs per validator in p2p gossip network to finalise a block). In contrast, Ethereum felt Tendermint offered too little decentralisation and wanted a middle way for all the parameters in the trade-off equation.
  • Liveness w some guarantee for safety. This aligns with the CAP theorem discussed by upavloff's answer. Tendermint halts the network if ≥ 1/3 validators are offline to preserve safety/consistency over liveness/availability. Ethereum chose to prioritise liveness (through inactivity leak, which prolongs finality time) but still wanted to offer some guarantee of safety. Note that Tendermint does not penalise validators for being offline, only if they are voting on/proposing conflicting block; whereas Ethereum slashes validator's stake in both conditions (though amount is smaller in inactivity situations).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.