Detailed description of the technical features of TON and the paradigm of smart contract development

Author: @Web3Mario

Introduction: With the launch of Notcoin, the largest game in the TON ecosystem by Binance, and the massive wealth effect triggered by the fully circulating token economic model, TON has gained significant attention in a short period. After discussing with friends, I learned that the technical threshold of TON is relatively high, and the DApp development paradigm differs greatly from mainstream public chain protocols. Therefore, I spent some time delving into related topics and would like to share some insights. In short, the core design philosophy of TON is to reconstruct traditional blockchain protocols in a "bottom-up" manner, sacrificing interoperability to achieve extreme pursuit of high concurrency and high scalability.

Core Design Philosophy of TON ------ High Concurrency and High Scalability

It can be said that all complex technical choices in TON stem from the pursuit of high concurrency and high scalability. Of course, we can understand this from its background. TON, or The Open Network, is a decentralized computing network that includes an L1 blockchain and multiple components. TON was initially developed by Nikolai Durov, the founder of Telegram, and his team, and is now supported and maintained by a community of independent contributors worldwide. Its origins can be traced back to 2017 when the Telegram team began exploring blockchain solutions for themselves. At that time, no existing L1 blockchain could support Telegram's nine-digit user base, so they decided to design their own blockchain, initially called Telegram Open Network. By 2018, to obtain the resources needed to realize TON, Telegram initiated the sale of the Gram token (later renamed Toncoin) in the first quarter of 2018. In 2020, due to regulatory issues, the Telegram team withdrew from the TON project. Subsequently, a small group of open-source developers and winners of Telegram competitions took over the TON codebase, renamed the project to The Open Network, and continued to actively develop the blockchain to this day, adhering to the principles outlined in the original TON white paper.

Since the design goal is to serve as a decentralized execution environment for Telegram, it naturally faces two challenges: high concurrency requests and massive data. We know that with the advancement of technology, even the highest TPS claimed by Solana has a maximum measured TPS of only 65,000, which is clearly insufficient to support the million-level TPS requirements of the Telegram ecosystem. Meanwhile, with the large-scale application of Telegram, the amount of data generated has long since exceeded astronomical levels. As a highly redundant distributed system, it is unrealistic to require every node in the network to maintain a complete copy of the data.

Therefore, to address these two issues, TON has made two optimizations to mainstream blockchain protocols:

• By adopting the "Infinite Sharding Paradigm," the system is designed to solve data redundancy issues, enabling it to handle big data while alleviating performance bottlenecks.
• By introducing a fully parallel execution environment based on the Actor model, it greatly enhances network TPS.

Building a Blockchain ------ Providing Each Account with a Dedicated Account Chain through Infinite Sharding Capability

Currently, we know that sharding has become the mainstream solution for most blockchain protocols to improve performance and reduce costs, and TON has taken this to the extreme by proposing the Infinite Sharding Paradigm. This paradigm allows the blockchain to dynamically increase or decrease the number of shards based on network load. This enables TON to maintain high performance while processing large-scale transactions and smart contract operations. Theoretically, TON can establish a dedicated account chain for each account and ensure consistency between these chains through certain rules.

To understand this abstractly, there are four layers of chain structure in TON:

• Account Chain: This layer represents a chain composed of a series of transactions related to a specific account. The reason transactions can form a chain structure is that for a state machine, as long as the execution rules are consistent, the state machine will yield the same result when receiving instructions in the same order. Therefore, all distributed systems in blockchain need to perform chain-based ordering of transactions, and TON is no exception. The account chain is the most basic unit of the TON network. Typically, the account chain is a virtual concept and is unlikely to exist as an independent account chain.

• Shard Chain: In most contexts, the shard chain is the actual unit of composition in TON, which is a collection of account chains.

