The Open Network

part of the block reward will still be given to them (cf. 2.6.20).
2.6.22. Validators are responsible for relative validity of signed
shardchain blocks; absolute validity follows. We would like to empha-
size once again that a validator's signature on a shardchain block B testies
to only the relative validity of that block (or maybe of d previous blocks
as well, if the signature has depth d, cf. 2.6.21; but this does not aect
the following discussion much). In other words, the validator asserts that
the next state s
0
of the shardchain is obtained from the previous state s by
applying the block evaluation function ev_block described in 2.2.6:
s
0
=
ev_block(B)(s)
(24)
In this way, the validator that signed block B cannot be punished if the
original state s turns out to be incorrect (e.g., because of the invalidity of
one of the previous blocks). A sherman (cf. 2.6.4) should complain only if it
nds a block that is relatively invalid. The PoS system as a whole endeavors
to make every block relatively valid, not recursively (or absolutely) valid.
Notice, however, that if all blocks in a blockchain are relatively valid, then all
of them and the blockchain as a whole are absolutely valid; this statement is
easily shown using mathematical induction on the length of the blockchain.
In this way, easily veriable assertions of relative validity of blocks together
demonstrate the much stronger absolute validity of the whole blockchain.
Note that by signing a block B the validator asserts that the block is
valid given the original state s (i.e., that the result of (24) is not the value ⊥
indicating that the next state cannot be computed). In this way, the validator
must perform minimal formal checks of the cells of the original state that are
accessed during the evaluation of (24).
For example, imagine that the cell expected to contain the original bal-
ance of an account accessed from a transaction committed into a block turns
out to have zero raw bytes instead of the expected 8 or 16. Then the original
53

---

2.6. Creating and Validating New Blocks
balance simply cannot be retrieved from the cell, and an unhandled excep-
tion happens while trying to process the block. In this case, the validator
should not sign such a block on pain of being punished.
2.6.23. Signing masterchain blocks. The situation with the masterchain
blocks is somewhat dierent: by signing a masterchain block, the valida-
tor asserts not only its relative validity, but also the relative validity of all
preceding blocks up to the very rst block when this validator assumed its
responsibility (but not further back).
2.6.24. The total number of validators. The upper limit T for the total
number of validators to be elected (cf. 2.6.7) cannot become, in the system
described so far, more than, say, several hundred or a thousand, because all
validators are expected to participate in a BFT consensus protocol to cre-
ate each new masterchain block, and it is not clear whether such protocols
can scale to thousands of participants. Even more importantly, masterchain
blocks must collect the signatures of at least two-thirds of all the validators
(by stake), and these signatures must be included in the new block (other-
wise all other nodes in the system would have no reason to trust the new
block without validating it by themselves). If more than, say, one thousand
validator signatures would have to be included in each masterchain block,
this would imply more data in each masterchain block, to be stored by all
full nodes and propagated through the network, and more processing power
spent to check these signatures (in a PoS system, full nodes do not need to
validate blocks by themselves, but they need to check the validators' signa-
tures instead).
While limiting T to a thousand validators seems more than sucient for
the rst phase of the deployment of the TON Blockchain, a provision must
be made for future growth, when the total number of shardchains becomes
so large that several hundred validators will not suce to process all of
them. To this end, we introduce an additional congurable parameter T
0
≤ T
(originally equal to T ), and only the top T
0
elected validators (by stake) are
expected to create and sign new masterchain blocks.
2.6.25. Decentralization of the system. One might suspect that a Proof-
of-Stake system such as the TON Blockchain, relying on T ≈ 1000 validators
to create all shardchain and masterchain blocks, is bound to become too
centralized, as opposed to conventional Proof-of-Work blockchains like Bit-
coin or Ethereum, where everybody (in principle) might mine a new block,
54

---

2.6. Creating and Validating New Blocks
without an explicit upper limit on the total number of miners.
However, popular Proof-of-Work blockchains, such as Bitcoin and Ether-
eum, currently require vast amounts of computing power (high hash rates)
to mine new blocks with non-negligible probability of success. Thus, the
mining of new blocks tends to be concentrated in the hands of several large
players, who invest huge amounts money into datacenters lled with custom-
designed hardware optimized for mining; and in the hands of several large
mining pools, which concentrate and coordinate the eorts of larger groups
of people who are not able to provide a sucient hash rate by themselves.
Therefore, as of 2017, more than 75% of new Ethereum or Bitcoin blocks
are produced by less than ten miners. In fact, the two largest Ethereum
mining pools produce together more than half of all new blocks! Clearly,
such a system is much more centralized than one relying on T ≈ 1000 nodes
to produce new blocks.
One might also note that the investment required to become a TON
Blockchain validatori.e., to buy the hardware (say, several high-performance
servers) and the stake (which can be easily collected through a pool of nom-
inators if necessary; cf. 2.6.3)is much lower than that required to become
a successful stand-alone Bitcoin or Ethereum miner. In fact, the parame-
ter L of 2.6.7 will force nominators not to join the largest mining pool
(i.e., the validator that has amassed the largest stake), but rather to look
for smaller validators currently accepting funds from nominators, or even to
create new validators, because this would allow a higher proportion s
0
i
/s
i
of
the validator'sand by extension also the nominator'sstake to be used,
hence yielding larger rewards from mining. In this way, the TON Proof-of-
Stake system actually encourages decentralization (creating and using more
validators) and punishes centralization.
2.6.26. Relative reliability of a block. The (relative) reliability of a block
is simply the total stake of all validators that have signed this block. In other
words, this is the amount of money certain actors would lose if this block
turns out to be invalid. If one is concerned with transactions transferring
value lower than the reliability of the block, one can consider them to be safe
enough. In this sense, the relative reliability is a measure of trust an outside
observer can have in a particular block.
Note that we speak of the relative reliability of a block, because it is a
guarantee that the block is valid provided the previous block and all other
shardchains' blocks referred to are valid (cf. 2.6.22).
55

---

2.6. Creating and Validating New Blocks
The relative reliability of a block can grow after it is committedfor
example, when belated validators' signatures are added (cf. 2.6.21). On the
other hand, if one of these validators loses part or all of its stake because
of its misbehavior related to some other blocks, the relative reliability of a
block may decrease.
2.6.27. Strengthening the blockchain. It is important to provide in-
centives for validators to increase the relative reliability of blocks as much as
possible. One way of doing this is by allocating a small reward to validators
for adding signatures to blocks of other shardchains. Even would-be valida-
tors, who have deposited a stake insucient to get into the top T validators
by stake and to be included in the global set of validators (cf. 2.6.7), might