PreprintPDF Available
Preprints and early-stage research may not have been peer reviewed yet.

Abstract and Figures

Sharding is the prevalent approach to breaking the trilemma of simultaneously achieving decentralization, security, and scalability in traditional blockchain systems, which are implemented as replicated state machines relying on atomic broadcast for consensus on an immutable chain of valid transactions. Sharding is to be understood broadly as techniques for dynamically partitioning nodes in a blockchain system into subsets (shards) that perform storage, communication, and computation tasks without fine-grained synchronization with each other. Despite much recent research on sharding blockchains, much remains to be explored in the design space of these systems. Towards that aim, we conduct a systematic analysis of existing sharding blockchain systems and derive a conceptual decomposition of their architecture into functional components and the underlying assumptions about system models and attackers they are built on. The functional components identified are node selection, epoch randomness, node assignment, intra-shard consensus, cross-shard transaction processing, shard reconfiguration, and motivation mechanism. We describe interfaces, functionality, and properties of each component and show how they compose into a sharding blockchain system. For each component, we systematically review existing approaches, identify potential and open problems, and propose future research directions. We focus on potential security attacks and performance problems, including system throughput and latency concerns such as confirmation delays. We believe our modular architectural decomposition and in-depth analysis of each component, based on a comprehensive literature study, provides a systematic basis for conceptualizing state-of-the-art sharding blockchain systems, proving or improving security and performance properties of components, and developing new sharding blockchain system designs.
Content may be subject to copyright.
Computer Science Review 46 (2022) 100513
Contents lists available at ScienceDirect
Computer Science Review
journal homepage: www.elsevier.com/locate/cosrev
Review article
Building blocks of sharding blockchain systems: Concepts, approaches,
and open problems
Yizhong Liu a,Jianwei Liu a,Marcos Antonio Vaz Salles d,1,Zongyang Zhang a,,Tong Li a,
Bin Hu a,Fritz Henglein b,Rongxing Lu c
aSchool of Cyber Science and Technology, Beihang University, Beijing, China
bDepartment of Computer Science, University of Copenhagen, Copenhagen, Denmark
cFaculty of Computer Science, University of New Brunswick, Fredericton, Canada
dIndependent Researcher
article info
Article history:
Received 13 February 2021
Received in revised form 21 May 2022
Accepted 27 September 2022
Available online xxxx
Keywords:
Sharding blockchain
Byzantine Fault Tolerance
Scalability
Throughput
Consensus
Modular decomposition
abstract
Sharding is the prevalent approach to breaking the trilemma of simultaneously achieving decen-
tralization, security, and scalability in traditional blockchain systems, which are implemented as
replicated state machines relying on atomic broadcast for consensus on an immutable chain of valid
transactions. Sharding is to be understood broadly as techniques for dynamically partitioning nodes
in a blockchain system into subsets (shards) that perform storage, communication, and computation
tasks without fine-grained synchronization with each other. Despite much recent research on sharding
blockchains, much remains to be explored in the design space of these systems. Towards that aim,
we conduct a systematic analysis of existing sharding blockchain systems and derive a conceptual
decomposition of their architecture into functional components and the underlying assumptions about
system models and attackers they are built on. The functional components identified are node selection,
epoch randomness, node assignment, intra-shard consensus, cross-shard transaction processing, shard
reconfiguration, and motivation mechanism. We describe interfaces, functionality, and properties of
each component and show how they compose into a sharding blockchain system. For each component,
we systematically review existing approaches, identify potential and open problems, and propose
future research directions. We focus on potential security attacks and performance problems, including
system throughput and latency concerns such as confirmation delays. We believe our modular
architectural decomposition and in-depth analysis of each component, based on a comprehensive
literature study, provides a systematic basis for conceptualizing state-of-the-art sharding blockchain
systems, proving or improving security and performance properties of components, and developing
new sharding blockchain system designs.
©2022 Elsevier Inc. All rights reserved.
Contents
1. Introduction......................................................................................................................................................................................................................... 3
1.1. Our contributions................................................................................................................................................................................................... 4
1.2. Paper organization................................................................................................................................................................................................. 4
2. Preliminaries ....................................................................................................................................................................................................................... 4
2.1. Background ............................................................................................................................................................................................................. 4
2.1.1. Blockchain consensus ............................................................................................................................................................................ 4
2.1.2. Sharding blockchains ............................................................................................................................................................................. 5
2.2. Notations................................................................................................................................................................................................................. 7
2.3. Definitions .............................................................................................................................................................................................................. 7
2.3.1. Network model....................................................................................................................................................................................... 7
2.3.2. Adversary model .................................................................................................................................................................................... 8
Corresponding author.
E-mail addresses: liuyizhong@buaa.edu.cn (Y. Liu), liujianwei@buaa.edu.cn (J. Liu), msalles@acm.org (M.A. Vaz Salles), zongyangzhang@buaa.edu.cn (Z. Zhang),
leetong@buaa.edu.cn (T. Li), hubin0205@buaa.edu.cn (B. Hu), henglein@di.ku.dk (F. Henglein), rlu1@unb.ca (R. Lu).
1Work was performed while the author was at the University of Copenhagen.
https://doi.org/10.1016/j.cosrev.2022.100513
1574-0137/©2022 Elsevier Inc. All rights reserved.
Y. Liu, J. Liu, M.A. Vaz Salles et al. Computer Science Review 46 (2022) 100513
2.3.3. Transaction model.................................................................................................................................................................................. 9
2.3.4. Intra-shard consensus............................................................................................................................................................................ 9
2.3.5. Sharding blockchains ............................................................................................................................................................................. 10
3. Decomposing sharding blockchains into functional components ................................................................................................................................ 11
3.1. Decomposition of sharding blockchains ............................................................................................................................................................. 11
3.1.1. Node selection ........................................................................................................................................................................................ 12
3.1.2. Epoch randomness ................................................................................................................................................................................. 13
3.1.3. Node assignment.................................................................................................................................................................................... 13
3.1.4. Intra-shard consensus............................................................................................................................................................................ 13
3.1.5. Cross-shard transaction processing...................................................................................................................................................... 13
3.1.6. Shard reconfiguration ............................................................................................................................................................................ 14
3.1.7. Motivation mechanism .......................................................................................................................................................................... 14
3.2. Composing separate components into sharding blockchain systems ............................................................................................................. 14
3.2.1. General methods to compose a sharding blockchain system........................................................................................................... 14
3.2.2. Distinct combinations of system models and components .............................................................................................................. 14
3.2.3. Instantiation of composing components into a sharding
blockchain system.................................................................................................................................................................................. 16
3.3. Summary................................................................................................................................................................................................................. 16
4. Node selection .................................................................................................................................................................................................................... 16
4.1. Basic concepts ........................................................................................................................................................................................................ 16
4.2. Existing approaches............................................................................................................................................................................................... 18
4.2.1. PoW-based node selection .................................................................................................................................................................... 18
4.2.2. PoS-based node selection...................................................................................................................................................................... 19
4.2.3. CA-based node selection ....................................................................................................................................................................... 19
4.3. Problems and future directions............................................................................................................................................................................ 19
4.3.1. PoW-based node selection .................................................................................................................................................................... 19
4.3.2. PoS-based node selection...................................................................................................................................................................... 20
5. Epoch randomness ............................................................................................................................................................................................................. 21
5.1. Basic concepts ........................................................................................................................................................................................................ 21
5.2. Existing approaches............................................................................................................................................................................................... 22
5.2.1. VRF ........................................................................................................................................................................................................... 22
5.2.2. Threshold signature ............................................................................................................................................................................... 22
5.2.3. PVSS ......................................................................................................................................................................................................... 22
5.2.4. Hash functions........................................................................................................................................................................................ 22
5.2.5. VDF........................................................................................................................................................................................................... 22
5.2.6. Others ...................................................................................................................................................................................................... 23
5.3. Comparison of distributed random beacon protocols....................................................................................................................................... 23
5.3.1. Network model....................................................................................................................................................................................... 23
5.3.2. Randomness properties ......................................................................................................................................................................... 23
5.3.3. Complexity evaluation ........................................................................................................................................................................... 23
5.4. Problems and future directions............................................................................................................................................................................ 25
5.4.1. Security requirements ........................................................................................................................................................................... 25
5.4.2. Performance improvements.................................................................................................................................................................. 25
5.4.3. Formal security analysis ........................................................................................................................................................................ 25
6. Node assignment ................................................................................................................................................................................................................ 25
6.1. Basic concepts ........................................................................................................................................................................................................ 25
6.2. Existing approaches............................................................................................................................................................................................... 25
6.2.1. Binomial distribution ............................................................................................................................................................................. 25
6.2.2. Hypergeometric distribution................................................................................................................................................................. 26
6.2.3. Other distribution................................................................................................................................................................................... 26
6.3. Problems and future directions............................................................................................................................................................................ 26
6.3.1. The analysis from Ato Bis ignored .................................................................................................................................................... 26
6.3.2. The infinite pool assumption is not accurate ..................................................................................................................................... 26
6.3.3. The failure rate with cumulative hypergeometric distribution is imprecise.................................................................................. 26
7. Intra-shard consensus ........................................................................................................................................................................................................ 26
7.1. Basic concepts ........................................................................................................................................................................................................ 26
7.2. Existing approaches............................................................................................................................................................................................... 27
7.2.1. Strong consistency ................................................................................................................................................................................. 27
7.2.2. Weak consistency................................................................................................................................................................................... 30
7.3. Problems and future directions............................................................................................................................................................................ 30
7.3.1. Instant sharding blockchains ................................................................................................................................................................ 30
7.3.2. Eventual sharding blockchains ............................................................................................................................................................. 31
8. Cross-shard transaction processing.................................................................................................................................................................................. 31
8.1. Basic concepts ........................................................................................................................................................................................................ 31
8.2. Existing approaches............................................................................................................................................................................................... 31
8.2.1. Two-phase commit based approaches................................................................................................................................................. 31
8.2.2. Transaction split based approaches ..................................................................................................................................................... 32
8.2.3. Relay transaction based approaches .................................................................................................................................................... 32
8.3. Problems and future directions............................................................................................................................................................................ 33
8.3.1. Two-phase commit based approaches................................................................................................................................................. 33
8.3.2. Transaction split based approaches ..................................................................................................................................................... 34
2
Y. Liu, J. Liu, M.A. Vaz Salles et al. Computer Science Review 46 (2022) 100513
8.3.3. Relay transaction based approaches .................................................................................................................................................... 34
9. Shard reconfiguration ........................................................................................................................................................................................................ 35
9.1. Basic concepts ........................................................................................................................................................................................................ 35
9.2. Existing approaches............................................................................................................................................................................................... 35
9.2.1. Reconfiguration through random replacement .................................................................................................................................. 35
9.2.2. Reconfiguration under specific rules ................................................................................................................................................... 35
9.3. Problems and future directions............................................................................................................................................................................ 36
9.3.1. Quantitative analysis of the corruption parameter τ........................................................................................................................ 36
9.3.2. Bootstrapping of new joined members ............................................................................................................................................... 36
9.3.3. Security analysis of new committees .................................................................................................................................................. 36
9.3.4. Initial setup of the protocol.................................................................................................................................................................. 36
10. Motivation mechanism ...................................................................................................................................................................................................... 37
10.1. Basic concepts ........................................................................................................................................................................................................ 37
10.2. Existing approaches............................................................................................................................................................................................... 37
10.2.1. Rewards for block producers and leaders........................................................................................................................................... 37
10.2.2. Penalties for negative behaviors .......................................................................................................................................................... 37
10.2.3. Rewards based on reputation............................................................................................................................................................... 37
10.3. Problems and future directions............................................................................................................................................................................ 38
10.3.1. Specific considerations for sharding blockchains............................................................................................................................... 38
10.3.2. Detailed analysis of the motivation mechanism ................................................................................................................................ 38
11. Related work....................................................................................................................................................................................................................... 38
11.1. Survey on sharding blockchain systems ............................................................................................................................................................. 38
11.2. Modular analysis of sharding blockchains.......................................................................................................................................................... 38
11.3. Blockchain consensus ............................................................................................................................................................................................ 38
11.4. Blockchain scalability ............................................................................................................................................................................................ 38
12. Conclusion ........................................................................................................................................................................................................................... 38
CRediT authorship contribution statement ..................................................................................................................................................................... 39
Declaration of competing interest.................................................................................................................................................................................... 39
Acknowledgments .............................................................................................................................................................................................................. 39
References ........................................................................................................................................................................................................................... 39
1. Introduction
A traditional blockchain system is a peer-to-peer (P2P) dis-
tributed system with decentralized governance. It implements a
replicated state machine that relies on an atomic broadcast (total
event order consensus) protocol for consensus on an immutable
chain (sequence) of valid transactions. A transaction can be any
record of data but is usually a digitally signed statement that
expresses a transfer of ownership of a digital resource (asset). In
the seminal and paradigmatic Bitcoin system [1],2a transaction
is a cryptographically signed transfer of a built-in synthetic cur-
rency, Bitcoin, by and to anonymous parties identified only by
public keys they themselves have generated. Any node can join
and leave the P2P network at any time, without authentication.
The nodes receive transactions submitted by clients, collect them
into blocks of valid transactions, and compete with other nodes to
have their block extend the currently longest chain of such blocks.
The node operators are incentivized to do this by receiving a fee,
in Bitcoin, whenever their block is the consensual continuation to
the currently longest chain.3
An idealized blockchain system strives for the combination of
decentralized control (no single party has an a priori privileged
role), consensus on a single state (‘‘single source of truth’’),
tamper-proof recording (validated transactions cannot feasibly
be deleted or updated ex post), once added to the blockchain),
privacy preservation (publicly shared data, but secured and priva-
tized by cryptographic techniques such as cryptographic hashing,
private–public key cryptography, secret sharing for
digital signatures [2,3], immutable self-certifying pointers [4],
zero-knowledge proofs and more), and high availability (high
degree of replication on nodes controlled by independent, non-
colluding node operators) in an untrusted environment [5].
2Where a blockchain is called chain of blocks; neither ‘‘blockchain’’ nor
‘‘block-chain’’ occur in the paper.
3This is a simplified description with technical infelicities.
Blockchain systems have tremendous application potential in
various fields, such as Internet of Things (IoT) [6,7], cloud comput-
ing [8,9] (with a trusted data center provider), smart cities [10],
finance [1113] (with authenticated legal entities), self-sovereign
identity management,4supply chain [14] and more.
Blockchain technology develops very rapidly, but faces both
fundamental and practical obstacles to wider applicability. The
most critical issue is the trilemma of decentralization, security,
and scalability. To achieve decentralization, solutions need to
support independent participants with varying assumptions on
how participants may join or leave a network, from permissioned
to permissionless blockchain systems [15].
As for security [16,17], a blockchain protocol has to be proved
secure [18,19] to ensure it resists certain classes of attacks that
may compromise its correct functioning vis a vis client.
For improved scalability, existing approaches can be classified
into off-chain and on-chain solutions [20]. The former employ a
hierarchical architecture, where the core blockchain system (on-
chain) only validates few aggregated resource transfers that are
the net effect of many fine-grained payments, which in turn are
managed separately in multiple unsynchronized subsystems. This
includes technologies such as micropayment [21,22], payment
channel networks [23,24], virtual payment channels [25], and
sidechains [2628]. Conceptually, these solutions correspond to
a (full-reserve) banking system, where the central bank corre-
sponds to the core blockchain system, and the channels to pop-up
banks that have initially some accounts transferred from the cen-
tral bank, perform internal transactions without synchronization
with other banks, and eventually transfer the final balances back
to the central bank such that only the netted result is stored in
the blockchain. Off-chain solutions avoid the computational cost
of a traditional blockchain system, which requires each honest
node to receive, store and send all transactions and to come to
4Such as ESSIF, part of the European Blockchain Services Initiative, Sovrin or
a number of Hyperledger identity management frameworks.
3
Y. Liu, J. Liu, M.A. Vaz Salles et al. Computer Science Review 46 (2022) 100513
an agreement amongst all nodes on a total order of all valid
transactions.
Despite the applicability of off-chain solutions in some sce-
narios, on-chain solutions where all transactions are recorded,
validated, and retained without netting, are desired in many other
application scenarios. A sharding blockchain system is an on-
chain solution that seeks to improve the scalability of a traditional
blockchain system while achieving the same level of security and
decentralization. In a sharding blockchain system, the nodes in
the network are dynamically partitioned into shards (subsets),
where each shard is responsible for managing its own blockchain.
The basic idea is that, instead of storing a chain of transactions
and replicating it across all nodes, an acyclic graph of transactions
is maintained, where each shard is only responsible for a specific
part of the graph. As new nodes join the network, the cumulative
transaction throughput can grow by increasing the number of
shards [29]. Sharding technology was pioneered for database
systems [30], where it describes methods for dynamically par-
titioning a database into parts, called shards, each managed by a
different node in a distributed system. The concept of partitioning
data and their management, including the term sharding, was
introduced to blockchain systems by ELASTICO [31].
The design and implementation of sharding blockchain sys-
tems currently suffer from a number of problems, however. First,
the structure of sharding blockchain systems is complicated; they
usually contain multiple key components,5such as the method
for selecting shard members, the consensus algorithm inside a
shard, and the processing method for transactions. Second, dif-
ferent sharding blockchain systems may adopt different models,
such as network, adversary, and transaction models, without
making these explicit enough to assess their design and (security)
properties. These model assumptions engender a considerable set
of design choices, which need to be characterized and compared
in the context of their model assumptions. Third, most sharding
blockchain systems are presented as end-to-end systems, describ-
ing a specific point in a tremendous design space for blockchain
systems, without providing an architecture for exploring system-
atic modular design to rapidly and securely explore the design
space for sharding blockchain systems. In particular, the func-
tionality of components and their interfaces are not clear enough,
which leads to difficulties in exploring various alternative designs
for each component.
In this paper, we address these points: We provide a concep-
tual and technical framework for decomposing existing sharding
blockchain systems into key functional components and describe
a conceptual and technical modular architecture for composing
them into full sharding blockchain systems. Besides, we pro-
pose a taxonomy for sharding blockchain systems from the di-
mensions of system models and components. Furthermore, we
provide a systematic, in-depth analysis of each component, de-
scribing its input dependencies, functionality, and key properties.
For each component, we classify existing approaches and solu-
tions, identify open problems, and provide directions for future
research.
1.1. Our contributions
In summary, we make the following contributions in this
paper.
Decomposing sharding blockchains into functional compo-
nents. We decompose sharding blockchains into multiple func-
tional components: node selection, epoch randomness, node as-
signment, intra-shard consensus, cross-shard transaction pro-
cessing, shard reconfiguration, and motivation mechanism. For
5We use the terms ‘‘functional component’’ and ‘‘building block’’
interchangeably.
each component, we give its input, output, function, and prop-
erty to be satisfied. Furthermore, we show how to compose
these components into a complete sharding blockchain system.
The component decomposition provides a path to systematically
developing yet unexplored sharding blockchain system designs.
A detailed taxonomy for sharding blockchain systems. We
provide a taxonomy for sharding blockchain systems in two di-
mensions: system models and components. System models in-
clude network model, adversary model, and transaction model.
We divide each model into categories that correspond to dif-
ferent types of sharding blockchain systems, such as eventual
and instant sharding blockchain systems, or permissioned and
permissionless sharding blockchain systems. For each component
of a sharding blockchain system, we classify solutions according
to their principles and algorithms.
In-depth analysis of components. For each component of a
sharding blockchain system, we first give its basic concepts, in-
cluding its purpose, functionality, and essential procedures. We
summarize and categorize existing approaches according to their
underlying characteristics; the specific operational details of each
method are expounded from multiple perspectives. In addition,
we identify and analyze possible problems for every type of
solution, including attacks an adversary might launch on secu-
rity, throughput, and latency (transaction confirmation delays).
Finally, we point out possible future research directions for each
component.
1.2. Paper organization
Section 2gives the background, definitions and notations that
are useful in this paper. In Section 3we decompose sharding
blockchains into several components and discuss methodologies
to derive sharding blockchain systems from their composition. In
Sections 4,5, and 6, basic concepts, existing approaches, open
problems and future directions of node selection, epoch random-
ness, and node assignment are given, respectively. These three
parts involve the method to confirm shard members. Then Sec-
tion 7describes the classic state machine replication algorithms
that are used as intra-shard consensus. In Section 8, cross-shard
transaction processing methods are analyzed in detail, which is
important to all sharding blockchain systems. Sections 9and 10
give the existing approaches and potential problems about shard
reconfiguration and motivation mechanisms. Section 11 describes
the related work. Finally, Section 12 summarizes this paper.
2. Preliminaries
In this section, we first give the background of sharding
blockchains. Then notations and definitions that are useful in the
paper are described in detail.
2.1. Background
Sharding blockchains adopt a unique blockchain consensus
mechanism. Next, we first describe the relevant background of
blockchain consensus and then introduce sharding blockchains.
2.1.1. Blockchain consensus
Blockchain technology is introduced by Bitcoin [1] in 2008,
which realizes the agreement of the ledger among distributed
nodes through a specific consensus mechanism. The reason why
the blockchain is called ‘‘chain’’ is because each block is linked
to the previous one in a specific cryptographic way. The contents
stored in a block mainly include the transactions generated in the
network during each period of time.
4
Y. Liu, J. Liu, M.A. Vaz Salles et al. Computer Science Review 46 (2022) 100513
Blockchain technology is currently a hot area of research and
has great application potential since it has the following charac-
teristics. The first characteristic is decentralization. Decentraliza-
tion means that there is no trusted third party in the network,
which is different from the traditional centralized transaction
mode. The second characteristic is trustlessness, which means
that nodes do not need to trust each other, and can finally reach
consensus on the ledger through a specific consensus mechanism.
The third characteristic is transparency. In a permissionless net-
work (ref. Definition 6), all nodes can join and leave the protocol
at any time, and nodes could obtain the historical ledger data
of the blockchain at any time. The fourth is tamper-resistance.
Under the assumptions of appropriate network and adversary
models, historical data in the blockchain cannot be illegally tam-
pered with, except for some special redactable blockchains [32,
33]. Once a block is confirmed (strong consistency blockchains,
ref. Definition 20), or a block reaches a certain depth (weak
consistency blockchains, ref. Definition 16), the contents of the
block can no longer be modified. The fifth is anonymity. Through
some approaches (such as transaction graph analysis [34,35]),
deanonymization analysis on historical transaction data could
be performed on some blockchains. However, by adopting some
cryptographic technologies, such as blind signatures [36,37], ring
signatures [38,39], and zero-knowledge proofs [40,41], privacy-
protection blockchains are designed to prevent users’ privacy
from leakage.
As shown in Fig. 1, the architecture of blockchain could be
divided into several layers, including a network layer, a consensus
layer, and an application layer. In the network layer, participating
nodes join a P2P communication network [42] to synchronize
information with each other. In a P2P network, the nodes are
distributed, and there is no central communication node in the
network. The transfer and update of information are completed
by the P2P communication between each node. Besides, there
could be other kinds of connecting nodes in a blockchain net-
work, such as databases, IoT devices, and lightweight clients.
In the consensus layer, the participating nodes in the network
with certain computing and communication capabilities act as
consensus nodes, that is, block producers (we use the term ‘‘block
producer’’ instead of ‘‘miner’’ to make the meaning more general),
and generate blocks through certain consensus algorithms. Note
that there are many types of consensus algorithms, and Fig. 1
shows a Byzantine Fault Tolerance (BFT) [43] algorithm. Many
applications, such as digital assets [44], smart contracts [45],
and decentralized applications [46], could be built based on a
blockchain, together constituting the application layer.
A consensus mechanism is very critical to a blockchain system,
and to a large extent determines the security and performance of
the system. A blockchain consensus is to ensure the consistency
and liveness of the system by formulating rules for nodes to
participate in the blockchain protocol. Consistency means that all
honest nodes ultimately have the same view of the blockchain.
Liveness refers to that the transactions uploaded by users to the
blockchain are sure to be processed after a certain period of time.
At present, the blockchain consensus mechanisms could be
divided into the following categories, according to [47]. First, it
is the classic distributed consensus algorithm, represented by
the Byzantine fault tolerance algorithms, which implements state
machine replication (ref. Definition 21) in a limited number of
participating nodes. The second is proof-of-work (PoW) based
consensus, including Bitcoin [1], Bitcoin-NG [48], GHOST [49],
FruitChains [50], SPECTURE [51], etc. Besides, there is proof-of-
stake (PoS) based consensus, such as Casper FFG [52], Snow
White [53], Ouroboros [54], etc. Finally, the hybrid consensus,
such as PeerCensus [55], ByzCoin [56], Solida [57], etc., com-
bines classic state machine replication algorithms and blockchain
technology. According to the number of committees, the hybrid
consensus mechanisms could be divided into single-committee
and multi-committee hybrid consensus mechanisms. The multi-
committee hybrid consensus is a kind of sharding consensus
mechanism, which is introduced in the following.
2.1.2. Sharding blockchains
Sharding technology is first proposed and used in the field of
databases [30]. By dividing all participating nodes in the network
into multiple shards, each shard is only responsible for main-
taining its own corresponding data. In this way, the scalability of
network processing capabilities could be achieved. As the number
of nodes in the network increases, the enhancement of process-
ing capabilities is realized by adding more shards. The sharding
blockchain is first proposed by ELASTICO [31], which combines
sharding technology and blockchain technology, with the pur-
pose to increase the transaction throughput, i.e., the number of
transactions processed per second. Since then, there have been
many studies on sharding blockchains, such as Omniledger [58],
Chainspace [58], RapidChain [59], and Monoxide [60]. Sharding
blockchains are a practical solution to the so-called blockchain
impossible triangle problem, which means it is impossible to re-
alize security (consistency), decentralization, and scalability (high
performance/high throughput/scale-out) simultaneously.
In general, sharding blockchains have the following three char-
acteristics. The first one is communication sharding. Participating
nodes are divided into different shards where nodes in each shard
only need internal communication most of the time. The clients
and nodes within each shard could obtain the current state of
the blockchain by communicating with the intra-shard nodes that
are responsible for maintaining the blockchain, e.g., a committee.
The second one is computation sharding, which means that each
shard is only responsible for processing its corresponding trans-
actions. The distribution of transactions to shards is diversified,
e.g., by selecting the corresponding shard according to the trans-
action ID. Generally speaking, according to the last several bits of
the transaction ID, it is determined which shard the transaction
belongs to. So transactions are handled by different shards in
parallel. When the number of nodes in the network increases,
more shards could be added to realize scalability. The third one is
storage sharding. Storage sharding means that nodes of different
shards only needs to store the data of its corresponding shard. The
data includes transaction history and unspent transaction output
(UTXO, ref. Definition 14) data. Transaction history data exists in
the form of a blockchain, while the UTXO data could be derived
from transaction history data or could be stored separately to
improve its processing efficiency. Storage sharding allows nodes
to store a fraction of the entire blockchain system data, reducing
the storage burden of nodes.
As shown in Fig. 2, communications play an important role
in sharding blockchain systems. Nodes in the same shard only
need to execute intra-shard communication most of the time and
send some key information to a coordinator of the shard. The
coordinator is usually responsible for cross-shard communication
as well as intra-shard consensus, and each shard has at least
one coordinator. Generally speaking, the coordinator needs to
have stronger communication capabilities than other intra-shard
nodes.
Note that some methods, such as OHIE [61] and Prism [62], are
designed to improve the throughput of the blockchains, while in
a strict sense, sharding technology is not used in their structures.
Hence, we will not introduce this type of solutions, while focusing
on the blockchains that use sharding technology.
Compared with other methods to improve scalability. There are
also other approaches to improve the blockchain performance
(high throughput, low transaction confirmation time, scalability).
Existing methods could be divided into on-chain (also called layer
1) and off-chain (also called layer 2) methods.
5
Y. Liu, J. Liu, M.A. Vaz Salles et al. Computer Science Review 46 (2022) 100513
Fig. 1. Blockchain layers.
Fig. 2. Communications in sharding blockchain systems.
On-Chain Methods. Sharding blockchains belong to the on-
chain methods, which include directed acyclic graph (DAG)
and sidechain approaches, too.
DAG Blockchain. Differently from the single main chain
in Bitcoin, a DAG blockchain uses multiple chains to
follow the main chain. The target direction of the
branch chain and the main chain are the same, and
there are no loops. The structure is no longer a simple
chain structure. Each newly added block will be linked
to multiple previous blocks, and its hash value will be
included in its own block. The genesis block can be
reached through traceability, and all transactions are
arranged in blocks that finally form a directed acyclic
graph structure. DAG-based blockchains include IOTA
Tangle [63], Byteball [64], Conflux [65], Tusk [66], and
Bullshark [67].
Sidechains.6Sidechains use a separate blockchain to
process transactions that might run a different con-
sensus mechanism than the one of the main chain.
The nodes involved in consensus and the consensus
algorithm could all be different from the main chain.
Meanwhile, there is a two-way peg, which is usually
implemented by smart contracts, to realize asset ex-
changes between the main chain and the sidechain.
Typical sidechain schemes include PoW sidechains [27]
and PoS sidechains [68].
Off-Chain Methods. Off-chain methods process a huge num-
ber of micro-payments by interacting with the main chain
6In other literature, sidechains are also classified as off-chain, or a class in
parallel with on-chain and off-chain.
6
Y. Liu, J. Liu, M.A. Vaz Salles et al. Computer Science Review 46 (2022) 100513
Table 1
Notations.
Symbol Definition
tx a transaction
the upper bound of the network’s delay
δthe actual delay of the network
uthe exact number of members in a shard committee
fthe maximum number of malicious node in a shard
committee
mthe total number of shards
nthe total number of nodes that participate in the protocol
shardithe ith shard
Ci
ethe ith committee of epoch e*
CR
ethe reference committee of epoch e
LOGithe output log of the ith shard’s nodes
chain a blockchain
ρthe fraction of the computational power that is held by an
adversary
τthe corruption time parameter of an adversary
pthe probability that one node finds a PoW solution
successfully in one single round
For the convenience of analysis, we assume that the number of members in
a committee is fixed.
* The concept of shard and committee is different. In committee-based sharding
blockchains, there is a committee responsible for processing transactions in
each shard, and we call it an ordinary committee. So the number of ordinary
committees is also m. Besides, some sharding blockchains, e.g., RapidChain [59],
utilize a reference committee to confirm committee members.
through channels. Typical methods include payment chan-
nels and state channels, such as in the Lighting Network
[21], Perun [69], etc. Please refer to [70] for off-chain scala-
bility protocols.
Compared with other methods, sharding blockchains split the
nodes involved in consensus into different groups and utilize par-
allel processing methods. A sharding blockchain usually includes
several major components such as node selection, epoch random-
ness, node assignment, intra-shard consensus, cross-shard trans-
action processing, and shard reconfiguration. Each component
could be implemented by different methods, and then by com-
posing all the components, a complete sharding blockchain could
be obtained. We will give a detailed analysis of each component
and their composition approach in this paper.
2.2. Notations
We summarize the notations that are used in our paper in
Table 1. To make it compatible with other protocols, we use n
to denote the total number of participating nodes, while we use
uto denote the number of members in a committee. So inside a
committee, the security condition that should be satisfied could
be represented by u=2f+1 or u=3f+1, where fis the number
of admissible failures. In addition, shardidenotes the ith shard,
while the notation Cidenotes the committee in shardi. These two
concepts are different since there might be no committee in a
shard in some kinds of sharding blockchains. The notation LOG
means the output log, or ledger of a shard, while chain denotes a
blockchain. The specific meanings of LOG and chain are similar,
while there are also differences. A blockchain chain might con-
tain other contents and information, such as block headers and
additional information in OP_RETURN [71]. LOG usually means
extracting key information from a blockchain, e.g., transaction
data.
2.3. Definitions
To make our description clearer, we give the definitions that
are useful in our paper and helpful in understanding sharding
blockchains. As shown in Fig. 3, we divide the definitions into
several major categories and give their relationships. Each cat-
egory of definitions could be seen as a tree, where we can select
one of the leaf nodes in each tree to form a sharding blockchain.
In the following, we introduce these definitions related to net-
work model, adversary model, transaction model, intra-shard
consensus, and sharding blockchains.
2.3.1. Network model
To describe the network model more precisely, we divide
network models into message transmission models7and node
admission models as follows.
Message transmission model. We assume that nodes participate in
the network with authentication. The messages sent by the nodes
are signed, and an adversary cannot forge the signature of any
honest node. There are different models for the message delay
rules. Next, we give the definitions of three different message
transmission models.
Definition 1 (Synchronous Network [74]).In a synchronous net-
work, messages between honest nodes are propagated in rounds.
In each round, the messages sent by honest nodes can reach all
other honest users before the next round. Each round has a fixed
length of time.
Synchronous networks are relatively strong network models.
There are two kinds of definitions for a partially synchronous
network.
Definition 2 (Partially Synchronous Network-Definition A [74]).In
a partially synchronous network, there is a certain upper bound
of message transmission delay in the network. The parameter
cannot be used as a parameter in the design of a protocol.
Definition 3 (Partially Synchronous Network-Definition B [75]).In
a partially synchronous network, there is a known bound and
an unknown Global Stabilization Time (GST), such that after GST,
all transmissions between two honest nodes arrive within time
.
Under this definition, a protocol usually ensures safety and
guarantees progress within a bounded duration after the GST.
The partially synchronous network is a commonly used network
model in the analysis of blockchain protocols.
Definition 4 (Asynchronous Network [75]).In an asynchronous
network, there exists an adversary who can arbitrarily delay or
reorder messages of honest nodes, as long as the messages of
honest users can reach each other. There is no upper limit of
message transmission delay.
About the asynchronous network, the FLP impossibility theo-
rem [76] argues that in an asynchronous system where the net-
work is reliable but where crash failures are allowed, there is no
deterministic consensus mechanism that can solve the consensus
problem.
Most blockchain protocols adopt one of the above three mod-
els. However, in a sharding blockchain, two situations need to be
considered. The first is the model of the entire network, and the
second is the internal model of each shard. These two models
could be the same or different and need to be analyzed according
to actual conditions and requirements.
7Note that in other work [72,73] network model mainly refers to message
transmission model in our paper.
7
Y. Liu, J. Liu, M.A. Vaz Salles et al. Computer Science Review 46 (2022) 100513
Fig. 3. Definitions and their relationships.
Node admission model. Note that we assume that the nodes in
the network are homogeneous, i.e., each node has close compu-
tation and communication capabilities. In blockchain protocols,
the rules for nodes to participate in the protocols are different.
We name these rules as node admission models and divide them
into permissioned and permissionless networks as follows.
Definition 5 (Permissioned Network).A permissioned network
means that the nodes participating in the protocol must first
complete identity authentication.
Identity authentication is usually done through a trusted third
party, e.g., a certificate authority (CA). In a permissioned network,
the number and identities of all nodes are known. This model
is mostly adopted by some internal protocols of enterprises or
units [77].
Definition 6 (Permissionless Network).In a permissionless net-
work:
Any node can join or leave at any time;
No identity authentication is required;
The number of participating nodes varies at any time and is
unpredictable.
So in a permissionless network, information about the num-
ber and identity of all participant nodes is unknown. The read
and write rights of the data are generally open to all nodes,
guaranteeing the decentralization property [29].
The words ‘‘permissioned’’ and ‘‘permissionless’’ in the above
two models can usually be combined with different terms, such
as ‘‘permissioned blockchain’’, which means a blockchain protocol
in a permissioned network, or ‘‘permissionless consensus’’, which
means a consensus algorithm in a permissionless network.
2.3.2. Adversary model
The adversary model describes the various capabilities of an
adversary in a protocol. We divide the adversary model into the
corruption model, the total proportion model, and the intra-shard
proportion model.
Corruption model. In this model, an adversary could completely
control a target node and obtain its secret information, the input
and output messages.
We describe an adversary’s corruption ability from two as-
pects, i.e., corruption timing and corruption speed. First, accord-
ing to the timing at which an adversary can launch a corrup-
tion attack, the corruption model could be divided into static
and adaptive corruption. Second, according to the time taken by
an adversary to complete the corruption attack, there are mild
corruption and immediate corruption.
Definition 7 (Static Corruption).A static corruption means that
an adversary can only select its corruption targets before the
protocol starts. Once the protocol starts running, it cannot choose
other honest nodes to corrupt.
Definition 8 (Adaptive Corruption [78]).Adaptive corruption
means that an adversary is able to dynamically corrupt target
nodes according to the information collected during the operation
of the protocol.
The above two models are usually considered in some cryp-
tographic protocols. In the context of sharding blockchains, it
8
Y. Liu, J. Liu, M.A. Vaz Salles et al. Computer Science Review 46 (2022) 100513
is more important to consider the corruption speed since this
will affect the reconfiguration process of a sharding blockchain.
Specifically, if the shard members remain unchanged, then an
adversary may corrupt and control one of the shards after a
period of time. Therefore, a sharding blockchain needs to update
committee members at regular intervals, where the interval is
called an epoch. In order to make the description clearer, we
introduce the definition of epoch here.
Definition 9 (Epoch).An epoch in a sharding blockchain refers
to the time period during which all shard members remain un-
changed and continue to operate. Different epochs correspond to
different shard member configurations.
A reconfiguration refers to switching from one epoch to an-
other, i.e., the process of updating the shard members. The time
length of an epoch is closely related to the time required for the
adversary to complete the corruption. To better describe this, we
give the following two definitions.
Definition 10 (Mild Corruption [79]).Mild corruption means that
it takes a certain amount of time which is usually denoted as
τfor an adversary to corrupt a node. An adversary first issues
the corruption command at time tto the target node. After τ
time, the target node is corrupted and becomes a malicious node.
Before time t+τ, the target node remains honest.
We call τthe corruption time parameter in this paper.
Definition 11 (Immediate Corruption).Immediate corruption
means that an adversary’s corruption attack is effective imme-
diately, i.e., τ=0.
At present, most sharding blockchains adopt the mild corrup-
tion model. As far as we know, the immediate corruption model
is only used in few blockchain protocols, e.g., Algorand [80].
Total proportion model. The total proportion model refers to a
certain limit on the proportion of computational power or stake
that an adversary can control in the whole network. For an entire
blockchain protocol, a percentage or fraction is generally used.
The common used total proportion model might be denoted by
25%, 1/3, 49%, etc. The adversary proportion is less than or equal
to these specific percentages or fractions.
For the sake of consistency, we use fractions to indicate the
total proportion of the adversary in this paper. According to
its relationship with the intra-shard proportion, we divide the
total proportion into [0,1/3) and [1/3,1/2), as shown in Fig. 3.
[0,1/3) means that the proportion is greater than or equal to 0
and less than 1/3. Similarly, [1/3,1/2) refers to the proportion
greater than or equal to 1/3 and less than 1/2.
Intra-shard proportion model. Generally speaking, the represen-
tation of an adversary model in a shard is different, since the
number of shard members is usually limited and fixed. Specifi-
cally, the relationship between the number of nodes controlled by
an adversary and the total number of shard members is expressed
in the form of an equation. fis used to represent the number
of malicious nodes, and udenotes the total number of nodes in
a shard.8The intra-shard adversary proportion model could be
described as follows.
Definition 12 (u=2f+1).The proportion of malicious nodes
that an adversary controls accounts for no more than 1/2 of the
whole shard.
8In other papers, nis usually used to denote the number of shard members.
In this paper, we use nto represent the total number of nodes in the protocol.
To avoid conflicts, we use uto denote the number of members in a shard.
Definition 13 (u=3f+1).The proportion of malicious nodes
that an adversary controls accounts for no more than 1/3 of the
whole shard.
These two models are usually utilized when there are com-
mittees running some BFT algorithms in the shards. u=2f+1 is
often in need in some synchronous BFT protocols, while partially
synchronous BFT protocols usually require the model to be u=
3f+1.
2.3.3. Transaction model
The main function of most blockchain systems is to process
transactions. A transaction usually contains information such as
timestamp, input, output, signature, etc., and is often used to
realize the transfer of property. Different blockchain systems
may adopt different transaction models. The existing transaction
models are mainly divided into the UTXO model, account model,
and others. The UTXO model and account model are the most
commonly used models, and we term such a model a ‘‘generic’’
one. Others refer to some special transaction models. For instance,
in Hyperledger Fabric [77], one can create transactions by not
associating a balance with an account.
UTXO model. The UTXO model is the most commonly used
blockchain transaction model.
Definition 14 (UTXO Model [81]).In the UTXO model, assets
(money/coins/stakes) are stored in unspent transaction outputs
(UTXOs). Each UTXO contains the public key address of the output
and its value. Each transaction spends existing UTXOs and creates
new UTXOs, essentially transferring assets from the input public
key address to the output public key address. Besides, a valid
transaction requires that the sum of values in the output UTXOs
must be equal to that in the input UTXOs.
Account model. The account model is another common
blockchain transaction model defined as follows.
Definition 15 (Account Model [81]).In the account model, each
user has a fixed account. The account information includes the
account address and account balance, and the account balance
must be non-negative. A transaction is to transfer assets from
one account to another account. A valid transaction requires that
the balance in the input account is greater than or equal to the
transaction amount.
2.3.4. Intra-shard consensus
Intra-shard consensus is crucial to sharding blockchains. Next,
we will introduce definitions related to intra-shard consensus in
terms of weak and strong consistency.
Weak consistency. Weak consistency is also known as eventual
consistency, which is defined as follows.
Definition 16 (Weak Consistency).Weak consistency means that
different nodes might end up having different views of a
blockchain, which leads to forks. A certain number of blocks at
the end of the blockchain need to be truncated to obtain stable
transactions.
Specifically, based on the election method of a block pro-
ducer, there might be two or more legal block producers in
the same round. In this case, a short-term fork might appear
in a blockchain. However, after a certain period of time, a final
blockchain is determined according to some kind of decision rule,
such as the longest chain rule of Bitcoin [1] or the heaviest chain
rule of GHOST [49]. Other blockchain systems that have weak
consistency property are PPCoin [82], Ouroboros [54], etc.
The following three properties proposed by the Bitcoin back-
bone protocol [18] are suitable for blockchains with weak consis-
tency property.
9
Y. Liu, J. Liu, M.A. Vaz Salles et al. Computer Science Review 46 (2022) 100513
Definition 17 (Common Prefix [18]).For any two blockchains
chain1,chain2output by any two honest nodes P1,P2in any two
rounds r1,r2, it holds that chaink
1chaink
2or chaink
2chaink
1
where kNis the security parameter. That is to say, when
r1r2is satisfied, it holds that chaink
1chaink<