TON Blockchain main features

## TON Blockchain as a Collection of 2-Blockchains

The TON Blockchain is actually a *collection* of blockchains (even a collection of *blockchains of blockchains*, or *2-blockchains*), because no single blockchain project is capable of achieving the goal of processing millions of transactions per second, as opposed to the now-standard dozens of transactions per second.

### List of blockchain types

The blockchains in this collection are:

* The unique *master blockchain*, or *masterchain* for short, containing general information about the protocol and the current values of its parameters, the set of validators and their stakes, the set of currently active workchains and their "shards", and, most importantly, the set of hashes of the most recent blocks of all workchains and shardchains.
* Several (up to 232) *working blockchains*, or *workchains* for short, which are actually the "workhorses", containing the value-transfer and smart-contract transactions. Different workchains may have different "rules", meaning different formats of account addresses, different formats of transactions, different virtual machines (VMs) for smart contracts, different basic cryptocurrencies and so on. However, they all must satisfy certain basic interoperability criteria to make interaction between different workchains possible and relatively simple. In this respect, the TON Blockchain is *heterogeneous*.
* Each workchain is in turn subdivided into up to 260 *shard blockchains*, or *shardchains* for short, having the same rules and block format as the workchain itself, but responsible only for a subset of accounts, depending on several first (most significant) bits of the account address. In other words, a form of sharding is built into the system. Because all these shardchains share a common block format and rules, the TON Blockchain is *homogeneous* in this respect.
* Each block in a shardchain (and in the masterchain) is actually not just a block, but a small blockchain. Normally, this "block blockchain" or "vertical blockchain" consists of exactly one block, and then we might think this is just the corresponding block of the shardchain (also called "horizontal blockchain" in this situation). However, if it becomes necessary to fix incorrect shardchain blocks, a new block is committed into the "vertical blockchain", containing either the replacement for the invalid "horizontal blockchain" block, or a "block difference", containing only a description of those parts of the previous version of this block that need to be changed. This is a TON-specific mechanism to replace detected invalid blocks without making a true fork of all shardchains involved. Each shardchain (and the masterchain) is not a conventional blockchain, but a *blockchain of blockchains*, or *2D-blockchain*, or just a *2-blockchain*.

### Infinite Sharding Paradigm

Almost all blockchain sharding proposals are "top-down": one first imagines a single blockchain, and then discusses how to split it into several interacting shardchains to improve performance and achieve scalability.

The TON approach to sharding is "bottom-up", explained as follows.

Imagine that sharding has been taken to its extreme, so that exactly one account or smart contract remains in each shardchain. Then we have a huge number of "account-chains", each describing the state and state transitions of only one account, and sending value-bearing messages to each other to transfer value and information.

Of course, it is impractical to have hundreds of millions of blockchains, with updates (i.e., new blocks) usually appearing quite rarely in each of them. In order to implement them more efficiently, we group these "account-chains" into "shardchains", so that each block of the shardchain is essentially a collection of blocks of account-chains that have been assigned to this shard. Thus the "account-chains" have only a purely virtual or logical existence inside the "shardchains".

This perspective is called the *Infinite Sharding Paradigm*. It explains many of the design decisions for the TON Blockchain.

### Instant Hypercube Routing

The Infinite Sharding Paradigm instructs us to regard each account (or smart contract) as if it were in its own shardchain by itself. Then the only way one account might affect the state of another is by sending a *message* to it. Therefore, a system of messages between accounts (and shardchains, because the source and destination accounts are, generally speaking, located in different shardchains) is of paramount importance to a scalable system such as the TON Blockchain. In fact, a novel feature of the TON Blockchain, called *Instant Hypercube Routing*, enables it to deliver and process a message created in a block of one shardchain into the very next block of the destination shardchain, *regardless of the total number of shardchains in the system*.

### Dynamic splitting and merging of shardchains

An important feature of the TON Blockchain is that it implements *dynamic sharding*, meaning that the number of shards is not fixed. Instead, shard can be automatically subdivided into two shards if some formal conditions are met (essentially, if the transaction load on the original shard is high enough for a prolonged period of time). Conversely, if the load stays too low for some period of time, the two shards can be automatically merged back into one shard.

Initially, only one shard is created for workchain. Later, it is subdivided into more shards, if and when this becomes necessary.

### Using the masterchain to make workchains and shardchains tightly coupled

