PyloChain: Hierarchical Sharded Blockchain

Updated 9 July 2026

PyloChain is a permissioned hierarchical sharded blockchain that uses lower-level local chains for speculative transaction execution and a higher-level main chain for global coordination and availability.
It leverages a partially synchronous DAG-based mempool combined with Byzantine Fault Tolerance to achieve significant throughput improvements (1.49x) and reduced latency (2.63x) over comparable systems.
The design incorporates a simple scheduling technique and fine-grained auditing to reduce transaction aborts and ensure reliable cross-shard execution and state repair.

Searching arXiv for papers on PyloChain and closely related hierarchical sharded blockchain work. PyloChain is a permissioned hierarchical sharded blockchain designed to balance performance and availability in sharded blockchain deployments. It consists of multiple lower-level local chains and one higher-level main chain. The local chains speculatively execute local transactions to obtain high parallelism, while the main chain uses a directed-acyclic-graph (DAG)-based mempool together with Byzantine Fault Tolerance (BFT) consensus to guarantee local block availability and to execute global (or cross-shard) transactions within a collocated sharding design. The system also introduces a simple scheduling technique to reduce aborted local transactions and a fine-grained auditing mechanism that externalizes main-chain operations to local members. The reported implementation shows 1.49x higher throughput and 2.63x faster latency than the state-of-the-art balanced hierarchical sharded blockchain under the highlighted comparison setting (Jo et al., 20 Aug 2025).

1. Design objective and problem setting

PyloChain is motivated by the classical tension in blockchain sharding: aggressive sharding improves throughput, but typically weakens availability because each shard is stored by fewer machines. The paper distinguishes two broad design points. In availability-favored sharding, every server maintains all shards, which preserves availability but increases storage, networking, and consensus costs. In performance-favored sharding, each shard is stored only by a disjoint subset of nodes, which reduces per-node cost but makes a shard unavailable if its committee fails or is partitioned. PyloChain is explicitly presented as a system that tries to avoid choosing only one side of that tradeoff (Jo et al., 20 Aug 2025).

The balancing strategy is hierarchical. At the lower layer, local members keep only one shard, preserving the main scalability benefit of sharding. At the upper layer, full members keep all shards, preserving availability when some local shard group becomes unavailable. This means PyloChain neither fully replicates everything at every node nor isolates shards completely. Instead, it assigns parallelism and lower per-node cost to local chains and cross-zone availability and global coordination to the main chain (Jo et al., 20 Aug 2025).

The paper positions PyloChain relative to prior balanced hierarchical sharding, especially DyloChain. It keeps the hierarchical O-X-O-V structure but replaces DyloChain’s synchronous upper layer with a more scalable partially synchronous DAG/BFT design, adds a scheduling rule for abort reduction, and introduces fine-grained auditing of the upper layer (Jo et al., 20 Aug 2025).

2. Hierarchical structure and participant roles

PyloChain uses a two-level hierarchy organized into zones. A zone is a logical shard domain. Each zone contains one full member that participates in the global main chain and multiple local members that participate only in that zone’s local chain (Jo et al., 20 Aug 2025).

Component	Scope	Function
Local chain	Per zone	Stores a single shard and speculatively executes local transactions
Main chain	Global	Stores or references local blocks from all zones and executes global transactions
Full member	Local + global	Stores a full copy of all shards and relays information between layers
Local member	Zone-local	Stores one shard and audits the full member using externalized evidence

At the lower level, each local chain stores a single shard, local execution state, and the locally agreed block sequence. Its role is to execute local transactions speculatively, package both local and global transactions into local blocks, and certify local blocks using PBFT-like local consensus. At the higher level, the main chain stores or references local blocks from all zones, establishes a global order, validates local transactions against global state, executes global transactions, and produces sync entries used to reconcile local chains (Jo et al., 20 Aug 2025).

The full member is the critical bridge between the two layers. It belongs to one zone, participates in the local chain of that zone, also participates in the global main chain, stores a full copy of all shards, and relays messages in both directions. By contrast, a local member belongs only to its own zone, stores only that zone’s shard, participates in local consensus, verifies speculative execution for local transactions, cannot directly verify global transactions, and instead audits the full member’s behavior through exposed certificates and timing evidence (Jo et al., 20 Aug 2025).

A central architectural term is collocated sharding. In the paper’s usage, this means that a server holds all shards locally, so cross-shard access can be performed without an isolated-shard commit protocol. PyloChain uses collocation only at the full members. Local members remain sharded, whereas the main chain can execute global transactions on full members that already possess all shard data (Jo et al., 20 Aug 2025).

