TON Blockchain Architecture
TON Blockchain Architecture is a data storage and management system in a blockchain. The architecture includes the organization of data, mechanisms for splitting data between accounts and blocks (sharding), rules for checking and securing transactions (consistency conditions), as well as a masterchain, which manages the main parameters and coordinates the work of shardchains.
Everything is a bag of cells
In TON Blockchain, all data is represented as a collection (bag) of cells. Each cell contains up to 1023 bits of data and up to 4 references to other cells. These cells are organized into trees of cells or directed acyclic graphs (DAGs) of cells, which ensure their structured storage and processing. All data blocks and blockchain states are serialized in cells, representing values in accordance with the TL-B (Type Language — Binary) scheme.
The structure of the cells includes two descriptor bytes, data, and links to other cells, represented by SHA256 hashes. This standard representation of cells is used for their serialization during storage or transmission of data across the network.
Principal components and blockchain states
TON Blockchain employs The Infinite Sharding Paradigm (ISP), where each account is treated as existing in its own separate accountchain. Virtual blocks of these accountchains are grouped into blocks of shardchains for efficiency. The state of a shardchain includes the states of all its accounts, and a shardchain block consists of a collection of virtual blocks for certain accounts.
The shardchain block and its state are divided into two parts: split and non-split. The split parts are associated with specific accounts, while the non-split parts include data such as descriptions of incoming and outgoing messages and the block header.
Components of the non-split part of a shardchain block
- InMsgDescr: descriptions of all incoming messages.
- OutMsgDescr: descriptions of all outgoing messages.
- Block Header: general information, including hashes and parameters of the block.
- OutMsgQueue: a queue of unprocessed messages, which are removed after their inclusion in neighboring shardchains.
The split part of the shardchain's state consists of a hashmap, which corresponds to each «defined» account identifier with the capacity of the corresponding account. The account's state includes a balance in Grams, code of smart-contract, persistent smart-contract data, storage usage statistics, an optional forma interface description, and user public information.
Notice that in TON Blockchain there is no distinction between «smart-contract» and «account».
Masterchain blocks
Blocks and state of the masterchain complement blocks of shardchain and their states. The masterchain does not split and does not merge, usually having one antecessor, except for the «masterchain block zero» at the initial configuration.
Consistency conditions
Important component of the blockchain structure are the consistency conditions between data stored in blocks. These conditions ensure the correctness and security of the blockchain, guaranteeing that data is changed only by authorized methods — as a result of transactions within the blocks.
Types of consistency conditions
- Global conditions — Invariants that operate across the entire blockchain, such as guarantees of message delivery.
- Internal (local) conditions — Conditions applied to data within a transaction, for example, processing incoming messages in transactions.
- External (global) conditions — Conditions concerning data in different blocks, usually pertaining to neighboring shardchains.
Validity conditions for a block
All global and local conditions related to a block constitute its validity conditions. A block is considered valid if it satisfies these conditions. Responsibility for generating and checking the validity of blocks lies with the validators. If a block does not meet validity conditions, it is deemed invalid.
Logical time
Logical time (LT) in TON Blockchain is a non-negative 64-bit integer number designated by certain events. If an event depends on other events, its logical time is greater than that of all events it depends on. For example, if an event does not depend on previous ones, its LT is 0.
TON Blockchain uses logical time and intervals for various components. For example, outgoing messages generated in a transaction receive a logical timestamp. This time depends on previous messages and transactions of the same account. Each transaction is assigned a logical time interval, and blocks, consisting of these transactions and messages, receive their intervals, which are recorded in the block header.
Total blockchain state
Each masterchain block contains a list of all current active shards and the latest blocks for each of them. In this regard, every masterchain block defines the corresponding total state of TON Blockchain, since it fixes the state of every shardchain, and of the masterchain as well.
Each shardchain block contains the hash of the last masterchain block in its header. This implies that all blocks listed in this masterchain block and their predecessors are considered «visible» to the shardchain block. A shardchain block must import messages from the OutMsgQueue states of visible neighboring shardchains and cannot contain messages from «invisible» blocks, even if they are otherwise valid.
Configurable parameters and smart contracts
In TON Blockchain, there exist what are termed configurable parameters, which can be specified values or smart contracts located in the masterchain.
Configurable parameters include:
- The minimum stake for validators.
- The maximum size of the group of elected validators.
- The maximum number of blocks for which the same group of validators are responsible.
- The validator election process.
- The validator punishing process.
- The currently active and the next elected set of validators.
- The process of changing configurable parameters.
These configurable parameters are stored in the persistent data of a special configuration smart contract located in the masterchain. Initial values of a majority of parameters and codes of fundamental smart contracts are present in the genesis block of the masterchain, forming a part of the blockchain's initial state.
New smart contracts and their addresses
Mechanisms for creating new smart contracts and assigning them addresses are described below, are valid only to the basic workchain and masterchain. Other workchains may utilize their own mechanisms for these purposes.
It is possible to send messages, including value-bearing messages, to previously unmentioned accounts. It creates an «uninitialized account» with a balance, without any code or data. The smart contract is created by sending a special construction message to its address. This message contains the initial code and data of the smart contract. The construction message usually also carries some value that will be transferred to the balance of the new smart contract. The minimum balance depends on the amount of storage used.
Smart contracts can automatically create new smart contracts during transaction processing. A user can compile the code for the new smart contract, generate the construction message, and use their smart contract wallet to send this message and create the new smart contract.
Modification and removal of smart contracts
The persistent data of smart contracts typically changes as a result of executing the smart contract's code in TVM during transaction processing. If the smart contract code does not provide for changes to the data, then the data remains unchanged. The actual code of the smart contract can only be changed if the current code allows for such modifications.
A smart contract cannot be destroyed unless its balance becomes zero or negative. This could happen due to storage fees or after sending an outgoing message that transfers almost all the funds. For example, a user can transfer all funds to another wallet or smart contract for updates.
When the account balance becomes negative or less than a certain minimum, the account is frozen, replacing its code and data with a 32-byte hash. This hash is retained for some time to allow the owner to restore the account by transferring funds and sending a message with the code and data.