-
Notifications
You must be signed in to change notification settings - Fork 0
Architecture
0xSCADA separates concerns by time domain: control that must be deterministic and fast stays off-chain; the integrity record that must be immutable goes on-chain. The two are bridged by cryptographic batch anchoring.
REAL-TIME DOMAIN (µs) BATCH DOMAIN (s / min)
┌─────────────────────┐ ┌─────────────────────┐
│ EVENT KERNEL │ │ MERKLE KERNEL │
│ • Ring buffer │ │ • Proof generation │
│ • < 50µs latency │ │ • O(log n) verify │
│ • Lock-free │ │ • HSM integration │
│ • PREEMPT_RT │ │ • Batch aggregation│
└─────────┬───────────┘ └─────────┬───────────┘
▼ ▼
┌───────────────┐ ┌───────────────┐
│ CONTROL LOGIC │ │ ANCHOR KERNEL │
│ • Safety │ │ • L2 sync │
│ • Actuators │ │ • Finality │
│ • Real-time │ │ • Gas opt │
└───────────────┘ └───────┬───────┘
▼
┌─────────────────┐
│ BLOCKCHAIN │
│ 0x5CADA │
│ • Immutable │
│ • Audit trails │
│ • Compliance │
└─────────────────┘
The real-time side never waits on the chain. Events are captured deterministically, control logic actuates, and — asynchronously — batches of events are Merkle-aggregated and anchored. A tamper of any anchored event breaks its inclusion proof.
| Kernel | Role | Pipeline | Timescale |
|---|---|---|---|
| Event | Deterministic real-time event processing | Hardware IRQ → ring buffer → control logic → actuator | µs |
| Merkle | Cryptographic proof generation & verification | Event batch → Merkle tree → inclusion proofs → HSM signing | s |
| Anchor | L2 blockchain state synchronization | Merkle root → gas optimization → L2 submit → finality tracking | s–min |
Batching events under one Merkle root before anchoring is what yields the 95–99% gas savings versus anchoring every event individually — while keeping O(log n) verification for any single event.
┌─────────────────────────────┐
│ 0xSCADA PROTOCOL v2.0 │
└──────────────┬──────────────┘
┌─────────────────────┼─────────────────────┐
┌─────▼─────┐ ┌─────▼─────┐ ┌─────▼─────┐
│ CLIENT │◄───────►│ SERVER │◄───────►│ BLOCKCHAIN│
│ React UI │ WebSock │ TS API │ JSON-RPC│ 0x5CADA │
│ Dashboard │ │ Gateway │ │ Clique │
└───────────┘ └─────┬─────┘ └─────┬─────┘
┌─────▼─────┐ ┌─────▼─────┐
│PostgreSQL │ │ Contracts │
│ + Redis │ │ Solidity │
└───────────┘ └───────────┘
┌─────▼─────┐ ┌─────▼─────┐
│FLUX STATE │ │ KERNEL │
│ ENGINE │ │ PREEMPT_RT│
└───────────┘ └───────────┘
INFRASTRUCTURE: Docker │ Kubernetes │ Helm │ ArgoCD │ Prometheus │ Grafana
- Client ↔ Server over WebSocket for real-time tag/alarm/health streaming.
- Server ↔ Blockchain over JSON-RPC for anchoring and verification.
- Flux State Engine publishes world state; Redis caches; PostgreSQL holds sites, assets, alarms, certificates, audit trails, and RBAC.
| Property | Value |
|---|---|
| Chain ID |
0x5CADA (380634) |
| Consensus (EVM chain) | Clique Proof-of-Authority |
| Block time | 5 seconds |
| Base | go-ethereum fork |
The purpose-built production node uses Kuramoto-BFT "Resonant Consensus" over QUIC/NATS, specified in 0xSCADA-node ADR-0001.
Naming note: an earlier BLS-based "Resonant Consensus" proposal was not adopted and is archived at
docs/archive/. The shipping protocol is the Kuramoto-BFT one linked above.
Architecture is governed by numbered ADRs (0008–0025). A few load-bearing ones:
- ADR-0008 Zero-trust agents · ADR-0009 Emergence guardrails · ADR-0010 Agent certification
- ADR-0011 OT-IT convergence · ADR-0012 End-to-end integration · ADR-0013 Autonomous agents
- ADR-0021 Dual-time control plane · ADR-0023 Evolutionary paradox resolution · ADR-0024 Sublinear decoherence prediction · ADR-0025 Living Fano dashboard
Full set: docs/adr/ and docs/decisions/. See also Documentation Map.
0xSCADA — decentralized industrial control · Apache 2.0 · 0x5CADA · "Where atoms meet bits." Verify, not trust.