Auditable Real-time Inference Architecture (ARIA)

Abstract

This document specifies the Auditable Real-time Inference Architecture (ARIA) protocol, a BSV application-layer standard for cryptographic accountability of AI inference systems operating in production. ARIA enables independent, post-hoc verification of which AI model produced which output at what time — without requiring access to the operator's systems or trust in the operator's claims.

The protocol uses a pre-commitment scheme: before any inference executes, the operator publishes an OP_RETURN transaction on BSV committing to the exact model versions and system state that will be used. After the inference batch completes, a second transaction seals the batch with a Merkle root of all records. The two transactions are cryptographically linked, making retroactive fabrication of records computationally infeasible.

---

Motivation

Production AI systems that make high-stakes decisions — medical triage, credit scoring, content moderation, judicial risk assessment — currently offer no externally verifiable record of their behavior. Audit logs are mutable; operators can alter, delete, or fabricate records before a regulatory inspection. Independent verification requires cooperation from the auditee.

The EU AI Act (Regulation (EU) 2024/1689), effective from 2026, mandates for high-risk AI systems (Annex III):

• Automatic event logging with sufficient granularity to identify the inputs that led to each output (Art. 12.1)
• Traceability across the AI system's lifecycle (Art. 12.2)
• Capacity for post-hoc verification of the system's outputs (Art. 12.3)

No open technical standard currently addresses all three requirements simultaneously with an economically viable implementation. ARIA fills this gap.

BSV is uniquely suited for this protocol. Its unbounded OP_RETURN capacity (100 KB+), fees of approximately $0.0001 per transaction, and Teranode-scale throughput make it economically viable to commit every epoch of a real-time inference system — costing approximately $2.10/year for a system processing 1.5-second epochs continuously, compared to $13M–$315M/year on Ethereum.

---

Specification

1. Terminology

2. Transaction Format

ARIA data is embedded in BSV transactions using a standard OP_RETURN output with the following script format:

OP_FALSE  OP_RETURN  PUSH4(0x41524941)  PUSHDATA(<json_bytes>)
  0x00      0x6A     0x04 0x41 0x52 0x49 0x41   <varint> <utf-8 json>

• OP_FALSE (0x00): Marks the output as provably unspendable per the standard OP_FALSE OP_RETURN pattern.
• OP_RETURN (0x6A): Standard OP_RETURN opcode.
• PUSH4 (0x04) followed by 0x41524941 (b'ARIA'): 4-byte application identifier.
• PUSHDATA: Standard Bitcoin script pushdata encoding of the JSON payload bytes.
  • Payloads ≤ 75 bytes: direct length byte.
  • Payloads 76–255 bytes: OP_PUSHDATA1 (0x4C) + 1-byte length.
  • Payloads 256–65535 bytes: OP_PUSHDATA2 (0x4D) + 2-byte little-endian length.
  • Payloads > 65535 bytes: OP_PUSHDATA4 (0x4E) + 4-byte little-endian length.
• JSON payload: UTF-8 encoded JSON object. MUST NOT contain whitespace outside string values.

A transaction MAY contain multiple outputs. Verifiers MUST inspect all outputs and use the first that matches the ARIA prefix.

3. EPOCH_OPEN Payload Schema

{
  "aria_version": "1.0",
  "type": "EPOCH_OPEN",
  "epoch_id": "ep_<unix_timestamp_ms>_<sequence_4digits>",
  "system_id": "<registered_system_identifier>",
  "model_hashes": {
    "<model_id>": "sha256:<64_hex_chars>"
  },
  "state_hash": "sha256:<64_hex_chars>",
  "timestamp": 1742848200,
  "nonce": "<32_hex_chars>"
}

Field definitions:

Constraints:

• epoch_id uniqueness is scoped to system_id. Two different systems MAY share an epoch_id.
• model_hashes values MUST use lowercase hex and the "sha256:" prefix.
• The EPOCH_OPEN transaction MUST be broadcast and confirmed (or at minimum in the mempool with a valid txid) before any AuditRecord for that epoch is created.

4. AuditRecord Schema

