Keytakeaways

TON possesses a core technological logic centered around high-speed applications: TON originated from Telegram, with transactions directly recorded on the chain based on messages, supporting peer-to-peer communication.

1. Asynchronous message delivery: FunC, chosen as the development language, facilitates communication among TON nodes through the exchange of “messages.” However, as TON operates as an asynchronous chain, introducing the concept of logical time (It) is crucial for correctly synchronizing messages across chains. This is achieved by ensuring that the logical time (lt) of messages is strictly executed in chronological order, guaranteeing the accurate execution of information.
2. Hypercube message routing mechanism: TON employs a combination of regular routing and fast routing. Regular routing passes messages between shards through a hypercube structure involving adjacent nodes. Fast routing incorporates Merkle proofs that can relay messages along the edges of the hypercube, enhancing speed.
3. PoS + BFT consensus for ecosystem development: POS avoids extensive computations during the block generation process, resulting in higher efficiency, lower costs, and improved network performance, making it conducive to the practical implementation of DAPP applications. While DPOS is faster, its trust speed is slower than BFT systems. Therefore, TON opts for the BFT consensus mechanism.

TON’s dynamic multi-shard architecture facilitates application scalability: TON enhances speed through parallel queries, improves query accuracy with dynamic sharding, and boosts extensibility through a bag of cells structure.

1. Dynamic multi-shard architecture: TON comprises three layers – a single masterchain, multiple Workchains, and shardchains that can dynamically increase, decrease, and split. Each shardchain is a collection of various account chains, and DAPPs can autonomously activate specific shardchains.
2. Rapidly updatable global state: Updating the global state involves a structure similar to DAG called “bag of cells.” It swiftly updates by combining a new and old set of cells, removing the old root. Simultaneously, it adopts a vertical block repair mechanism for updating blocks.

TON will continue optimizing its technical framework in the future: Through parallel expansion, the introduction of chain sharding tools, and the reinforcement of node inspections, TON aims to sustain its advantages in speed and scalability.

Blockchain Scaling Challenges

Blockchain scalability is a crucial technical challenge and a key driver for the development of blockchain technology: As blockchain applications grow and user numbers increase, existing blockchain networks often face issues of insufficient throughput and long transaction confirmation times. Traditional blockchain designs limit their ability to handle large-scale transactions and user demands, leading to network congestion, high transaction costs, and inefficiency.

The challenges of blockchain scalability primarily stem from the distributed architecture and consensus mechanisms: The consensus mechanism and distributed nature of blockchain require every node in the network to verify and record all transactions, limiting the throughput of the network. Additionally, blockchain’s security and decentralized features demand that all nodes maintain complete blockchain copies, increasing the burden on storage and transmission.

To address the challenge of blockchain scalability, researchers have proposed various scaling solutions such as Sharding, Sidechains, and Layer 2 solutions: These approaches aim to enhance network throughput and performance by dividing the network into smaller segments, introducing independent blockchains, or constructing additional structures on the main chain. However, these solutions bring about new technical challenges and security issues, such as inter-shard communication, cross-shard asset transfers, and consensus mechanism design.

1. Sharding, for example, involves dividing the entire blockchain network into smaller fragments or shards, with each shard independently processing a portion of transactions and data. While this mechanism can improve the overall network throughput and performance, it still faces challenges related to the security and consistency of inter-shard communication and cross-shard transactions. Additionally, sharding mechanisms must address the design and implementation of consensus mechanisms to ensure the overall network’s consistency and security.
2. Sidechain technology involves creating and running independent blockchains connected to the main chain within a blockchain network. Sidechains facilitate two-way asset transfers with the main chain while having their own rules and functionality. The basic principle of sidechain technology is to process some transactions on the sidechain, relieving the main chain’s burden and providing higher scalability and flexibility. However, sidechains require secure mechanisms and protocols to ensure asset safety and consistency in two-way asset transfers. Additionally, the design and implementation of sidechains must consider compatibility and interoperability with the main chain.
3. Rollup, on the other hand, stores a large volume of transaction data off-chain in a sidechain and submits summary information of these transactions to the main chain for verification. Its advantage lies in significantly improving the scalability and performance of the blockchain network by storing transaction data off-chain and using the main chain for verification. However, concerns about centralization and security exist with the Rollup approach.
4. New consensus mechanisms, such as Solana’s Proof of History (POH), associate timestamps with each transaction, providing a verifiable time sequence for the blockchain. This time sequence can be used to verify transaction order and time, reducing communication costs and delays in the consensus process. While Solana claims a TPS of up to 65,000, the actual data throughput, considering node-to-node communication, is around 6-8k TPS (daily around 4-5k).

