---
title: 'PyloChain: Hierarchical Sharded Blockchain'
url: https://www.emergentmind.com/topics/pylochain
type: topic
---

# PyloChain: Hierarchical Sharded Blockchain

Searching arXiv for recent 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 [2508.14457].

## 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 [2508.14457].

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 [2508.14457].

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 [2508.14457].

## 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 [2508.14457].

| 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 [2508.14457].

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 [2508.14457].

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 [2508.14457].

## 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 [2508.14457].

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 [2508.14457].

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** [2508.14457].

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** [2508.14457].

Main-block processing follows a specific schedule. First,

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

and

$$
\textit{SyncEntries} \leftarrow \{\}.
$$

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

$$
res \leftarrow \textsf{Validate}(tx).
$$

If validation succeeds, the system applies

$$
\textsf{Update}(tx).
$$

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

$$
rwset \leftarrow \textsf{Execute}(tx),
$$

then appends its writes to sync entries and applies

$$
\textsf{Update}(tx).
$$

For each write \(w\) in a write set, the repair logic computes

$$
z \leftarrow \textsf{Ownership}(w.key)
$$

and

$$
v_{lat} \leftarrow \textsf{GetStates}(z, w.key),
$$

then appends \(\{txid, w.key, v_{lat}\}\) to \(\textit{SyncEntries}_z\) [2508.14457].

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 [2508.14457].

## 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

$$
3f_L + 1
$$

local members, with up to

$$
f_L
$$

Byzantine faults. For the main chain, there are

$$
3f_F + 1
$$

full members, with up to

$$
f_F
$$

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

$$
2f_F + 1
$$

ACKs. Local block integrity depends on signatures from

$$
2f_L + 1
$$

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

$$
2f_F + 1
$$

full members [2508.14457].

The network model is **partially synchronous**. PyloChain assumes alternating asynchronous and synchronous intervals, asynchronous behavior lasting up to global stabilization time \(\Delta_{GST}\), and message delivery within \(\Delta_{Sync}\) 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 [2508.14457].

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 \(b_x^i\) and \(b_x^j\) from local chain \(x\), if

$$
i < j
$$

then \(b_x^i\) must be ordered before \(b_x^j\) 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 [2508.14457].

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** \(cert_{local}\), the **availability certificate** \(cert_{avail}\), the **processing certificate** \(cert_{proc}\), and the order of local block headers inside the processing certificate [2508.14457].

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

$$
\Delta_{avail} = 3\Delta_{Sync}.
$$

DAG mempool inclusion also takes

$$
3\Delta_{Sync},
$$

main block consensus takes

$$
4\Delta_{Sync},
$$

and the main block processing certificate takes

$$
\Delta_{proc} = 2\Delta_{Sync}.
$$

The paper also summarizes an upper-layer delay of

$$
9\Delta_{Sync} = 3\Delta_{Sync} + 4\Delta_{Sync} + 2\Delta_{Sync}
$$

to receive main-block processing evidence. If the expected evidence does not arrive, local members conservatively wait up to \(\Delta_{GST}\); only after that do they deem the full member malicious and trigger replacement and recovery [2508.14457].

## 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 [2508.14457].

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

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

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 [2508.14457].

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 [2508.14457].

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 [2508.14457].

## 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 [2508.14457].

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 [2508.14457].

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 [2508.14457].

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** [2508.14457].

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 [2508.14457].

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 [2508.14457].

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 [2508.14457].

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 [2508.14457].

## 7. Scope, nomenclature, and related systems

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 [2508.14457].

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 [2212.09064]. **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 [2306.09735]. **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 [2407.06630]. 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 [2209.02974].

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 [2508.14457].

Source: https://www.emergentmind.com/topics/pylochain