I believe that with the massive traffic resources of Telegram, the TON ecosystem will definitely bring some new applications to Web3.

By @Web3Mario

Introduction: With the launch of the largest game in the TON ecosystem, Notcoin, on Binance, and the massive wealth effect caused by the fully circulating token economic model, TON has quickly gained great attention. After chatting with friends, I learned that TON has a relatively high technical threshold, and the DApp development paradigm is quite different from mainstream public chain protocols. Therefore, I spent some time delving into the relevant topics and gained some insights to share with you. In short, the core design concept of TON is to reconstruct traditional blockchain protocols in a "bottom-up" manner and achieve the ultimate pursuit of high concurrency and scalability at the cost of abandoning interoperability.

Core Design Concept of TON - High Concurrency and Scalability

It can be said that all the complex technical choices in TON are derived from the pursuit of high concurrency and scalability, which is understandable from its background. TON, 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 has now been supported and maintained by a global community of independent contributors. Its inception dates back to 2017 when the Telegram team began exploring blockchain solutions for themselves. As there were no existing L1 blockchains capable of supporting Telegram's nine-digit user base at the time, they decided to design their own blockchain, then known as the Telegram Open Network. In 2018, in order to obtain the resources needed to implement TON, Telegram initiated the sale of Gram tokens (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 the Telegram competition took over the TON codebase, renamed the project The Open Network, and continued to actively develop the blockchain, following the principles outlined in the original TON whitepaper.

Since the design goal is to serve as a decentralized execution environment for Telegram, it naturally needs to address two issues: high concurrency requests and massive data. As we know, with the development of technology, even Solana, which claims to have the highest TPS, has a tested maximum TPS of only 65,000, which is clearly insufficient to support the million-level TPS requirements of the Telegram ecosystem. At the same time, with the large-scale application of Telegram, the amount of data it generates has long since skyrocketed. As a highly redundant distributed system, it is not practical for every node in the network to store a complete set of data.

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

• By adopting the "Infinite Sharding Paradigm" design system to solve the data redundancy problem, allowing it to handle big data while alleviating performance bottlenecks;
• By introducing a fully parallel execution environment based on the Actor model, greatly increasing network TPS.

Building a Blockchain - Allowing each account to have 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 and proposed the concept of infinite sharding. The so-called infinite sharding paradigm allows the blockchain to dynamically increase or decrease the number of shards based on network load. This paradigm enables TON to maintain high performance while handling large-scale transactions and smart contract operations. In theory, TON can establish a dedicated account chain for each account and ensure the consistency of these chains through certain rules.

In abstract terms, TON has four layers of chain structure:

• Account Chain: This layer represents a chain composed of a series of transactions related to an account. The reason transactions can form a chain structure is that for a state machine, as long as the execution rules are consistent, the results obtained by the state machine after receiving the same sequence of instructions are consistent. Therefore, all blockchain distributed systems need to chain transactions, and TON is no exception. The account chain is the most basic unit in the TON network, and in most cases, it is a virtual concept, and it is unlikely that there is a truly independent account chain.
• Shard Chain: In most contexts, the shard chain is the actual unit in TON. The so-called shard chain is a collection of account chains.
• Work Chain: Also known as a group of shard chains with custom rules, for example, creating a work chain based on EVM to run Solidity smart contracts. In theory, everyone in the community can create their own work chain. In fact, building it is a rather complex task, and before that, you need to 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, in TON, there is a special chain called the master chain, which is responsible for bringing finality to all shard chains. Once the hash value of a shard chain's block is merged into a block on the master chain, the shard chain block and all its parent blocks are considered to have finality, meaning they can be considered as fixed and immutable content referenced by all subsequent blocks of the shard chain.

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

• Dynamic sharding: TON can automatically split and merge shard chains to adapt to changes in load. This means that new blocks are always generated quickly, and transactions do not result in long waiting times.
• Highly scalable: Through the infinite sharding paradigm, TON can support almost an infinite number of shards, theoretically reaching 2 to the power of 60 work chains.
• Adaptability: When the load in a part of the network increases, 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.

With such a multi-chain system, the first issue to be faced is cross-chain communication, especially because of the ability to have infinite shards. When the number of shards in the network reaches a certain level, the routing of information between chains will become a difficult task. Imagine a network with 4 nodes, each responsible for maintaining an independent work chain. The connection relationship indicates that the node not only needs to be responsible for the transaction sorting work in its own work chain but also needs to listen to and process state changes in the target chain. In TON, this is specifically achieved by listening to the output queue messages.

