Skip to content
WitnessChain logo
witnesschain.network
WitnessChain

A Sovereign Post‑Quantum Execution Layer

Threshold Dilithium DKG, enclave-bound key isolation, and sealed computation — specified as invariants under an explicit adversary model.

Development phase: Month 2 — Quantum Fortress
Primary workstreams: T‑Dilithium DKG • SGX enclave hardening • PQC ingress validation

Philosophy

Protocols fail where invariants are absent.

WitnessChain is not a product surface. It is a formal system: actors, messages, state transitions, and failure modes are specified first; implementation is forced to conform.

Most chains ship a VM and call the remainder “consensus”. Trust boundaries are implicit. Security properties are discovered by incident response. Cryptography is bolted on after the fact.

  • No adversary model. Assumptions are unstated, so they cannot be stress‑tested.
  • No determinism. Parallel execution is attempted without explicit state boundaries; reorgs and undefined behavior become protocol features.
  • No credible privacy. “Encryption at rest” is not privacy; execution still leaks.

WitnessChain takes the opposite posture: if a property cannot be stated as an invariant and verified under a concrete threat model, it is not part of the protocol.

Core Architecture

Four pillars. No narrative components.

Each layer is specified as a security boundary with concrete verification rules. This is where protocol engineering starts.
PQC

Post‑Quantum Cryptography

Threshold CRYSTALS‑Dilithium for witness operations, with QROM‑grade reasoning and an explicit ingress validation gate to eliminate malformed‑scalar crash vectors before any parallel worker sees input.
ZK

Zero‑Knowledge + zkVM

RISC‑V zkVM execution with recursive proof aggregation: the chain exports proofs of correct execution, not “trust the validator set”.
FHE

Sealed Computation

TFHE‑class sealed execution on ciphertext state. Privacy is enforced by the computation model: witnesses cannot extract value from data they cannot decrypt.
JAM

JAM Accumulator

JAM‑inspired parallel accumulation: WorkPackages declare explicit state boundaries, enabling deterministic parallel execution with a canonical merge.
System Overview
Mermaid
graph TB
  PQC["Threshold Dilithium (QROM)"] --> EXEC["WorkPackages + SAL"]
  EXEC --> JAM["JAM Accumulator (parallel)"]
  EXEC --> ZK["RISC-V zkVM proofs"]
  EXEC --> FHE["TFHE sealed compute"]
  NET["gRPC over QUIC"] --> PQC

Execution Model

Deterministic parallelism by construction.

Transactions are not allowed to “discover” their state surface at runtime. The scheduler can only parallelize what the protocol can prove non‑conflicting.

WitnessChain uses WorkPackages as a first‑class unit of execution. Each transaction carries a sender‑signed State Access List (SAL): storage slots, callable code hashes, and sealed compute key handles are declared up front.

Off‑list access triggers a deterministic abort: zero state mutation, base gas only, typed receipt, block remains valid. The result is executable determinism under concurrency — not an emergent property of a runtime.

Parallelism is obtained without mutex contention in the hot path: disjoint access masks batch into independent sets, execute in parallel, then merge in a canonical order.

WorkPackages + SAL
Mermaid
graph TD
  TX["Tx + signed SAL"] --> MASK["disjoint_access_list (BitVec)"]
  MASK --> BATCH["Invariant-split partition"]
  BATCH --> PAR["Parallel exec (disjoint shards)"]
  PAR --> MERGE["Canonical merge (sorted)"]
  TX -->|undeclared slot| ABORT["Deterministic abort: no writes"]

Current Phase

Month 2 — Quantum Fortress

Engineering priority is concrete: build the post‑quantum trust anchor and harden the witness execution perimeter before higher layers expand the surface area.
Threshold Dilithium DKG
  • 90-of-101 threshold key material; committee public key is the on-chain anchor.
  • QROM-aware signature security posture; abort behavior is first-class.
  • Bandwidth discipline via multiplexed rounds over QUIC.
