On October 31, 2023, TON (formerly Telegram Open Network) set a new world record by achieving an astonishing peak of 104,715 transactions per second in its first public performance live test, 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 all L1 blockchains and centralized payment networks like PayPal, Visa, and Mastercard in processing speed. 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. Challenges of Scalability In the development of blockchain technology, scalability has always been a major challenge. The main purpose of blockchain scalability solutions is to increase the system's throughput and reduce transaction costs, enabling blockchain networks to handle more transactions and better adapt to large-scale applications. Despite continuous attempts by different public chains to explore new consensus and architecture designs, the current results are still unsatisfactory, becoming a bottleneck for the blockchain's transition to large-scale applications and making it difficult to support the vision of serving billions of TG users. The current mainstream scalability solutions can be categorized as follows: Sharding: Dividing the network into smaller parts, each capable of processing transactions and smart contracts in parallel, significantly increasing the network's throughput. However, sharding brings potential security issues, as the security of each shard may be lower than that of the entire network. In addition, cross-shard communication is also a technical challenge. Examples include Ethereum 2.0 and NEAR's Nightshade protocol. Sidechains: Independent blockchains running separately from the main chain, with their own consensus mechanism and block parameters. Through sidechains, users can transfer assets between two chains, thereby offloading the burden on the main chain. An example is Polygon. Layer 2 solutions: Building another layer on top of the main chain, L2 can provide faster transaction confirmation times and lower transaction fees. Notable L2 solutions include Optimism and Arbitrum, both designed specifically for Ethereum's scalability. With Ethereum's upgrade, their transactions per second (TPS) limit has increased from the original 2-4k to approximately 20k. zkSync 2.0: Significantly improving upon zkSync 1.0's limit of several hundred TPS, the zkSync team claims that its 2.0 version can reach a limit of 100,000 TPS, although most institutions predict its actual limit to be around 10-20k. Starknet, after completing the Quantum Leap upgrade in June, currently has a slightly over 100 TPS. Solana: Utilizing an innovative consensus algorithm called Proof of History (PoH) as its core scalability solution. Although Solana claims its TPS can reach 65,000, the actual transaction volume may only have a limit of 6-8k 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 yet successfully implemented the rotation of central nodes. The designers of the TON blockchain come from the core team of Telegram, one of the world's most popular social platforms with nearly 900 million monthly active users. While providing high security and privacy, Telegram also offers a stable and smooth user experience, with billions of messages transmitted within the software every day. The concept of web3 is relatively well-known, but in reality, native encrypted users are still a minority, with most people relying on centralized exchanges to access tokens. The 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 geeks. Infinite Sharding Paradigm Sharding is a concept derived from database design, referring to the division of a large logical data set into multiple independent databases that can be distributed across multiple servers. In simple terms, sharding provides the ability for horizontal scaling, allowing data to be broken down 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 once announced a fixed 64 shards but abandoned the plan due to its difficulty, while NEAR's Nightshade protocol plans to achieve 100 shards next year, with the current active shards being 4. Unlike traditional sharding methods, TON adopts the strategy of infinite sharding. However, the reason 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, nearly approaching infinity. Elasticity of shard numbers: 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 requirements. Currently, TON consists of two working chains: the main chain (Masterchain) for synchronization and governance, and the workchain for smart contracts. Below the workchain are the shard chains and the bottom-level virtual account chain. The workchain can be divided into N shards (from 1 to 256 shards). Each shard has its own group of validators responsible for executing transactions within their shard. At the same time, it continuously downloads blocks from all other shards of its workchain. In general, a blockchain is a series of records of its state changes. For POS blockchains, validators first agree on how they want to change the blockchain state by compiling a list of changes in a block. 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. The throughput capacity of a block thread is very limited because validators must check all transactions in the block before agreeing to accept it. So TON has many threads, which can be thought of as mini micro-blockchains. They exist in parallel, each with its own set of validators. Main Chain The main chain is the main block thread in TON. It is used to synchronize all other blocks and recompute the validator set. Once all threads reach consensus on a new block, they sign it and register it in the main chain. However, main 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 rules. For example, they may have different virtual machines or extend the time for releasing 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 security guarantees. Since they can exchange messages, these messages carry network tokens. There are currently two active work chains: the main chain and the first processing work chain. Work chains are determined by address prefixes: -1:ax...1s2 - account address in the main chain. -1 is the main chain prefix. 0:zx...123 - account address in the first work chain. 0 is the prefix of the first processing work chain.

Shard Chain

A processing thread, also known as a shard chain, is an independent block thread within the workchain. By default, workchain 0 has only one thread and one chain. The validators of this thread receive external messages and process them, as well as handle internal messages sent by themselves or from other workchains. If a thread becomes overloaded in the recent N blocks, it will be split: one thread is divided into two, and transactions are processed in parallel.

Accounts with addresses starting from 0:00.. - 0:88.. are now located in thread 1, while accounts 0:88.. - 0:FF.. are located in thread 2. Since all smart contracts communicate asynchronously with each other, there are no failures, and the throughput is doubled. When the load decreases, the threads will merge back after a period of time. If the load continues to increase, the two threads can be split repeatedly, and so on. The main chain has only one thread.

