Merkle Bridge — Off-Chain State, On-Chain Proof
Status: pre-launch. This page describes target design; this document does not establish a deployed service.
This page describes the target Merkle-bridge design for SPECTRE. Read the mechanism below as protocol architecture unless a narrower runtime proof has explicitly closed the loop.
The Scalability Problem
At scale, the ledger is meant to process thousands of gossip rounds per second across thousands of nodes. Writing every state transition to a Layer 1 ledger would be prohibitively expensive, slow, and would negate the performance gains of the separate hashgraph ledger. But without external anchoring, there is no broad verifiability.
The Merkle Bridge is the intended solution: accumulate state off-chain, compress it into a single Merkle root, and post one transaction per epoch.
How It Works
1. Off-Chain Accumulation (Continuous)
During each epoch (24 hours), each participating SPECTRE node would process gossip rounds and accumulate state transitions such as:
- Proof of Relay lottery ticket claims
- P-score updates from SmallEBM telemetry
- Routing reputation changes
- Immune system flags and resolutions
- Cross-report variance data
Each state transition would be hashed and inserted into a Merkle tree maintained by the node.
Historical committee selection and posting proposal — unresolved research, not current implementation
2. Epoch Closure (Every 24 Hours)
At epoch boundary:
- Each node would compute its local Merkle root from all state transitions in the epoch.
- Nodes would gossip their local roots to the network.
- The top 21 nodes by P-score would be designated as epoch signers.
- The 21 signers would compute the global Merkle root from the union of all local roots.
- Each signer would sign the global root with their node key.
The threshold in the target design is 15 of 21 signatures (>2/3 supermajority) to finalize the epoch root. This is a standard BFT threshold and would tolerate up to 6 Byzantine signers without compromising root integrity.
3. On-Chain Posting (One Transaction)
The finalized epoch root, accompanied by the 15+ signatures, would be posted as a single Hedera Consensus Service (HCS) message. One transaction. One fee. Containing the cryptographic commitment to every state transition that occurred in the network during the 24-hour epoch.
4. Verification (Anytime)
Any party would be able to verify a specific claim against the posted root:
- Request the Merkle proof (the path from the specific leaf to the root) from any SPECTRE node.
- Recompute the root from the proof.
- Compare against the posted root.
If the roots match, inclusion in the committed dataset is verified. This does not establish factual truth, valid execution, authorization, dataset completeness or settlement.
Historical performance-selected trust model and fraud-proof extrapolation — unresolved research, not current implementation
Why Top 21 by P-Score
The signer set is not random in the target design. It is the 21 nodes with the highest P-scores — the nodes that have demonstrated the most consistent combination of coherence (Phi) and viability (V) over their operating history.
P-score selection provides:
- Skin in the game: High-P-score nodes have the most to lose from signing a fraudulent root (P-score would collapse, routing allocation would plummet).
- Competence filter: P-score correlates with uptime, reliability, and honest behavior. Nodes that have earned high scores are empirically the most trustworthy.
- Dynamic rotation: The signer set changes as P-scores change. A node that degrades is replaced. A rising node is included. No fixed committee. No elections. No politics.
Scalability Properties
| Property | Value |
|---|---|
| On-chain transactions per epoch | 1 |
| Off-chain state transitions per epoch | Unbounded |
| Verification cost | O(log N) where N = number of state transitions |
| Signer set size | 21 (top P-score nodes) |
| Signature threshold | 15/21 (BFT supermajority) |
| Epoch length | 24 hours |
The ratio of off-chain work to on-chain cost is effectively infinite. A network processing 1 million state transitions per epoch pays the same on-chain fee as a network processing 1 billion. The Merkle root is the same size regardless of tree depth.
Fraud Proofs
If a signer signs a root containing a fraudulent state transition:
- Any node could submit a fraud proof: the Merkle proof showing the fraudulent leaf, plus evidence that the leaf's content is invalid.
- The fraud proof would be broadcast via SPECTRE gossip.
- The immune system would process the proof and, if valid, slash the offending signer's P-score.
- If the fraud invalidates the epoch root, a corrected root would be computed excluding the fraudulent leaves and re-signed.
The fraud proof mechanism means signers cannot collude to insert false claims without risking detection and P-score destruction.
What the Bridge Carries
Each epoch's Merkle tree contains leaves for:
- Relay rewards: Which nodes earned Proof of Relay payouts, and how much.
- P-score deltas: How each node's P-score changed during the epoch.
- Reputation events: Promotions, demotions, immune flags, and resolutions.
- Routing statistics: Aggregate throughput, latency, and reliability per node.
A posted root is a cryptographic commitment to supplied data. Access, availability, provenance, validity and adversarial coverage require separate controls; it is not an unforgeable index of reality.
The Principle
A posted Merkle root can support inclusion checks against supplied data. The commitment alone proves neither data availability or completeness nor factual validity, consensus safety, authorization or settlement. Transport, ledger finality and capacity require separate evidence.
Historical predecessor wording — retained on 2026-09-27, not active rules
The displaced passages are preserved verbatim for lineage. This retention date is not their original authorship date.
Predecessor passage 1
If the roots match, the claim is verified. The verifier does not need to download the entire state — only the logarithmic-depth proof path.
Predecessor passage 2
This is not raw data. It is compressed, hashed commitments. The raw data would live off-chain on SPECTRE nodes. The posted root would be the unforgeable index.
Historical follow-up wording — retained on 2026-09-27, not active rules
Follow-up predecessor passage 1
One transaction per day. Near-unbounded scalability. Full verifiability. The Merkle Bridge is designed to turn SPECTRE's off-chain hashgraph into an auditable, trust-minimized system without sacrificing the performance that makes hashgraph worth using.