An AuditRecord represents a single inference event. AuditRecords are stored locally by the operator and are NOT individually broadcast to BSV. Their hashes are committed collectively via the Merkle root in EPOCH_CLOSE.

{
  "aria_version": "1.0",
  "record_id": "rec_<epoch_id>_<sequence_6digits>",
  "epoch_id": "ep_<...>",
  "model_id": "<must_be_key_in_EPOCH_OPEN_model_hashes>",
  "input_hash": "sha256:<64_hex_chars>",
  "output_hash": "sha256:<64_hex_chars>",
  "confidence": 0.95,
  "latency_ms": 47,
  "sequence": 0,
  "metadata": {
    "decision_class": "triage_priority_1",
    "custom": {}
  }
}

Field definitions:

PII handling: Operators MUST identify and remove personally identifiable information fields from the input before computing input_hash. The set of PII fields is operator-defined and SHOULD be documented in the system registration. Output data is considered accountability-relevant and SHOULD NOT be PII-filtered unless legally required.

5. EPOCH_CLOSE Payload Schema

{
  "aria_version": "1.0",
  "type": "EPOCH_CLOSE",
  "epoch_id": "ep_<...>",
  "prev_txid": "<64_hex_chars_of_EPOCH_OPEN_txid>",
  "records_merkle_root": "sha256:<64_hex_chars>",
  "records_count": 42,
  "duration_ms": 1498
}

Field definitions:

6. AuditRecord Hash Algorithm

The hash of an AuditRecord is the SHA-256 of its canonical JSON serialization. The following fields are included in the canonical form, in this exact order:

{
  "aria_version": "1.0",
  "confidence": <float_or_null>,
  "epoch_id": "<string>",
  "input_hash": "<string>",
  "latency_ms": <integer>,
  "metadata": <object>,
  "model_id": "<string>",
  "output_hash": "<string>",
  "record_id": "<string>",
  "sequence": <integer>
}

Note: keys are sorted alphabetically. This matches the canonical JSON rules in §7.

The hash is computed as:

record_hash = "sha256:" + hex(SHA-256(canonical_json_bytes))

where canonical_json_bytes is the UTF-8 encoding of the canonical JSON string (no whitespace).

7. Canonical JSON Serialization

All hashes in ARIA use a deterministic JSON serialization to ensure cross-implementation reproducibility.

Rules:

1. No whitespace: No spaces, tabs, or line breaks outside string values.
2. Alphabetically sorted keys: Object keys sorted by Unicode code point, recursively at all nesting levels.
3. Float representation: IEEE 754 double-precision. Trailing zeros removed. No scientific notation unless the magnitude requires it (exponent ≥ 17 or ≤ -4). Up to 17 significant digits.
4. Null: Serialized as null.
5. NaN and Infinity: MUST NOT appear in canonical data. Implementations MUST reject inputs containing NaN or Infinity values.
6. Array order: Preserved as-is. Arrays are NOT sorted.
7. String encoding: UTF-8. Unicode escape sequences (\uXXXX) are permitted for non-ASCII characters.
8. Boolean: true / false (lowercase).

8. Merkle Tree Construction

ARIA uses a SHA-256 Merkle tree with second-preimage attack protection following RFC 6962 (Certificate Transparency):

leaf_hash(data)     = SHA-256(0x00 || data)
internal_hash(l, r) = SHA-256(0x01 || l || r)

Where || denotes byte concatenation and data is the raw SHA-256 digest bytes (32 bytes) of a record hash string decoded from hex.

Construction algorithm:

1. Sort all AuditRecord hashes by their sequence field (ascending).
2. Compute leaf hashes: for each record hash h, compute leaf = SHA-256(0x00 || bytes.fromhex(h[7:])) where h[7:] strips the "sha256:" prefix.
3. Build the tree bottom-up. If a level has an odd number of nodes, duplicate the last node.
4. The root of the tree with a single leaf is leaf_hash(record_hash).
5. The root of an empty tree is SHA-256(b"").

Merkle proof format:

A Merkle proof for a leaf is a list of (sibling_hash, position) tuples where position is "left" or "right", indicating which side the sibling is on relative to the path to the root.

9. Epoch Lifecycle