• Work Chain: This can also be called a set of shard chains with custom rules. For example, creating a work chain based on EVM to run Solidity smart contracts. Theoretically, anyone in the community can create their own work chain. In fact, building it is a rather complex task, and one must pay the (expensive) fee to create it and obtain 2/3 of the votes from validators to approve the creation of your work chain.

• Master Chain: Finally, there is a special chain in TON called the master chain, which is responsible for providing finality for all shard chains. Once the hash of a shard chain block is merged into a block of the master chain, that shard chain block and all its parent blocks are considered final, meaning they can be regarded as fixed and immutable content referenced by subsequent blocks of all shard chains.

By adopting this paradigm, the TON network possesses the following three characteristics:

• Dynamic Sharding: TON can automatically split and merge shard chains to adapt to changes in load. This means new blocks are always generated quickly, and transactions do not experience long wait times.

• High Scalability: Through the Infinite Sharding Paradigm, TON can support an almost unlimited number of shards, theoretically reaching 2 to the power of 60 work chains. Adaptability: When a certain part of the network experiences increased load, that part can be subdivided into more shards to handle the increased transaction volume. Conversely, when the load decreases, shards can be merged to improve efficiency.

In such a multi-chain system, the first challenge is the cross-chain communication issue, especially since the ability to infinitely shard means that when the number of shards in the network reaches a certain scale, routing information between chains becomes a challenging task. Imagine a network with four nodes, each responsible for maintaining an independent work chain. The link relationships indicate that apart from managing the transaction ordering in its own work chain, each node must also listen for and process state changes in the target chain, which is specifically achieved in TON by listening to messages from the output queue.

Assuming account A in work chain 1 wants to send a message to account C in work chain 3, this involves a message routing problem. In this example, there are two routing paths: work chain 1 -> work chain 2 -> work chain 3, and work chain 1 -> work chain 4 -> work chain 3.

When faced with more complex situations, an efficient and low-cost routing algorithm is needed to quickly complete message communication. TON has chosen the so-called "Hypercube Routing Algorithm" to achieve cross-chain message communication routing discovery. The hypercube structure refers to a special network topology, where an n-dimensional hypercube consists of 2^n vertices, each uniquely identified by an n-bit binary number. In this structure, any two vertices that differ by only one bit in their binary representation are considered adjacent. For example, in a 3-dimensional hypercube, vertices 000 and 001 are adjacent because they differ only in the last bit. The above example illustrates a 2-dimensional hypercube.

In the hypercube routing protocol, the routing process of messages from the source work chain to the target work chain is conducted by comparing the binary representations of the source and target work chain addresses. The routing algorithm finds the minimum distance between these two addresses (i.e., the number of differing bits in their binary representation) and forwards the information step by step through adjacent work chains until it reaches the target work chain. This method ensures that data packets are transmitted along the shortest path, thereby improving the communication efficiency of the network.

Of course, to simplify this process, TON has also proposed an optimistic technical solution. When users can provide valid proof of a certain routing path, usually a Merkle trie root, nodes can directly acknowledge the credibility of the message submitted by the user. This is also known as instant hypercube routing.

Therefore, we can see that addresses in TON are distinctly different from those in other blockchain protocols. Most mainstream blockchain protocols use the hash of the public key generated by the elliptic curve cryptography algorithm as the address, as addresses are only meant for uniqueness and do not need to carry routing addressing functions. In TON, addresses consist of two parts: (workchainid, accountid), where workchain_id is encoded according to the hypercube routing algorithm, which will not be elaborated here.

Another point that may raise questions is that you might have noticed the master chain and each work chain are linked. So, can't all cross-chain information be relayed through the master chain, similar to Cosmos? In TON's design philosophy, the master chain is only used to handle the most critical tasks, namely maintaining the finality of numerous work chains. Routing messages through the master chain is possible, but the transaction fees incurred would be quite expensive.

