TBFT

Threaded BFT is a consensus upgrade that aims to solve a number of problems that exist with the original protocol of Nikolay Durov.

Safety of Block Generation in Threads and Finality

As we have already described, one thread block is generated by 11 validators (which is a network parameter), so 2/3+1 of them may conspire to issue a corrupted block. In a network with many threads where validators rotate between them every few minutes, the probability of having malicious validators in one thread is high, and according to the probability theory, a singular increase in malicious validators would increase the probability of their presence in one thread with a speed higher than that of linear.

Nikolay Durov offered a solution to this problem based on fishermen and vertical blocks. It was suggested that anyone who placed a small deposit could initiate verification of any block by the masterchain validators. If the block turned out to be faulty, the validators who created it would be slashed, and a special vertical block would be created. The second parallel blockchain would fix only the accounts impacted by the fraudsters.

But this solution has several problems:

• Finality - The number of threads may grow enormously under the load, and there’s no way of knowing how much time you have to wait before you are sure the thread will not roll back.
• Fixing broken states - Vertical blocks aimed at fixing all the contracts is an elegant idea on paper, but in practice, a corrupted block can impact a huge number of smart contracts. The implementation of vertical blocks seems like an enormously difficult task, and it should be carried out not only in the node software but in alternative nodes and various network indexers as well.
• DeFi -Without a clear finality, many DeFi services—like bridges—cannot exist. And if fraudsters have already withdrawn their tokens to another network, no vertical block is going to able to fix that.

Now, here is how TBFT addresses this issue by means of verifiers:

• Inside a session, validators still collate a block and sign it.
• To register a block in the master, 50% + 1 validators of this workchain must submit their signatures in order to verify the fact that they have accepted the block (BLS signature). This is proof that the block has been distributed over the network.
• When a workchain validator receives a broadcast with a block, they calculate if they have to check this block. It is impossible to know beforehand which validator will check your block. This is achieved not via VDF but just with a predicate function, for example hash(block_hash + validator_broadcast_private_key) % N == 0 where N is chosen in such a way that each block is checked by an average required minimum of verifiers.
• After checking a block, the verifier sends ACK or NACK to the masterchain. If there was at least one NACK, the complete verification of this block by the whole masterchain is triggered. If the block is invalid, all the validators who signed it, sent ACK, or kept silent, are slashed.
• Once in every N blocks, all the validators should reveal their validator_broadcast_private_key to determine who should check which blocks.
• There is also a provision in case verifiers do not have enough time to check a block, fraudsters found issues in TVM or the block requires too much time to check. If one of the above occurs, verifiers send a timeout to the master, and after receiving several such timeouts, the masterchain initiates a check of this block.

In this way, we can easily count the number of verifiers required to check each block and rule out the possibility of an attack.

Data Availability

For a block to be added to the master, it should collect 50% of BLS signatures of the whole workchain testifying that they have received this block. Because of this, we believe that blocks are guaranteed not to get lost.

Block Issuing Speed

Also, Soft Majority Fault Tolerance suggests that in the future BFT be simplified during the validation session (decreasing the threshold to 50%+) or that the session get canceled in a thread (but remains in the masterchain). A block is added to the master after the verifiers check only one random block collator. To control forks, it is enough to have BFT in the masterchain. We consider any block written there to be correct.

This could potentially speed up the issuing of blocks.