Sharded Recursive zk-SNARK Proofs

TL;DR In a sharded blockchain protocol that utilizes recursive zk-SNARK proofs to enable scalable, private cross-shard transactions with constant-size proofs of validity. This architecture allows for horizontal scaling while maintaining strong privacy guarantees.

Background Existing blockchain systems face significant challenges in terms of scalability and privacy. Sharding is a promising approach to improve transaction throughput by parallelizing computation across multiple chains. However, cross-shard communication remains a bottleneck, as verifying transactions across shards typically requires expensive cross-shard proofs.

Zero-knowledge proofs, particularly zk-SNARKs, offer a powerful tool for enhancing privacy by allowing users to prove knowledge of secret information without revealing it. Unfortunately, generating and verifying zk-SNARK proofs incurs high computational overhead, limiting their practicality for large-scale applications.

Prior solutions have attempted to combine zk-SNARKs with sharding, but fail to fully address the scalability challenges. For example, Zexe uses zk-SNARKs in a sharded setting but requires storing a linear-size “state proof” on-chain. Coda achieves constant-size proofs using recursive composition, but lacks the horizontal scaling benefits of sharding.

Proposal We introduce a novel construction that synergistically combines sharding with recursive zk-SNARK proofs for unparalleled scalability and privacy.

At the core of this DLT is a hierarchy of zk-SNARK proofs that recursively attest to the validity of state transitions within and across shards. Each shard generates succinct proofs, called Zero-Knowledge Balance & Inclusion State Proofs (ZkBISPs), certifying the correctness of their local state updates. These ZkBISPs are then aggregated by a designated coordinator into a global proof, termed a Zero-Knowledge Succinct Nested Global-state Proof (ZkSNGP).

Crucially, the ZkSNGP is a constant-size proof that recursively verifies the validity of all shard-level ZkBISPs, thereby providing a succinct and efficient means to prove the integrity of the entire cross-shard state transition. Verifying the ZkSNGP requires only logarithmic time in the number of shards, enabling exponential savings compared to naively checking each shard’s proofs individually.

Formally, we define the intra-shard state transition language \mathcal{L}_{\mathsf{ST}}^{(t,i)} for each shard i at epoch t as the set of tuples (x, w) where:

  • The statement x = (\mathsf{shardID}_i, \mathsf{root}_i^{(t-1)}, \mathsf{root}_i^{(t)}, B_i^{(t)}) includes the shard ID, starting and ending state roots, and final account balances.
  • The witness w = (\mathsf{txs}_i^{(t)}, \mathcal{T}_i^{(t-1)}, \mathcal{T}_i^{(t)}) contains the list of transactions, along with the initial and final account state trees.
  • (x, w) \in \mathcal{L}_{\mathsf{ST}}^{(t,i)} \Leftrightarrow \mathsf{root}_i^{(t-1)} = H(\mathcal{T}_i^{(t-1)}) \wedge \mathsf{root}_i^{(t)} = H(\mathcal{T}_i^{(t)}) \wedge \text{transition}(\mathcal{T}_i^{(t-1)}, \mathsf{txs}_i^{(t)}) \rightarrow \mathcal{T}_i^{(t)}, i.e, the roots match the account trees and the final tree results from applying valid transactions to the initial tree.

Similarly, we define the cross-shard state transition language \mathcal{L}_{\mathsf{CST}}^{(t)} for epoch t as the set of tuples (x, w) where:

  • The statement x = (\mathsf{root}_G^{(t-1)}, \mathsf{root}_G^{(t)}) consists of the starting and ending global state roots.
  • The witness w = \left(\left\{\left(\mathsf{shardID}_i, \pi_{\mathsf{ST},i}^{(t)}, \mathsf{root}_i^{(t-1)},\mathsf{root}_i^{(t)}, B_i^{(t)}\right)\right\}_{i=1}^{\ell},\mathcal{T}_G^{(t-1)},\mathcal{T}_G^{(t)}\right) includes the shard IDs, ZkBISPs, local roots and balances, and global account trees.
  • (x, w) \in \mathcal{L}_{\mathsf{CST}}^{(t)} \Leftrightarrow \forall i: \mathsf{Verify}_{\mathsf{ST}}(\mathsf{vk}_{\mathsf{ST}}, x_i, \pi_{\mathsf{ST},i}^{(t)}) \wedge \mathsf{root}_G^{(t-1)} = H(\mathcal{T}_G^{(t-1)}) \wedge \mathsf{root}_G^{(t)} = H(\mathcal{T}_G^{(t)}) \wedge \text{merge}(\mathcal{T}_G^{(t-1)}, \{\mathsf{root}_i^{(t)}, B_i^{(t)}\}_{i=1}^{\ell}) \rightarrow \mathcal{T}_G^{(t)}, i.e., the ZkBISPs verify w.r.t. their shards, the Merkle roots match, and the final global tree is the result of correctly merging the shards’ final local trees and balances.

