Foundations of blockchain
This section covers the core concepts that underlie how transactions work in TON. You'll learn how accounts and smart contracts interact, how messages trigger asynchronous transactions, and how TON’s multi-chain layout records those transactions.
Execution model
Actor
An actor is an abstract behavioral model, formalized as a computational object that reacts to incoming messages, changes its internal state, creates new actors, and sends messages to others. Actors are isolated: they do not have access to each other’s state and interact only through message passing.
In other words:
An actor is an independent entity with its state and behavior. Actors interact by exchanging messages. Each actor can:
- change its state
- send messages to other actors
- spawn new actors
Actor model
The actor model is a model of concurrent computation in which a system is described as a collection of actors that interact through message passing.
Key properties of the model:
- actor isolation
- asynchronous communication
- any computational abstraction can be implemented as an actor
The model is used to precisely describe and analyze distributed systems. For example:
- Email can be modelled as an actor system: users are represented as actors and email addresses serve as actor addresses.
- Web services with endpoints (e.g., SOAP) can be interpreted as actors that handle messages sent to their addresses.
Account
An account in TON is an actor characterized by the following components:
- Account properties — common properties of any account: ID, balance, status, and last transaction (
last_tx
) - Data — user defined data
- Code — custom logic defining the account's behavior
The general state fully defines all account types in TON. Examples:
(ID1, 0 TON, unexist)
(ID2, 10 TON, uninit, last_tx)
(ID3, -0.5 TON, frozen)
Smart contract
A smart contract is an account whose code and data are already deployed to the blockchain in addition to its general state.
Difference between an account and a smart contract
- An account is an actor that has a general state — such as balance, address, and status — and may optionally include code and data.
Example: (ID1, 0 TON, unexist)
or (ID2, 2 TON, inited, last_tx, data, code)
- A smart contract is an actor with deployed code and data that define its specific behavior.
Example: (ID2, 2 TON, inited, data, code)
Entity structure in TON Blockchain
Asynchrony
In TON, contracts or actors do not call each other directly. Instead, they communicate by sending messages, each of which is processed independently of the others. All interaction happens through asynchronous message passing.
Asynchrony is a property of communication, meaning that a message does not need to be processed immediately. This implies the following:
- No immediate response is guaranteed. The receiver may delay responding or may not respond at all.
- The sender does not wait for a reply. After sending a message, an actor continues handling other messages or tasks without blocking or waiting for a response to the previous one—even if that response never arrives.
- Message ordering is preserved. All incoming messages are processed in the order they are received. However, if a message is malformed or incomplete, it is skipped, and the next message is processed without delay.
This is different from synchronous models, where the flow is: call → wait for a response → continue. In TON, a result can only be received as a separate message — and only if it is explicitly sent.
Message feature
A message is a set of instructions intended for a single actor.
Transaction feature
A transaction represents an update to an account's state triggered by an incoming message. It may also produce one or more outgoing messages, depending on the contract logic.
In TON, a transaction is required to update an account's state in response to an incoming message and, if necessary, to continue interacting with other accounts by sending outgoing messages.
Asynchronous transactions
In TON, accounts interact exclusively through messages — this is the core of actor-based communication. Each message triggers a transaction, which records the entire context: the triggering message, state updates, and any generated outbound messages.
Transactions are processed asynchronously, meaning that each account’s updates and message handling occur independently over time.
Data layout
Account structure
Earlier, we mentioned that an account is an actor defined by the following components:
- Account properties (ID, balance, status,
last_tx
) - Data
- Code
In practice, the actual data layout is more complex, but the logical distinction between an account and a smart contract remains the same. To describe data structures, in TON, TL-B schemas are used. These define how data is laid out at the bit level.
Let’s take a look at how an account is defined. The account structure consists of several nested objects:
account_none$0 = Account;
account$1 addr:MsgAddressInt storage_stat:StorageInfo
storage:AccountStorage = Account;