Blockchain Projects

Classification of Blockchain Projects
blockchains (?shardchains?) with the same rules, and keep the state of an
account in exactly one shard selected depending on the rst byte of its
account_id.
Sharding is a natural approach to scaling blockchain systems, because,
if it is properly implemented, users and smart contracts in the system need
not be aware of the existence of sharding at all. In fact, one often wants to
add sharding to an existing single-chain project (such as Ethereum) when
the load becomes too high.
An alternative approach to scaling would be to use a ?confederation? of
heterogeneous workchains as described in 2.8.10, allowing each user to keep
her account in one or several workchains of her choice, and transfer funds
from her account in one workchain to another workchain when necessary,
essentially performing a 1 : 1 altcoin exchange operation. The drawbacks of
this approach have already been discussed in 2.8.10.
However, sharding is not so easy to implement in a fast and reliable fashion, because it implies a lot of messages between dierent shardchains. For
example, if accounts are evenly distributed between N shards, and the only
transactions are simple fund transfers from one account to another, then only
a small fraction (1/N) of all transactions will be performed within a single
blockchain; almost all (1 − 1/N) transactions will involve two blockchains,
requiring inter-blockchain communication. If we want these transactions to
be fast, we need a fast system for transferring messages between shardchains.
In other words, the blockchain project needs to be ?tightly-coupled? in the
sense described in 2.8.14.
2.8.13. Dynamic and static sharding. Sharding might be dynamic (if
additional shards are automatically created when necessary) or static (when
there is a predened number of shards, which is changeable only through a
hard fork at best). Most sharding proposals are static; the TON Blockchain
uses dynamic sharding (cf. 2.7).
2.8.14. Interaction between blockchains: loosely-coupled and tightlycoupled systems. Multi-blockchain projects can be classied according to
the supported level of interaction between the constituent blockchains.
The least level of support is the absence of any interaction between different blockchains whatsoever. We do not consider this case here, because
we would rather say that these blockchains are not parts of one blockchain
system, but just separate instances of the same blockchain protocol.
70
2.8. Classification of Blockchain Projects
The next level of support is the absence of any specic support for
messaging between blockchains, making interaction possible in principle,
but awkward. We call such systems ?loosely-coupled?; in them one must
send messages and transfer value between blockchains as if they had been
blockchains belonging to completely separate blockchain projects (e.g., Bitcoin and Ethereum; imagine two parties want to exchange some Bitcoins,
kept in the Bitcoin blockchain, into Ethers, kept in the Ethereum blockchain).
In other words, one must include the outbound message (or its generating
transaction) in a block of the source blockchain. Then she (or some other
party) must wait for enough conrmations (e.g., a given number of subsequent blocks) to consider the originating transaction to be ?committed? and
?immutable?, so as to be able to perform external actions based on its existence. Only then may a transaction relaying the message into the target
blockchain (perhaps along with a reference and a Merkle proof of existence
for the originating transaction) be committed.
If one does not wait long enough before transferring the message, or if
a fork happens anyway for some other reason, the joined state of the two
blockchains turns out to be inconsistent: a message is delivered into the
second blockchain that has never been generated in (the ultimately chosen
fork of) the rst blockchain.
Sometimes partial support for messaging is added, by standardizing the
format of messages and the location of input and output message queues in
the blocks of all workchains (this is especially useful in heterogeneous systems). While this facilitates messaging to a certain extent, it is conceptually
not too dierent from the previous case, so such systems are still ?looselycoupled?.
By contrast, ?tightly-coupled? systems include special mechanisms to provide fast messaging between all blockchains. The desired behavior is to be
able to deliver a message into another workchain immediately after it has
been generated in a block of the originating blockchain. On the other hand,
?tightly-coupled? systems are also expected to maintain overall consistency
in the case of forks. While these two requirements appear to be contradictory
at rst glance, we believe that the mechanisms used by the TON Blockchain
(the inclusion of shardchain block hashes into masterchain blocks; the use
of ?vertical? blockchains for xing invalid blocks, cf. 2.1.17; hypercube routing, cf. 2.4.19; Instant Hypercube Routing, cf. 2.4.20) enable it to be a
?tightly-coupled? system, perhaps the only one so far.
Of course, building a ?loosely-coupled? system is much simpler; however,
71
2.8. Classification of Blockchain Projects
fast and ecient sharding (cf. 2.8.12) requires the system to be ?tightlycoupled?.
2.8.15. Simplied classication. Generations of blockchain projects.
The classication we have suggested so far splits all blockchain projects into
a large number of classes. However, the classication criteria we use happen
to be quite correlated in practice. This enables us to suggest a simplied
?generational? approach to the classication of blockchain projects, as a very
rough approximation of reality, with some examples. Projects that have not
been implemented and deployed yet are shown in italics; the most important
characteristics of a generation are shown in bold.
ˆ First generation: Single-chain, PoW, no support for smart contracts.
Examples: Bitcoin (2009) and a lot of otherwise uninteresting imitators
(Litecoin, Monero, . . . ).
ˆ Second generation: Single-chain, PoW, smart-contract support. Example: Ethereum (2013; deployed in 2015), at least in its original form.
ˆ Third generation: Single-chain, PoS, smart-contract support. Example: future Ethereum (2018 or later).
ˆ Alternative third (3
0
) generation: Multi-chain, PoS, no support for
smart contracts, loosely-coupled. Example: Bitshares (2013?2014; uses
DPOS).
ˆ Fourth generation: Multi-chain, PoS, smart-contract support,
loosely-coupled. Examples: EOS (2017; uses DPOS), PolkaDot (2016;
uses BFT).
ˆ Fifth generation: Multi-chain, PoS with BFT, smart-contract support,
tightly-coupled, with sharding. Examples: TON (2017).
While not all blockchain projects fall precisely into one of these categories,
most of them do.
2.8.16. Complications of changing the ?genome? of a blockchain
project. The above classication denes the ?genome? of a blockchain
project. This genome is quite ?rigid?: it is almost impossible to change it
once the project is deployed and is used by a lot of people. One would need a
series of hard forks (which would require the approval of the majority of the