3. Transaction model and end-to-end processing

PyloChain uses the O-X-O-V classification inherited from DyloChain. The state database is key-value based, and each state item is modeled as a tuple

$(key, value, version)$

where the version is defined using block number and transaction offset. Ownership metadata maps each key to a shard (Jo et al., 20 Aug 2025).

A transaction is local if it accesses only a single shard. A transaction is global if it accesses multiple shards or remote-shard state. This distinction determines the execution path. Local transactions are executed speculatively in the local chain and later validated on the main chain. Global transactions are not executed in the local chain; they are carried upward through certified local blocks and executed only at the main chain (Jo et al., 20 Aug 2025).

For a local transaction, the full member executes it locally, computes its read/write set, and updates the local shard state speculatively. The full member then packages transactions into a local block, which may contain both local transactions with computed read/write sets and global transactions that were not executed locally. Local members verify the block’s integrity, the correctness of speculative execution for local transactions, and the validity of the read/write sets. If the block is accepted, local members also speculatively update local state and endorse the block, producing a local commit certificate (Jo et al., 20 Aug 2025).

Once a local block is certified, the full member disseminates it upward. The main-chain protocol begins with reliable local block distribution. After receiving a local block certificate for block $b_i^z$ from zone $z$ , a full member stores the block in $\mathcal{M}_z$ and broadcasts

$\langle \text{REPL}, z, i, b_i^z \rangle_{\sigma_p}$

to all full members. The receivers store $b_i^z$ and reply with

$\langle \text{ACK}, z, i, D(b_i^z) \rangle_{\sigma_q}.$

After collecting $2f_F+1$ ACKs, the block obtains an availability guarantee. The proposer then forms a DAG vertex containing digests of consecutive ready local blocks and invokes

$DAG.\textsf{Include}(candidates, cert_{avail}).$

Full members execute Bullshark locally over the DAG. In even rounds, each full member selects a predetermined anchor vertex, and the committed sub-DAG between anchors becomes a main block (Jo et al., 20 Aug 2025).

Main-block processing follows a specific schedule. First,

$globalTXs \leftarrow \text{extract global TXs from } B$

and

$b_i^z$ 0

The system then iterates over local transactions in the main block. For each local transaction,

$b_i^z$ 1

If validation succeeds, the system applies

$b_i^z$ 2

Otherwise it creates repair metadata by appending the latest main-chain state for the transaction’s written keys. After local transactions have been handled, the system processes each global transaction by

$b_i^z$ 3

then appends its writes to sync entries and applies

$b_i^z$ 4

For each write $b_i^z$ 5 in a write set, the repair logic computes

$b_i^z$ 6

and

$b_i^z$ 7

then appends $b_i^z$ 8 to $b_i^z$ 9 (Jo et al., 20 Aug 2025).

This workflow resolves conflicts by combining speculative local execution, global total ordering, MVCC validation on the main chain, and downward state synchronization. Local transactions that have become stale with respect to the globally ordered main-chain state are aborted, and the authoritative values are pushed back into the affected zones through sync entries (Jo et al., 20 Aug 2025).

4. Consensus, availability, and auditing

PyloChain assumes a permissioned consortium blockchain with Byzantine thresholds defined separately for the two layers. For each local chain, there are

$z$ 0

local members, with up to

$z$ 1

Byzantine faults. For the main chain, there are

$z$ 2

full members, with up to

$z$ 3

Byzantine faults. Availability of a local block at the main-chain layer is established after gathering

$z$ 4

ACKs. Local block integrity depends on signatures from

$z$ 5

local members, while main-chain processing integrity depends on signatures from

$z$ 6

full members (Jo et al., 20 Aug 2025).

The network model is partially synchronous. PyloChain assumes alternating asynchronous and synchronous intervals, asynchronous behavior lasting up to global stabilization time $z$ 7, and message delivery within $z$ 8 after GST. The main chain combines a Narwhal-style DAG mempool with Bullshark consensus. The paper’s rationale is that the DAG separates data dissemination and availability from ordering, allowing full members to distribute local blocks at network speed and enabling Bullshark to commit a causal history of many vertices using anchor selection rather than a strict linear dissemination bottleneck (Jo et al., 20 Aug 2025).

The paper states three correctness properties. Validity says that if a local block is agreed upon in a local chain, it will eventually be confirmed on the main chain. Bottom-up Consistency says that for two local blocks $z$ 9 and $\mathcal{M}_z$ 0 from local chain $\mathcal{M}_z$ 1, if

$\mathcal{M}_z$ 2

