ESBOCS (Enhanced Stake-based Block Operating Consensus) is an upgraded Proof of Stake (PoS) consensus created using Catchain protocol from the Telegram Open Network (TON).
Reasons for choice
We chose Catchain because it is fairly well-documented, with documentation available from both the developers of this consensus and an external group that essentially conducted reverse engineering and provided details in a separate document. We then compared what this reverse engineering revealed to us with other similar consensuses like pBFT, Tendermint, and Algorand. Catchain has shown itself to be more efficient than others.
Catchain is a Byzantine Fault Tolerant (BFT) consensus, and it requires confirmation from 2/3 of the participants in the consensus to function. However, since it is a Proof of Stake (PoS) consensus, the 2/3 requirement is based on the relative “weight” of the network participants.
Note
The “weight” of the validator is defined by the quantity of locked m-tokens in its wallet.
The size of the stakes nodes or groups of nodes have invested determines their weighted rights. They can propose or reject blocks, and the verifying group must have at least 2/3 of the total “weight” to establish consensus.
There’s a risk of a single node monopolizing consensus if they control 2/3 of the total stake. This could give them excessive power over network decisions. To prevent this, we’ve modified the original consensus.
Another drawback is that confirming 2/3 of the “weight” requires collecting many block signatures. While this is manageable for non-quantum-resistant signatures, post-quantum signatures require limiting the number to around 10 to keep block sizes reasonable. Otherwise, the chain’s size would grow rapidly, slowing down synchronization.
In order for our chains to be more dynamic, we need to ensure that the required number of signatures is not too large.
How it works
-
We have to choose, who will provide the current block in the consensus i.e. submit the current block. It depends on the “weight” of participants. However, everything after that will be defined by Proof of Stake (PoS) consensus.
-
We took some of the consensus participants. There can be many of them since, theoretically, their quantity is not limited. For example: we have several hundreds of validators in the network and we take some of them based on their weight for validation in the current round. Then, one validator will be chosen from the ones chosen in the previous step.
Every validator in the consensus has its own weight, but the common number of validators is chosen based on minimal quantity of signatures - this parameter (quantity of signatures needed for one block) is set by decrees.
Example
10 - minimum signatures, 15 - maximum. If all nodes are online and connection is stable, we can probably collect all 15 signatures, but even 10 would be sufficient. If the quantity of collected signatures for one candidate is less than 10, this right transfers to another candidate, who will now provide its block for signing.
The greater the candidate’s “weight” - the more probability of choice him as validator who has the right of signing, and one who can offer his block. Eventually, the probability of this validator offering his block in current round would be proportional to its “weight” compared to common “weight” of all validator keys.
- Next, the validator proposes a block, submits it, and all participants in the current round receive this block for signing. In other words, the initial sample that was taken at the beginning participates in the voting process. Participants verify the validity of the block and either approve or reject it. Once the block reaches the minimum approval condition, the signing of the block begins.
ESBOCS improvements
- A block is signed by every validator independently without any sequence. Eventually, the block collects a defined number of signatures and if this number exceeds the minimal threshold, then these signatures are sorted. After this, the signed block and its hash are presented for voting again as the final hash, which must get in the chain.
This mechanism is not initially provided in the Catchain consensus, and the question of what to do when the signatures are collected remains open. Here, our enhancements come into play. The current block, once it has been signed, undergoes another round of voting to ensure that all participants of the current round confirm the order and number of signatures for this particular block to be placed in the chain. This is important because even a slight change in the order of signatures, or especially in the number of signatures, can have a significant impact.
5. If the validator successfully established its block, it has right to receive a fee from it. The fee would be proportional to stake size. The greater the stake size - the more total fees the validator can receive in future, the more blocks he can offer and sign first. Correspondingly, the validator’s profit will increase too.
Example
If someone stakes 10 m-tokens and delegates his key, then, roughly speaking, he will get 10 tokens a year from fees. Similarly to bank deposits, if you contribute one million, you receive 5% from this sum, but if you contribute ten millionswith the same percent rate, you will receive 10 times more. Everything is fair. Wealthy stakers don’t have any additional advantages. They get more because they contribute more.
Conclusion
ESBOCS is actually a partially BFT consensus within a separate group (cell) that is randomly selected in each consensus round. However, we cannot extend this selection to the entire consensus due to the limitation on the number of block signatures, which would make its size unreasonably large if it were to be signed by all participants. Therefore, it can be said that the consensus generates a cell based on its own fault-tolerance rules, within which a new block strictly follows the BFT protocol.