A shard’s ZkBISP for epoch t is generated as \pi_{\mathsf{ST},i}^{(t)} \leftarrow \mathsf{Prove}_{\mathsf{ST}}(\mathsf{pk}_{\mathsf{ST}}, x_i, w_i) for (x_i, w_i) \in \mathcal{L}_{\mathsf{ST}}^{(t,i)}, where \mathsf{pk}_{\mathsf{ST}} is the proving key for the corresponding zk-SNARK scheme. The coordinator’s ZkSNGP is computed analogously as \pi_{\mathsf{CST}}^{(t)} \leftarrow \mathsf{Prove}_{\mathsf{CST}}(\mathsf{pk}_{\mathsf{CST}}, x, w) for (x, w) \in \mathcal{L}_{\mathsf{CST}}^{(t)}

The coordinator, randomly selected in each epoch, collects these ZkBISPs along with the shards’ final state roots \mathsf{root}_i^{(t)} and account balances B_i^{(t)}. It then generates the ZkSNGP \pi_{\mathsf{CST}}^{(t)} (green proof) certifying the validity of the overall state transition, including the correct application of all shard-level updates to the global state.

Advantages The network simultaneously achieves exceptional horizontal scalability and privacy without sacrificing security or decentralization.

In terms of scalability, the concept supports an unprecedented number of shards and transactions per second while retaining a constant-size proof of the system’s entire state. Concretely, if there are \ell shards each processing N transactions, the communication cost per epoch is only O(\ell) for the coordinator to collect the ZkBISPs, and the ZkSNGP proof adds just O(1) to the blockchain size. Crucially, verifying the ZkSNGP requires O(\log \ell) time, an exponential speedup compared to naively verifying all \ell shards.

For example, suppose the network is instantiated with \ell = 2^{10} shards, each processing N = 2^{20} transactions in 2-minute epochs. This configuration could support a peak throughput of roughly 1 billion transactions per epoch, or 500,000 transactions per second, with a ZkSNGP verification time of only 10\log \ell \approx 100 ms on ordinary hardware. The recursive proof would contribute a mere 1 KB to the blockchain per epoch, maintaining years of history in a highly compact format.

In terms of privacy, the ZkSNGPs inherit the zero-knowledge property of the underlying zk-SNARK scheme, revealing nothing about the shards’ local transactions beyond the final state roots and balances. An adversary that compromises the coordinator cannot glean any additional information, as the shards’ ZkBISPs are similarly zero-knowledge. Transactional privacy thus holds as long as at least one shard remains honest.

Compared to prior sharded blockchain designs, the network is the first to achieve sublinear proof sizes and verification times by recursively composing zk-SNARKs. Relative to Zexe, the network attains a qualitative improvement in scalability by eliminating the linear-size “state proof” in favor of constant-size ZkSNGPs. Compared to Coda, the network offers strictly stronger performance due to its sharded architecture, while still leveraging Coda’s core technique of recursive proof composition.

Applications the network’s dual emphasis on scalability and privacy renders it a natural foundation for a variety of high-throughput, privacy-centric blockchain applications.

On the payments front, the network could serve as a backend for a globally-scalable digital currency with strong confidentiality guarantees, concealing both transaction amounts and participants. The subtransactions within each shard could clear near-instantaneously, while cross-shard payments would incur a maximum delay of one epoch (e.g., 2 minutes) before the ZkSNGP confirms finality. This would support a substantially higher payment volume than existing solutions like Zcash without leaking metadata.

More broadly, the network could function as a privacy-preserving platform for general smart contract execution. Shards would not only process token transfers but also arbitrary state transitions, with the ZkBISPs and ZkSNGP verifying the correctness of all contract logic and dependencies. This would enable complex applications such as private decentralized exchanges, automated market makers, and lending protocols to run at scale, without disclosing individual users’ balances or positions.

The network’s sharded architecture could also be adapted to specific domains to meet their unique performance requirements. For instance, a decentralized adtech ecosystem that handles billions of micropayments per day could utilize more granular sharding (e.g., \ell = 2^{20} shards), with each shard perhaps corresponding to a particular geographic region or publisher. A secure messaging app that routes payments alongside packets could likewise tune its cross-shard spanning tree structure based on network topology.