Once the hash of a block of a shardchain is incorporated into a block of the masterchain, that shardchain block and all its ancestors are considered "canonical", meaning that they can be referenced from the subsequent blocks of all shardchains as something fixed and immutable. In fact, each new shardchain block contains a hash of the most recent masterchain block, and all shardchain blocks referenced from that masterchain block are considered immutable by the new block.

Essentially, this means that a transaction or a message committed in a shardchain block may be safely used in the very next blocks of the other shardchains, without needing to wait for, say, twenty confirmations (i.e., twenty blocks generated after the original block in the same blockchain) before forwarding a message or taking other actions based on a previous transaction, as is common in most proposed "loosely-coupled" systems, such as EOS.

### Proof-of-Stake approach for generating new blocks

The TON Blockchain uses a Proof-of-Stake (PoS) approach for generating new blocks in the shardchains and the masterchain. This means that there is a set of, say, up to a few hundred *validators* — special nodes that have deposited *stakes* (large amounts of TON coins) by a special masterchain transaction to be eligible for new block generation and validation.

Then a smaller subset of validators is assigned to each shard in a deterministic pseudorandom way, changing approximately every 1024 blocks. This subset of validators suggests and reaches consensus on what the next shardchain block would be, by collecting suitable proposed transactions from the clients into new valid block candidates. For each block, there is a pseudo-randomly chosen order on the validators to determine whose block candidate has the highest priority to be committed at each turn.

Validators and other nodes check the validity of the proposed block candidates; if a validator signs an invalid block candidate, it may be automatically punished by losing part or all of its stake, or by being suspended from the set of validators for some time. After that, the validators should reach consensus on the choice of the next block, essentially by an efficient variant of the BFT (Byzantine Fault Tolerant) consensus protocol, similar to PBFT or Honey Badger BFT. If consensus is reached, a new block is created, and validators divide between themselves the transaction fees for the transactions included, plus some newly-created ("minted") coins.

Each validator can be elected to participate in several validator subsets; in this case, it is expected to run all validation and consensus algorithms in parallel.

After all new shardchain blocks are generated or a timeout is passed, a new masterchain block is generated, including the hashes of the latest blocks of all shardchains. This is done by BFT consensus of *all* validators (Actually, two-thirds by stake is enough to achieve consensus, but an effort is made to collect as many signatures as possible).

### Correcting invalid shardchain blocks

Normally, only valid shardchain blocks will be committed, because validators assigned to the shardchain must reach a two-thirds Byzantine consensus before a new block can be committed. However, the system must allow for detection of previously committed invalid blocks and their correction.

Of course, once an invalid shardchain block is found — either by a validator (not necessarily assigned to this shardchain) or by a "fisherman" (any node of the system that made a certain deposit to be able to raise questions about block validity) — the invalidity claim and its proof are committed into the masterchain, and the validators that have signed the invalid block are punished by losing part of their stake and/or being temporarily suspended from the set of validators (the latter measure is important for the case of an attacker stealing the private signing keys of an otherwise benign validator).

However, this is not sufficient, because the overall state of the system (TON Blockchain) turns out to be invalid because of the invalid shardchain block previously committed. This invalid block must be replaced by a newer valid version.

Most systems would achieve this by "rolling back" to the last block before the invalid one in this shardchain and the last blocks unaffected by messages propagated from the invalid block in each of the other shardchains, and creating a new fork from these blocks. This approach has the disadvantage that a large number of otherwise correct and committed transactions are suddenly rolled back, and it is unclear whether they will be included later at all.

The TON Blockchain solves this problem by making each "block" of each shardchain and of the masterchain ("horizontal blockchains") a small blockchain ("vertical blockchain") by itself, containing different versions of this "block", or their "differences". Normally, the vertical blockchain consists of exactly one block, and the shardchain looks like a classical blockchain. However, once the invalidity of a block is confirmed and committed into a masterchain block, the "vertical blockchain" of the invalid block is allowed to grow by a new block in the vertical direction, replacing or editing the invalid block. The new block is generated by the current validator subset for the shardchain in question.

The rules for a new "vertical" block to be valid are quite strict. In particular, if a virtual "account-chain block" contained in the invalid block is valid by itself, it must be left unchanged by the new vertical block.

