An AMA session, mainly devoted to the discussion of the Free TON Whitepaper, was held on August 18 with Mitja Goroshevsky, Pavel Prigolovko, and other community members.
The questions asked to the CTO of TON Labs perfectly reflect the state of the Free TON platform:
- when will the mainnet move to the Rust node?
- how to speed up the process of implementing Governance 2.0?
- what is the new consensus protocol to replace (or rather complement) the BFT?
The answer to most of them was given by Pavel Prigolovko, who summarized the situation with the development of Free TON as follows:
What is being developed now is such a new thing that it will not be possible to use old experience in estimating deadlines.
Moving to the Rust Node
Regarding moving to the Rust node, Mitja Goroshevsky said that there are two options to consider.
The first is to move now without implementing a new consensus protocol. Here, it will be necessary to conduct a security audit and prepare a transition protocol. The optimistic estimate for the timing is three months, the pessimistic estimate is the end of the year. However, this is not an option that the CTO himself likes, as he considers it a waste of time to move to a new node for the sake of the very fact of the move.
The second option takes into account the initial implementation of the new consensus, which can take months to implement. Right now, no one is ready to predict exactly how long it will take.
- Being busy with a Rust node and a new consensus — isn’t this all slowing down the implementation of Governance 2.0?
The horizon is an imaginary line. It is important that Gov 2.0 does not become this horizon. AMA session participants
Mitja replied that the implementation of decentralized blockchain governance is handled by a completely different team, so there is no such dependence. As for intensifying the transition to new governance, much depends on the activity and availability of stakeholders. The SMV smart contract system is already at a high degree of readiness and can be launched.
New Consensus Algorithm
The main part of the AMA session was devoted to this topic. Mitja explained in detail the innovations in the Whitepaper which we wrote about and revealed the technical details of the algorithm.
Disadvantages of the Current Protocol
According to Mitja, blockchain is currently divided into threads. Many people incorrectly call them shards, though it is more correct to call them threads, in which a certain number of validators are distributed. In accordance with the BFT protocol, they reach a consensus, sign the block and send the block header and the block itself to the masterchain.
The masterchain validates the block is signed, i.e. the block is only verified by the BFT consensus of the corresponding thread, after which the block header is added to the masterchain block, and the block itself is discarded. Transferring a thread block to the masterchain is required only to confirm the fact of a broadcast.
There are many problems with this approach, the most obvious is finalization. To make sure that the block is finalized, wait until its header is included in the masterchain block, which takes at least 10 seconds, and usually 20-30 seconds.
Proof of Block Distribution
It is suggested not to wait for the end of the consensus. BFT is there and let it stay in the thread. After a collator releases a block, that block is a candidate and is immediately sent to the broadcast. In this case, there is no need to wait for any finalization within the thread.
Sending blocks to the master chain limits the scalability of the entire network.
Using the BLS signature from any sample of validators, you can aggregate the signature into a 32-byte structure. Knowing the public keys of all validators, you can prove that there is a public key in this signature. All validators that receive a block prepare this BLS signature and send it to a number of broadcast protectors. They collect signatures, and when 51% of the signatures are collected, it will be considered that the transfer to the Broadcast has happened.
We have to move from proof of storage to proof of transfer. Mitja Goroshevsky
Now, instead of a block, this 32-byte structure is sent to the masterchain. Upon receiving it, the masterchain quickly verifies that it has 51% of the public keys of the set of validators of this workchain, and this is enough for each workchain.
The final stage of the consensus algorithm is to determine a random sub-set of validators that validate a given block. If one of them finds an error, he writes NACK, if there is no error, then ACK. The masterchain needs to get one NACK to run a re-validation on this block with a large number of validators, because if this block was signed by a minority (less than 51%) rather than a majority, then all validators in this thread who created and signed the block can be slashed.
No one knows who the verifiers are until they check the block and do acknowledge their ACK or NACK score when they send their response.
NACK is sent to all masterchain nodes and to other workchain nodes, that is, to all existing Free TON nodes. All this is done within a single block, with a validation speed in the thread itself of 0.5-0.6 seconds.
Advantages of the New Protocol
The probability of a successful blockchain attack, in this case, tends to zero, as there is enough of one honest validator (chosen randomly) to perform a close check on a block that raises doubts. Also, with the number of validators that Free TON currently has, it becomes pointlessly expensive for a 51% attack.
Besides security, the algorithm has the speed advantage. Because of the new consensus algorithm, Free TON is becoming the most productive and decentralized network among existing blockchains, each node of which guarantees the security of the entire platform.