Conclusion the network introduces a powerful new paradigm for designing scalable and private blockchain protocols through recursive zk-SNARK proof composition. By strategically combining recursive proofs with sharding, the network enables a significant breakthrough in blockchain performance, supporting over a million transactions per second with sublinear proof sizes and verification times.


Almost a year already spent on this, so as you can imagine, we are well beyond just PoC. Q&A welcome. Here or -

By incorporating Triadic Consensus: A Fast and Resilient Consensus Mechanism for Sharded Blockchains with this ZKP method, the coordinator could be autonomous in its decision making, simply responding to the supermajority.

intra-shard probalistic, inter-shard deterministic.

Pull-in Client-Side Ordinal Transaction Ordering (COTO) - #2 by cryptskii to remove T.O. from consensus.

I like the idea; it’s actually the same thing that we’re doing for the zkSharding concept (Section 7).
I think one important part here is that proofs still require time to generate and aggregate. Aggregation adds delays compared to zkRollups.
From here, a question arises: should the execution system be decentralized-and-verified or centralized-but-verified, similar to modern zkRollups? What do you think?

decentralized-and-verified 100%

for topology:

This will run as EVM but the ZkSNGPs with be anchored to Bitcoin like so:

Example Workflow

  1. Generate zkSNGPs: At regular intervals (e.g., end of each epoch), generate zkSNGPs for all state transitions.
  2. Aggregate zkSNGPs: Collect a predefined number of zkSNGPs or aggregate over a specific time period.
  3. Create Merkle Tree: Construct a Merkle tree with zkSNGP hashes as leaves.
  4. Compute Merkle Root: Compute the Merkle root of the tree.
  5. Create Bitcoin Transaction: Embed the Merkle root in the OP_RETURN field of a Bitcoin transaction.
  6. Broadcast Transaction: Broadcast this transaction to the Bitcoin network.
  7. Store Batch Information: Record the batch details and the corresponding Bitcoin transaction ID in your L1 system.
import hashlib
from bitcoinlib.transactions import Transaction, OP_RETURN

def create_merkle_root(hashes):
    if len(hashes) == 1:
        return hashes[0]
    if len(hashes) % 2 != 0:
    new_level = []
    for i in range(0, len(hashes), 2):
        new_hash = hashlib.sha256(hashes[i] + hashes[i+1]).hexdigest()
    return create_merkle_root(new_level)

def create_bitcoin_transaction(merkle_root):
    tx = Transaction()
    tx.add_output(OP_RETURN, merkle_root)
    tx.sign()  # Sign the transaction with appropriate private keys
    return tx

zkSNGPs = [...]  # List of zkSNGP hashes
merkle_root = create_merkle_root(zkSNGPs)
bitcoin_tx = create_bitcoin_transaction(merkle_root)
bitcoin_tx.broadcast()  # Broadcast to Bitcoin network