Once a new "vertical" block is committed on top of the invalid block, its hash is published in a new masterchain block (or rather in a new "vertical" block, lying above the original masterchain block where the hash of the invalid shardchain block was originally published), and the changes are propagated further to any shardchain blocks referring to the previous version of this block (e.g., those having received messages from the incorrect block). This is fixed by committing new "vertical" blocks in vertical blockchains for all blocks previously referring to the "incorrect" block; new vertical blocks will refer to the most recent (corrected) versions instead. Again, strict rules forbid changing account-chains that are not really affected (i.e., that receive the same messages as in the previous version). In this way, fixing an incorrect block generates "ripples" that are ultimately propagated towards the most recent blocks of all affected shardchains; these changes are reflected in new "vertical" masterchain blocks as well.

Once the "history rewriting" ripples reach the most recent blocks, the new shardchain blocks are generated in one version only, being successors of the newest block versions only. This means that they will contain references to the correct (most recent) vertical blocks from the very beginning.

The masterchain state implicitly defines a map transforming the hash of the first block of each "vertical" blockchain into the hash of its latest version. This enables a client to identify and locate any vertical blockchain by the hash of its very first (and usually the only) block.

### TON coins and multi-currency workchains

The TON Blockchain supports up to 232 different "cryptocurrencies", "coins", or "tokens". New cryptocurrencies can be added by special transactions in the masterchain. Each workchain has a basic cryptocurrency, and can have several additional cryptocurrencies.

There is one special cryptocurrency with *currency\_id* = 0, namely, the *TON coin*, also known as the *Crystal*. It is the basic cryptocurrency of Workchain Zero. It is also used for transaction fees and validator stakes.

In principle, other workchains may collect transaction fees in other tokens. In this case, some smart contract for automated conversion of these transaction fees into Crystals should be provided.

### TON Virtual Machine

The *TON Virtual Machine*, also abbreviated as *TON VM* or *TVM*, is the virtual machine used to execute smart-contract code in the masterchain and in the basic workchain. Other workchains may use other virtual machines alongside or instead of the TVM.

Here we list some of its features:

* TVM represents all data as a collection of *(TVM) cells*. Each cell contains up to 128 data bytes and up to 4 references to other cells. As a consequence of the "everything is a bag of cells" philosophy, this enables TVM to work with all data related to the TON Blockchain, including blocks and blockchain global state if necessary.
* TVM can work with values of arbitrary algebraic data types, represented as trees or directed acyclic graphs of TVM cells. However, it is agnostic towards the existence of algebraic data types; it just works with cells.
* TVM has built-in support for hashmaps.
* TVM is a stack machine. Its stack keeps either 64-bit integers or cell references.
* 64-bit, 128-bit and 256-bit arithmetic is supported. All *n*-bit arithmetic operations come in three flavors: for unsigned integers, for signed integers and for integers modulo 2n (no automatic overflow checks in the latter case).
* TVM has unsigned and signed integer conversion from *n*-bit to *m*-bit, for all 0≤*m*, *n*≤256, with overflow checks.
* All arithmetic operations perform overflow checks by default, greatly simplifying the development of smart contracts.
* TVM has "multiply-then-shift" and "shift-then-divide" arithmetic operations with intermediate values computed in a larger integer type; this simplifies implementing fixed-point arithmetic.
* TVM offers support for bit strings and byte strings.
* Support for 256-bit Elliptic Curve Cryptography (ECC) for some predefined curves, including Curve25519, is present.
* Support for Weil pairings on some elliptic curves, useful for fast implementation of zk-SNARKs, is also present.
* Support for popular hash functions, including `sha256`, is present.
* TVM can work with Merkle proofs.
* TVM offers support for "large" or "global" smart contracts. Such smart contracts must be aware of sharding. Usual (local) smart contracts can be sharding-agnostic.
* TVM supports closures.
* A "spineless tagless *G*-machine" can be easily implemented inside TVM.

Several high-level languages can be designed for TVM, in addition to the "TVM assembly". All these languages will have static types and will support algebraic data types. We envision the following possibilities:

* A Java-like imperative language, with each smart contract resembling a separate class.
* A lazy functional language (think of Haskell).
* An eager functional language (think of ML).

### Configurable parameters

An important feature of the TON Blockchain is that many of its parameters are *configurable*. This means that they are part of the masterchain state, and can be changed by certain special proposal/vote/result transactions in the masterchain, without any need for hard forks. Changing such parameters will require collecting two-thirds of validator votes and more than half of the votes of all other participants who would care to take part in the voting process in favor of the proposal.

## Creating and Validating New Blocks

The TON Blockchain ultimately consists of shardchain and masterchain blocks. These blocks must be created, validated and propagated through the network to all parties concerned, in order for the system to function smoothly and correctly.

### Validators

