Skip to main content

Blockchain of blockchains

tip

Terms 'smart contract', 'account', and 'actor' are used interchangeably in this document to describe a blockchain entity.

Single actor​

Let's consider one smart contract.

In TON, it is a thing with properties like address, code, data, balance and others. In other words, it is an object with some storage and behavior. That behavior has the following pattern:

  • contract receives a message
  • contract handles that event according to its properties by executing its code in TON Virtual Machine
  • contract modifies its properties consisting of code, data, and others
  • contract optionally generates outgoing messages
  • contract goes into standby mode until the next event occurs

A combination of these steps is called a transaction. Since it is essential to handle events one by one, transactions follow a strict order and cannot interrupt each other.

This behavior pattern is well known and called actor.

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 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 and stored in one node, so we just split that chain into two smaller ShardChains with each chain accounting for half a million accounts and each chain processed on a separate subset of nodes.

Analogously, if some shards become too unoccupied, 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. The delivery of all messages
  2. The delivery of messages from a specific account A to another specific account B happens in the same order as they were sent. However, if there are multiple accounts 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 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 MasterChain is used for that purpose. Blocks of MasterChain contain additional information, like the latest block hashes, about all other chains in the system, thus any observer unambiguously determines the state of all multichain systems at a single MasterChain block.

See also​

Was this article useful?