then $\mathcal{M}_z$ 3 must be ordered before $\mathcal{M}_z$ 4 on the main chain. Top-down Consistency says that a local chain does not finalize any transactions inconsistent with main-chain processing results. Cross-shard atomicity is not stated as a separate theorem in the conventional two-phase-commit sense; instead, global transactions are executed directly on the collocated main chain and synchronized downward (Jo et al., 20 Aug 2025).

A distinctive feature of PyloChain is its fine-grained auditing mechanism. Because full members are the only participants that directly bridge local and main chains, they are a potential source of bottom-up attacks and top-down attacks. To mitigate this asymmetry, the full member must externalize phase-specific evidence of local block availability, DAG mempool inclusion, main block consensus, and main block processing to local members. Local members verify the local block certificate $\mathcal{M}_z$ 5, the availability certificate $\mathcal{M}_z$ 6, the processing certificate $\mathcal{M}_z$ 7, and the order of local block headers inside the processing certificate (Jo et al., 20 Aug 2025).

The auditing logic relies on explicit timing bounds. For local block availability,

$\mathcal{M}_z$ 8

DAG mempool inclusion also takes

$\mathcal{M}_z$ 9

main block consensus takes

$\langle \text{REPL}, z, i, b_i^z \rangle_{\sigma_p}$ 0

and the main block processing certificate takes

$\langle \text{REPL}, z, i, b_i^z \rangle_{\sigma_p}$ 1

The paper also summarizes an upper-layer delay of

$\langle \text{REPL}, z, i, b_i^z \rangle_{\sigma_p}$ 2

to receive main-block processing evidence. If the expected evidence does not arrive, local members conservatively wait up to $\langle \text{REPL}, z, i, b_i^z \rangle_{\sigma_p}$ 3; only after that do they deem the full member malicious and trigger replacement and recovery (Jo et al., 20 Aug 2025).

5. Scheduling, interference, and state repair

Because PyloChain speculatively executes local transactions before final global ordering, interference can occur when later global transactions invalidate those local speculative results. This effect becomes more pronounced when the DAG-based upper layer aggregates many local blocks into one main block, increasing the amount of globally ordered work that can conflict with speculative state (Jo et al., 20 Aug 2025).

To reduce this effect, PyloChain introduces a simple scheduling technique: within a main block, the system processes all local transactions first, then processes all global transactions. In the pseudocode, this is represented by first extracting

$\langle \text{REPL}, z, i, b_i^z \rangle_{\sigma_p}$ 4

and then validating and updating local transactions before executing the elements of globalTXs. The paper’s stated intuition is that a global transaction in a given main block cannot retroactively invalidate local transactions from that same block if local validation is completed first (Jo et al., 20 Aug 2025).

This mechanism does not eliminate interference across subsequent main blocks, but it reduces interference within the same main block. The effect is fewer aborted local transactions, fewer sync entries, and more useful committed work. The paper also notes an additional implication: when global transactions are pushed to the end, independent local blocks from different zones can be processed in parallel more effectively (Jo et al., 20 Aug 2025).

The repair mechanism is tightly integrated with scheduling. If a local transaction fails MVCC validation against the globally ordered main-chain state, PyloChain uses sync entries to carry the authoritative values back to the affected local chain. For global transactions, sync entries carry committed writes. For aborted local transactions, sync entries carry the latest main-chain state for the keys in the transaction’s write set (Jo et al., 20 Aug 2025).

6. Implementation, evaluation, and tradeoffs

PyloChain was prototyped in Go for blockchain logic, with Hyperledger Fabric v2.1 as the local-chain baseline, LevelDB for state management, and Rust-based Narwhal/Bullshark for the main-chain DAG/BFT layer. Local members are implemented as peer nodes, and full members combine peer and orderer functionality (Jo et al., 20 Aug 2025).

The evaluation used a cluster of 24 machines connected by 10 Gbps Ethernet, running Ubuntu 20.04 and Docker containers on Docker Swarm overlay network. Deployments scaled to 18 zones. Each zone contained 1 full member, 4 local members, and 4 clients, yielding 18 full members and 72 local members at the largest setting. The workload was the SmallBank micro-payment application with 300k users evenly distributed across zones. The average transaction size was 2.89 KB, the average local block size was 1.4 MB, each worker batch contained one local block, a primary could propose up to 40 digests per vertex, and the primary proposal max delay was 800 ms. Client load was varied from 10k to 110k requests/sec in steps of 10k, and latency was measured from submission to commit event (Jo et al., 20 Aug 2025).