New blocks are created and validated by special designated nodes, called *validators*. Essentially, any node wishing to become a validator may become one, provided it can deposit a sufficiently large stake (in TON coins, i.e., Crystals) into the masterchain. Validators obtain some "rewards" for good work, namely, the transaction, storage and gas fees from all transactions (messages) committed into newly generated blocks, and some newly minted coins, reflecting the "gratitude" of the whole community to the validators for keeping the TON Blockchain working. This income is distributed among all participating validators proportionally to their stakes.

However, being a validator is a high responsibility. If a validator signs an invalid block, it can be punished by losing part or all of its stake, and by being temporarily or permanently excluded from the set of validators. If a validator does not participate in creating a block, it does not receive its share of the reward associated with that block. If a validator abstains from creating new blocks for a long time, it may lose part of its stake and be suspended or permanently excluded from the set of validators.

All this means that the validator does not get its money "for nothing". Indeed, it must keep track of the states of all or some shardchains (each validator is responsible for validating and creating new blocks in a certain subset of shardchains), perform all computations requested by smart contracts in these shardchains, receive updates about other shardchains and so on. This activity requires considerable disk space, computing power and network bandwidth.

### Validators instead of miners

Recall that the TON Blockchain uses the Proof-of-Stake approach, instead of the Proof-of-Work approach adopted by Bitcoin, the current version of Ethereum, and most other cryptocurrencies. This means that one cannot "mine" a new block by presenting some proof-of-work (computing a lot of otherwise useless hashes) and obtain some new coins as a result. Instead, one must become a validator and spend one’s computing resources to store and process TON Blockchain requests and data. *In short, one must be a validator to mine new coins*. In this respect, *validators are the new miners*.

However, there are some other ways to earn coins apart from being a validator.

### Nominators and "mining pools"

To become a validator, one would normally need to buy and install several high-performance servers and acquire a good Internet connection for them. This is not so expensive as the ASIC equipment currently required to mine Bitcoins. However, one definitely cannot mine new TON coins on a home computer, let alone a smartphone.

In the Bitcoin, Ethereum and other Proof-of-Work cryptocurrency mining communities there is a notion of mining pools, where a lot of nodes, having insufficient computing power to mine new blocks by themselves, combine their efforts and share the reward afterwards.

A corresponding notion in the Proof-of-Stake world is that of a nominator. Essentially, this is a node lending its money to help a validator increase its stake; the validator then distributes the corresponding share of its reward (or some previously agreed fraction of it — say, 50%) to the nominator.

In this way, a nominator can also take part in the "mining" and obtain some reward proportional to the amount of money it is willing to deposit for this purpose. It receives only a fraction of the corresponding share of the validator's reward, because it provides only the "capital", but does not need to buy computing power, storage and network bandwidth.

However, if the validator loses its stake because of invalid behavior, the nominator loses its share of the stake as well. In this sense the nominator shares the risk. It must choose its nominated validator wisely, otherwise it can lose money. In this sense, nominators make a weighted decision and "vote" for certain validators with their funds.

On the other hand, this nominating or lending system enables one to become a validator without investing a large amount of money into Crystals (TON coins) first. In other words, it prevents those keeping large amounts of Crystals from monopolizing the supply of validators.

### Fishermen: obtaining money by pointing out others' mistakes

Another way to obtain some rewards without being a validator is by becoming a *fisherman*. Essentially, any node can become a fisherman by making a small deposit in the masterchain. Then it can use special masterchain transactions to publish (Merkle) invalidity proofs of some (usually shardchain) blocks previously signed and published by validators. If other validators agree with this invalidity proof, the offending validators are punished (by losing part of their stake), and the fisherman obtains some reward (a fraction of coins confiscated from the offending validators). Afterwards, the invalid (shardchain) block must be corrected. Correcting invalid masterchain blocks may involve creating "vertical" blocks on top of previously committed masterchain blocks; there is no need to create a fork of the masterchain.

Normally, a fisherman would need to become a full node for at least some shardchains, and spend some computing resources by running the code of at least some smart contracts. While a fisherman does not need to have as much computing power as a validator, we think that a natural candidate to become a fisherman is a would-be validator that is ready to process new blocks, but has not yet been elected as a validator (e.g., because of a failure to deposit a sufficiently large stake).

### Collators: obtaining money by suggesting new blocks to validators

