Helix: STARK Proof System
Overview
Helix is the audit trail engine of ULedgerNET. It runs as a sidecar process alongside each validator node and produces STARK proofs: cryptographic checkpoints that compress the entire history of the council's consensus output into a short, verifiable proof.
Helix is the feature that makes "the audit trail cannot be forged" a provable statement rather than a policy claim. It is not an optional component; it is the foundation of ULedgerNET's tamper-evidence guarantee.
What Is a STARK Proof?
A STARK (Scalable Transparent ARgument of Knowledge) is a cryptographic proof that a computation was performed correctly, without requiring the verifier to re-execute the computation.
In ULedgerNET's context:
- The computation is: "the council of nodes reached BFT consensus on these blocks, in this order, with these transaction roots."
- The proof is: a short artifact (a few kilobytes) that mathematically guarantees the above.
- The verifier is: any party with the council's public keys, including an independent auditor with no access to any live node.
ULedgerNET uses Plonky3, a recursive STARK proving system, to generate these proofs.
Why STARK Proofs for Audit Trails?
Traditional audit logs fail under these conditions:
- Administrator compromise: a rogue admin can alter or delete log files.
- System compromise: an attacker who controls the database can rewrite history.
- Vendor access: the platform operator can silently modify records.
- Time-based attacks: logs from weeks ago can be backdated if the log system lacks sequence integrity.
STARK checkpoints eliminate these failure modes:
- Immutable: once a checkpoint proof is generated and distributed, altering the underlying blocks would produce a different proof, immediately detectable by any verifier.
- Transparent: STARK proofs require no trusted setup. There is no secret ceremony or trusted party whose compromise would undermine the proof system.
- Compact: recursive proof folding means the entire chain history is represented in a constant-size proof, regardless of how many blocks exist.
- Verifier-independent: an auditor can verify the proof using only the proof artifact and the council's public keys. No access to the live system, the SDK, or the wallet files is required.
- Post-quantum anchored: checkpoints are signed with both secp256k1 (classical) and ML-DSA-87 (post-quantum) signatures, ensuring the proof remains valid even as classical cryptography is broken.
Helix Architecture
┌─────────────────────────────────────────────────────────────────────┐
│ Council (9 nodes) │
│ │
│ Node 1 Node 2 Node 3 ... Node 9 │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Blocks │ │ Blocks │ │ Blocks │ │ Blocks │ │
│ │ (BFT │ │ (BFT │ │ (BFT │ │ (BFT │ │
│ │ consensus│ │ consensus│ │ consensus│ │ consensus│ │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
│ │ │ │ │ │
│ ┌────▼─────┐ ┌────▼─────┐ ┌────▼─────┐ ┌────▼─────┐ │
│ │ Helix │ │ Helix │ │ Helix │ │ Helix │ │
│ │ Sidecar │ │ Sidecar │ │ Sidecar │ │ Sidecar │ │
│ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │
└─────────────────────────────────────────────────────────────────────┘
│
Epoch batch (block headers + member data)
│
▼
┌──────────────────────────┐
│ Plonky3 STARK Prover │
│ (Rust sidecar process) │
└──────────────────────────┘
│
STARK proof for this epoch
│
▼
┌──────────────────────────┐
│ Recursive Proof Folding │
│ (prior proof ← new proof)│
└──────────────────────────┘
│
Checkpoint written to principal chain
(secp256k1 + ML-DSA-87 cross-anchor)
│
▼
┌──────────────────────────┐
│ Independent Auditor │
│ (no node access needed) │
│ Verifies checkpoint proof│
└──────────────────────────┘
What a Checkpoint Proves
A Helix checkpoint proof mathematically guarantees:
- Quorum consensus: the council members whose signatures appear in the proof actually voted for this checkpoint. A Byzantine minority cannot forge quorum.
- Height chaining: each checkpoint's block height is strictly greater than the prior checkpoint. Gaps are detected; no block can be silently skipped.
- Member-head data availability: the member chains' block data was accessible and consistent at checkpoint time. Withholding or tampering with member data is detected.
- Receipt chain integrity: transaction receipts form a valid Merkle chain. An individual transaction cannot be retroactively inserted or removed.
- Skip-unchanged behavior: epochs where no new blocks were produced are correctly recorded as skipped; checkpoint height does not advance falsely.
- Cross-algorithm anchoring: both classical (secp256k1) and post-quantum (ML-DSA-87) signatures anchor the checkpoint, ensuring durability against future cryptographic advances.
Epoch Cadence
Helix produces checkpoints on a time-driven cadence (auto-minting):
- Each Helix sidecar monitors its node's chain for new finalized blocks.
- After a configured epoch interval (or when a block threshold is reached), the sidecar initiates proof generation.
- Proof generation is performed by the Plonky3 Rust prover subprocess.
- The completed checkpoint is submitted as a
CHECKPOINT_MARKERtransaction to the principal chain. - The independent auditor (running separately from all nodes) fetches and verifies each checkpoint as it appears.
Independent Auditor
The independent auditor is a standalone process (separate from all validator nodes) that:
- Connects to the principal chain via its own endpoint.
- Fetches each
CHECKPOINT_MARKERtransaction as it appears. - Verifies the embedded STARK proof using the
checkpoint_verifytool. - Records pass/fail for each checkpoint.
The auditor has no write access to any chain. It cannot be silenced by a compromised node. Its verification log is the ground truth for whether the audit trail is intact.
Chaos and Resilience
The Helix runbook defines five chaos injection profiles for the Docker cluster:
| Profile | Description |
|---|---|
light | Network delay on a subset of nodes (simulates slow peers). |
medium | Packet loss on a subset of nodes (simulates unreliable links). |
catastrophic | Heavy delay + loss (simulates near-partition). |
byzantine-a | One node sends conflicting votes to different peers. |
byzantine-b | One node withholds block data while participating in consensus. |
Under all profiles, the expected behavior is:
- The council survives: BFT consensus continues with the honest majority.
- Checkpoints are eventually produced: proof generation may be delayed but not halted.
- Recovery converges: the cluster reconverges and resumes normal checkpoint cadence.
- Equivocation is detected: Byzantine nodes attempting to double-sign are identified.
The 20-item pass/fail checklist in the runbook covers all of these scenarios.
What Helix Does Not Prove
Helix proves that the chain's history was recorded correctly; it does not prove:
- That the agents made correct decisions.
- That the smart contract logic is correct.
- That the data submitted to transactions was accurate or truthful.
It proves that whatever was submitted, was submitted: in the stated order, by the stated wallets, at the stated block heights, and agreed upon by a quorum of validators.
Tooling
| Tool | Purpose |
|---|---|
helix sidecar binary | Runs alongside each node; collects blocks, drives prover, submits checkpoints. |
| Plonky3 prover (Rust) | Generates STARK proofs from epoch batches. |
checkpoint_verify | CLI tool for independent auditors; verifies a checkpoint proof without node access. |
| Auditor sidecar | Automated process that fetches and verifies all checkpoints in real time. |