The Open Network

participate in this activity (if they agree to keep their stake frozen instead
of withdrawing it after having lost the election). Such would-be validators
might double as shermen (cf. 2.6.4): if they have to check the validity of
certain blocks anyway, they might as well opt to report invalid blocks and
collect the associated rewards.
2.6.28. Recursive reliability of a block. One can also dene the recursive
reliability of a block to be the minimum of its relative reliability and the
recursive reliabilities of all blocks it refers to (i.e., the masterchain block, the
previous shardchain block, and some blocks of neighboring shardchains). In
other words, if the block turns out to be invalid, either because it is invalid by
itself or because one of the blocks it depends on is invalid, then at least this
amount of money would be lost by someone. If one is truly unsure whether
to trust a specic transaction in a block, one should compute the recursive
reliability of this block, not just the relative one.
It does not make sense to go too far back when computing recursive
reliability, because, if we look too far back, we will see blocks signed by
validators whose stakes have already been unfrozen and withdrawn. In any
case, we do not allow the validators to automatically reconsider blocks that
are that old (i.e., created more than two months ago, if current values of
congurable parameters are used), and create forks starting from them or
correct them with the aid of vertical blockchains (cf. 2.1.17), even if they
turn out to be invalid. We assume that a period of two months provides
ample opportunities for detecting and reporting any invalid blocks, so that
if a block is not challenged during this period, it is unlikely to be challenged
at all.
56

---

2.7. Splitting and Merging Shardchains
2.6.29. Consequence of Proof-of-Stake for light nodes. An important
consequence of the Proof-of-Stake approach used by the TON Blockchain is
that a light node (running light client software) for the TON Blockchain does
not need to download the headers of all shardchain or even masterchain
blocks in order to be able to check by itself the validity of Merkle proofs
provided to it by full nodes as answers to its queries.
Indeed, because the most recent shardchain block hashes are included in
the masterchain blocks, a full node can easily provide a Merkle proof that a
given shardchain block is valid starting from a known hash of a masterchain
block. Next, the light node needs to know only the very rst block of the
masterchain (where the very rst set of validators is announced), which (or
at least the hash of which) might be built-in into the client software, and
only one masterchain block approximately every month afterwards, where
newly-elected validator sets are announced, because this block will have been
signed by the previous set of validators. Starting from that, it can obtain the
several most recent masterchain blocks, or at least their headers and validator
signatures, and use them as a base for checking Merkle proofs provided by
full nodes.
2.7 Splitting and Merging Shardchains
One of the most characteristic and unique features of the TON Blockchain is
its ability to automatically split a shardchain in two when the load becomes
too high, and merge them back if the load subsides (cf. 2.1.10). We must
discuss it in some detail because of its uniqueness and its importance to the
scalability of the whole project.
2.7.1. Shard conguration. Recall that, at any given moment of time,
each workchain w is split into one or several shardchains (w, s) (cf. 2.1.8).
These shardchains may be represented by leaves of a binary tree, with root
(w, ∅)
, and each non-leaf node (w, s) having children (w, s.0) and (w, s.1).
In this way, every account belonging to workchain w is assigned to exactly
one shard, and everybody who knows the current shardchain conguration
can determine the shard (w, s) containing account account_id: it is the only
shard with binary string s being a prex of account_id.
The shard congurationi.e., this shard binary tree, or the collection
of all active (w, s) for a given w (corresponding to the leaves of the shard
binary tree)is part of the masterchain state and is available to everybody
57

---

2.7. Splitting and Merging Shardchains
who keeps track of the masterchain.
22
2.7.2. Most recent shard conguration and state. Recall that hashes
of the most recent shardchain blocks are included in each masterchain block.
These hashes are organized in a shard binary tree (actually, a collection of
trees, one for each workchain). In this way, each masterchain block contains
the most recent shard conguration.
2.7.3. Announcing and performing changes in the shard congura-
tion. The shard conguration may be changed in two ways: either a shard
(w, s)
can be split into two shards (w, s.0) and (w, s.1), or two sibling shards
(w, s.0)
and (w, s.1) can be merged into one shard (w, s).
These split/merge operations are announced several (e.g., 2
6
; this is a
congurable parameter) blocks in advance, rst in the headers of the cor-
responding shardchain blocks, and then in the masterchain block that refers
to these shardchain blocks. This advance announcement is needed for all