Architecture¶

Overview¶

zkSTAR couples an Extended Kalman Filter (EKF) anomaly detector with two zkSNARK circuits that let a regulator verify the detector's outputs without accessing raw process data.

┌─────────────────────────────────────────────────────────────────┐
│  ICS Operator (Utility)                                         │
│                                                                 │
│   Sensor readings  ──►  KFLSTMModel (EKF forward pass)         │
│                              │                                  │
│               ┌──────────────┼──────────────┐                  │
│               ▼              ▼              ▼                   │
│         Prediction      Innovation       State                  │
│          Circuit         Residuals      Estimate                │
│         (zkSNARK)            │                                  │
│               │              ▼                                  │
│               │       Hypothesis Circuit                        │
│               │         (zkSNARK)                               │
│               │              │                                  │
└───────────────┼──────────────┼─────────────────────────────────┘
                │ proof        │ alarm decision + proof
                ▼              ▼
┌─────────────────────────────────────────────────────────────────┐
│  Regulator                                                      │
│                                                                 │
│   ezkl.verify(proof, vk, settings)  ──►  compliance decision   │
└─────────────────────────────────────────────────────────────────┘

EKF-LSTM Model¶

The KFLSTMModel implements a nonlinear Kalman filter whose sub-models are parameterised by neural networks:

State transition (LSTMModel) — an LSTM that maps the current hidden state to the predicted next state.
Observation decoder (FeedForwardDecoder) — a feed-forward network that maps the hidden state to the predicted measurement space.
Covariance predictors — separate feed-forward networks that output the process noise covariance Q and observation noise covariance R.

At each timestep the model computes:

Predicted state and covariance via the LSTM transition.
Innovation residual δy = y − ŷ.
Innovation covariance CPCT_cov = C P Cᵀ + R.
Optimal Kalman gain K = P Cᵀ (CPCT_cov)⁻¹.
Updated state estimate and covariance.

See KFLSTMModel for full API details.

DVAL Interval¶

Rather than generating one proof per timestep, zkSTAR batches D consecutive EKF steps into a single proof interval (the DVAL interval). Within each interval, the innovation residuals and covariances are accumulated:

sum_dy       = Σ δyᵢ     (i = 0 … D−1)
sum_CPCT_cov = Σ CPCT_covᵢ

This amortises circuit overhead across D timesteps. The D value is configured via the D_VAL environment variable (default: 120).

Prediction Circuit¶

The PredictionWrapper exposes fixed-length forward1, forward2, forward4, … methods, each compiled to a separate ONNX graph by ezkl. The circuit takes padded EKF inputs (with one trailing nonce column per tensor for ezkl's Poseidon hash commitment) and outputs the updated state, accumulated residuals, and Kalman check status — all with nonce columns appended.

The Kalman check (KalmanReconstructionCheck) verifies inside the circuit that the supplied Kalman gain is consistent with the supplied covariance, preventing a malicious utility from substituting an incorrect gain.

See PredictionWrapper and zkSNARK utilities.

Hypothesis Circuit¶

The HypothesisTest module takes the DVAL-accumulated sum_dy and sum_CPCT_cov, whitens the residual using a pre-supplied SVD factorisation, computes the chi-squared statistic, and compares it against the Upper Control Limit (UCL = chi2.ppf(1 − α, df=MD)).

The SVD check (SVDReconstructionCheck) verifies inside the circuit that the supplied U and S factors correctly represent the inverse of sum_CPCT_cov, preventing manipulation of the whitening step.

The circuit output includes:

Output	Description
`alarm_status`	1 if chi-squared statistic > UCL
`svd_check_status`	1 if SVD reconstruction passes
`kcr_status`	Accumulated Kalman check result
`chi_squared_statistic`	Raw test statistic (sensitive; not in public proof)
`svd_diff`	Element-wise SVD reconstruction error
`svd_threshold`	Per-element tolerance used in SVD check

See HypothesisTest & Checks.

Lazy, On-Demand Proving¶

zkSTAR decouples detection from compliance verification. During normal operations, the utility runs the EKF forward pass and chi-squared hypothesis test using the same circuit computations that underlie the zkSNARK proofs — but without invoking the prover. Detection runs continuously at full speed with no proving overhead.

Witness inputs for each DVAL interval (EKF state, covariance, Jacobians, Kalman gains, residuals, nonce values) are retained in storage. When a regulator requests compliance verification for a specific time period — whether as part of a routine audit or in response to an incident — the utility generates a proof for that interval on demand, asynchronously, without disrupting ongoing detection.

Normal operation:
  sensor data → EKF forward pass → alarm decision   (no proof generated)
                     ↓
              witness retained in storage

On regulator challenge:
  stored witness → ezkl prove → proof file → regulator verifies

This means proving is an audit-time cost, not a real-time operational cost. The infrastructure requirement is storage for witness data over the regulatory retention window, not a continuously running high-performance prover.

Docker Container Layout¶

Container	Mode	Role
`utility-setup`	one-shot	Compiles both circuits, runs the ezkl trusted setup, writes tolerance marker to `PRELOADED_PROOF_ROOT`
`utility-gen-witness`	one-shot	Runs the full EKF forward pass, dumps circuit inputs, generates all witnesses
`utility-prover`	long-running	Serves the utility REST API; calls ezkl to produce prediction and hypothesis proofs on demand
`utility-stats-logger`	long-running	Collects Docker resource metrics; serves proof hash and check-result snapshots
`regulator`	one-shot	Fetches VK/settings from the utility, verifies proofs, logs compliance decisions