Finally, a brief mention of its consensus algorithm: TON adopts a BFT+PoS approach, meaning any staker has the opportunity to participate in block packaging. The TON election governance contract randomly selects a cluster of validators from all stakers at regular intervals. The selected nodes, known as validators, will package blocks using the BFT algorithm. If they package incorrect information or act maliciously, their staked tokens will be confiscated; conversely, they will receive block rewards. This has essentially become a relatively common choice, so it will not be elaborated further here.

Smart Contracts Based on the Actor Model and Fully Parallel Execution Environment

Another point where TON differs from mainstream blockchain protocols is its smart contract execution environment. To break through the TPS limitations of mainstream blockchain protocols, TON adopts a bottom-up design approach and reconstructs smart contracts and their execution methods using the Actor model, enabling fully parallel execution capabilities.

We know that most mainstream blockchain protocols use a single-threaded serial execution environment. Taking Ethereum as an example, its execution environment EVM is a state machine with transactions as input. When the block-producing node completes the ordering of transactions by packaging blocks, it executes the transactions in that order through the EVM. The entire process is completely serial and single-threaded, meaning only one transaction can be executed at a time. The advantage of this approach is that once the transaction order is confirmed, the execution results have consistency across a widely distributed cluster. Meanwhile, since only one transaction is serially executed at a time, there cannot be any other transactions modifying the state data being accessed during execution, thus achieving interoperability between smart contracts. For example, when we use Uniswap to purchase ETH with USDT, the distribution of LPs in that transaction pair is a determined value, allowing us to derive the corresponding result through certain mathematical models. However, if the situation were different, such as when executing a bonding curve calculation, and another LP added new liquidity, the calculation result would be outdated, which is clearly unacceptable.

However, this architecture has obvious limitations, namely the TPS bottleneck, which seems outdated in the current multi-core processor environment. It's like using a modern PC to play some old computer games, such as Red Alert; when the number of combat units reaches a certain quantity, you will still find it lagging, which is a software architecture issue.

You may have heard that some protocols are already paying attention to this issue and have proposed their own parallel solutions. For example, Solana, which claims to have the highest TPS, also possesses parallel execution capabilities. However, its design philosophy differs from that of TON. In Solana, the core idea is to group all transactions based on execution dependency relationships, with no shared state data between different groups. This means there are no identical dependencies, allowing transactions within different groups to be executed in parallel without worrying about conflicts. However, transactions within the same group still follow the traditional serial execution method.

In contrast, TON completely abandons the serial execution architecture and adopts a development paradigm specifically designed for parallel execution, using the Actor model to reconstruct the execution environment. The Actor model was first proposed by Carl Hewitt in 1973, aiming to solve the complexity of shared state in traditional concurrent programs through message passing. Each Actor has its own private state and behavior, and does not share any state information with other Actors. The Actor model is a computational model for concurrent computing that achieves parallel computation through message passing. In this model, an "Actor" is the basic unit of work, capable of processing received messages, creating new Actors, sending more messages, and deciding how to respond to subsequent messages. The Actor model must possess the following characteristics:

• Encapsulation and Independence: Each Actor is completely independent when processing messages and can handle messages in parallel without interfering with each other.

• Message Passing: Actors interact only by sending and receiving messages, and message passing is asynchronous.

• Dynamic Structure: Actors can create more Actors at runtime, allowing the Actor model to expand the system as needed.

TON adopts this architecture to design its smart contract model, which means that in TON, each smart contract is an Actor model with completely independent storage space, as it does not rely on any external data. Additionally, calls to the same smart contract are still executed according to the order of messages in the receiving queue, allowing transactions in TON to be efficiently executed in parallel without worrying about conflict issues.

However, this design also brings some new implications. For DApp developers, their accustomed development paradigms will be disrupted, as follows:

1. Asynchronous Calls Between Smart Contracts: In TON's smart contracts, it is impossible to make atomic calls to external contracts or access external contract data. In Solidity, for example, calling function2 of contract B from function1 of contract A, or accessing certain state data through the read-only function3 of contract C, is an atomic process executed in a single transaction, which is very straightforward. However, in TON, this is not possible. Any interaction with external smart contracts will be executed asynchronously by packaging new transactions, which are referred to as internal messages initiated by the smart contract. During execution, it cannot be blocked to obtain execution results.

