TON Whitepaper Analysis Unveiling the Behind-the-Scenes Technology of the World’s Fastest Blockchain

Unlocking the Tech Behind the World's Fastest Blockchain An Analysis of the TON Whitepaper

On October 31, 2023, TON (formerly Telegram Open Network) set a new world record in its first public performance livestream test, reaching an astonishing peak of 104,715 transactions per second and completing a total of 107,652,545 transactions in just 25 minutes. Verified and confirmed by Certik, this performance makes TON the fastest and most scalable blockchain in the world, surpassing the processing speed of all L1 blockchains and famous centralized payment networks like LianGuaiyLianGuail, Visa, and Mastercard.

TON is undoubtedly a remarkable project. This article will provide an in-depth analysis of the TON whitepaper, revealing its unique technical features and innovations, and explaining why TON can become the fastest blockchain in the world.

Scalability Challenge

In the development process of blockchain technology, scalability has always been a major challenge. The scalability solutions for blockchain mainly aim to improve system throughput and reduce transaction costs, enabling the blockchain network to process more transactions and better adapt to large-scale applications. Despite the continuous attempts of different public chains in new consensus and architecture designs, the current results are still unsatisfactory, becoming a bottleneck for the large-scale application of blockchain and unable to support our vision of serving billions of TG users. The mainstream scalability solutions can be categorized as follows:

• The Metaverse: A Long-Term Vision Filled with Short-Term Failures
• Web3 Financing Weekly Report Total financing amount of approximately $396 million USD, Hong Kong virtual bank WeLab receives $260 million USD asset financing from Citibank
• ETH Hong Kong 2023 successfully concluded, empowering the innovation of the Web3 ecosystem.

Sharding: Dividing the network into smaller parts, called shards, each capable of processing transactions and smart contracts in parallel, significantly improving network throughput. However, sharding brings potential security issues as the security of each shard may be lower than that of the entire network. Additionally, cross-shard communication is also a technical challenge. Examples include the previous Ethereum 2.0 and NEAR Nightshade protocols.

Sidechains: Sidechains are independent blockchains that operate separately from the main chain, with their own consensus mechanisms and block parameters. Through sidechains, users can transfer assets between the two chains, thus alleviating the burdens on the main chain. Example: Polygon.

Layer 2 solutions: By building another layer on top of the main chain, Layer 2 solutions can provide faster transaction confirmation times and lower transaction fees. Regarding well-known Layer 2 solutions, Optimism and Arbitrum, both are designed as scaling solutions specifically for Ethereum. Therefore, parts of the architecture for Optimism and Arbitrum are located in Layer 1. With the upgrade of Ethereum, the maximum transaction per second (TPS) limit for these solutions increased from the original 2-4k to approximately 20k.

zkSync 2.0: Compared to the several hundred TPS limit of zkSync 1.0, zkSync 2.0 brings significant improvements. The zkSync team claims that its 2.0 version can reach a maximum of 100,000 TPS, but most institutions predict that the actual limit may be around 10,000-20,000. Starknet: After completing the Quantum Leap upgrade in June, its TPS currently slightly exceeds 100TPS.

Solana: Solana uses an innovative consensus algorithm called Proof of History (PoH) as the core of its scalability solution. Although Solana claims that its TPS can reach 65,000, in reality, most of the TPS is used for node communication. The actual transaction volume may only have a limit of 6,000-8,000 TPS. Additionally, due to its centralized consensus mechanism design, Solana has experienced multiple outages when facing a large number of requests, such as during NFT minting. Furthermore, Solana has not successfully implemented the rotation of central nodes.

The designer of the TON blockchain is from the founder and core team of Telegram. As one of the most popular social platforms globally, Telegram has nearly 900 million monthly active users and provides a stable and smooth user experience, along with high security and privacy. It transmits billions of messages within the software every day. The concept of web3 is relatively well-known, but in reality, native crypto users are still a minority, and most people rely on centralized exchanges to interact with tokens. The world’s most popular decentralized crypto wallet, Metamask, currently has only 30 million monthly active users. The design concept of TON is based on serving billions of users from the beginning, not just a few web3 enthusiasts.