In TON, blocks are not just a list of transactions needed to achieve state changes. Instead, a block is:

A list of messages executing transactions, removing them from the incoming queue. New messages resulting from message processing entering the outgoing queue, and then message processing causing changes in the smart contract state. In other words, for validators of shard X to maintain the current state of shard Y, they do not need to execute all transactions in shard Y's block. They only need to download the block and summarize the changes that have occurred. This occurs in the message queue and smart contract state.

Fundamentally changing the blockchain world is not possible without a cost. To utilize 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 an address, code, and data unit (persistent state). This unit is called an atomic unit because smart contracts always have atomic synchronous access to all their persistent states.

Hypercube Network Routing

TON has pioneered an intelligent routing mechanism to ensure that transactions between any two blockchains can always be processed quickly, regardless of the system's size. The time required to send messages between TON blockchains increases logarithmically with the number of chains, allowing them to communicate at the fastest speed even when scaled to millions of chains.

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

 

Fast Routing (Instant Hypercube Routing): The idea proposed by TON to speed up message routing, allowing cross-chain transactions to be completed in a very short time. In the traditional slow hypercube routing process, a message is routed from one shard chain to the destination shard chain along the hypercube network. However, during the message routing process, the validators of the destination shard chain can choose to process the message early and include it in a block, then provide a Merkle proof (receipt) to send a receipt to destroy the message being transmitted. This 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 by the number of hops between vertices. Through this method, transactions can be quickly routed on the shortest path, achieving efficient cross-chain interaction. Fast routing can complete cross-chain transactions in seconds without waiting for block confirmation.

Slow Routing: Slow routing is a relatively traditional method for processing cross-chain transactions, achieved by gradually transferring transactions from the source chain to the target chain. In this method, transactions are first packaged into a block on the source chain, then transferred to the target chain through a relayer. The validators of the target chain verify the validity of the transaction and then package it 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 a complete block confirmation process. Similar to the TCP/IP network, messages are addressed and sent to the destination by the destination IP address, ensuring that messages are reliably propagated to the destination chain in order. For a sharded chain hypercube network with a scale of N, the number of intermediate sharded chains (hop) required is log16(N)-1. Therefore, only 4 routing nodes (intermediate sharded chains) are needed to support millions of sharded chains.

Why Design It This Way?

Distributed validation nodes are needed. If the system is very large and has tens of thousands of nodes, the burden is too heavy to expand. After sharding, each shard has a set, shard0, shard1, etc., and cross-shard communication is required. Communication can cross shards, from one to another, meaning there needs to be a routing mechanism between shards. Connections form a route, passing through certain intermediate nodes. Each time a message passes through a route, the transmission time increases by one block time.

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

If a message is sent to a shard different from the current one, the current shard identifier's hexadecimal number (deterministically chosen) will be replaced by the corresponding number of the target shard, and the resulting identifier will serve as the approximate target, becoming the recipient of the forwarded message.

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

Hypercube routing introduces some additional delay and cost, as messages need to be forwarded through several intermediate shard chains. However, the number of these intermediate shard chains grows very slowly, related to the logarithm of the total number of shard chains N.

Asynchronous Communication

Smart contracts on TON implement asynchronous communication, analogous 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 architecture. This distributed approach requires some trade-offs but can bring benefits to user experience. Modern system management relies on sequencers like Kubernetes to obtain a set of containerized microservices, automatically start new instances on demand (auto-scaling), and effectively partition them between machines.

Analogous to using Kubernetes (a large-scale cluster management system), 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 will never be 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 sharding mechanism in the sharding field. The entire database is separated and placed on different shards. Each shard stores all its own data, rather than the state of the entire blockchain.

In the 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 implementation path, where each user can manage token state in their own contract, truly achieving decentralization at the blockchain state level. I will explore the principles of this design in detail through a case study.

First, it is necessary to understand the Wallet contract and Jetton wallet contract. The Wallet contract is a user-specific smart contract used to manage a user's tokens on the TON blockchain. The Jetton wallet contract is a special type of Wallet contract specifically used to manage a user's Jetton tokens. These tokens can be used to pay network fees and execute 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 transfers and transactions.

Suppose 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 token transfer. The entire process does not rely on a centralized contract, but rather is achieved through two decentralized contracts.

Users on the TON blockchain have their own contracts to manage asset states, meaning there is no risk of a single centralized contract managing all assets. This increases the decentralization of the system and reduces the risk of single points of failure. The asset states of all users are managed by a dedicated contract, preventing attackers from affecting the entire system by attacking a single centralized contract. Asset transactions between users can also be automatically executed through smart contracts, avoiding the risk of human error. Users can also customize their own Wallet contract and Jetton wallet contract according to their needs, enabling more functionality and use cases. This provides users with greater flexibility and autonomy. Each person manages asset states in their own contract, improving the system's scalability. 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.

The above is my analysis of the scalability and technical architecture concepts in the TON blockchain whitepaper. I would like to thank Dr. Awesome Doge for editing the first draft. I also want to express my gratitude to the development teams in Russia and Ukraine for their persistent efforts, and finally, I would like to thank Mr. Nikolai Durov, the founder of Telegram, for his great design many years ago, all for the glory of the human mind.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。