For example, if account A in work chain 1 wants to send a message to account C in work chain 3, it involves the issue of message routing. 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 facing 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 consisting of 2^n vertices, each uniquely identified by an n-bit binary number. In this structure, any two vertices that differ in only one bit in their binary representation are considered adjacent. For example, in a 3-dimensional hypercube, vertex 000 and vertex 001 are adjacent because they differ only in the last bit. The example mentioned above is a 2-dimensional hypercube.

In the hypercube routing protocol, the routing process from the source work chain to the target work chain is based on 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 different 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 network communication efficiency.

To simplify this process, TON has also proposed an optimistic technical solution. When a user can provide valid proof of a certain routing path, usually in the form of a Merkle trie root, the node 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 the addresses in TON are significantly different from those in other blockchain protocols. Most mainstream blockchain protocols use the hash of the public key generated by elliptic encryption as the address, as the address is only used for uniqueness and does not need to support routing addressing. In TON, the address consists of two parts, (workchainid, accountid), where the workchain_id is encoded according to the hypercube routing algorithm, which will not be detailed here.

There is also a point that may raise questions. You may have noticed that there are links between the master chain and each work chain. Couldn't all cross-chain information be relayed through the master chain, similar to Cosmos? In the design philosophy of TON, the master chain is only used for the most critical task, maintaining the finality of numerous work chains. Routing messages through the master chain is possible, but the resulting transaction fees would be very expensive.

Finally, let's briefly mention its consensus algorithm. TON adopts a BFT+PoS approach, where any staker has the opportunity to participate in block packaging. TON's governance election contract randomly selects a cluster of validators from all stakers at regular intervals, and the selected nodes, called validators, will use the BFT algorithm to package blocks. If they package incorrect information or act maliciously, their staked tokens will be penalized; otherwise, they will receive block rewards. This is a fairly common approach and will not be further elaborated here.

Based on the Actor model of smart contracts and a fully parallel execution environment

Another point where TON differs from mainstream blockchain protocols is its smart contract execution environment. In order to overcome the TPS limitations of mainstream blockchain protocols, TON adopts a bottom-up design approach and uses the Actor model to reconstruct smart contracts and their execution, giving them the ability to execute fully in parallel.

We know that most mainstream blockchain protocols use a single-threaded serial execution environment. For example, in Ethereum, the execution environment EVM is a state machine that takes transactions as input. When the block-producing node completes the sorting of transactions by packaging a block, the transactions are executed in that order through EVM. The entire process is completely serial and single-threaded, meaning only one transaction can be executed at a time. The benefit of this approach is that once the transaction order is confirmed, the execution results are consistent across a widely distributed cluster. At the same time, because only one transaction is executed serially at a time, it is impossible for another transaction to modify state data being accessed by a transaction in progress, thus achieving interoperability between smart contracts. For example, when using Uniswap to purchase ETH with USDT, the distribution of LP in that transaction pair is a deterministic value, allowing for the corresponding result to be derived through certain mathematical models. However, if the situation is different, such as when calculating a bonding curve and another LP adds new liquidity during the calculation, the result will be outdated, which is clearly unacceptable.

However, this architecture also has obvious limitations, namely the bottleneck of TPS, which appears quite outdated on current multi-core processors, similar to using a new PC to play old computer games like Red Alert, where the game still lags when there are a certain number of combat units. This is a problem with the software architecture.

You may have heard that some protocols are already addressing this issue and have proposed their own parallel solutions. Taking Solana, which claims to have the highest TPS, as an example, it also has the ability to execute in parallel. However, its design approach is different from TON. In Solana, the core idea is to divide all transactions into groups based on their execution dependencies, and transactions in different groups do not share any state data. This means that transactions within different groups can be executed in parallel without the risk of conflicts. For transactions within the same group, the traditional serial execution method is still used.

In TON, however, it completely abandons the serial execution architecture and instead adopts a development paradigm specifically designed for parallelism, the Actor model, to reconstruct the execution environment. The Actor model was first proposed by Carl Hewitt in 1973 with the aim of solving the complexity of sharing 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 handling received messages, creating new Actors, sending more messages, and deciding how to respond to the next message. The Actor model has several key features:

