Tezos is a scalable blockchain-based platform designed for the development of smart contracts.
The Tezos (XTZ) protocol is currently based on a Liquid Proof of Stake (Liquid Staking) consensus algorithm, called Tenderbake, which replaces Emmy*.
Actually, Tenderbake adapts Tendermint to the Tezos blockchain, which in turn is inspired by PBFT (Pratical Byzantine Fault Tolerance) and DLS (Distributed Ledger System).
Tenderbake add 2 majors improvement to Tendermint :
With Tenderbake, a block that has been appended to the chain of a node is marked as final when it has 2 additionnal blocks on top off it, regardless of network latency.
Tenderbake can finish in a real quick time, that's why it is known as fast.
Even if a part of the network is down during an asynchronous period, when synchrony is restored, the blockchain will just return to where it left off. It's one of the main advantage of Tenderbake consensus algorithms.
Level of a block : It's his "position" from the genesis block, which is at level ("position") 0.
In Tezos blockchain, the fundamental unit of identity is a cryptographic key.
A delegate is a cryptographic key. Owner can participate in the consensus algorithm and in the governance process by registering their public key on the chain and by holding at least one roll (around 8000 TZ). Of course, the owner have to be active recently.
For each new level of block, Tenderbake is executed by validators, which are, actually, delegates selected at random based on their stake, just like endorsers were selected in Emmy*. Then, validator's job is to choose which block to add next.
So, a simple approach for validators to choose a block could be : one validator, by using the native Tezos proposal mechanism, propose its block as the next block to add in the Tezos blockchain. After that, others validators can vote for blocks through the Tezos network as Tezos Operations.
To complete the vote, for each level, that we mentioned earlier, Tenderbake proceeds in rounds which are just an attempt to make validators to agree on the current level's block. Each round has its own duration, that can be increased in order that, when a message delay or an asynchronous period appears because of network slowdowns or failure, have a longer round.
Each round has three phases:
The first one, "a block proposal phase", a validator is chosen as "the round master", and it have to propose a candiate block.
The second one, "a preendorsement phase", is a Tezos operation containing a tuple (x,bc,r).
Validators send a supporting vote on the candidate block's contents, called preendorsement.
We can sum up it with the following form : " I, validator x, hereby endorse block contents bc for round r“
The third one, "the endorsement phase", if validators have observed a quorum (the minimum number of members of a deliberative assembly) of preendorsement, then they will send a confirmation vote, called endorsement, for the candidate block's contents and they will certify that they have observed a quorum of preendorsments.
We can sum up it with the following form : "I, validator x, hereby affirm to have observed a quorum of preendorsements for block contents bc at round r"
So validators have to vote twice with Tenderbake.
There is a difference between the first round and others for the proposer.
In the first round, the proposer, which have to propose a block, is free to propose a block contents from the memory pool of its node, which is the blockchain's "waiting room" (when a operation is verified, it will wait in the mempool for beeing put in a block ). In the next rounds, the proposer have to propose the same contents of block candidate that it has proposed in the previous round, but only if a quorum of preendorsement was observed, otherwise the proposer is free to choose a block candidate like in the first round.
When a validator observes a quorum of endorsement at the current round, so the validator will think that an agreement is found on the current block candidate for the current level L and will move to the next level L+1.
But if a validator doesn't observe any quorum of endorsement at the current round, the validator will think that an agreement was not found yet and will skip to the next round. It can happen when :
You have to notice that for each block candidate at level L+1, it have to include level L quorums endorsement in order to have a proof that an agreement was successfully reached at previous level L.
At the end, the last round will look like this :
Then, our loop terminates with consensus.
Tenderbake has also the advantage to be fast, it can finish in at most 1 minute assuming good network conditions.
To shorten it, Tenderbake acts in the following way :
1- A validator make a proposition by injecting a candidate block and votes into the attached node
2- Then it diffuses those blocks and votes to all of the others nodes of the network
3- After that, it communicates them to validators attached to those nodes
4- And finally, they can vote on which block to accept
