Proposed verification framework

Consensus

Enerdex Surplus-Storage Consensus. A proposed application-layer framework for energy evidence, verifier agreement, and XRPL settlement records.

ESSC designXRPL settlementVerifier agreement
0% read

Purpose

Define verifier agreement on evidence for dispatchable surplus before ledger submission, then record a reference on the XRP Ledger (XRPL). This is a proposed design, not a deployed consensus service or a proof of physical delivery.

Actors & Keys

  • Storage Node (SN): Proposed metered storage participant. Example keys: SN_ed25519 (ledger), SN_device (device attestation, where supported).

  • Verifier Node (VN): Application verifiers that assess source evidence. Example key: VN_ed25519. Membership belongs to Enerdex verification, not XRPL validator consensus.

  • Anchor Agent (AA): Proposed coordinator that submits agreed record references to XRPL.

  • Application Policy: Off-ledger rules for evidence, duplicate detection, and submission authorization.

Measurement Windows

Discrete epochs E identify measurement batches. A claim relates to a window [t0, t1] ⊂ E.

Data Structures

StorageProof (SP):

 
SP = {
  storage_id,               // fixed per battery inverter
  epoch_id = E,
 window = [t0,t1],
  kWh_avail,                 // measured surplus, dispatchable
  meter_root,                // Merkle root of raw meter ticks
  firmware_attest,           // TEE quote or signed firmware hash
  prev_nonce, nonce,         // anti-replay chain
  SN_sig = Sig_SN_device(H(SP))
}

EnergySlice (ES): identifier for a measurement claim

 
ES = H(storage_id || E || t0 || t1 || nonce)

Vote & QuorumCertificate (QC):

 
Vote = Sig_VN(H(SP || ES || policy_params))
QC = { E, ES, SP_digest, S = AggSig(2f+1 Votes), vn_bitmap }

(Signature aggregation is an application design choice. A ledger record references the certificate; XRPL does not independently validate energy evidence.)

AnchorCommit (AC):

 
AC = H(QC)

A proposed reference carried by a supported XRPL transaction. Application services verify the underlying certificate.

Protocol (Round per ES)

Phase 0 — Measurement (SN):

  1. A compatible device records measurements and signs source evidence for meter_root.

  2. SN composes SP, chains nonce, signs with SN_device.

Phase 1 — Proposal (SN → VNs):
3. SN gossips SP to participating verifiers.

Phase 2 — Verification (VNs):
4. Each VN checks:

  • Device signature validity and supported firmware policy.

  • Non-overlap: ES uniqueness (storage_id,E,nonce) not seen before.

  • Continuity: prev_nonce → nonce chain matches SN’s history.

  • Dispatchability: configured operational guards and available system status.

  • Plausibility: measurement continuity, clock consistency, and plausible values.

  1. If valid, VN issues Vote.

Phase 3 — Certification (AA):
6. AA collects ≥ 2f+1 Votes (example threshold for N = 3f+1 with at most f faulty verifiers).
7. AA builds QC and AC = H(QC).

Phase 4 — XRPL Anchor (AA → XRPL):
8. AA posts Anchor Tx using a supported transaction carrying a reference to QC.

  • The application checks submission policy before sending:

    • epoch monotonicity,

    • ES uniqueness (seen set),

    • VN quorum (bitmap vs allowlist),

    • the policy version for the measurement batch.

  1. Only a successful result in a validated ledger confirms transaction completion. Submission alone is not finality.

Safety & Liveness (Sketch)

  • Safety:

    • Non-overlap invariant: The proposed verifier rules reject repeated records for (storage_id,E,nonce). Application persistence and recovery must preserve this check.

    • One record per ES: RecordLock rejects a duplicate ES within the application record set.

    • Byzantine tolerance: Under the stated membership and fault assumptions, 2f+1 votes form a quorum for N = 3f+1.

  • Liveness:

    • Agreement depends on network connectivity, participating verifiers, and the selected protocol.

    • XRPL transaction status must be reconciled against a validated ledger.

    • A coordinator recovery procedure is required when submission status is uncertain.