Operator side                       BSV
─────────────────────────────────   ──────────────────────────
1. Prepare model_hashes
2. Compute state_hash
3. Generate nonce
4. Broadcast EPOCH_OPEN ──────────► txid_open confirmed/mempool
5. [EPOCH_OPEN txid available]
6. Execute inferences
7. Create AuditRecord per inference
8. Persist records to local storage
9. Compute Merkle root
10. Broadcast EPOCH_CLOSE ────────► txid_close confirmed/mempool
    (prev_txid = txid_open)

Anti-backdating guarantee: Because EPOCH_OPEN is broadcast before inferences begin, and BSV blocks include timestamps, no operator can claim a different model version or system state was in effect at decision time. The commitment is public and immutable.

10. Verification Algorithm

Given open_txid and optionally close_txid, a verifier MUST perform the following checks:

Epoch verification:

1. Fetch the transaction at open_txid and extract the ARIA payload.
2. Verify payload.type == "EPOCH_OPEN".
3. If close_txid is not provided, locate it by searching for an EPOCH_CLOSE transaction whose prev_txid == open_txid. Implementations MAY use a local index or require the caller to supply close_txid explicitly.
4. Fetch the transaction at close_txid and extract the ARIA payload.
5. Verify payload.type == "EPOCH_CLOSE".
6. Verify close_payload.prev_txid == open_txid. If this check fails, the epoch is TAMPERED.
7. Verify close_payload.epoch_id == open_payload.epoch_id. If this check fails, the epoch is TAMPERED.

Record verification (in addition to epoch verification):

8. Reconstruct the AuditRecord from the provided record data.
9. Verify record.epoch_id == open_payload.epoch_id. If this fails, the record is TAMPERED.
10. Verify record.model_id ∈ open_payload.model_hashes. If this fails, the record is TAMPERED.
11. If local storage is available: reconstruct the Merkle tree from all stored records for this epoch and verify that the record's hash is a member (Merkle proof). Verify the reconstructed root matches close_payload.records_merkle_root. If this fails, the record is TAMPERED.

11. Verification Result

Implementations MUST produce a structured verification result with at minimum:

---

12. ZK Extension (Optional)

Implementations MAY include a zk field in the EPOCH_CLOSE payload to provide zero-knowledge proof evidence and EU AI Act regulatory claims. When present, the zk field MUST conform to the following schema.

12.1 ZKPayload

{
  "zk_enabled": true,
  "claims_count": 3,
  "all_claims_satisfied": true,
  "statement_hash": "sha256:<64_hex_chars>",
  "claims": [<ClaimResult>, ...],
  "aggregate_proof": <AggregateProof | null>
}

The statement_hash commits to the epoch's regulatory state:

statement_hash = SHA256(canonical_json({
  "epoch_id": <str>,
  "claims": [{"claim_type": ..., "params": ..., "satisfied": ...}, ...],
  "aggregate_digest": <str | "">
}))

12.2 ClaimResult

{
  "claim_type": "confidence_percentile",
  "params": {"p": 99, "threshold": 0.85},
  "satisfied": true,
  "evidence_hash": "sha256:<64_hex_chars>",
  "human_description": "99th percentile confidence 0.912 ≥ 0.85",
  "eu_ai_act_reference": "Art. 9 §7 — accuracy and robustness requirements",
  "detail": null
}

Standard claim_type values and their EU AI Act mapping:

The evidence_hash is computed as:

evidence_hash = SHA256(canonical_json({"evidence": sorted(str(v) for v in values)}))

where values is the set of data values used to evaluate the claim (e.g., the list of confidence scores for confidence_percentile).

12.3 AggregateProof

{
  "proofs_merkle_root": "sha256:<64_hex_chars>",
  "n_proofs": 42,
  "aggregation_scheme": "merkle",
  "aggregate_digest": "sha256:<64_hex_chars>"
}

• proofs_merkle_root: Merkle root of per-record ZK proof digests.
• aggregation_scheme: "merkle" (production), "nova" (future), "plonk_recursive" (future).
• aggregate_digest: SHA-256 of the raw aggregate bytes (the bytes themselves are NOT embedded on-chain due to size constraints).

12.4 Proving tiers

