Advanced Level
In this section, we'll take a closer look at how the Venom blockchain works. The blockchain is complicated, because it facilitates a high level of decentralization and warranties along with a very high block-adding speed and infinite scaling.
Masterchain and Elections
The current set of network-wide validators is determined by the Elector's contract. This is a service contract which the network inherited from the testnet created by Nikolay Durov. It will be updated to a new contract written on Solidity with the support of a lot of workchains and more advanced slashing support. Now, elections start once every 18 hours and continue for 7 hours, during which validators have to put their stake at their contract address. Then the validators' set is re-calculated. This contract also calculates rewards for the previous validation round.
Slashing is currently not enabled. The network mostly works because validators are not anonymous.
The masterchain is validated by the top 100 validators by stake size. They also take part in the validation of other workchains. As shown in the previous chapter, the workchain processing (now it's only workchain 0) may have 1 to 65536 threads (the current practical threshold is about 250 threads).
The task for the masterchain is to register new blocks of threads in order to be the source of Truth for workchains and also execute smart contracts, but to do this in one thread only. The masterchain uses BFT consensus (we won't cover it in detail here, read this if you need more info).
Let's move on to processing workchains and threads. One thread is validated by 11 validators, and these validators are changed every few minutes. The work of validators inside a thread is called a session. Inside a session, validators negotiate over blocks, and they also use the BFT consensus and register it in the master. One validator can take part in the validation of multiple processing threads. Since the hardware requirements for validators are high, resources should not be an issue for them.
11 validators per thread and 100 per masterchain is, of course, based on network parameters and subject to change.
Yes, only 11 validators are responsible for composing a block in a thread. When registering a block in the master, its validators evidently don't check it for validity since they cannot verify all the blocks in all processing threads. So it means that 11*2/3+1 = 8 validators may conspire and wait for some time until they are on the same thread to create a broken block which may, for example, spend other people's money.
The original TON design suggested combating this issue via fishermen and vertical blocks. It was proposed that anybody could place a small deposit and then appeal the validity of any block in the masterchain. If they won the appeal, a very complicated procedure would follow to fix the blockchain’s state. This solution was only intended to fix a broken state. Of course, it was never implemented in practice as it would make the protocol very difficult for implementation with the accompanying software.
Besides, such a system would mean the de-facto absence of finality. With thousands of threads, fishermen may not be able to process them quickly enough, which means a corrected block may arrive, for example, in 30 minutes. DeFi and especially bridges cannot exist with such undefined finality.
Venom decided to address this issue through an updated consensus which is now under development. How this will be done is explained in this article, in the TBFT section.
Sharding of Computational Resources
Computation is a bottleneck affecting a majority of EVM blockchains. Due to synchronous architecture and bad design, executing transactions is difficult to parallelize, so even if we disregard the time necessary to compose a block, still the consensus, network and speed of state change are limited by a couple of CPU threads at best.
Venom presents a unique combination of data sharding and computational resources. Despite the fact that one processing thread is validated by only 11 validators at a time, actually all validators of the workchain (there can be hundreds) have the same data and only share computational resources. This allows for the rotation of validators in threads to occur very quickly, which in turn ensures the quick delivery of messages.
When validators of a thread create their block, they always base it on a masterchain block. To import the next master block, they download all the threads registered in it and apply them to the state. And a block in Venom is not simply a list of transactions to execute in order to update your state. The block also stores all the changes of accounts and message queues. So, for a validator from the 2nd thread to change the state of the 1st thread, it is not necessary to execute all the transactions in the block, instead they only have to apply changes to account states and queues. Therefore, all the validators of a workchain always have the actual state of the whole workchain, and at the same time they need to execute transactions of only the accounts in the range of their thread. As mentioned above a thread block is not just a list of transactions to execute, but also:
- A list of imported external and internal messages
- A list of new outgoing internal messages
- A list of executed transactions and account updates which happened as a result of these transactions
- A block header with meta information and validator signatures
In other words, for a thread A to apply a thread B block to its state, it does not have to carry out any computations. It is enough to just apply changes to accounts and queues. This is what is meant by sharding of computational resources and this allows for the rotation of validators in workchains and ensures the quick delivery of messages between threads at the speed of issuing master blocks with guaranteed delivery and guaranteed order. And we remind you that one workchain can have up to 65536 threads in theory and 250 in practice, while transaction execution is well parallelized even inside one thread.
Data Sharding
Actually, data sharding has not yet been implemented. The original TON design featured hypercube routing (inside a workchain) to decrease the load on block collator and establish the possibility of data sharding in the future.
Although the blockchain node supports hypercube routing, it does not provide data sharding on its own. At the moment, it has been decided to abandon it as it significantly slows down the delivery of internal messages, and there is no design that would allow data sharding with its help.
Instead, at the first stage, different processing workchains will be used as data sharding. That is, N processing workchains will be added to the 0th processing workchain. At the same time, the workchain will not need to download all the blocks of threads from other workchains, only a part of the block where there is a change in the message queue if there are messages in its thread. Because messages between workchains will travel as freely as within a workchain.
What should be done when the state of one workchain becomes too large is still an open question. Perhaps some form of data sharding inside a workchain will become necessary after all.
Guaranteed Message Delivery
Guaranteed message delivery is based on very simple mechanisms. All workchain threads access the data of all accounts and all outgoing and incoming queues.
Auxiliary image
- Thread A receives an external message, and the transaction it triggers creates an outgoing message with the destination account in Thread B. This outgoing message is recorded in a block in OutMsgDescr, which is the section of the block that reflects all new outgoing messages created in this block. Additionally, the message is added to OutMsgQueue, which is the section of the thread's state where all undelivered messages are stored.
- Thread A registers its block in the masterblock.
- Thread B sees a new masterblock, downloads it, and downloads\imports all the blocks of other threads in its workchain which are registered in this masterblock. So it download new block from thread A and sees a new message.
- Thread B collates its block based on the latest master. According to the rules of block compilation, it should import messages from outcoming queues (of other threads or its own) strictly in the order that their logical time increases. Messages are imported one by one until Thread B has enough gas limit for the execution of transactions caused by this message. After that, the imported message is immediately executed which triggers the transaction. All imported messages are recorded into the InMsgDescr part of the block.
- Thread B registers its block in masterblock.
- Thread A sees the new masterblock, downloads it, and deletes from its own OutMsgQueue all the messages which were included in the InMsgDescr of other threads.
As you can see, everything is pretty simple and effectively prevents the loss of messages. This protocol also prevents validators from ignoring any messages because they have to import messages in the order in which their logical time increases. If the logic time is the same, the message with the more smaller hash will be first. For more, read this section about logical time and order guarantee.
Of course, things are actually a bit more complicated. One thread can register in one master block up to 8 of its own blocks. Also, the thread does not have to based on the latest master block since master blocks come out very fast. It can based on the Top - 1/2/3 as well which is not prohibited by the protocol.
In other words, we have a masterchain as the source of Truth and a lot of thread chains, each of which follows master blocks at their own pace, but they always try to catch up with the latest master. The visibility scope of the thread is determined by which master block it imported last.