Infinite Sharding Paradigm

Sharding is a concept derived from database design. It refers to splitting a large logical data set and distributing it to multiple non-shared databases, which can be spread across multiple servers. Simply put, sharding provides the ability for horizontal scalability, allowing data to be divided into independent parts that can be processed in parallel.

TON is not the first project to introduce sharding technology into blockchain. For example, Ethereum 2.0 previously announced fixed 64 shards but abandoned it due to the difficulty, while NEAR’s Nightshade protocol plans to achieve 100 shards next year, currently having 4 shards in operation.

Unlike traditional sharding methods, TON adopts the strategy of infinite sharding.

However, the reason why TON’s approach is considered advanced is not because it has more shards, but because of the following two unique features:

• Variable number of shards: TON supports an increasing number of shards based on business needs, with a maximum of 2^60 working chains, which is nearly infinite in quantity.

• Elastic number of shards: TON can automatically split shards when the system load is high and merge them when the load decreases. This is a very effective strategy for dynamically expanding needs.

Currently, TON consists of two working chains: the master chain for synchronization and governance (Masterchain), and the work chain for smart contracts (Workchain). Below the work chain, there are shard chains (Shardchain) and the bottom-level virtual account chain (Accountchain).

The work chain can be divided into N shards (from 1 to 256 shards). Each shard has its own group of validators. The work chain group is responsible for executing transactions within their own shard. At the same time, it continuously downloads blocks from all other shards of its work chain. Generally, a blockchain is a series of blocks that record its state changes. For a Proof of Stake (POS) blockchain, validators first agree on how they want to change the blockchain state by compiling a block containing the list of changes. They then vote for this block, and if enough votes are collected, they apply the block to the blockchain state and move to the next block.

A block thread’s throughput is very limited because validators must check all transactions in a block before agreeing to accept it. So TON has many threads, which can be simply imagined as mini micro-blockchains. They coexist in parallel, each with its own set of validators.

Master Chain

The master chain is the main block thread in TON. It is used to synchronize all other blocks and recalculate the set of validators. When all threads reach consensus on a new block, they sign it and register it in the master chain. However, master chain validators do not verify the validity of the block; they only check if it is signed by the appropriate validators. Therefore, many threads can coexist in parallel. Contracts from different threads communicate with each other by sending messages.

Work Chain

The work chain is an independent address space that can operate according to its own rules. For example, they may have different virtual machines or extend the time to release blocks with high gas limits. Most importantly, work chains must have the same message queue format so that they can exchange messages. This also means that all work chains must have roughly the same level of security guarantee. Since they can exchange messages, these messages carry network tokens. Currently, there are two active work chains: the master chain and the first processing work chain. The work chain is determined by the address prefix: -1:ax…1s2 – Account address in the master chain. -1 is the master chain prefix.

0:zx…123 – Account address in the first work chain. 0 is the prefix for the first processing work chain.

Shard Chain

A processing thread, or shard chain, is an independent block thread within a work chain. By default, work chain 0 has only one thread and one chain. The validators of this thread accept external messages and process them along with internal messages they send or receive from other work chains. If a thread becomes overloaded during the recent N blocks, it will be split: one thread will become two, and transactions will be processed in parallel.

Accounts starting with 0:00.. – 0:88.. are now located in thread 1, while accounts 0:88.. – 0:FF.. are located in thread 2. Due to the asynchronous communication between all smart contracts, there are no failures, yet the throughput has doubled. When the workload decreases, the threads merge back together after a certain period of time. If the workload continues to increase, the two threads can split again and again, and so on. The main chain has only one thread.

