Understanding TON's Technical Logic: High-Speed Applications at the Core
TechFlow Selected TechFlow Selected
Understanding TON's Technical Logic: High-Speed Applications at the Core
The technical part of the TON roadmap will continue to advance TON's advantages in speed and scalability.
Navigating Web3 tides with focused insightsAuthor: Peking University Blockchain Association Kiwi
TON has a technical architecture centered on high-speed applications: TON was born within Telegram, where transactions are directly recorded on-chain as messages and support peer-to-peer interactions.
-
Asynchronous message passing: Since FunC is used as the smart contract programming language, nodes in TON communicate by exchanging "messages." However, TON is an asynchronous blockchain, so to correctly synchronize inter-chain messages, it introduces the concept of logical time (lt). By ensuring that message lt values are strictly executed in chronological order, correct execution of information is guaranteed.
-
Hypercube-based message routing: TON uses a dual-path routing system—regular routing and fast routing. Regular routing transfers cross-shard messages through adjacent nodes using a cubic structure, while fast routing introduces Merkle proofs along hypercube edges to relay messages more quickly.
-
PoS + BFT consensus facilitates ecosystem development: PoS avoids heavy computation during block production, resulting in higher efficiency, lower costs, and better network performance—ideal for DApp deployment. Although DPoS is faster, its trust establishment is slower than in BFT systems; hence, TON adopts BFT.
TON’s dynamic multi-shard architecture enables application scalability: TON improves speed via parallel queries, enhances query accuracy through dynamic sharding, and increases scalability with its “bag of cells” design.
-
Dynamic multi-shard architecture: TON consists of three layers—a single masterchain, multiple workchains, and shardchains that can be dynamically added, removed, or split. Each shardchain is a collection of account chains, and DApps can independently activate specific shardchains.
-
Rapidly updatable global state: The global state is updated using a DAG-like “bag of cells” structure. Updates occur by combining new and old cell sets and deleting the old root, enabling fast transitions. Vertical block repair is also employed to update blocks.
TON will continue optimizing its technical framework: Through parallelization, introducing sharding tools, enhancing node validation, and other mechanisms, TON will further advance its advantages in speed and scalability.
The Blockchain Scalability Challenge
Blockchain scalability is a critical technical challenge and one of the key drivers of blockchain advancement: As blockchain applications grow and user numbers increase, existing networks often face 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 fees, and inefficiency.
The scalability challenge primarily stems from distributed architecture and consensus mechanisms: First, blockchain consensus and decentralization require every node to validate and record all transactions, limiting network throughput. Second, security and decentralization demand that all nodes maintain full copies of the blockchain, increasing storage and bandwidth burdens.
To address scalability issues, researchers have proposed various solutions: such as sharding, sidechains, and Layer 2 solutions. These approaches aim to improve throughput and performance by splitting the network into smaller parts, introducing independent blockchains, or building additional structures atop the main chain. However, these solutions introduce new technical and security challenges, including cross-shard communication, cross-chain asset transfers, and consensus design.
-
Sharding: The core idea is to divide the blockchain network into smaller segments (shards), each capable of independently processing a subset of transactions and data. By distributing transactions across shards, sharding increases overall throughput and performance. However, it faces challenges in cross-shard communication and consistency, and requires careful consensus design to ensure network-wide security and coherence.
-
Sidechains: Sidechain technology involves creating independent blockchains connected to the main chain (mainnet), allowing bidirectional asset transfers. Sidechains operate under their own rules and functions, offloading transaction processing from the main chain to enhance scalability and flexibility. However, secure protocols are needed to ensure asset safety and consistency during transfers, and compatibility and interoperability with the main chain must be addressed.
-
Rollups: The basic principle is storing large volumes of transaction data off-chain (on a sidechain) and submitting only summary data to the main chain for verification. This significantly reduces on-chain storage and computational load, improving scalability and performance. However, concerns about centralization and security remain.
-
New consensus mechanisms: For example, Solana’s Proof of History (PoH) associates timestamps with each transaction, creating a verifiable time sequence. This helps verify transaction order and timing, reducing communication overhead and latency in consensus. While Solana claims up to 65,000 TPS, most of this reflects internal node messaging—the actual data throughput ceiling is around 6–8k (typically 4–5k).
TON Blockchain originated from Telegram, with an initial vision focused on serving massive user bases: Telegram is one of the world’s most popular social platforms, with over 800 million monthly active users and hundreds of billions of messages transmitted daily. As Telegram’s Web3 evolution, TON was designed from the outset to serve billions—not just a niche audience.
TON's Technical Architecture
Adaptive Infinite Sharding Multi-Chain Design
TON’s sharding is bottom-up: Most blockchain sharding schemes use a top-down approach—starting with a single chain and then partitioning it into interconnected sub-chains to boost performance. In contrast, TON takes a bottom-up approach: organizing account chains into shardchains, where account chains (workchains) exist purely as virtual or logical constructs within shardchains. TON enables multiple chains to process transactions in parallel, forming a “blockchain of blockchains,” effectively enhancing system performance.
TON employs a dynamic sharding architecture: Comprising masterchain, workchains, and shardchains. The masterchain coordinates the system, while workchains and shardchains handle actual transaction processing. TON’s sharding is dynamic—each account acts as a shardchain and can adaptively merge into larger shardchains based on interaction patterns to meet scaling needs.
-
Masterchain: There is only one masterchain, which stores protocol parameters, validator sets and their stakes, and tracks currently active workchains and their shardchains. Lower-level chains submit the hash of their latest block to the masterchain to ensure accurate state tracking during cross-chain message reads.
-
When sharding reaches its limit, each shardchain may contain just a single account or smart contract. This leads to numerous “account-chains” representing individual account states and transitions, which exchange information among each other—forming workchains from shardchains.
-
Workchain: A virtual construct representing a collection of shardchains. The system supports up to 2^32 workchains. Each workchain can customize rules—such as transaction types, token standards, smart contracts, and address formats—as long as they comply with interoperability standards. However, all workchains must use the same message queue format to enable message exchange, implying roughly equivalent security guarantees across workchains.
-
Shardchain: To enhance processing efficiency, shardchains can automatically split under high load and merge when load decreases. Each workchain can be subdivided into up to 2^60 shardchains. Work is distributed across all shardchains, with each serving only a subset of accounts.
Message Passing Mechanism
Message: Since TON uses the send_raw_message function in FunC, inter-node communication in TON is referred to as "message." A transaction in TON consists of an inbound message that triggers it and a set of outbound messages sent to other contracts.
Hypercube Routing: A 3D-structured message delivery mechanism that allows a message created in one shardchain block to be rapidly delivered and processed in the next block of the target shardchain.
Asynchronous Message Passing
Asynchronous calls introduce synchronization challenges: In synchronous blockchains, a transaction can include multiple smart contract calls. In asynchronous systems, users cannot immediately receive responses from target contracts within the same transaction, as contract execution may span several blocks. The routing distance between source and destination blocks affects this delay.
To achieve infinite sharding, messages must be fully parallelized—leading to the concept of logical time: In TON, each transaction executes on only one smart contract, with inter-contract communication occurring via messages. This necessitates the use of logical time (Lamport time, abbreviated as lt) in asynchronous chains to synchronize inter-chain messages. Each message carries an lt value used to track event causality and determine processing priority for validators.
Messages are executed strictly in lt order to ensure logical consistency: Messages sent from an account and transactions occurring on an account are strictly ordered. The lt of any resulting transaction exceeds that of the initiating message, and the lt of any message sent within a transaction is strictly greater than the lt of the transaction that triggered it. When multiple messages exist, those with lower lt values are processed first.
Message Hypercube Routing Mechanism
TON runs fast routing and slow routing in parallel:
Slow Routing: A more stable and traditional method for cross-chain message handling. Messages are packaged into a block on the source chain and relayed from one shardchain to another via relayers, potentially traversing multiple intermediate shardchains. All shardchains form a “hypercube” graph, and messages propagate along its edges. After validation, messages are included in a new block. This method ensures higher security and decentralization due to full block confirmation. In a hypercube network of size N, the number of hops required is log₁₆(N). Thus, only 4 relay nodes are needed to support a million shardchains.
Fast Routing: While slow routing propagates messages along hypercube edges, fast routing allows validators of the destination shardchain to pre-process the message, generate a Merkle proof, and send back a receipt to destroy the in-flight message.
Fast routing is quicker (nodes can find optimal paths) and prevents double delivery, but cannot replace slow routing entirely—since validators face no penalties for losing receipts, there is some security risk.
Global State of Shardchains
"Bag of Cells": A set of cells updated in a DAG-like structure. The new state is represented as another “bag of cells” with its own root. The system combines the new and old bags and deletes the old root to finalize the update.
Vertical Block Repair: Each block in a TON shardchain is not a single block but part of a chain. When repairing an erroneous block, a new block is submitted to a “vertical blockchain” to replace the faulty one.
Consensus Mechanism
Three roles exist in the PoS network:
-
Validator Nodes: Can participate in securing the network by staking 300,000 TON after meeting hardware requirements.
-
Blocks are produced by 100–1,000 elected nodes, reselected monthly. During elections, nodes must lock their staked TON coins. Elected nodes are grouped into working teams to create new blocks. A block is valid once signed by over 2/3 of the team’s staked nodes. Malicious behavior results in slashing and disqualification.
-
Fishermen: Monitor validators by submitting invalidity proofs to detect negligence or misconduct—acting as auditors.
-
Collators: Propose candidate blocks for new shardchains. If selected, collators earn rewards. They verify the state of a shardchain and neighboring shard data before sending it to validators.
BFT: After evaluation, TON determined that although DPoS is faster, its trust propagation is slower than BFT systems. Therefore, TON chose Byzantine Fault Tolerance (BFT).
TON’s New Framework Supports Telegram’s High-Speed Messaging
TON achieves high transaction speed and finality through dynamic multi-sharding: TON can assign a dedicated chain to each user wallet. Parallel computation across shards, instant cross-shard communication, and TVM support for asynchronous execution form the theoretical foundation for high TPS.
TON’s message-passing mechanism enhances scalability: Smart contract calls in TON are asynchronous, not atomic. When one contract calls another, the call isn’t executed immediately but is processed in a future block after the current transaction ends. This design enables greater scalability by avoiding the need to complete all processing within a single block.
TON Will Continue Optimizing Its Technical Framework...
TON’s roadmap will continue advancing its speed and scalability advantages:
-
Separation of sequencers and validators;
-
Enhanced scalability and speed: Enabling TON to scale in parallel when handling large transaction volumes;
-
Sharding guidelines and tools: Providing best practices and code examples for deploying high-load TON operations in exchanges, payment systems, and TON services;
-
Improved coordination among validator nodes: Strengthening detection and penalties for underperforming validators.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
