GearBox

Abstract

Sharding is an emerging technique to overcome scalability issues on blockchain based public ledgers. Without sharding, every node in the network has to listen to and process all ledger protocol messages. The basic idea of sharding is to parallelize the ledger protocol: the nodes are divided into smaller subsets that each take care of a fraction of the original load by executing lighter instances of the ledger protocol, also called shards. The smaller the shards, the higher the efficiency, as by increasing parallelism there is less overhead in the shard consensus.In this vein, we propose a novel approach that leverages the sharding safety-liveness dichotomy. We separate the liveness and safety in shard consensus, allowing us to dynamically tune shard parameters to achieve essentially optimal efficiency for the current corruption ratio of the system. We start by sampling a relatively small shard (possibly with a small honesty ratio), and we carefully trade-off safety for liveness in the consensus mechanism to tolerate small honesty without losing safety. However, for a shard to be live, a higher honesty ratio is required in the worst case. To detect liveness failures, we use a so-called control chain that is always live and safe. Shards that are detected to be not live are resampled with increased shard size and liveness tolerance until they are live, ensuring that all shards are always safe and run with optimal efficiency. As a concrete example, considering a population of 10K parties with at most 30% corruption and 60-bit security, previous designs required over 5800 parties in each shard to guarantee security. Our design requires only 1713 parties in the worst case with maximal corruption, and in the optimistic case works with only 35 parties without compromising security.Moreover, in this highly concurrent execution setting, it is paramount to guarantee that both the sharded ledger protocol and its sub protocols (i.e., the shards) are secure under composition. To prove the security of our approach, we present ideal functionalities capturing a sharded ledger as well as ideal functionalities capturing the control chain and individual shard consensus, which needs adjustable liveness. We further formalize our protocols and prove that they securely realize the sharded ledger functionality in the UC framework.

FleetChain: A Secure Scalable and Responsive Blockchain Achieving Optimal Sharding

“…Each shard is considered an honest shard, where the number of Byzantine parties 𝑓 satisfies 𝑓 < 𝑛/3 (𝑛 is the shard size). A secure shard configuration could be realized by [3,15,17,53,54].…”

“…It is crucial to ensure that a majority of participants in each shard are honest, which means the proportion of Byzantine nodes falls within the fault tolerance of the adopted BFT protocol. Therefore, the methods for secure shard configuration become a pivotal area of research, and many prominent works, such as Gearbox [17] (CCS '22), provide remarkable solutions.…”

Graphical Consensus-Based Sharding for Efficient and Secure Sharings in Blockchain-Enabled Internet of Vehicles

“…Moreover, although the sharding BIoVs ensures the security of on-chain data, the off-chain sharings between vehicles and infrastructure are still faced with threats, which is so-called "off-chain attack" [17]. Such issues are important challenges in developing effcient and secure sharing in BIoVs [18], [19], [20].…”

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

“…Blockchain sharding [16], [27], [14], [5], [29], [7], [8], [15], [20], [9], [12], [13], [23], [24] is a method that aims to improve the scalability of a vote-based blockchain system by randomly dividing the network into smaller divisions, called shards. The idea is to increase parallelism and reduce the overhead in the consensus process of each shard, thereby increasing efficiency.…”

“…Recent proposals [7], [21], [22] aim to increase the number of parallel shards by increasing S and decreasing L of each shard. This is based on the fact that S < 1 − L (synchronous model) or S < 1 − 2L (partially synchronous model) holds because given L percent of nodes that attack liveness, a block will only be accepted if at least 1−L or 1−2L percent of nodes respectively have voted in favor of it.…”