Describe in detail the technical characteristics of TON and its smart contract development paradigm
TechFlow Selected TechFlow Selected
Describe in detail the technical characteristics of TON and its smart contract development paradigm
Given Telegram's massive traffic resources, the TON ecosystem will surely bring some entirely new applications to Web3.
Navigating Web3 tides with focused insightsAuthor: @Web3Mario
Introduction: With Binance listing Notcoin—the largest game in the TON ecosystem—and the massive wealth effect driven by its fully circulating token economic model, TON has quickly drawn significant attention. After discussing with friends, I learned that TON has a relatively high technical barrier and its DApp development paradigm differs significantly from mainstream blockchain protocols. Therefore, I spent some time deeply researching these topics and would like to share my insights. In short, TON’s core design philosophy is to reconstruct traditional blockchain protocols in a “bottom-up” manner, sacrificing interoperability in pursuit of extreme performance in concurrency and scalability.
TON’s Core Design Philosophy—High Concurrency and High Scalability
It can be said that all complex technical decisions within TON are ultimately aimed at achieving high concurrency and scalability. This is understandable given its origins. TON, or The Open Network, is a decentralized computing network comprising an L1 blockchain and multiple components. Originally developed by Telegram founder Nikolai Durov and his team, today it is supported and maintained by a global community of independent contributors. Its roots trace back to 2017 when the Telegram team began exploring blockchain solutions for their platform. At the time, no existing L1 blockchain could support Telegram’s hundreds of millions of users, so they decided to build their own—originally called the Telegram Open Network. In early 2018, to secure funding for development, Telegram conducted a sale of Gram tokens (later renamed Toncoin). However, due to regulatory issues, the Telegram team exited the project in 2020. A small group of open-source developers and winners of Telegram contests then took over the codebase, rebranded it as The Open Network, and have continued active development ever since, adhering closely to the principles outlined in the original TON whitepaper.
Given that TON was designed to serve as a decentralized execution environment for Telegram, it must address two key challenges: handling high-concurrency requests and managing vast amounts of data. As we know, even Solana—the blockchain boasting the highest TPS—has only achieved around 65,000 TPS in real-world testing, far below what would be required for a Telegram-scale ecosystem demanding millions of TPS. Meanwhile, the volume of data generated by Telegram’s widespread use has long been astronomical. Requiring every node in a blockchain—a highly redundant distributed system—to store a full copy of this data is simply impractical.
To solve these two problems, TON introduces two major improvements over conventional blockchain designs:
-
Adopting the "Infinite Sharding Paradigm" to tackle data redundancy, enabling large-scale data handling while alleviating performance bottlenecks;
-
Introducing a fully parallel execution environment based on the Actor model to dramatically increase network TPS.
Building Chains Within the Chain—Dedicated Account Chains via Infinite Sharding
Today, sharding is widely adopted by many blockchain protocols to improve performance and reduce costs. TON takes this concept further by introducing the Infinite Sharding Paradigm—an architecture allowing the blockchain to dynamically scale the number of shards based on network load. This enables TON to maintain high performance while processing massive transaction volumes and smart contract operations. In theory, TON can create a dedicated account chain for each user, maintaining consistency across chains through defined rules.
Abstractly speaking, TON features four layers of chain structure:
-
AccountChain: Represents a sequence of transactions associated with a specific account. Transactions form a chain because, in a state machine, identical sequences of instructions produce consistent results under uniform execution rules. Thus, all blockchain systems require sequential ordering of transactions. The AccountChain is the most fundamental unit in TON, though typically virtual rather than physically separate.
-
ShardChain: In practice, ShardChains are the actual building blocks of TON—each being a collection of AccountChains.
-
WorkChain: A set of ShardChains operating under custom rules. For example, one could deploy an EVM-compatible WorkChain to run Solidity smart contracts. Theoretically, anyone in the community can create their own WorkChain. However, doing so is highly complex, requires paying substantial fees, and needs approval from 2/3 of validators.
-
MasterChain: A special chain responsible for finalizing all ShardChain blocks. Once a ShardChain block hash is included in a MasterChain block, that block and all its ancestors are considered finalized—immutable and referenced by subsequent blocks across the network.
This architecture gives TON three key characteristics:
-
Dynamic Sharding: TON automatically splits and merges ShardChains based on load, ensuring fast block generation and minimal transaction latency.
-
High Scalability: Through infinite sharding, TON supports nearly unlimited shard counts—up to 2^60 WorkChains in theory.
-
Adaptivity: When load increases in part of the network, that section can split into more shards; when load decreases, shards merge for efficiency.
With such a multi-chain system, cross-chain communication becomes critical—especially given the potential for an enormous number of shards. As shard count grows, routing messages between chains becomes increasingly difficult. Consider a network with four nodes, each maintaining a distinct WorkChain. The connections indicate that each node not only orders transactions on its own chain but also monitors and processes state changes on other chains—implemented in TON by listening to outgoing message queues.
Suppose Account A on WorkChain 1 wants to send a message to Account C on WorkChain 3. This raises the issue of message routing. In this case, two possible routes exist: WorkChain 1 → WorkChain 2 → WorkChain 3, or WorkChain 1 → WorkChain 4 → WorkChain 3.
For more complex scenarios, an efficient and low-cost routing algorithm is essential. TON employs the "Hypercube Routing Algorithm" for cross-chain message routing. A hypercube is a special network topology where an n-dimensional hypercube consists of 2^n vertices, each uniquely identified by an n-bit binary number. Two vertices are adjacent if their binary representations differ by exactly one bit. For instance, in a 3D hypercube, vertex 000 is adjacent to 001. The above example illustrates a 2D hypercube.
In the hypercube routing protocol, messages are routed by comparing the binary representations of source and destination WorkChain addresses. The algorithm calculates the Hamming distance (number of differing bits) and forwards the message step-by-step through adjacent WorkChains until reaching the destination. This ensures transmission along the shortest path, improving communication efficiency.
To streamline this process, TON also offers an optimistic mechanism: if a user provides valid proof—typically a Merkle trie root—a node can immediately accept the message’s authenticity. This is known as Instant Hypercube Routing.
Thus, TON addresses differ significantly from those in other blockchains. Most chains use hashes of public keys derived from elliptic-curve cryptography purely for uniqueness, without routing functionality. In contrast, TON addresses consist of two parts: (workchain_id, account_id), where workchain_id is encoded according to the hypercube routing scheme (details omitted here).
One might wonder: since the MasterChain connects to all WorkChains, couldn’t all cross-chain messages simply be relayed through it, like in Cosmos? While technically feasible, the TON design reserves the MasterChain for critical tasks—mainly finality. Using it for message routing would incur prohibitively high fees.
Finally, TON uses a BFT+PoS consensus mechanism: any staker may participate in block production. At regular intervals, an election smart contract randomly selects a validator committee from all stakers. Selected validators use BFT to produce blocks. Misbehavior or invalid blocks result in slashing, while honest participation earns rewards. This is now a common approach and won’t be elaborated further here.
Actor-Based Smart Contracts and Fully Parallel Execution Environment
Another key distinction of TON is its smart contract execution model. To overcome TPS limitations of conventional blockchains, TON adopts a bottom-up design using the Actor model to rebuild smart contracts and enable full parallel execution.
Most mainstream blockchains use single-threaded, sequential execution. Ethereum’s EVM, for example, is a state machine that processes transactions in order after block proposers finalize their sequence. This serial execution ensures deterministic outcomes across distributed nodes. It also prevents race conditions—no other transaction can modify shared state during execution, enabling reliable composability. For instance, when swapping USDT for ETH via Uniswap, the pool’s liquidity state is fixed during execution, allowing accurate calculation. If liquidity changed mid-execution (e.g., during a bonding curve calculation), the result would be outdated and invalid.
However, this architecture faces clear TPS bottlenecks—especially outdated in today’s multi-core computing era. It's akin to running an old game like Command & Conquer on modern hardware: despite powerful specs, performance lags due to architectural constraints.
Some protocols have addressed this with partial parallelization. Solana, currently claiming the highest TPS, groups transactions by state dependencies—only executing non-overlapping groups in parallel, while still processing intra-group transactions sequentially.
TON, however, completely abandons serial execution. Instead, it embraces the Actor model—first proposed by Carl Hewitt in 1973—to eliminate shared-state complexity in concurrent systems. Each Actor maintains private state and communicates solely via asynchronous message passing. Actors are autonomous units capable of processing messages, creating new actors, sending messages, and determining future behavior. Key features include:
-
Encapsulation and Independence: Each Actor processes messages independently, enabling safe parallelism without interference.
-
Message Passing: Interaction occurs exclusively through asynchronous message exchange.
-
Dynamic Structure: Actors can spawn new Actors at runtime, enabling adaptive scaling.
TON applies this model to smart contracts: each contract is an independent Actor with isolated storage, eliminating external data dependencies. Furthermore, calls to the same contract are processed in message queue order. This allows TON to execute transactions in parallel without conflicts.
However, this design disrupts conventional development patterns, posing new challenges:
1. Asynchronous Cross-Contract Calls: In TON, smart contracts cannot atomically call external contracts or read their data. In Solidity, calling function2 of Contract B from function1 of Contract A—or reading state via a view function—is atomic and occurs within a single transaction. In TON, such interactions require asynchronous internal messages—transactions initiated by contracts themselves—which cannot block for return values.
For example, consider building a DEX. On EVM, a router contract typically orchestrates multi-pool swaps atomically. But in TON, this isn't straightforward. Reusing the same pattern would involve one external message from the user and three internal messages (note: this is illustrative; even ERC-20 standards need redesigning).
2. Error Handling and Bounce Functions: In EVM, failed transactions roll back entirely. But in TON’s asynchronous model, once a transaction succeeds, it cannot be undone—even if later steps fail. To handle this, TON implements “bounce messages”: if an internal message causes failure, the callee can trigger a predefined bounce function in the caller to revert relevant states.
3. No Guaranteed Execution Order: In complex cases, earlier-received messages may not finish first. Hence, assuming strict temporal order is unsafe. Every message in TON carries a Lamport timestamp (lt), indicating causal relationships and processing priority. In simple cases, earlier arrival means earlier completion.
Here, A and B represent two contracts. If msg1_lt < msg2_lt, then tx1_lt < tx2_lt.
But in complex cases, this breaks down. Official docs provide an example: three contracts A, B, and C. A sends two internal messages—msg1 to B, msg2 to C—in order. Yet we cannot guarantee msg1 will be processed before msg2, due to varying routing paths and validator sets. If B and C reside on different ShardChains, one message may take several blocks to arrive. Two possible paths emerge:
4. Data Storage via DAG of Cells: TON stores contract state as a directed acyclic graph (DAG) of Cells—compact data units encoded in a tree-like structure, unlike EVM’s hashmap-based storage. Due to differing access algorithms, deeper Cells cost more gas. This opens a DoS vector: malicious users can flood shallow Cells, driving up storage costs for honest users. In EVM, hashmap lookups are O(1), so gas is uniform. TON developers should avoid unbounded data types and shard them when necessary.
5. Other notable traits include rent for storage, native contract upgradability, and built-in account abstraction—every wallet address is essentially an uninitialized smart contract. Developers must carefully account for these features.
These are my reflections from studying TON technology recently. I welcome corrections for any inaccuracies. Moreover, given Telegram’s massive user base, I believe the TON ecosystem will bring innovative applications to Web3. Developers interested in building TON DApps are welcome to reach out—I’d love to discuss further.
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
@web3_mario
