Skip to main content

LayerEdge BSN

The LayerEdge BSN guarantees that all zk-proofs processed within the system remain:

  • Publicly accessible
  • Cryptographically committed
  • Tamper-evident
  • Efficiently verifiable without requiring full data replication

This system is essential for preserving decentralization and trust in a network that handles potentially millions of zk-proofs across rollups, L2s, oracles, and off-chain computation systems.


Purpose and Role​

Traditional blockchain designs often require nodes to store and reprocess all submitted data — an approach that doesn't scale for proof-heavy systems like zk-rollups or recursive aggregation networks.

The LayerEdge BSN solves this by providing:

  • Lightweight access to proof inclusion
  • Immutable commitments to all proofs in a given batch
  • Efficient detection of missing, tampered, or excluded data

This enables zk-verification to scale while maintaining auditable and tamper-resistant data inclusion, even for light clients.


Architecture: The LayerEdge BSN​

The LayerEdge BSN operates as a sovereign Cosmos-based chain purpose-built for data availability and zk-proof anchoring.

Key Functions:​

  • Publishes Merkle roots representing zk-proofs submitted in each verification epoch
  • Maintains timestamped attestations of when batches are committed
  • Allows on-demand querying for proof inclusion and status
  • Serves as a persistent availability layer ensuring verifiable proof storage

The BSN acts as the durable metadata backbone for the broader LayerEdge protocol.


Merkle Tree Construction​

Proofs submitted to the LayerEdge BSN are organized using Merkle tree commitments for secure, efficient verification.

Step-by-Step Process​

1. Per-Proof Hashing​

Every normalized zk-proof πi\pi_i is first hashed individually:

  • Default hash: SHA-256
  • ZK-friendly hash (optional): Poseidon
Hi=H(πi)Hi=H(πi)H_i = H(\pi_i)H_i = H(\pi_i)

These hashes represent the base data for Merkle tree leaves.

2. Merkle Leaves​

All H(πi)H(\pi_i) hashes are used as leaves in the Merkle tree.

Leafnodes:H(π1),H(π2),...,H(πn)Leaf nodes: H(\pi_1), H(\pi_2),..., H(\pi_n)

3. Tree Building​

3. Tree Building​

  • Hash pairs of adjacent leaves:
H1−2=H(H(π1)∣∣H(π2))H3−4=H(H(π3)∣∣H(π4))H_{1-2} = H(H(\pi_1)||H(\pi_2))H_{3-4} = H(H(\pi_3)||H(\pi_4))
  • Repeat recursively until a single Merkle root is produced.
MerkleRoot=root(H(π1),H(π2),...,H(πn))MerkleRoot = root(H(\pi_1), H(\pi_2), ..., H(\pi_n))

This Merkle root is then published on the LayerEdge BSN, representing a verifiable commitment to the full batch of proofs.


Data Retrieval & Verification​

Merkle Path Queries​

Clients can verify proof inclusion by retrieving the Merkle path from leaf to root. Each query only requires:

  • The proof hash H(πi)H(\pi_i)
  • Its sibling hashes up the tree
  • The committed root MerkleRoot\text{MerkleRoot}

This allows verification in O(log n) time with minimal data transfer - ideal for light clients.

Tamper Detection​

Merkle commitments are collision-resistant. Any alteration to a proof or its hash:

  • Breaks the path to the root
  • Makes it impossible to re-derive the committed root
  • Flags the tampering attempt instantly

This ensures a cryptographically sound availability model for all zk-verification operations.


Cross-Layer Interactions​

Aggregated Proof Commitment​

  • The final recursive proof πagg\pi_{agg} can itself be hashed and committed as a node in the Merkle tree
  • This creates a two-level integrity system:
    • Raw proofs at the leaf level
    • Aggregated proofs or summaries at internal nodes or anchors

This supports both fine-grained auditability and high-level finality checks.

Light Node Integration​

Light Nodes actively rely on the DA Layer for:

  • Verifying that their zk-proofs are included
  • Detecting omission or tampering
  • Independently querying the BSN for committed Merkle roots
  • Attesting that a given aggregated batch includes their participation

This makes the DA system foundational for trust-minimized light clients, enabling full protocol participation without needing to store all data.


Use Cases​

Use CaseRole of LayerEdge BSN
zk-Rollup AggregationCommits to each rollup’s proofs for later verification
AI Model AuditingVerifies off-chain zkML inference was committed
Decentralized OraclesEnsures data feeds have provable zk-backed computation
Staking / Airdrop ValidationCommits proof of participation or task completion for rewards
Light Node IncentivesTracks and verifies which users’ nodes contributed valid proofs

Performance Advantages​

FeatureBenefit
LightweightVerifiers only need log(n) hashes per proof
ScalableBatches millions of proofs into a single commitment
ImmutableOnce published on BSN, commitments are tamper-proof
Trustless QueriesLight clients can audit participation without full state
Modular DesignFuture support for off-chain DA attestations or zkRollup-DA bridges

Summary​

The LayerEdge BSN is a core trust foundation in LayerEdge:

  • It allows zk-proofs to be anchored and verified without full replication
  • It ensures data integrity, auditability, and low-bandwidth inclusion verification
  • It empowers lightweight clients, auditors, and ecosystem integrators to verify inclusion independently
  • It bridges zk-verification to modular, sovereign DA infrastructure on the LayerEdge BSN

By using Merkle commitments, log-time queries, and cross-layer integrity hooks, the DA Layer ensures that every proof matters — and none can be hidden.