Yet another way to obtain some rewards without being a validator is by becoming a *collator*. This is a node that prepares and suggests to a validator new shardchain block candidates, complemented (collated) with data taken from the state of this shardchain and from other (usually neighboring) shardchains, along with suitable Merkle proofs. (This is necessary, for example, when some messages need to be forwarded from neighboring shardchains.) Then a validator can easily check the proposed block candidate for validity, without having to download the complete state of this or other shardchains.

Because a validator needs to submit new (collated) block candidates to obtain some ("mining") rewards, it makes sense to pay some part of the reward to a collator willing to provide suitable block candidates. In this way, a validator may free itself from the necessity of watching the state of the neighboring shardchains, by outsourcing it to a collator.

However, we expect that during the system's initial deployment phase there will be no separate designated collators, because all validators will be able to act as collators for themselves.

### The total number of validators

The upper limit *T* for the total number of validators to be elected cannot become, in the system described so far, more than, say, several hundred or a thousand, because all validators are expected to participate in a BFT consensus protocol to create each new masterchain block, and it is not clear whether such protocols can scale to thousands of participants. Even more importantly, masterchain blocks must collect the signatures of at least two-thirds of all the validators (by stake), and these signatures must be included in the new block (otherwise all other nodes in the system would have no reason to trust the new block without validating it by themselves). If more than, say, one thousand validator signatures would have to be included in each masterchain block, this would imply more data in each masterchain block, to be stored by all full nodes and propagated through the network, and more processing power spent to check these signatures (in a PoS system, full nodes do not need to validate blocks by themselves, but they need to check the validators' signatures instead).

While limiting *T* to a thousand validators seems more than sufficient for the first phase of the deployment of the TON Blockchain, a provision must be made for future growth, when the total number of shardchains becomes so large that several hundred validators will not suffice to process all of them. To this end, we introduce an additional configurable parameter *T′≤T* (originally equal to *T*), and only the top *T′* elected validators (by stake) are expected to create and sign new masterchain blocks.

### Decentralization of the system

One might suspect that a Proof-of-Stake system such as the TON Blockchain, relying on *T*≈1000 validators to create all shardchain and masterchain blocks, is bound to become "too centralized", as opposed to conventional Proof-of-Work blockchains like Bitcoin or Ethereum, where everybody (in principle) might mine a new block, without an explicit upper limit on the total number of miners.

However, popular Proof-of-Work blockchains, such as Bitcoin and Ethereum, currently require vast amounts of computing power (high "hash rates") to mine new blocks with non-negligible probability of success. Thus, the mining of new blocks tends to be concentrated in the hands of several large players, who invest huge amounts of money into datacenters filled with custom-designed hardware optimized for mining; and in the hands of several large mining pools, which concentrate and coordinate the efforts of larger groups of people who are not able to provide a sufficient "hash rate" by themselves.

Therefore, as of 2017, more than 75% of new Ethereum or Bitcoin blocks are produced by less than ten miners. In fact, the two largest Ethereum mining pools produce together more than half of all new blocks! Clearly, such a system is much more centralized than one relying on *T*≈1000 nodes to produce new blocks.

One might also note that the investment required to become a TON Blockchain validator — i.e., to buy the hardware (say, several high-performance servers) and the stake (which can be easily collected through a pool of nominators if necessary) — is much lower than that required to become a successful stand-alone Bitcoin or Ethereum miner. In fact, the parameter *L* will force nominators not to join the largest "mining pool" (i.e., the validator that has amassed the largest stake), but rather to look for smaller validators currently accepting funds from nominators, or even to create new validators, because this would allow a higher proportion *s′i/si* of the validator's — and by extension also the nominator's — stake to be used, hence yielding larger rewards from mining. In this way, the TON Proof-of-Stake system actually *encourages* decentralization (creating and using more validators) and *punishes* centralization.

az:TON Blok zəncirinin əsas xüsusiyyətləri
be:Асноўныя асаблівасці блокчэйна TON
bg:Основни особености на TON блокчейн
cs:Hlavní vlastnosti blockchainu TON
de:Hauptmerkmale der TON Blockchain
el:Κύρια χαρακτηριστικά του blockchain TON
es:Características principales
fa:ویژگی­ های اصلی بلاک چین TON
fr:Particularités principales de la blockchain TON
hu:A TON blockchain alapvető tulajdonságai
id:Fitur Utama Blockchain TON
it:Le caratteristiche principali di Free TON Blockchain
pt:Particularidades principais de blockchain TON
ru:Основные\_особенности\_блокчейна\_TON
tr:TON blok zincirinin ana özellikleri
uk:Основні особливості блокчейну TON