How TON Works and Why It’s More Than Just a Blockchain

You’ve probably already heard about TON — the project by Pavel Durov and the Telegram developers, associated with blockchain, cryptocurrencies, and decentralization. In this article, I’ll explain what to expect and why TON is not just another blockchain.

For a long time, there was little concrete information: Durov made no official announcements, and various sources disagreed on what TON actually was. The first reliable news appeared in February 2018, when Pavel Durov registered the companies TON Issuer and Telegram Group with the U.S. Securities and Exchange Commission (SEC). Through two rounds of closed ICO, the team managed to raise $1.7 billion in investments.

Even though Durov hasn’t made any public statements, work on the project is in full swing. TON’s documentation and code are available to everyone at test.ton.org, and a ton-blockchain organization has appeared on GitHub, publishing the TON Blockchain Software source code.

What is TON?

TON stands for Telegram Open Network. First and foremost, it’s a platform, with TON Blockchain as one of its key components. TON itself is not just a blockchain — it’s more like a decentralized supercomputer built on blockchain technology. TON includes the following components:

• TON Blockchain — the key component, discussed in detail below.
• TON Network — the network layer used for communication. All other system components use TON Network to interact.
• TON DHT — a distributed hash table, similar to Kademlia. This is a crucial part of the platform, used in TON Storage (to find nodes storing specific files), TON Proxy, and other services.
• TON Storage — decentralized file storage, independent of the blockchain. TON Blockchain and TON DHT provide “access” to files, while the files themselves can be stored anywhere. This is similar to how torrents work today.
• TON Proxy — a proxy service. This allows communication through intermediaries willing to provide their nodes, similar to how I2P works.
• TON Services — a platform for services. For example, you can create a “website in TON.”
• TON DNS — more on this later.
• TON Payments — a platform for (micro)payments.

TON Blockchain

This is the core component of TON. It’s not just a blockchain, but a collection of different blockchains:

• Masterchain — the main blockchain, a classic chain of blocks containing system parameters, the state of workchains and their shards (more on these below), hashes of all recent blocks, the number of issued Grams, and other essential information for the system’s operation.
• Workchain — groups shards together. There can be up to 2³² workchains, each with a unique identifier and its own logic. For example, each workchain can have its own virtual machine and address formats. Theoretically, you could create a workchain for processing Ethereum smart contracts. The first workchain, with prefix 0, is reserved for TON’s main workchain.
• Shardchain (or shard) — the main element of scaling. Each workchain can have up to 2⁶⁰ shards. Shards can “communicate” with each other, each is responsible for certain accounts, and follows all the rules of its workchain.
• Accountchain — essentially a ledger for incoming and outgoing messages of a specific account.

This structure was designed to solve two major problems. The first is the ever-growing size of blockchains — for example, Bitcoin’s blockchain exceeded 200 GB in 2019. Most cryptocurrencies require storing and syncing the entire blockchain, which becomes increasingly burdensome as the network grows. The second problem is that making significant infrastructure changes often requires “recreating” the blockchain, i.e., forking it.

TON addresses the first problem with the Infinite Sharding Program. To explain how this works, let’s start with the fact that a workchain is actually a virtual blockchain that unites several shards. The workchain identifier is part of the shard’s identifier, which lets you know which workchain a shard belongs to.

Anyone can create a workchain if they’re willing to pay a high transaction fee in the masterchain and publish the specification and “rules” for the new workchain. However, consensus from two-thirds of current validators is required, since they’ll need to update their software to work with the new workchain’s blocks.

Each shard has an identifier in the form of a tuple: workchain_id and the shard’s own prefix. The prefix determines which accounts (addresses) are included in the shard. For example, if the prefix is 1337, all addresses starting with 1337 will be in that shard. The prefix can change dynamically and range from 0 to 60 bits in length. This allows for merging underloaded shards and splitting overloaded ones.

Accountchain is another virtual blockchain, identified by a tuple: workchain_id and the account’s identifier.

Mining

Instead of the usual hash brute-forcing on GPUs, TON uses a variation of the PoS (Proof-of-Stake) algorithm, which solves the Byzantine Generals Problem (BFT): consensus requires two-thirds of validators.

New blocks are created and verified by validators. Anyone can become a validator if they’re willing to stake a large amount of GRM in the masterchain, confirming their commitment. This “stake” is frozen for at least a month. Currently, to become a validator in the test network, you need 100,000 test GRM.

Validators are randomly distributed among all existing shards. About every 1,024 blocks, validators switch to a different shard. Within a shard, validators select a new block (thanks to BFT). If consensus is reached, a new block is formed, and transaction fees and emissions in that block are distributed among the validators. The same validator can validate multiple shards in parallel.

If a validator selects an “incorrect block,” they can be penalized with part or all of their stake. Validators can also be suspended for a period. When all shards have formed new blocks (or after a timeout, presumably five seconds), a masterchain block is generated containing the hashes of all new shard blocks. This block is formed by consensus of all validators in the system.

