A Two-Layer Blockchain Sharding Protocol Leveraging Safety and Liveness for Enhanced Performance

TL;DR

The paper tackles blockchain sharding scalability under adaptive adversaries by introducing Reticulum, a two-layer protocol with process shards (unanimous first-phase voting) and control shards (majority-based second-phase finalization). It uniquely avoids runtime shard respawns or overlapping memberships while leveraging Byzantine Reliable Broadcast to align votes and expel adversaries, achieving safety and liveness in a synchronous setting. The authors provide thorough analytical and empirical evaluations, showing higher throughput and lower storage per transaction compared to Gearbox and RapidChain, supported by an open-source prototype. Overall, Reticulum offers a scalable, robust sharding solution suitable for large, adversarial environments with fixed shard memberships and a clear two-phase coordination mechanism.

Abstract

Sharding is essential for improving blockchain scalability. Existing protocols overlook diverse adversarial attacks, limiting transaction throughput. This paper presents Reticulum, a groundbreaking sharding protocol addressing this issue, boosting blockchain scalability. Reticulum employs a two-phase approach, adapting transaction throughput based on runtime adversarial attacks. It comprises "control" and "process" shards in two layers. Process shards contain at least one trustworthy node, while control shards have a majority of trusted nodes. In the first phase, transactions are written to blocks and voted on by nodes in process shards. Unanimously accepted blocks are confirmed. In the second phase, blocks without unanimous acceptance are voted on by control shards. Blocks are accepted if the majority votes in favor, eliminating first-phase opponents and silent voters. Reticulum uses unanimous voting in the first phase, involving fewer nodes, enabling more parallel process shards. Control shards finalize decisions and resolve disputes. Experiments confirm Reticulum's innovative design, providing high transaction throughput and robustness against various network attacks, outperforming existing sharding protocols for blockchain networks.

Figures (11)

• Figure 1: The typical structure of a sharding approach leveraging liveness and safety thresholds. The size of shards increases with the liveness threshold $L$ increase. There are three shards in the system. The increased size either reduces the number of shards or causes shards to overlap.
• Figure 2: The structure overview of Reticulum protocol. Every node is, at the same time, in only one process shard ($L=0, S<100\%$) and one control shard ($(L=S)<50\%$) that governs this process shard.
• Figure 3: An example of the two-layer consensus. In this example, the control shard $cs_1$ contains two process shards, $ps_1$ and $ps_2$. We denote the state and block of $ps_i$ for Epoch $X$ by "$ps_i$.X.state" and "$ps_i$.X.block" respectively. A new state of $ps_i$ is derived by applying the transactions in $ps_i$.X.block over $ps_i$.X.state. In the depicted scenario, $ps_1$ and $ps_2$ generated unanimously approved blocks in Epoch $X$, but $ps_2$ failed to agree on the process block of Epoch $X+1$ unanimously. Therefore, $ps_2$.(X+1).block is attached to $cs_1$.(X+1).block, which denotes the block of $cs_1$ for epoch $X+1$. Nodes in $cs_1$ vote on $ps_2.X+1.block$. In this case, $cs_1$ rejects this block, so $ps_2.X+1.state$ remains the same as $ps_2.X.state$. Note that $T_2$ in Epochs $X+1$ and $X+2$ are longer than that in Epoch $X$ because some process blocks did not pass unanimous voting. $T_2$ in Epoch $X+1$ and $X+2$ are longer than that in Epoch $X$ because there are process blocks not passing the unanimous voting.
• Figure 4: $\tau$ corresponding to $Rp$ of the worst case
• Figure 5: The theoretical throughput and storage considering different $R_p$, with $UB=952.708 KB/s$

Theorems & Definitions (22)

• Theorem 1
• proof
• Definition 1
• Lemma 1
• proof
• Theorem 2
• proof
• Corollary 1
• proof
• Theorem 3