# Store batch metadata in L1 system
batch_metadata = {
    'merkle_root': merkle_root,
    'bitcoin_tx_id': bitcoin_tx.txid,
    'zkSNGPs': zkSNGPs


  1. Immutability and Data Integrity: By committing zkSNGPs to the Bitcoin blockchain, ProofChain inherits Bitcoin’s immutability properties. Once a batch of zkSNGPs is recorded on the Bitcoin blockchain, it becomes part of BTC’s immutable ledger, providing a tamper-proof and verifiable history of ProofChain’s state transitions on Bitcoin.

  2. Decentralized Security: Anchoring zkSNGPs to Bitcoin distributes the security of ProofChain across the decentralized Bitcoin network. The Bitcoin blockchain is maintained by a vast network of miners, making it extremely difficult for any single entity to compromise the integrity of the zkSNGPs stored on it.

  3. Timely Finality: Bitcoin’s proof-of-work consensus mechanism ensures timely finality of transactions. Once a Bitcoin transaction containing a batch of zkSNGPs is confirmed and included in a block, it is considered final and irreversible. This provides a reliable and timely mechanism for ProofChain to achieve finality for its state transitions.

  4. Simplified Verification Process: By leveraging Bitcoin’s existing infrastructure and tools, the verification process for zkSNGPs becomes simplified. Verifiers can utilize Bitcoin’s block explorers, APIs, and libraries to efficiently verify the presence and integrity of zkSNGPs on the Bitcoin blockchain.

  5. Backup and Redundancy: Committing zkSNGPs to the Bitcoin blockchain acts as a backup mechanism for ProofChain. In the event of any data loss or system failure on ProofChain’s end, the zkSNGPs stored on the Bitcoin blockchain can be used to recover and validate the state of the ProofChain ledger.

1 Like

Expanding on the original post, we propose enhancing the protocol by leveraging Verkle trees [^1] for state commitments within each shard. Verkle trees are a drop-in replacement for Merkle trees that offer substantially smaller proofs by replacing hashing with vector commitments.

Concretely, let \mathbf{F} be a finite field. A polynomial commitment over \mathbf{F} consists of three algorithms (\mathsf{Setup}, \mathsf{Commit}, \mathsf{Open}):

  • \mathsf{Setup}(1^\lambda, d) \to (\mathsf{pk}, \mathsf{vk}): On input security parameter 1^\lambda and polynomial degree bound d, output public parameters \mathsf{pk} and verification key \mathsf{vk}.

  • \mathsf{Commit}(\mathsf{pk}, f(X)) \to c: On input \mathsf{pk} and polynomial f(X) \in \mathbf{F}_{\leq d}[X], output a commitment c.

  • \mathsf{Open}(\mathsf{pk}, f(X), r, v) \to \pi: On input \mathsf{pk}, polynomial f(X), evaluation point r \in \mathbf{F}, and claimed value v \in \mathbf{F}, output an evaluation proof \pi attesting that f(r) = v.

  • \mathsf{Verify}(\mathsf{vk}, c, r, v, \pi) \to \{0,1\}: On input \mathsf{vk}, commitment c, point r, claimed value v, and proof \pi, output 1 if f(r) = v for the polynomial f(X) committed in c, else 0.

In our construction, each shard S_i maintains a Verkle tree \mathcal{T}_i^{(t)} over its state at epoch t. For a tree of arity b and depth d, the leaves are partitioned into b^{d-1} groups, each interpolated by a polynomial f_{i,j}(X) \in \mathbf{F}_{\leq b-1}[X]. The root commitment is computed as c_{i,0} := \mathsf{Commit}(\mathsf{pk}, f_{i,0}(X)), where f_{i,0}(X) interpolates the commitments to f_{i,1}(X), \ldots, f_{i,b}(X).

To generate the \mathsf{zkBISP} for shard S_i, the statement x_i now includes the Verkle root commitments c_{i,0}^{(t-1)} and c_{i,0}^{(t)} in place of Merkle roots:

\begin{aligned} x_i &= (i, c_{i,0}^{(t-1)}, c_{i,0}^{(t)}, \mathbf{B}_i^{(t)}) \\ w_i &= (\mathbf{txs}_i^{(t)}, \mathcal{T}_i^{(t-1)}, \mathcal{T}_i^{(t)}) \end{aligned}

The shard proves the inclusion of its state updates in the Verkle tree by computing evaluation proofs for each modified leaf:

\{\pi_{i,j}^{(t)} \leftarrow \mathsf{Open}(\mathsf{pk}, f_{i,j}(X), r_{i,j}, v_{i,j}^{(t)})\}_{j=1}^m

Here r_{i,j} is the leaf position and v_{i,j}^{(t)} is the leaf value after applying \mathbf{txs}_i^{(t)}.

The coordinator’s \mathsf{zkSNGP} relation \mathcal{R}_\mathsf{CST}^{(t)} is modified to include the shards’ Verkle commitments and proofs:

\begin{aligned} x &= (c_{G,0}^{(t-1)}, c_{G,0}^{(t)}) \\ w &= (\{\mathsf{zkBISP}_i^{(t)}, c_{i,0}^{(t)}, \{\pi_{i,j}^{(t)}\}_{j=1}^m\}_{i=1}^\ell, \mathcal{T}_G^{(t-1)}, \mathcal{T}_G^{(t)}, \{\mathbf{txs}_{ij}^{(t)}\}_{i,j=1}^\ell) \end{aligned}

To verify the \mathsf{zkSNGP}, clients check that:

  1. \mathsf{Verify}(\mathsf{vk}_\mathsf{ST}, x_i, \pi_{\mathsf{ST},i}^{(t)}) = 1 for each \mathsf{zkBISP}_i^{(t)}, i.e., the per-shard proofs are valid.

  2. \mathsf{Verify}(\mathsf{vk}, c_{i,j}^{(t)}, r_{i,j}, v_{i,j}^{(t)}, \pi_{i,j}^{(t)}) = 1 for each Verkle proof \pi_{i,j}^{(t)}, i.e., the claimed leaf updates are correct.

  3. \mathsf{merge}(\mathcal{T}_G^{(t-1)}, \{c_{i,0}^{(t)}\}_{i=1}^\ell, \{\mathbf{txs}_{ij}^{(t)}\}_{i,j=1}^\ell) = \mathcal{T}_G^{(t)}, i.e., the final global tree is consistent with the shards’ commitments and cross-shard transactions.

By replacing Merkle trees with Verkle trees, we reduce the size of state inclusion proofs from O(d \cdot \lambda) to O(d \cdot (\log b + \lambda)), where \lambda is the security parameter. This yields a corresponding reduction in the size of \mathsf{zkBISP} and \mathsf{zkSNGP} proofs.

For a concrete example, suppose each shard maintains a tree with 1 billion leaves, i.e., b = 1024 and d = 10. With Merkle trees using \lambda = 256 bit hashes, each inclusion proof requires 2560 bits. With Verkle trees, setting \log b = 10 and using the same \lambda, the proofs are just 266 bits each, nearly a 10\times savings.

More notably, since Verkle proofs are constant-size in the witness length, we can aggregate updates across many leaves into a single \mathsf{zkBISP} without significantly increasing the proof size. If each shard batches k leaf updates into a single \mathsf{zkBISP}, the amortized proof size per update is just O((\log b + \lambda)/k), an exponential savings over Merkle proofs which grow linearly in k.

In summary, augmenting our protocol with Verkle trees for state commitments offers compounding improvements in performance and scalability:

  1. Each shard can compute succinct proofs for large batches of state updates, reducing the number of \mathsf{zkBISP} s generated per epoch.

  2. The size of each \mathsf{zkBISP} and the aggregate \mathsf{zkSNGP} is substantially reduced, minimizing on-chain storage costs.

  3. Shards can verifiably update more state per epoch without increasing the cross-shard proof verification overhead.

By achieving sublinear proof sizes in both the number of shards and the amount of state updated per shard, our Verkle-enhanced design offers a significant scalability improvement while preserving the strong privacy guarantees of the original protocol.

[^1]: J. Kuszmaul. Verkle Trees.

Privacy Analysis

The use of Verkle trees not only improves scalability but also enhances the privacy properties of our sharded blockchain protocol. We analyze the privacy guarantees both within and across shards.

Intra-Shard Privacy

For transactions within a single shard S_i, the \mathsf{zkBISP} relation ensures that the proof \pi_{\mathsf{ST},i}^{(t)} leaks no information about the shard’s internal transactions \mathbf{txs}_i^{(t)} beyond what is revealed by the initial and final state commitments c_{i,0}^{(t-1)} and c_{i,0}^{(t)}.

Specifically, let \mathcal{T}_i^{(t-1)} and \mathcal{T}_i^{(t)} be the Verkle trees representing the shard’s state at the start and end of epoch t, respectively. The \mathsf{zkBISP} for shard S_i satisfies the following privacy property:

For any two sets of transactions \mathbf{txs}_i^{(t)}, \widetilde{\mathbf{txs}}_i^{(t)} that result in the same final state \mathcal{T}_i^{(t)} when applied to \mathcal{T}_i^{(t-1)}, the corresponding proofs \pi_{\mathsf{ST},i}^{(t)} \leftarrow \mathsf{Prove}(\mathsf{pk}_\mathsf{ST}, x_i, w_i) and \tilde{\pi}_{\mathsf{ST},i}^{(t)} \leftarrow \mathsf{Prove}(\mathsf{pk}_\mathsf{ST}, x_i, \tilde{w}_i), where

\begin{aligned} w_i &= (\mathbf{txs}_i^{(t)}, \mathcal{T}_i^{(t-1)}, \mathcal{T}_i^{(t)}) \\ \tilde{w}_i &= (\widetilde{\mathbf{txs}}_i^{(t)}, \mathcal{T}_i^{(t-1)}, \mathcal{T}_i^{(t)}) \end{aligned}

are computationally indistinguishable.

This property, which follows directly from the zero-knowledge guarantee of the zk-SNARK, implies that the \mathsf{zkBISP} does not leak any information about the specific transactions executed by the shard, only the final Verkle tree commitment c_{i,0}^{(t)}.

Cross-Shard Privacy

For transactions that span multiple shards, the \mathsf{zkSNGP} provides strong privacy guarantees at both the coordinator and verifier level.

First, due to the zero-knowledge property of the \mathsf{zkBISP} s, the coordinator learns nothing about the shards’ internal transactions \mathbf{txs}_i^{(t)} or the details of any cross-shard transactions \mathbf{txs}_{ij}^{(t)} beyond the final Verkle commitments c_{i,0}^{(t)} and account balances \mathbf{B}_i^{(t)}.

Second, when verifying the \mathsf{zkSNGP}, clients do not learn any information beyond the initial and final global state roots c_{G,0}^{(t-1)} and c_{G,0}^{(t)} (which are already public). The zk-SNARK proof \pi_\mathsf{CST}^{(t)} ensures that the final state is consistent with some set of valid cross-shard transactions, without revealing their details.

In essence, while each shard’s \mathsf{zkBISP} “encrypts” its local transactions, the coordinator’s \mathsf{zkSNGP} provides an “encrypted” aggregation that hides information between shards. This enables clients to verify the correctness of the global state transition without compromising privacy.

From a formal perspective, we can model this privacy property as an indistinguishability game. The adversary is given the initial global state \mathcal{T}_G^{(t-1)} and two sets of valid cross-shard transactions \{\mathbf{txs}_{ij}^{(t)}\}_{i,j=1}^\ell and \{\widetilde{\mathbf{txs}}_{ij}^{(t)}\}_{i,j=1}^\ell that result in the same final state \mathcal{T}_G^{(t)}. It must then distinguish whether the \mathsf{zkSNGP} \pi_\mathsf{CST}^{(t)} was generated using the first or second set.

By the zero-knowledge property of the zk-SNARK, the adversary’s advantage in this game is negligible. Essentially, the \mathsf{zkSNGP} reveals only that some set of cross-shard transactions was executed, without specifying which one.

Optimizations and Tradeoffs

While our protocol provides strong privacy guarantees, there are several knobs we can tune to achieve different tradeoffs between performance and privacy:

  1. Balancing local and global privacy: The size of each shard’s \mathsf{zkBISP} grows with the number of transactions executed locally, while the global \mathsf{zkSNGP} proof has size independent of the total transaction count. Thus, increasing the number of shards allows more total transactions to be processed per epoch with the same proof size, but with each transaction receiving weaker privacy guarantees (as it is hidden among a smaller anonymity set within its shard). Conversely, using fewer shards provides stronger per-transaction privacy, but with higher on-chain proof sizes.

  2. Adjusting update frequency: Shards can generate \mathsf{zkBISP} 's less frequently (e.g., every k epochs for some k > 1) to reduce proving overheads, at the cost of delayed finality for cross-shard transactions. This tradeoff allows the system to adapt to environments with varying requirements for confirmation latency.

  3. Selective disclosure: If desired, shards can reveal specific transaction details to clients off-chain by providing the corresponding witnesses. This allows opt-in transparency for cases where privacy is not required, without compromising the privacy of other transactions. However, these disclosures must be done carefully to avoid linking transactions that are intended to be anonymous.

In practice, we envision shards being able to adjust these parameters dynamically based on their specific privacy and performance requirements. By providing this flexibility, our protocol can support a wide range of applications with varying demands for anonymity and scalability.


By combining Verkle trees for state commitments with recursive zk-SNARKs for proof aggregation, our sharded blockchain protocol achieves both scalability and privacy. The use of Verkle trees enables succinct proofs of large state transitions within each shard, while the zk-SNARK proof composition allows shards to execute cross-chain transactions without revealing their contents.

Compared to existing solutions, our protocol offers several key advantages:

  1. Horizontal scaling via parallel transaction processing across many shards.
  2. Sublinear growth in on-chain proof sizes, even as the number of shards and transactions per shard increases.
  3. Strong privacy for both intra-shard and cross-shard transactions, without sacrificing verifiability.

Through this combination of layer-1 sharding and cryptographic privacy, our protocol provides a foundation for building scalable and secure decentralized applications. As blockchain adoption continues to grow, we believe these techniques will be increasingly essential for enabling mainstream use cases with demanding performance and privacy requirements.

Future work in this area could explore enhancements such as multi-round sharding, optimistic execution, and dynamic shard rebalancing to further improve scalability and efficiency. These optimizations, together with application-specific customization of the protocol parameters, offer promising avenues for expanding the reach and impact of our design.

Ultimately, by creating trustless systems that can protect user privacy while still scaling to real-world workloads, we can help realize the full potential of blockchain technology to transform how we interact and transact online.