Enclave Perimeter (SGX)
  • Remote attestation binds measurement (MRENCLAVE) to published keys.
  • Key isolation for witness signing and sealed compute control paths.
  • Explicit containment: enclave is a boundary, not a trust amplifier.
MPC Channels
  • gRPC over QUIC with multiplexed streams and bounded backpressure.
  • Lock-free I/O↔crypto handoff (reactor/forge bifurcation).
  • Rate-limiting and load shedding against Byzantine peers.
Ingress Hardening
  • SIMD bounds gate rejects malformed lattice scalars before worker dispatch.
  • Deterministic abort receipts for invalid state surface access (SAL).
  • No undefined behavior under concurrency as a protocol invariant.

Roadmap

Sequence, not spectacle.

Roadmaps are security boundaries: each phase expands the surface area only after its trust anchors are stabilized.
Phase 1 — Core
  • Protocol skeleton, state model, baseline consensus wiring.
  • Foundational cryptographic interfaces and invariants.
Done
Phase 2 — PQC + Enclave
  • Threshold Dilithium DKG + committee key anchoring.
  • Remote attestation and enclave-bound signing perimeter.
  • MPC transport hardening (QUIC, backpressure, load shedding).
Current
Phase 3 — Sealed Compute + zkVM
  • TFHE sealed execution pipelines and key management.
  • RISC‑V zkVM proofs + recursive aggregation for light clients.
  • DA sampling, proof-carrying execution receipts.
Next
Phase 4 — Bridges + DA + Expansion
  • Privacy-preserving bridge surfaces with circuit breakers.
  • DA, clients, and cross-domain security boundaries.
  • Public codebase release.
Next

Security Model

Assumptions are explicit or they do not exist.

WitnessChain treats the threat model as the protocol surface. What the adversary can do — and what they cannot — is written down and designed against.
Adversary Capabilities
  • Static corruption of up to 33 witnesses (Byzantine fraction < 1/3).
  • Adaptive corruption below the threshold for sensitive operations (t = 90 of 101).
  • Network control: deliver/delay/reorder messages under bounded delay.
  • Full observation of on-chain state, ciphertexts, and ZK proofs.
Non‑Capabilities (Assumptions)
  • Cannot break MLWE/MSIS hardness (classical or quantum) at chosen parameters.
  • Cannot break IND‑CPA of the FHE scheme used for sealed computation.
  • Cannot observe keys inside honest enclaves (SGX/TrustZone model).
  • Cannot shortcut VDF evaluation beyond sequential bounds.
Threshold Invariants
  • No trusted operators: security reduces to threshold + cryptographic assumptions.
  • Sensitive transitions require t = 90 witness participation; no single key ever exists.
  • Violations fail closed: deterministic aborts, typed receipts, no partial state writes.
Trust Boundaries
  • Hardware root-of-trust is treated as a boundary, not a magic box.
  • Attestation binds enclave measurement to published keys and roles.
  • Protocol rules dominate: witnesses cannot mint privilege via off-chain agreements.

Developer Entry

Inspect the system, not the pitch.

Engineering claims should be falsifiable. The public surface is the specification today; the full implementation will be published at the completion of Phase 4.
Stack
  • Rust core (deterministic execution boundaries)
  • Tokio I/O reactor ↔ Rayon crypto forge separation
  • gRPC over QUIC (HTTP/3) witness channels
  • SIMD ingress validation (AVX2/AVX‑512)
Targets
  • Threshold Dilithium DKG + signing
  • RISC‑V zkVM + recursive aggregation
  • TFHE sealed compute pipelines
  • Explicit State Access Lists (SAL)

Codebase release: end of Phase 4 (Bridges + DA + Expansion).

Final Statement

WitnessChain is not a rollup.
Not a fork. Not an extension.

It is a base layer: a system of invariants with explicit trust boundaries, adversary assumptions, and deterministic execution rules — designed for a post‑quantum horizon.

If a property cannot be verified, it is not part of the protocol.

If execution cannot be made deterministic, it is not parallelized.

If secrecy depends on good behavior, it is not privacy.