Implementations MAY use any of the following proving tiers:

The tier is a per-proof attribute stored locally. Only the aggregate Merkle root is committed on-chain.

---

Security Considerations

What ARIA guarantees

1. Pre-commitment immutability: Once EPOCH_OPEN is confirmed in a BSV block, the committed model_hashes and state_hash cannot be altered. Any claim that a different model version was used is verifiably false.

2. Merkle root tamper detection: Any modification to any single record in an epoch — adding, removing, or altering — invalidates the Merkle root. This is detectable without access to all records (Merkle proof suffices).

3. Chronological ordering: The BSV block timestamp of EPOCH_OPEN provides an external lower bound on the inference time. EPOCH_CLOSE must reference EPOCH_OPEN via prev_txid, establishing a directed chain.

4. Operator key compromise does not alter history: A compromised private key can create new fraudulent epochs but cannot alter already-confirmed transactions.

What ARIA does NOT guarantee

1. Input/output correctness: ARIA commits hashes of inputs and outputs, not the inputs/outputs themselves. An operator could hash a different input than the actual one. ARIA cannot detect this without access to the original data.

2. Model quality or safety: ARIA verifies which model produced an output. It does not verify that the model is safe, accurate, or unbiased.

3. Real-time tamper detection: ARIA detects tampering during post-hoc verification, not in real time.

4. BSV network availability: If BSV becomes unavailable, epochs cannot be committed. Implementations MUST queue epochs and retry.

Threat model

---

Test Vectors

Canonical JSON

Input object:

{"b": 2, "a": 1, "c": {"z": 3, "x": 1}}

Canonical form: {"a":1,"b":2,"c":{"x":1,"z":3}}

SHA-256: a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3 (This is the hash of the canonical string above, encoded as UTF-8.)

AuditRecord hash

Given:

{
  "aria_version": "1.0",
  "record_id": "rec_ep_1742848200000_0001_000000",
  "epoch_id": "ep_1742848200000_0001",
  "model_id": "triage",
  "input_hash": "sha256:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
  "output_hash": "sha256:bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb",
  "confidence": null,
  "latency_ms": 0,
  "sequence": 0,
  "metadata": {}
}

Canonical JSON (keys sorted, no whitespace):

{"aria_version":"1.0","confidence":null,"epoch_id":"ep_1742848200000_0001","input_hash":"sha256:aaaa...","latency_ms":0,"metadata":{},"model_id":"triage","output_hash":"sha256:bbbb...","record_id":"rec_ep_1742848200000_0001_000000","sequence":0}

Merkle root (2 records)

Leaf 0 hash (64 hex chars): h0 Leaf 1 hash (64 hex chars): h1

leaf0 = SHA-256(0x00 || bytes.fromhex(h0[7:]))
leaf1 = SHA-256(0x00 || bytes.fromhex(h1[7:]))
root  = SHA-256(0x01 || leaf0 || leaf1)

OP_RETURN script

For payload {"type":"EPOCH_OPEN"} (21 bytes UTF-8):

00 6a 04 41524941 15 7b2274797065223a22455043...

• 00 = OP_FALSE
• 6a = OP_RETURN
• 04 41524941 = PUSH4 + ARIA
• 15 = direct length byte (21)
• 7b... = UTF-8 JSON bytes

---

Reference Implementation

The canonical reference implementation of BRC-122 is the aria-bsv Python package, available at:

https://github.com/JuanmPalencia/aria-bsv

The reference implementation includes:

• aria/core/hasher.py — canonical JSON and SHA-256 hashing
• aria/core/merkle.py — RFC 6962 Merkle tree with second-preimage protection
• aria/core/record.py — AuditRecord schema and hash algorithm
• aria/core/epoch.py — EpochManager: EPOCH_OPEN / EPOCH_CLOSE lifecycle
• aria/verify.py — Independent Verifier with WhatsOnChain integration
• aria/auditor.py — High-level InferenceAuditor (5-line integration API)
• aria/zk/ — ZK extension: tiered prover, EU AI Act claims DSL, proof aggregation, EpochStatement

---

Copyright

This BRC is placed in the public domain. Authors waive all copyright and related rights.