The baselines were DyloChain, availability sharding, and performance sharding. For performance sharding, the comparison implemented a 2PC cross-shard protocol with a designated full member as coordinator. Under 12 zones and 20% global transactions at send rate 90,000, PyloChain (DAG+Sched) achieved 57,263 TPS, with 1.49x higher throughput and 2.63x lower latency than DyloChain, and also 1.39x higher throughput and 2.76x lower latency than PyloChain (DAG) without the scheduling enhancement (Jo et al., 20 Aug 2025).

For all-local workloads, the upper-layer DAG/BFT replacement of DyloChain’s synchronous main chain produced better zone scalability. With 9 zones, PyloChain (DAG) reached 37,432 TPS and 2.67 s, compared with DyloChain’s 35,148 TPS and 3.92 s. With 18 zones, PyloChain (DAG) reached 37,090 TPS and 4.84 s, compared with DyloChain’s 30,672 TPS and 8.13 s (Jo et al., 20 Aug 2025).

The paper also reports main block processing delay. For PyloChain (DAG), delay values were 119 / 94 / 190 ms at 0% global TX, 212 / 193 / 299 ms at 20%, and 241 / 225 / 331 ms at 40%, for 6 / 12 / 18 zones respectively. For PyloChain (DAG+Sched), the corresponding values were 53 / 48 / 81 ms, 105 / 94 / 136 ms, and 145 / 123 / 172 ms. At 12 zones / 20% global TX, the scheduling enhancement reduced processing delay from 193 ms to 94 ms, a 2.05x speedup (Jo et al., 20 Aug 2025).

Interference analysis at 15 zones, 40% global transactions, 80k send rate, and 300k accounts reported abort ratios of 10.20%, 13.19%, and 5.66% for PyloChain (DAG+Sched), described as 1.8x lower than DyloChain and 2.3x lower than PyloChain (DAG). The text notes that the exact mapping of the three percentages to transaction classes is not explained in the prose description (Jo et al., 20 Aug 2025).

Storage cost illustrates the system’s compromise position. In a 1-minute all-local run with 18 zones, availability sharding reached up to 457 GB, the balanced sharding design reached up to 122 GB, and performance sharding reached up to 30.7 GB. The paper therefore presents PyloChain as substantially cheaper than full replication but more expensive than pure performance-oriented isolated-shard designs (Jo et al., 20 Aug 2025).

The paper identifies several limitations. The main chain remains the principal overhead because full members store all shards, broadcast local blocks across zones, and process all global state reconciliation. Speculative execution can still create aborts and repair work. The DAG mempool introduces all-to-all dissemination costs and becomes bandwidth-sensitive; the paper identifies a network bottleneck around 12 zones, largely due to local block broadcasts among full members and Docker overlay network bandwidth limits. The system also assumes partial synchrony, and global transactions are still executed sequentially on the main chain in the current design (Jo et al., 20 Aug 2025).

PyloChain belongs to the literature on hierarchical sharded blockchains for permissioned settings. Within that space, its closest comparison is DyloChain, from which it inherits the hierarchical O-X-O-V structure while changing the upper-layer architecture, introducing scheduling, and adding fine-grained auditing (Jo et al., 20 Aug 2025).

It should not be conflated with several similarly named blockchain systems in other subfields. PlexiChain is a secure blockchain-based flexibility aggregator framework for built environments, demand response, and DSO/TSO-facing flexibility markets, rather than a sharded blockchain for balancing performance and availability (Karumba et al., 2022). PIEChain is a Kafka-based cross-chain communication framework centered on cross-chain services (CC-SVCs) and atomic commit/abort coordination for interoperability across existing blockchains, rather than a hierarchical sharding system (Reijsbergen et al., 2023). Toychain is a simple, lightweight blockchain implemented in Python for swarm robotics research, with Python smart contracts and pluggable Proof-of-Work and Proof-of-Authority consensus, again addressing a different problem space (Pacheco et al., 2024). A further related but distinct design is the Delphinus cross-chain aggregator, a ZK-SNARK based multi-blockchain layer that maintains a synchronized global state across multiple smart-contract chains through proxy contracts and proof-carrying execution, rather than through hierarchical sharding (Gao et al., 2022).

This separation of scope matters because PyloChain’s central contribution is not generic blockchain interoperability, Python-based experimental infrastructure, or blockchain-based flexibility aggregation. Its subject is specifically the balance between local parallelism, cross-zone availability, and global reconciliation in a permissioned hierarchical sharded blockchain. In that sense, PyloChain is best characterized as a two-level architecture in which local chains perform speculative shard-local work, while a main chain with collocated full members provides availability, total ordering, global execution, and auditable correction of speculative state (Jo et al., 20 Aug 2025).