Skip to main content

Blockchain of blockchains

tip

In this document, the terms smart contract, account, and actor are used interchangeably for simplicity. Technically, an account in TON is an actor, and a smart contract is an account with deployed code and data.

Single actor​

In TON, a smart contract is a computational entity with properties such as address, code, data, and balance. In other words, it is an object with persistent storage and defined behavior.

That behavior follows this pattern:

  • the contract receives a message
  • it handles the event according to its properties, possibly executing its code in the TON Virtual Machine
  • it may update its state, including code, data, and balance
  • it may generate outgoing messages
  • it becomes idle until the next message arrives

Successfully processing a message through these steps results in a transaction. Since accounts handle messages one at a time, messages are processed in strict order, producing transactions without overlap or interruption.

This behavior follows the actor model, where each contract is an independent entity reacting to messages.

The lowest level: AccountChain​

A chain can be viewed as a sequence of transactions, such as Tx1 → Tx2 → Tx3 → …. When this transaction sequence pertains to a single account, it is specifically termed an AccountChain.

Since nodes processing these transactions periodically need to synchronize the smart contract state to achieve consensus, transactions are grouped into batches called blocks. For instance:

[Tx1 → Tx2] → [Tx3 → Tx4 → Tx5] → [] → [Tx6]

Batching does not alter the underlying sequence. Each transaction still references exactly one preceding transaction (prev tx) and at most one succeeding transaction (next tx). Batching simply organizes this sequence into manageable blocks for consensus purposes.

Additionally, each block can contain queues of incoming and outgoing messages. Incorporating these queues ensures that a block fully encapsulates all events and state changes relevant to the smart contract within the block period.

Many AccountChains: Shards​

Now let's consider many accounts. We can get a few AccountChains and store them together; such a set of AccountChains is called a ShardChain. In the same way, we can cut a ShardChain into ShardBlocks, which are an aggregation of individual AccountBlocks.

Dynamic splitting and merging of ShardChains​

Note that since a ShardChain consists of easily distinguished AccountChains, we can easily split it. That way, if we have one ShardChain that describes events that happen with one million accounts and there are too many transactions per second to be processed by a single node, we split that chain into two smaller ShardChains, with each chain accounting for half a million accounts and each processed on a separate subset of nodes.

Analogously, if some shards become underutilized, they can be merged into one shard.

There are two limiting cases: when the shard already has 2^256/2^60 accounts (TON Blockchain does not support further sharding) and when the shard contains all accounts.

Accounts can interact with each other by sending messages. A unique routing mechanism moves messages from outgoing queues to corresponding incoming queues and ensures:

  1. All messages are delivered.
  2. Messages from a specific account A to a specific account B are delivered in the same order they were sent. However, if multiple accounts are involved, the order of message delivery is not guaranteed.
SIDE NOTE

An aggregation of AccountChains into shards is based on the bit-representation of account addresses to make splitting and merging deterministic. For example, an address looks like (shard prefix, address). That way, all accounts in the ShardChain will have the same binary prefix (for instance, all addresses will start with 0b00101).

WorkChain​

An aggregation of all shards, which contains all accounts that behave according to one set of rules, is called a WorkChain.

In TON, there can be many sets of rules, and thus, many WorkChains operate simultaneously and can interact with each other by sending messages cross-chain in the same way that accounts of one chain can interact with each other.

WorkChain: a blockchain with your own rules​

If you want to customize the rules of the ShardChains group, you could create a WorkChain. For example, it's theoretically possible to create a WorkChain that supports EVM to run Solidity smart contracts, but this would be a complex undertaking due to the differences between TVM and EVM.

Theoretically, anyone in the community can propose their own WorkChain. However, building one is a complex task. Furthermore, it requires a significant fee and must be approved by a 2/3 vote from the validators.

TON allows creating up to 2^32 WorkChains, subdivided into 2^60 shards.

Nowadays, there are only two WorkChains in TON: MasterChain and BaseChain.

BaseChain is used for everyday transactions between actors because it's cheap, while MasterChain has a crucial function for TON.

MasterChain​

There is a necessity for the synchronization of message routing and transaction execution. In other words, nodes in the network need a way to fix some 'point' in a multichain state and reach a consensus about that state. In TON, a special chain called the MasterChain is used for that purpose. Blocks of the MasterChain contain additional information—such as the latest block hashes—about all other chains in the system, so any observer can unambiguously determine the state of the multichain system at a single MasterChain block.

See also​

Was this article useful?