Error Correction

Error correction deserves its own section, as it’s a very interesting topic in the blockchain world (think of the DAO and Ethereum Classic) and I was asked about it a lot during my last TON presentation.

Of course, errors shouldn’t happen, since consensus requires two-thirds of validators, but the system includes mechanisms for detecting and correcting “incorrect” blocks. Suppose an “incorrect” block is found and the validators who signed it are punished. But the system still contains the incorrect block — so these measures aren’t enough.

In most other systems, this would require a fork from the last “correct” block. This approach has many drawbacks: it’s hard to implement, you have to convince all participants to switch to the new network after the fork, and there’s the issue of what to do with valid transactions made after the “incorrect” block.

TON Blockchain solves this differently. Each block in a shard (and in the masterchain) is a blockchain by default consisting of a single block. If an “incorrect” block needs to be fixed, this mini-blockchain grows by one more block, which replaces the previous one. This block is also generated by the validators currently working in the shard.

It’s specifically mentioned that blocks in the virtual accountchain won’t be changed if they were correct. The idea is that only “incorrect” transactions will be fixed in the new block, without affecting the correct ones.

Smart Contracts

Smart contracts in TON allow you to write business logic that will be executed in a decentralized way. The contracts are Turing-complete and are meant to be written in the Fift language. Fift is a new programming language created specifically for TON, with some similarities to Forth.

A virtual machine — TON VM (TON Virtual Machine) — was written to execute smart contracts. However, keep in mind that a workchain, along with other defining parameters, can have its own virtual machine and smart contract language. That’s why I won’t focus on Fift and TON VM in this article.

Smart contracts are used everywhere in TON: in TON Storage, TON DNS, and other services. They’re also used for block validation and consensus. As you can see, TON is a very self-sufficient platform and doesn’t depend on external factors. It’s also worth mentioning that every account can formally be a smart contract.

By the way, TON Labs is preparing compilers for other programming languages, so you’ll be able to write smart contracts in more than just Fift. Compilers for C and Solidity are already available at ton.dev.

TON DNS

TON DNS is one of TON’s services. It’s used to convert human-readable identifiers (domain names, addresses) into ADNL addresses and TON Blockchain addresses.

For example, you can use TON DNS to send money to an identifier instead of a wallet address. This makes things much easier, since you can now send funds to a readable address or username. You can also redirect an identifier to a smart contract — for example, to issue an invoice in a store, and after payment, the contract processes the transaction.

TON DNS itself is implemented as several special smart contracts, forming a tree structure. Each contract is responsible for registering subdomains for a specific zone or domain. The root contract, which manages top-level domains in the TON network, is located in the masterchain.

Registering a new domain (identifier) is done by sending a message to the smart contract responsible for the desired subdomain. This costs a certain amount (as do all messages); you specify the key, owner, and registration period. Identifiers are registered on a first-come, first-served basis.

To sum up, TON DNS has a broader application than DNS as we know it. Given the capabilities of TON Blockchain, ADNL, and smart contracts, an identifier can represent anything from a regular wallet to a full-fledged service with business logic.

ADNL

ADNL is TON’s own protocol, used at the lowest level. Its main advantage is that you don’t have to worry about IPv4/IPv6 addresses, ports, etc. — they’re all hidden by an abstract network layer. Data exchange uses 256-bit network addresses (“abstract network addresses”). In simple terms, it’s like SSL over UDP. To receive and decrypt messages for a specific address, you need its private key. To send a message, you need the recipient’s public key in addition to their address.

For most TON components, only ADNL exists, allowing messages to be sent from one address to another. The current white paper says ADNL will be implemented over UDP, with an optional fallback to TCP if UDP is unavailable. The document also mentions RLDP (Reliable Large Datagram Protocol), a higher-level protocol similar to TCP.

Creating a Website in TON

Now that we know about ADNL and TON DNS, let’s talk about how to create a website in TON. Such a site would be hosted in a decentralized way on the TON Network. Services that are fully within the TON Network are called ton-services.

As an example, the white paper describes creating a service that accepts HTTP requests via RLDP. To implement this, you need a regular browser and a proxy server that translates HTTP requests into the TON Network. Communicating via RLDP, the service can respond to requests, and the proxy server returns them to the client in the usual format.

It’s worth mentioning that at this stage, you can use TON DNS for “short” addresses, recreating the familiar order of things. In the future, we might see a TON Browser, similar to the Tor Browser.

Conclusion

As you can see, it’s not easy to describe TON in just a few words. It’s a large and complex system made up of various low-level components, and the TON blockchain is just one of them. But TON is much more than just a blockchain.

We may see the launch of the full network as early as this year. Most likely, some platform components described in this article will become available later than others.

However, you can already try out the client and network on the test node. If you’re interested in this topic and want to experiment, check out the blockchain explorer or even build your own client and node.