TON blockchain , originating from Telegram , was conceived with the idea of serving a massive user base: Telegram is one of the world’s most popular social platforms, boasting over 800 million monthly active users and transmitting billions of messages within the software every day. TON, as Telegram’s foray into web3, was designed from the outset to cater to billions of users rather than just a small user base.

TON’s Technical Architecture

Adaptive Infinite Split Multi-Chain Design

TON’s sharding is bottom-up: While conventional blockchain sharding schemes typically adopt a top-down approach, establishing a single blockchain first and then breaking it down into interactive blockchains to enhance performance, TON’s sharding takes a bottom-up approach. It organizes these account chains into shardchains, forming a Shardchain, where Workchains exist purely in virtual or logical forms. TON achieves parallel transaction processing across multiple chains, referred to as a “blockchain of blockchains.” This approach effectively boosts system performance.

TON features a dynamic sharding architecture, consisting of masterchain, workchain, and shardchain: The masterchain coordinates, while actual transaction processing occurs within various workchains and shardchains. Additionally, TON’s sharding is dynamic, with each account functioning as a shardchain. These can adaptively combine into larger shardchains based on the interactions among accounts to address dynamic expansion needs.

1. Masterchain: There is only one, encompassing protocol parameters, validator sets, corresponding shares, and recording current active workchains and their subordinate shardchains. Lower chains submit the latest block hash to the masterchain to ensure determining the latest state when cross-chain message retrieval is necessary.

If sharding reaches its limit, each shardchain will store only one account or smart contract. This results in numerous “account-chains” describing the state and transitions of individual accounts, with these chains mutually transmitting information, forming Workchain through Shardchains.

1. Workchain: It’s a virtual concept existing as a collection of Shardchains, with the system supporting up to 2^32 Workchains. Each Workchain can flexibly customize rules, such as transaction types, token types, smart contracts, and address formats, as long as interoperability standards are met. However, Workchains must share the same message queue format for efficient message exchange, implying similar security guarantees for all Workchains.
2. Shardchain: To enhance processing efficiency, Shardchains automatically split during high loads and merge during decreased loads. Each Workchain further divides into Shardchains (up to 2^60). Shardchains distribute work across all Shardchains, with each serving only a portion of the account collection.

Information Transfer Mechanisms

Message: Since TON uses FunC’s send_raw_message function to develop its language, the messages passed by TON nodes are called “messages”. A transaction in TON consists of an inbound message that initially triggers it and a set of outbound messages that are sent to other contracts;

Hypercube Routing: A three-dimensional structured messaging mechanism that enables messages created in one block of a sharded chain to be rapidly delivered and processed to the next block of the target sharded chain.

Asynchronous message delivery

Asynchronous calls pose synchronization challenges: In synchronous blockchains, transactions can include multiple smart contract calls. In asynchronous systems, users cannot promptly receive responses from the target smart contract in the same transaction. This delay is because contract calls may take several blocks to process, and the routing distance between source and destination blocks affects this process.

To achieve infinite sharding, it is essential to ensure complete parallelization of messages, leading to the introduction of the concept of logical time: In TON, each transaction executes solely on a single smart contract and communicates between contracts using messages. This introduces the concept of logical time in asynchronous chains, enabling synchronization of messages between chains. Each message has its logical time or Lamport time (hereafter referred to as lt). This time is used to track the relationships between events and determine which events validators need to process first.