• Encapsulation and independence: Each Actor is completely independent when processing messages and can process messages in parallel without interfering with each other.
• Message passing: Actors interact only through sending and receiving messages, and message passing is asynchronous.
• Dynamic structure: Actors can create more Actors at runtime, allowing the system to expand as needed.

TON adopts this architecture to design the smart contract model, which means that in TON, each smart contract is an Actor model with completely independent storage space. Because it does not rely on any external data, calls to the same smart contract are executed according to the order of messages in the receive queue. Therefore, transactions in TON can be efficiently executed in parallel without the need to worry about conflicts.

However, this design approach also brings some new implications. For DApp developers, their accustomed development paradigm will be disrupted in the following ways:

1. Asynchronous calls between smart contracts: In TON, it is not possible to atomically call external contracts or access external contract data within a smart contract. In Solidity, for example, calling function1 of contract A from function2 of contract B, or accessing certain state data through the read-only function3 of contract C, is an atomic process executed within a single transaction. However, in TON, this will not be possible. Any interaction with external smart contracts will be executed asynchronously by packaging new transactions, and such transactions initiated by smart contracts are also known as internal messages. The execution process cannot be blocked to obtain the execution result.

For example, if we develop a DEX, using the common paradigm in EVM, there is usually a unified router contract for managing transaction routing, and each pool separately manages LP data related to a specific trading pair. So, let's assume there are currently two pools: USDT-DAI and DAI-ETH. When a user wants to directly purchase ETH using USDT, they can sequentially request these two pools in a single transaction through the router contract to complete an atomic transaction. However, in TON, it is not so easy to achieve this and requires a new development paradigm. If the same paradigm is reused, the information flow might be as follows: this request will be accompanied by an external message initiated by the user and three internal messages to complete (note that this is used to illustrate the differences, and even the ERC20 paradigm needs to be redesigned in real development).

2. Careful consideration is needed for handling execution errors when making cross-contract calls, and corresponding "bounce" functions should be designed for each contract call. We know that in the mainstream EVM, when a transaction encounters a problem during execution, the entire transaction will be rolled back, i.e., reset to the initial state of execution. This is easily understood in a serial single-threaded model. However, in TON, due to the asynchronous execution of contract calls, even if there is an error later on, because the previously successfully executed transactions have been executed and confirmed, this could potentially cause problems. Therefore, TON has 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 through the bounce function reserved in the triggering contract.

3. In some complex situations, the transaction received first may not necessarily be executed first, so this kind of temporal relationship cannot be predetermined. In an asynchronous and parallel smart contract call system like this, defining the order of operations may be difficult. This is why every message in TON has its logical time, Lamport time (hereinafter referred to as lt). It is used to understand which event triggers another and what validators need to process first. For a simple model, the transaction received first will definitely be executed first.

In this model, A and B represent two smart contracts, so if msg1lt msg2lt, then tx1lt tx2lt represents the temporal relationship.

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

4. In TON, the persistent storage of its smart contracts uses a directed acyclic graph (DAG) with a Cell as the unit of data structure. Data is compactly compressed into a Cell according to the encoding rules, and extends downward in the form of a directed acyclic graph. This is different from the hashmap-based structure of state data in EVM. Due to the different data retrieval algorithms, TON sets different Gas prices for processing data at different depths of the Cell. The deeper the Cell data, the higher the Gas required for processing. Therefore, in TON, there is a paradigm for DOS attacks, where malicious users can occupy all shallow-level Cells in a smart contract by sending a large amount of junk messages, meaning that the storage cost for honest users will increase. In EVM, the hashmap query complexity is o(1), so it has the same Gas and does not have similar problems. Therefore, TON DApp developers should try to avoid unbounded data types in smart contracts. When unbounded data types occur, they should be fragmented through sharding.

5. There are also some features that are not so special, such as smart contracts needing to pay rent for storage. In TON, smart contracts are naturally upgradeable, and there is native abstract account functionality, meaning that all wallet addresses in TON are smart contracts, just uninitialized, etc. These need to be carefully noted by developers.

The above are some insights I have gained from studying TON-related technologies recently, which I would like to share with you. If there are any mistakes, I hope everyone can correct them. At the same time, I believe that with the massive traffic resources of Telegram, the TON ecosystem will definitely bring some new applications to Web3. If there are any friends interested in TON DApp development, please feel free to contact me and discuss with us.

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