Prototype Node Architecture Specification

This document specifies the architecture of a single ENF Protocol testnet node with sufficient precision to identify the engineering unknowns that must be resolved before implementation begins. It is not a whitepaper, an investor document, or a completed design. It is a build target — the minimum specification needed to answer "can we build it?" with real data instead of estimates.

The document addresses each layer of the node stack in order, from physical grid interface to ledger, specifying: what the layer must produce, what inputs it requires, what format those inputs and outputs take, and where the open questions are. Open questions are flagged explicitly with UNKNOWN markers.

A complete node consists of six functional layers above the physical grid. Each layer consumes the output of the layer below it and produces a defined artifact for the layer above.

Each arrow represents a specification problem. This document works through each one.

The grid is the physical source. No node component controls it. The node's interface to the grid is through a standard wall outlet, from which the ENF sensor draws both power and signal.

Requirements

The ENF sensor measures the instantaneous frequency of the mains supply and produces a signed time-series of frequency readings. This is the primary ENF signal. The camera witness (Layer 2) provides a secondary, independent signal for cross-correlation.

Hardware options

Output specification

{
  "layer": "enf_sensor",
  "node_id": "string (ed25519 public key)",
  "grid_region": "string (e.g. WECC-CA, NPCC-NY)",
  "sample_rate_hz": 1000,
  "window_seconds": 60,
  "nominal_hz": 60.0,
  "samples": [
    {
      "t_unix_ms": 1748000000000,
      "freq_hz": 59.9873,
      "snr_db": 42.1
    }
    // ... one entry per ms
  ],
  "window_hash": "sha256 of samples array",
  "signature": "ed25519 signature over window_hash"
}

Open questions

The camera witness extracts ENF signal from video by analyzing luminance fluctuation in each frame. Artificial lighting driven by grid power flickers at the grid frequency and its harmonics. The camera captures this flicker passively, producing an independent ENF time-series that can be cross-correlated against the electrical sensor reading.

Hardware requirements

Processing pipeline

RAW FRAME (N pixels × M rows)
  ↓
LUMINANCE EXTRACTION
  Mean luminance per frame → scalar time-series L[t]
  ↓
BANDPASS FILTER
  Isolate 55–65 Hz band (NA) or 45–55 Hz band (EU)
  Remove DC component, harmonics above 3rd order
  ↓
FREQUENCY ESTIMATION
  Zero-crossing detection or FFT on L[t] window
  Output: freq_hz per window
  ↓
CAMERA ENF TIME-SERIES
  Same format as sensor output, flagged source="camera"

Open questions

The correlation engine is the security-critical layer. It receives two independent ENF time-series — one from the electrical sensor, one from the camera — and determines whether they agree within a tolerance threshold. Agreement produces a signed attestation. Divergence triggers a tamper alert and suppresses attestation output.

Correlation algorithm (proposed)

INPUTS
  S_elec[t]  — electrical sensor frequency time-series
  S_cam[t]   — camera frequency time-series
  Both over identical window W (e.g. 60 seconds)

STEP 1: Normalize
  S_elec_norm = (S_elec - mean(S_elec)) / std(S_elec)
  S_cam_norm  = (S_cam  - mean(S_cam))  / std(S_cam)

STEP 2: Cross-correlate
  XC = cross_correlate(S_elec_norm, S_cam_norm)
  peak_r = max(XC)          // Pearson r at optimal lag
  peak_lag_ms = argmax(XC)  // Timing offset between sensors

STEP 3: Threshold check
  IF peak_r >= R_min AND abs(peak_lag_ms) <= LAG_max:
    PASS → generate attestation
  ELSE:
    FAIL → log tamper alert, suppress output

PARAMETERS (all TBD — testnet measurement targets)
  R_min     = minimum acceptable correlation coefficient
  LAG_max   = maximum acceptable inter-sensor lag (ms)

Attestation output format

{
  "layer": "attestation",
  "node_id": "string",
  "window_start_unix_ms": 1748000000000,
  "window_end_unix_ms":   1748000060000,
  "grid_region": "WECC-CA",
  "enf_fingerprint": "sha256 of S_elec normalized window",
  "correlation_r": 0.9741,
  "correlation_lag_ms": 12,
  "sensor_window_hash": "...",
  "camera_window_hash": "...",
  "attestation_hash": "sha256 of above fields",
  "signature": "ed25519 signature over attestation_hash"
}

Open questions

The node software orchestrates the layers below it, participates in BFT consensus, maintains the transaction pool, and signs all outbound messages. It is the only layer that communicates with other nodes.

Responsibilities

Block structure (proposed)

{
  "height": 1042,
  "prev_hash": "sha256 of previous block",
  "timestamp_unix_ms": 1748000060000,
  "enf_attestation": { ... },   // from Layer 3
  "transactions": [ ... ],
  "proposer_id": "node public key",
  "proposer_signature": "...",
  "commit_signatures": [        // from BFT precommit round
    { "node_id": "...", "signature": "..." },
    // ... ≥ ⌈2n/3⌉ + 1 signatures required
  ]
}

Open questions

The BFT cluster is a set of 15–50 nodes in the same grid interconnection region, running a Byzantine Fault Tolerant consensus protocol. The cluster agrees on the ordering and finality of blocks. ENF attestations serve as an additional consistency check across nodes — if a node's ENF signal diverges from the regional consensus, it is treated as a fault.

Protocol selection

Tendermint/CometBFT is the recommended starting point for the testnet due to mature tooling and extensive documentation. ENF attestation comparison can be added as a pre-vote validity check without modifying the core protocol.

Cluster sizing model

n  = node count
f  = tolerable faults = ⌊(n-1)/3⌋
q  = quorum = ⌈2n/3⌉ + 1

Minimum viable:   n=7,  f=2,  q=5
Conservative:     n=21, f=6,  q=15
Recommended:      n=33, f=10, q=23
Upper practical:  n=50, f=16, q=34

Above n≈50: O(n²) message overhead begins degrading throughput
on 100 Mbps node links with 5 KB consensus messages.

Open questions

The ledger is the finalized, ordered record of transactions. Once a block is committed by BFT quorum, it is appended to the chain and considered final. The ENF attestation embedded in each block provides a physically anchored timestamp for every committed transaction.

Storage requirements (testnet)

Application interface

// Minimum ledger query interface for testnet
GET /block/{height}         → block + attestation + tx list
GET /block/{height}/enf     → ENF attestation only
GET /tx/{hash}              → transaction + block height + ENF fingerprint
GET /enf/region/{region}    → recent ENF fingerprints for region
POST /tx                    → submit transaction to pool

The following questions are the critical path for moving from specification to testnet. Each one is a measurement target — it cannot be answered analytically and requires empirical data from real hardware in real environments.

The minimum viable testnet to answer the critical path questions above. This is not a production deployment. It is an instrumented measurement environment.

Estimated testnet hardware cost

Per node:
  Raspberry Pi 4 (4GB)       $80
  Camera module 3            $25
  Sound card (USB, isolated) $30
  MicroSD 64GB               $12
  Power supply + case        $20
  ─────────────────────────────
  Per node total:           $167

7-node testnet:            $1,169
Plus: network switch, cables, misc: ~$100
─────────────────────────────────────────
Total testnet hardware:  ~$1,270

The following are real problems that must be solved before a production network is viable. They are out of scope for this document because they cannot be specified without testnet measurement data, or because they are governance rather than engineering questions.