For instance, if we develop a DEX and use the common paradigm in EVM, there would typically be a unified router contract to manage transaction routing, while each pool separately manages the LP data related to a specific trading pair. Suppose there are two pools: USDT-DAI and DAI-ETH. When a user wants to purchase ETH directly with USDT, they can sequentially request these two pools through the router contract in a single transaction to complete an atomic transaction. However, in TON, this is not so easily achievable. A new development paradigm must be considered. If the existing paradigm is reused, the information flow might look like this: the request will be accompanied by an external message initiated by the user and three internal messages (note that this is for illustrative purposes; in real development, even the ERC20 paradigm would need to be redesigned).

2. Careful Consideration of Error Handling Processes During Cross-Contract Calls, Designing Corresponding Bounce Functions for Each Contract Call: In mainstream EVMs, when a transaction encounters an issue during execution, the entire transaction will be rolled back to its initial state. This is easy to understand in a serial single-threaded model. However, in TON, since inter-contract calls are executed asynchronously, even if a subsequent step encounters an error, the previously successfully executed transactions have already been confirmed, which could lead to issues. Therefore, TON has set up a special message type called a bounce message. When an error occurs in the subsequent execution process triggered by an internal message, the triggering contract can reset certain states in the triggering contract using the reserved bounce function.

3. In Some Complex Cases, Transactions that Are Received First May Not Be Executed First, So Such Temporal Relationships Cannot Be Preset: In a system with asynchronous and parallel smart contract calls, defining the order of operations can be challenging. This is why every message in TON has its logical time, known as Lamport time (hereinafter referred to as lt). It is used to understand which event triggered another and to verify what validators need to process first. In a simple model, transactions that are received first will definitely be executed first.

In this model, A and B represent two smart contracts, and if msg1lt < msg2lt, then tx1lt < tx2lt holds true.

However, in more complex situations, this rule may be broken. In the official documentation, there is an example where we have three contracts A, B, and C. In a single transaction, A sends two internal messages msg1 and msg2: one to B and the other to C. Although they are created in exact order (first msg1, then msg2), we cannot determine that msg1 will be processed before msg2. This is because the routing from A to B and from A to C may differ in length and validator sets. If these contracts are located on different shard chains, one message may take several blocks to reach the target contract. Thus, we have two possible transaction paths, as shown in the diagram.

4. In TON, the persistent storage of its smart contracts adopts a directed acyclic graph (DAG) structure with Cells as units. Data is compactly compressed into a Cell according to encoding rules and extends downward in a directed acyclic manner. This differs from the hashmap-based structure of state data in EVM. Due to different data request algorithms, TON sets different Gas prices for data processing at different depths. The deeper the Cell, the higher the Gas required for processing. Therefore, in TON, there exists a DOS attack paradigm, where malicious users can send a large number of junk messages to occupy all shallow Cells in a smart contract, meaning that honest users' storage costs will increase. In contrast, in EVM, due to the hashmap's query complexity being O(1), there is a uniform Gas cost, avoiding similar issues. Therefore, TON DApp developers should avoid using unbounded data types in smart contracts. When unbounded data types are present, they should be fragmented through sharding.

5. There are also some features that are less unique, such as smart contracts needing to pay rent for storage, smart contracts being inherently upgradeable in TON, and the native abstract account functionality, meaning all wallet addresses in TON are smart contracts, just not initialized, etc. These require careful attention from developers.

The above are some insights I have gained while studying TON-related technologies during this time. I hope to share them with everyone, and I welcome corrections if there are any mistakes. Meanwhile, I believe that with Telegram's massive traffic resources, the TON ecosystem will undoubtedly bring some new applications to Web3. Anyone interested in TON DApp development can also contact me to discuss together.