Double-Claim Resistance

  • Physical layer: Signed measurements, device integrity checks, and operational evidence.

  • Consensus layer: Nonce continuity, record identifiers, and measurement windows.

  • Ledger layer: An application-managed Seen(ES) set and RecordLock reference validated XRPL results. It is not a native ledger rule.

Cryptography & Identifiers

  • Device attestation: supported signatures and firmware evidence require hardware-specific validation.

  • Verifier votes: authenticated signatures over the agreed evidence digest, represented by S.

  • All hashes: H = SHA-256 in this example; encoding and ledger compatibility require implementation review.

  • IDs: storage_id = H(serial || grid_id || owner_key).

Application State and XRPL Records

  • state.seen[ES] = 1 after an accepted application record.

  • state.last_epoch[storage_id] monotonic.

  • state.policy_hash identifies the applicable verification policy.

  • Reject duplicate records if seen[ES]==1 or the measurement sequence regresses.

Interfaces (sketch)

SN → VN

 
POST /prove
 body: SP
 resp: ack | err

VN → AA

 
gossip: Vote(SP_digest, ES)

AA → XRPL

  • Submit a supported transaction referencing QC; reconcile the validated result before marking the record complete.

    Why This Works for Enerdex on XRPL

    • Enerdex proposes application-layer consensus (ESSC) on evidence-based data (stored kWh) before submitting a ledger reference. Verification reduces risk but cannot establish physical truth by itself.

    • XRPL provides validated transaction finality for supported transactions. Once a record reference is successfully committed, its ledger result can be independently inspected.

    • The trio (source evidence + verifier agreement + XRPL records) links measurement → agreement → settlement.

    Scalability, Determinism, and Ledger Coupling

    The proposed ESSC architecture separates energy verification from ledger processing. Evidence can be assessed across application services while XRPL handles supported transactions. Its deterministic close model establishes finality for validated transactions, not the accuracy of the energy evidence referenced by them.

    Enerdex application verification is separate from XRPL consensus:

    • ESSC determines agreement on supplied evidence under a stated policy.

    • XRPL consensus determines order and finality for accepted ledger transactions.

    This separation enables parallelism in measurement verification while serializing settlement through XRPL. Capacity, recovery behavior, and operational limits require testing before deployment claims can be made.

    Threat Model and Adversarial Resistance

    Physical Layer Attacks

    • Forged Energy Claims: Device attestations, independent checks, and measurement provenance are proposed controls; compromised hardware remains a risk.

    • Replay / Duplicate Claims: Nonce continuity and durable identifier checks help detect repeated evidence.

    Consensus Layer Attacks

    • Byzantine Verifiers: The example quorum assumes at most f malicious VNs in a network of N nodes, requiring 2f+1 votes to form a QC when N = 3f+1. This does not guarantee physical accuracy.

    • Leader Misbehavior: Coordinator recovery and authenticated membership are required; availability depends on network and fault conditions.

    Ledger Layer Attacks

    • Invalid Anchor Injections: Application services check certificate structure, authorized signers, policy, and sequence before submission. XRPL checks its transaction rules.

    • State Rollback: Validated ledger results provide a final transaction history. Off-ledger records still require backup, reconciliation, and recovery controls.

    Formal Invariants

    • Non-overlap Invariant: For each ES: at most one accepted application record

    • Monotonic Epoch Invariant: epoch(storage_id)_{n} < epoch(storage_id)_{n+1}

    • Policy Lock Invariant: policy_hash_epoch_n == policy_hash_epoch_commit

    These are proposed application invariants. They require implementation tests and persistent state; they are not enforced by native XRPL energy-verification logic.

    Performance Considerations

    • Verification Latency: Depends on evidence size, hardware checks, and verifier implementation.

    • Quorum Formation: Depends on network conditions and 2f+1 vote availability under the stated assumptions.

    • Ledger Settlement: Completion requires a successful validated transaction result; no fixed completion time is promised.

    • Throughput: Capacity must be measured against realistic workloads. No production throughput is claimed.

    Back to topEnerdex framework