Table of Contents
Fetching ...

A Hierarchical Sharded Blockchain Balancing Performance and Availability

Yongrae Jo, Chanik Park

TL;DR

PyloChain is proposed, a hierarchical sharded blockchain that balances availability and performance, and provides a fine-grained auditing mechanism to mitigate faulty higher-level members by externalizing main chain operations to lower-level local members.

Abstract

Blockchain networks offer decentralization, transparency, and immutability for managing critical data but encounter scalability problems as the number of network members and transaction issuers grows. Sharding is considered a promising solution to enhance blockchain scalability. However, most existing blockchain sharding techniques prioritize performance at the cost of availability (e.g., a failure in a few servers holding a shard leads to data unavailability). In this paper, we propose PyloChain, a hierarchical sharded blockchain that balances availability and performance. PyloChain consists of multiple lower-level local chains and one higher-level main chain. Each local chain speculatively executes local transactions to achieve high parallelism across multiple local chains. The main chain leverages a directed-acyclic-graph (DAG)-based mempool to guarantee local block availability and to enable efficient Byzantine Fault Tolerance (BFT) consensus to execute global (or cross-shard) transactions within a collocated sharding. PyloChain speculatively executes local transactions across multiple local chains to achieve high parallelism. In order to reduce the number of aborted local transactions, PyloChain applies a simple scheduling technique to handle global transactions in the main chain. PyloChain provides a fine-grained auditing mechanism to mitigate faulty higher-level members by externalizing main chain operations to lower-level local members. We implemented and evaluated PyloChain, demonstrating its performance scalability with 1.49x higher throughput and 2.63x faster latency compared to the state-of-the-art balanced hierarchical sharded blockchain.

A Hierarchical Sharded Blockchain Balancing Performance and Availability

TL;DR

PyloChain is proposed, a hierarchical sharded blockchain that balances availability and performance, and provides a fine-grained auditing mechanism to mitigate faulty higher-level members by externalizing main chain operations to lower-level local members.

Abstract

Blockchain networks offer decentralization, transparency, and immutability for managing critical data but encounter scalability problems as the number of network members and transaction issuers grows. Sharding is considered a promising solution to enhance blockchain scalability. However, most existing blockchain sharding techniques prioritize performance at the cost of availability (e.g., a failure in a few servers holding a shard leads to data unavailability). In this paper, we propose PyloChain, a hierarchical sharded blockchain that balances availability and performance. PyloChain consists of multiple lower-level local chains and one higher-level main chain. Each local chain speculatively executes local transactions to achieve high parallelism across multiple local chains. The main chain leverages a directed-acyclic-graph (DAG)-based mempool to guarantee local block availability and to enable efficient Byzantine Fault Tolerance (BFT) consensus to execute global (or cross-shard) transactions within a collocated sharding. PyloChain speculatively executes local transactions across multiple local chains to achieve high parallelism. In order to reduce the number of aborted local transactions, PyloChain applies a simple scheduling technique to handle global transactions in the main chain. PyloChain provides a fine-grained auditing mechanism to mitigate faulty higher-level members by externalizing main chain operations to lower-level local members. We implemented and evaluated PyloChain, demonstrating its performance scalability with 1.49x higher throughput and 2.63x faster latency compared to the state-of-the-art balanced hierarchical sharded blockchain.

Paper Structure

This paper contains 44 sections, 8 theorems, 5 equations, 10 figures, 1 table, 3 algorithms.

Key Result

Lemma 1

If a full member $q \in \Pi_F^z$ fails to timely relay inter-layer messages to $p \in \Pi_L^z$, such misbehavior is eventually detected and recovered by replacing $q$ with a new full member.

Figures (10)

  • Figure 1: Availability vs. Number of Shards ($N=200$, $p_a=0.995$).
  • Figure 2: System Overview. PyloChain is composed of multiple lower-level local chains and a single higher-level DAG-based main chain.
  • Figure 3: The Main Chain Protocol of PyloChain. Within each sharding zone, full members concurrently distribute their local blocks to ensure availability. They then propose an ordering for these blocks—while preserving their local sequence—for inclusion in the DAG mempool. Subsequently, once a main block is generated by a consensus, each full member processes the main block. Then, the processing results are exchanged among the full members, forming a certificate signed by a quorum of full members before being delivered to the local chains.
  • Figure 4: Comparisons of main block processing. A naive approach simply aggregates a fixed number of local blocks from each local chain into a single main block, resulting in a linearly growing chain with a single processing thread. In contrast, PyloChain (DAG) concurrently appends local blocks from each local chain, and PyloChain (DAG+Sched) further optimizes processing with multiple threads and scheduling.
  • Figure 5: Overall Performance of PyloChain: Each plot represents the performance in terms of throughput and latency, according to the number of zones and the percentage of global transactions, denoted by #Zones / %GlobalTX. For example, "12 / 20%" indicates that the experiment was conducted in 12 zones with 20% of the global transactions.
  • ...and 5 more figures

Theorems & Definitions (18)

  • Definition 4.1: System Model
  • Definition 4.2: Predicates
  • Lemma 1: Eventual Recovery
  • proof : Proof
  • Lemma 2: Eventual Commitment
  • proof
  • Lemma 3: Eventual Synchronization
  • proof
  • Theorem 4.1: Liveness
  • proof
  • ...and 8 more