Blocks in TON are not just a list of transactions that need to be completed to achieve state changes. Instead, a block is:

A list of messages that execute transactions, removing them from the incoming queue. New messages that have been processed enter the outgoing queue, and message processing leads to changes in the state of smart contracts. In other words, in order for validators of shard X to maintain the current state of shard Y, they do not need to execute all the transactions in shard Y’s block. They simply download the block and aggregate the changes that have occurred. Happening in the message queue and smart contract state.

It is not possible to fundamentally change the blockchain world without cost. To take advantage of this radical approach, TON smart contract developers must design their contracts in a different way. The basic atomic unit of the TON blockchain is the smart contract. Smart contracts have addresses, code, and data units (persistent states). These units are called atomic units because smart contracts always have atomic synchronous access to all their persistent states.

Hypercube Network Routing

TON has invented smart routing mechanisms to ensure that transactions between any two blockchains can always be processed quickly, regardless of the size of the system. The time required to send messages between TON blockchains increases only logarithmically with the number of chains, so even if it extends to millions of chains, they can communicate at the fastest speed.

In the TON blockchain, fast routing (Instant Hypercube Routing) and slow routing (Slow Routing) are two routing mechanisms used to handle cross-chain transactions.

 

Instant Hypercube Routing: TON’s idea to speed up message routing, allowing cross-chain transactions to be completed in a very short time. In the traditional slow cube routing process, a message is routed from one shard chain to another shard chain along the hypercube network. However, during the message routing process, the validator belonging to the destination shard chain of this message can choose to process the message ahead of time, join the block, and provide a Merkle proof (receipt), which is then sent back as a receipt to destroy the message being transmitted. It allows cross-chain transactions to be completed in a very short time. Fast routing achieves efficient cross-chain interaction by constructing a high-dimensional hypercube routing structure. In this structure, each chain is mapped to a vertex of the hypercube, and the distance between chains is represented as the number of hops between vertices. With this approach, transactions can be quickly routed on the shortest path, thus achieving efficiency in cross-chain interaction. Fast routing can complete cross-chain transactions in seconds without waiting for block confirmations.

Slow Routing: Slow routing is a relatively traditional method of handling cross-chain transactions. It achieves this by gradually transferring the transactions from the source chain to the target chain. In this method, the transactions are first packaged into a block on the source chain and then transferred to the target chain through a relayer. The validators on the target chain verify the validity of the transactions and then package them into a block on the target chain. The advantage of slow routing over fast routing is that it provides higher security and decentralization, as cross-chain transactions require complete block confirmation. Similar to the TCP/IP network, messages are addressed and sent to the destination based on the destination IP address, ensuring that they are reliably propagated to the target chain in order. For a shard chain hypercube network with a scale of N, it needs to pass through hop = log16(N)-1 intermediate shard chains. Therefore, only four routing nodes (intermediate shard chains) are needed to support millions of shard chains.

Why is it designed this way?

Distributed systems require validating nodes. If the system is very large with thousands of nodes, the burden would be too heavy to expand. After sharding, each shard has a set, shard0, shard1…and they need to communicate across shards. Communication can happen across shards, from one shard to another, which means there needs to be a routing mechanism between shards. The connection forms a route by hopping through certain intermediate nodes. Each time a message goes through a route, it increases the transmission time by one block time.

As the total number of shard chains grows, it will require a large amount of computing power and network bandwidth, thus limiting the scalability of the system. Therefore, it is not possible to directly transmit messages from any shard to all other shards. Instead, each shard is only “connected” to a different shard on a hexadecimal digit in their (w, s) shard identifier. In this way, all shard chains form a “hypercube” graph and messages propagate along the edges of this hypercube.

If a message is sent to a different shard than the current one, one hexadecimal digit of the current shard identifier (deterministically chosen) will be replaced by the corresponding digit of the target shard, resulting in an approximate target identifier that becomes the recipient for forwarding the message.