The execution logic is guaranteed by strictly following the execution order of message lt: Messages sent from an account and transactions occurring on an account are strictly ordered, with the lt of generated transactions greater than the lt of messages. Additionally, the lt of messages sent in a transaction is strictly greater than the lt of the transaction that triggers the messages. In the case of multiple messages, those with lower lt are processed earlier.

Message Hypercube routing mechanism

TON employs parallel execution with Fast Routing + Slow Routing:

Slow Routing: A more stable and traditional cross-chain information processing method, where information is packaged into a block on the source chain and then relayed from one shard chain to another through a relayer. Multiple intermediary shard chains can also be used for transmission. All shard chains form a “hypercube” graph, and messages propagate along the edges of this hypercube. After validation by validators, the information is packaged into another block.

The advantage of Slow Routing lies in higher security and decentralization, as all information needs to go through a complete block confirmation process. For a hypercube network of shard chains with a scale of N, the number of routes hop = log16(N). Therefore, only 4 routing nodes are needed to support a million shard chains.

Fast Routing: In Slow Routing, messages propagate along the edges of the hypercube. To speed up, Fast Routing allows the validators of the destination shard chain to process the message in advance, provide a Merkle proof, and send a receipt to destroy the transmitting message.

Fast Routing is faster (nodes can find the optimal path) and prevents double delivery. However, it cannot replace Slow Routing because validators are not penalized for losing receipts, posing a certain security risk.

Global state of a sharded blockchain

“Bag of cells”: A set of cells updated in a manner similar to a Directed Acyclic Graph (DAG). This involves representing the new state as another “bag of cells” with its own root, and then combining the new and old sets of cells while simultaneously removing the old root.

Vertical block repair: In TON shard chains, each block is not just a single block but a chain. When it is necessary to fix a block in an erroneous shard chain, a new block will be submitted to the “vertical block chain” for the replacement of the block.

Consensus

POS network consists of three roles:

1. Validator Nodes: Participants in maintaining network security by staking 300,000 TON upon meeting hardware requirements. Blocks are created by 100 to 1000 selected nodes, elected monthly. During their tenure, elected nodes are divided into multiple working groups to create new blocks. Each new block requires signatures from over 2/3 of the staked nodes in the working group to be considered successfully created. Malicious behavior may lead to slashing and disqualification.
2. Fisherman: Acts as a supervisor by sending invalid proof to check if validator nodes have diligently completed their verification tasks.
3. Nominator: Suggests new shard chain candidate blocks to validator nodes. If the block is elected, the curator profits. They are responsible for verifying the state of the shard chain and neighboring shard chain data and sending it to validator nodes.

BFT (Byzantine Fault Tolerance ): TON, after weighing options, chooses BFT over DPOS for its higher trust level and speed, despite DPOS being faster.

TON’s new framework can support TG’s high-speed information transfer

TON achieves high transaction speed and finality through a dynamic multi-shard architecture: Each user wallet in TON can have its own chain, and the theoretical basis for high TPS includes parallel computation of shards, support for instant cross-shard communication, and TVM supporting asynchronous computation.

TON brings higher scalability through an information-passing mechanism: In TON blockchain, calls between smart contracts are asynchronous rather than atomic. This means that when one smart contract calls another, the call is not executed immediately but is processed in some future block after the transaction ends. This design allows for higher scalability as it doesn’t require completing all transaction processing in a single block.

TON will continue to optimize the technical framework in the future…

TON’s technical roadmap will continuously advance the speed and scalability advantages of TON:

1. Separation of Sorters and Validators.
2. Scalability and Speed Improvement: Enabling TON to achieve parallel expansion in handling a large number of transactions.
3. Chain Sharding Guides and Tools: Organizing guides and code examples for handling high loads of TON work in exchanges, payment systems, and TON services.
4. Enhancing Coordination Among Validator Nodes: Strengthening and improving the detection and punishment of underperforming validators.

Disclaimer：

1. This article is reprinted from [community.tonup]. All copyrights belong to the original author [Kiwi from PKU blockchain Association]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.