Skip to content

Update blockchain-of-blockchains.md #991

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
May 13, 2025
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -23,13 +23,18 @@ This behavior pattern is well known and called **actor**.

### The lowest level: AccountChain

A sequence of transactions `Tx1 -> Tx2 -> Tx3 -> ....` may be called a **chain**. When considering a single account, we call the chain of transactions an **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**.

Now, since nodes that process transactions need from time to time to coordinate the state of the smart contract to reach a consensus about the state, those transactions are batched:
`[Tx1 -> Tx2] -> [Tx3 -> Tx4 -> Tx5] -> [] -> [Tx6]`.
Batching does not intervene in sequencing; each transaction still has only one 'prev tx' and at most one 'next tx', but now this sequence is cut into the blocks.
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.

It is also expedient to include queues of incoming and outgoing messages in blocks. In that case, the block will contain a full set of information that determines and describes what happened to the smart contract during that block.

## Many AccountChains: Shards

Expand Down Expand Up @@ -76,4 +81,4 @@ BaseChain is used for everyday transactions between actors because it's cheap, w
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
- [Smart contract addresses](/v3/concepts/dive-into-ton/ton-blockchain/smart-contract-addresses/)
- [Smart contract addresses](/v3/concepts/dive-into-ton/ton-blockchain/smart-contract-addresses/)
Loading