The main advantage of hypercube routing lies in the block validity condition. Validators creating blocks for shard chains must collect and process the messages from the output queues of “adjacent” shard chains, otherwise they will lose their staking. In this way, it can be expected that any message will eventually reach its final destination; messages are neither lost nor duplicated during transmission.

Hypercube routing introduces some additional latency and cost because messages need to be forwarded through several intermediate shard chains. However, the growth rate of these intermediate shard chains is very slow and logarithmically related to the total number of shard chains N.

Asynchronous Communication

Smart contracts on TON implement asynchronous communication, similar to microservices on the internet. Each microservice only has atomic synchronous access to its local data. Communication between two microservices involves sending asynchronous messages over the network.

In system architecture, larger systems often require microservice architectures. This distributed approach requires some trade-offs but can bring benefits to user experience. Modern systems management relies on sequencers like Kubernetes to acquire a set of containerized microservices and automatically start new instances on demand (auto-scaling) and effectively partition them across machines.

Using Kubernetes (a large-scale cluster management system) as an analogy, this is exactly what TON does. As the load on a specific shard chain increases, it is split into two parts. Since smart contracts are atomic, they are never split in half. This means that some smart contracts that were once on the same shard chain may one day find themselves on different shard chains.

TON’s virtual machine (TVM) is applying the concept of distributed microservices to the overall architecture, benchmarking against Ethereum’s EVM.

Decentralized State

This is the most complex and challenging form of sharding mechanism in the sharding field. The entire database is separated and placed on different shards. Each shard stores all the data within its shard, rather than the entire blockchain’s state.

In TON blockchain sharding, all services are implemented as smart contracts, and the state data of smart contracts is only stored in the corresponding shard network, achieving state sharding.

Furthermore, in TON, contracts have implemented a unique industry path, allowing each user to manage token states in their own contracts, truly achieving decentralization from the blockchain state. I will discuss the principles of this design in detail using case studies.

Firstly, it is necessary to understand the Wallet contract and the Jetton wallet contract. The Wallet contract is a user-owned smart contract used for managing tokens on the TON blockchain. The Jetton wallet contract is a special type of Wallet contract specifically designed for managing Jetton tokens of users. These tokens can be used for paying network fees and executing smart contracts. Each user has their own Wallet contract and Jetton wallet contract. These contracts act as the user’s digital wallet for storing and managing tokens. At the same time, these contracts can interact with the contracts of other users, enabling decentralized asset transfer and transactions.

In this scenario, let’s assume that User A and User B each have their own Wallet contract. User A wants to transfer a certain amount of tokens to User B. In this case, User A’s Wallet contract will interact with User B’s Wallet contract to facilitate the transfer of tokens. The entire process does not rely on a centralized contract, but is achieved through two decentralized contracts.

In the TON blockchain, users have their own contracts to manage asset states, which means there is no risk of a single centralized contract managing all assets. This increases the level of decentralization and reduces the risk of a single point of failure. The asset states of all users are managed by dedicated contracts, preventing attackers from impacting the entire system by attacking a single centralized contract. Asset transactions between users can also be automatically executed through smart contracts, eliminating the risk of human error. Users can also customize their own Wallet contracts and Jetton wallet contracts according to their needs, enabling more functionalities and use cases. This provides users with greater flexibility and autonomy. Each person manages asset states within their own contracts, improving the scalability of the system. As the number of users increases, the number of contracts will also increase accordingly, but this will not put excessive pressure on the entire system as each contract operates independently.

Above is my analysis of the scalability of TON Blockchain and the technical architecture concept in the whitepaper. I would like to thank Dr. Awesome Doge for editing the first draft. I also want to express gratitude to the diligent work of the development teams from Russia and Ukraine. And lastly, a special thanks to Mr. Nikolai Durov, the founder of Telegram, for his visionary design many years ago, all in the pursuit of human intellectual glory.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!