Source-linked AI summary
SharPer: Sharding Permissioned Blockchains Over Network Clusters
Mohammad Javad Amiri, Divyakant Agrawal, Amr El Abbadi
TL;DR
Blockchain scalability and efficient cross-shard processing remain difficult, especially for permissioned systems. SharPer clusters nodes, shards data, maintains partial ledger views, and uses flattened cross-shard consensus to exploit parallelism. Experiments report the strongest performance advantage when workloads contain a low percentage of cross-shard transactions, while that advantage diminishes at high percentages.
Problem
Blockchain scalability limits business adoption, and existing sharding approaches do not efficiently address cross-shard transactions.
Method
SharPer partitions nodes into crash-only or Byzantine clusters, assigns replicated data shards to clusters, maintains cluster ledger views, and orders cross-shard transactions through flattened consensus.
Results
SharPer performs three to four times better than FPaxos and active/passive replication when cross-shard workloads are below 20%, while retaining higher throughput than AHL at 80% and 100% cross-shard workloads.
Takeaways & Limitations
SharPer’s parallel processing is most beneficial for typical partitioned-database workloads with relatively few cross-shard transactions.
Takeaways & Limitations
At high cross-shard percentages, sharding has no significant advantage and FPaxos or active-passive replication can provide better performance, especially lower latency.
Abstract
from arXiv · showhide
Scalability is one of the main roadblocks to business adoption of blockchain systems. Despite recent intensive research on using sharding techniques to enhance the scalability of blockchain systems, existing solutions do not efficiently address cross-shard transactions. In this paper, we introduce SharPer, a permissioned blockchain system that improves scalability by clustering (partitioning) the nodes and assigning different data shards to different clusters where each data shard is replicated on the nodes of a cluster. SharPer supports both intra-shard and cross-shard transactions and processes intra-shard transactions of different clusters as well as cross-shard transactions with non-overlapping clusters simultaneously. In SharPer, the blockchain ledger is formed as a directed acyclic graph where each cluster maintains only a view of the ledger. SharPer also incorporates a flattened protocol to establish consensus among clusters on the order of cross-shard transactions. The experimental results reveal the efficiency of SharPer in terms of performance and scalability especially in workloads with a low percentage of cross-shard transactions.
1 Introduction
SharPer addresses blockchain scalability and cross-shard processing by partitioning nodes and data into clusters while exploiting parallelism. It targets permissioned networks with many non-faulty nodes and orders non-overlapping cross-shard transactions concurrently.
- Motivation: Scalability remains a major obstacle to blockchain business adoption, while block-size and off-chain approaches introduce propagation, verification, decentralization, or security concerns.Increasing block size raises propagation and verification costs; off-chain solutions face security issues, especially denial-of-service attacks.
- Motivation: Data sharding improves distributed-database scalability by maintaining multiple shards on different subsets of nodes, but cross-shard support remains a challenge.Permissioned systems such as Fabric require trusted channels or atomic commit for cross-shard transactions, while Cosmos requires bidirectional trusted channels.
- Motivation: Using all available permissioned-blockchain nodes for consensus can degrade performance because message exchanges grow quadratically without improved resiliency.Existing active/passive and reduced-replica techniques do not utilize the extra nodes for parallel transaction processing.
- SharPer: SharPer partitions nodes into clusters of 2f + 1 crash-only or 3f + 1 Byzantine nodes, targeting networks with a very high percentage of non-faulty nodes.The system expands prior work by adding consensus protocols for intra- and cross-shard transactions and designing a scalable implementation.
- SharPer: SharPer supports intra-shard and cross-shard transactions, processing independent cluster workloads concurrently and ordering cross-shard transactions among involved clusters.Cross-shard transactions with non-overlapping clusters can be ordered in parallel using flattened consensus protocols.
2 The SHARPER Model
The SharPer model clusters nodes, assigns each cluster a replicated data shard, and gives each cluster a ledger view. Its ledger and transaction organization support parallel processing while coordinating cross-shard ordering.
- Infrastructure: SharPer assigns each data shard to a cluster, whose nodes replicate that shard and maintain a corresponding view of the blockchain ledger.The system is designed for asynchronous networks with crash-only or Byzantine failures and many non-faulty nodes.
- Cluster and Shard Formation: Crash-only clusters contain 2f + 1 nodes, whereas Byzantine clusters contain 3f + 1 nodes; nodes are primarily grouped by geographical proximity.The number of clusters depends on the node count, tolerated failures, and failure model.
- Cluster and Shard Formation: Workload-aware sharding seeks to keep records accessed by one transaction in the same shard, although some transactions still access multiple shards.Such distributed transactions require cross-shard coordination.
- Blockchain Ledger: Transactions accessing one shard can be ordered locally, while transactions on disjoint shard subsets can be added concurrently.Cross-shard labels encode each transaction’s order among transactions of every involved cluster.
- Blockchain Ledger: SharPer’s ledger is a directed acyclic graph represented as the union of cluster-specific physical views rather than maintained in its entirety by any cluster.Each view contains local intra-shard transactions and cross-shard transactions involving that cluster’s shard.
- Transaction Model: SharPer uses the account-based transaction model, and cross-shard correctness is achieved through a global consensus protocol.This contrasts with UTXO-based approaches that avoid distributed commit but may have isolation or blocking issues.
3 Consensus with Crash-Only Nodes
SharPer establishes consensus for intra-shard and cross-shard transactions among clustered crash-only nodes. Intra-shard transactions proceed locally, while cross-shard transactions coordinate involved clusters and preserve consistent ordering.
- 3.1 Intra-shard consensus: SharPer uses 2f+1 nodes per cluster and multi-Paxos to order intra-shard transactions in crash-only networks.The primary assigns sequence numbers, multicasts proposals, and commits after receiving f+1 matching accepts from other nodes.
- 3.2 Cross-Shard Consensus: Cross-shard transactions require agreement among all involved clusters so each appends them in the same order.SharPer coordinates only the clusters accessed by the transaction.
- 3.2 Cross-Shard Consensus: A primary multicasts a proposed cross-shard request, collects f+1 matching accepts from every involved cluster, and broadcasts a commit containing their sequence numbers.Nodes append and execute the transaction after receiving a valid commit and completing lower-sequence transactions.
- 3.2 Cross-Shard Consensus: Transactions involving disjoint clusters can proceed concurrently, as illustrated by two cross-shard flows over four clusters with three nodes each.The concurrent flows concern crash-only nodes and transactions accessing disjoint shards.
- 3.4 Primary Failure Handling: Primary failure handling uses timeouts to let replicas make progress while preserving completed-client history.Cross-shard requests use a larger timeout because they require agreement from multiple clusters.
- 3.5 Correctness: SharPer’s crash-only consensus satisfies agreement, validity, consistency, and termination.Quorum intersection supports agreement after primary failure, while the lemmas state validity, cross-cluster ordering consistency, and eventual completion.
4 Consensus with Byzantine Nodes
SharPer extends clustered consensus to Byzantine nodes using larger quorums, signed messages, and view changes. Its correctness arguments establish safety and liveness for intra- and cross-shard processing, while hybrid failure models remain supported.
- 4.1 Byzantine consensus: Byzantine-tolerant clusters contain 3f+1 nodes and use quorums of 2f+1 for cross-shard consensus.All involved clusters participate, and signed messages address malicious primary behavior.
- 4.2 Cross-Shard Consensus with Byzantine Nodes: The Byzantine cross-shard protocol validates signed proposals, gathers matching accepts from every involved cluster, and then gathers matching commit messages.A transaction commits only when the required 2f+1 evidence is obtained from each involved cluster.
- 4.2 Cross-Shard Consensus with Byzantine Nodes: Two concurrent cross-shard transactions over disjoint shards are illustrated in a four-cluster network with four nodes per cluster.The example uses f = 1 Byzantine fault per cluster.
- 4.5 Correctness Arguments: The Byzantine protocol’s propose and accept phases prevent two different requests from being committed with the same sequence number.The argument relies on quorum composition, where at least f+1 nodes in each 3f+1-node cluster are non-faulty.
- 4.5 Correctness Arguments: View changes preserve previously accepted requests because the commit and view-change quorums intersect in at least one correct node.This propagates accepted requests into subsequent views.
- 4.5 Correctness Arguments: SharPer’s Byzantine consensus satisfies agreement, validity, consistency, and termination.The paper states these properties through dedicated lemmas and correctness arguments.
- 4.6 An Optimization for Clustered Networks: SharPer can combine crash-only and Byzantine consensus across clusters in hybrid cloud environments.A hybrid fault-tolerant protocol such as SeeMoRe can order cross-shard transactions across clusters with different failure models.
5 Experimental Evaluations
SharPer’s evaluation shows that sharding improves throughput and scalability, especially when cross-shard transactions are uncommon. Cross-shard overhead reduces throughput, but parallel processing of non-overlapping transactions preserves an advantage over comparison systems.
- Crash-only networks: With no cross-shard transactions, SharPer processed 35230 transactions at 91 ms latency before throughput saturation in crash-only networks.Its throughput was substantially higher than APR-C and FPaxos in the same setting.
- Crash-only networks: At 20% cross-shard transactions, SharPer processed 23000 transactions at 100 ms latency, compared with 21000 for AHL-C.The advantage reflects parallel processing of non-overlapping cross-shard transactions and fewer communication phases.
- Crash-only networks: At 80% and 100% cross-shard transactions, SharPer’s peak throughput fell to 12300 and 10500, respectively.At 100% cross-shard transactions, SharPer’s peak throughput was 44% higher than AHL-C’s, although sharding offered no significant advantage at the highest cross-shard shares.
- Byzantine networks: In Byzantine networks with no cross-shard transactions, SharPer processed more than 25000 transactions at 200 ms latency.APR-B and FaB processed 5900 and 6800 transactions, respectively, in comparison.
- Byzantine networks: At 20% cross-shard transactions, SharPer’s peak throughput was 18700 at 240 ms latency and reached 320% and 270% of APR-B’s and FaB’s throughput, respectively.SharPer processed 15% more transactions than AHL-B at their respective peak throughputs.
- Scalability with more nodes: Increasing clusters increased throughput almost linearly under crash failures and enhanced throughput under Byzantine failures.SharPer processed 37000 transactions with five crash-only clusters and more than 27000 with five Byzantine clusters.
- Discussion: With 20% or less cross-shard transactions, SharPer outperformed the alternatives under both failure models and improved semi-linearly as clusters increased.With high cross-shard percentages, sharding had no significant advantage, while non-overlapping transactions still improved SharPer’s throughput.
6 Related Work
Related work applies sharding, replication, and consensus techniques to blockchain scalability and fault tolerance. SharPer distinguishes itself by combining clustered sharding with parallel processing of disjoint-shard transactions and a DAG ledger view.
- Replication and consensus: Paxos and related replication techniques establish crash-fault tolerance with 2f+1 nodes, while extra nodes can reduce communication phases or serve as passive replicas.These approaches address fault tolerance but do not inherently partition transaction processing across clusters.
- Permissioned blockchain sharding: Permissioned blockchains such as Fabric use channels to process intra-shard transactions efficiently, but cross-shard transactions require trusted channels or atomic commit protocols.This motivates protocols that handle cross-shard agreement without relying on those mechanisms.
- Scalability limitations: Increasing nodes does not necessarily improve blockchain performance when every transaction must be processed by every node.SharPer addresses this limitation by partitioning nodes into clusters that process transactions in parallel.
- Blockchain sharding: Sharding is widely used in permissionless and permissioned blockchains to improve scalability, including Elastico, OmniLedger, Rapidchain, Fabric, AHL, Cosmos, and RSCoin.Existing systems differ in node assignment, consensus, and cross-shard coordination mechanisms.
- Cross-shard coordination: OmniLedger uses an atomic cross-shard protocol but requires clients to actively coordinate a lock/unlock protocol.AHL instead uses trusted hardware, a reference committee, two-phase commit, and two-phase locking for cross-shard transactions.
- DAG-based systems: Unlike DAG blockchains that parallelize block construction, SharPer processes intra-shard transactions of different clusters simultaneously because they access disjoint data shards.This produces lower latency and higher throughput within SharPer’s clustered design.
7 Conclusion
SharPer targets networks with many more nodes than required for fault tolerance by partitioning nodes into clusters and processing transactions in parallel. Its ledger views and flattened consensus support concurrent cross-shard processing, while experiments report better performance in typical low-cross-shard workloads.
- SharPer targets networks with N ≫ 3f + 1 Byzantine nodes or N ≫ 2f + 1 crash-only nodes.The design is intended for networks with a very high percentage of non-faulty nodes.
- Nodes are partitioned into fault-tolerant clusters, enabling transactions on different clusters to be processed in parallel.Clusters contain 3f + 1 Byzantine or 2f + 1 crash-only nodes.
- Each cluster maintains a ledger view containing its intra-shard transactions and the cross-shard transactions in which it participates.The global ledger is a directed acyclic graph that no single node maintains in full.
- A flattened consensus protocol orders cross-shard transactions without relying on extra nodes or trusted participants.SharPer also processes cross-shard transactions involving non-overlapping clusters in parallel.
- SharPer demonstrates better performance with crash-only and Byzantine nodes in workloads containing a low percentage of cross-shard transactions.The paper characterizes these workloads as typical settings and compares SharPer with other approaches.