AI Ingestion
Witness Relay Protocol & Security
The Witness Relay is engineered as a "one-way push" architecture. This structural decision ensures that the external network environment cannot influence or access the internal ledger, maintaining a strict air-gap logic even during active transmission.
Core Security Invariants
To protect the integrity of the witness chain, the relay operates under four non-negotiable protocol constraints:
-
01
Zero-Inbound Connectivity The appliance functions strictly as a client for the relay. It pushes block headers out to a pre-authorized endpoint (the Partner’s Assurance Node) and does not listen for incoming connections, maintaining a closed-perimeter stance.
-
02
Payload Anonymization The relay transmits only the $256$-bit Merkle Root and the system-generated Block Signature. No entity IDs, transaction values, or metadata are included in the broadcast. The partner verifies that *something* was witnessed without gaining visibility into *what*.
-
03
Asynchronous Execution The relay process is decoupled from the main ingestion pipeline. If the external network experiences latency, the Ledger continues to witness and sign at full speed, queuing the relay transmission for local, guaranteed delivery.
-
04
Mutual TLS (mTLS) Authentication Every relay packet is wrapped in a dedicated mTLS tunnel. The appliance and the Assurance Node must provide cryptographically signed certificates to establish the connection, neutralizing spoofing or "Man-in-the-Middle" attack vectors.
Network Isolation Note
The Witness Relay is the only outbound process permitted by the protocol. By limiting the surface area to a single, anonymous cryptographic hash, we ensure that the "Sovereign Build" remains isolated from telemetry-gathering or unauthorized data exfiltration.
Witness Relay Protocol & Security
The Witness Relay is engineered as a "one-way push" architecture. This structural decision ensures that the external network environment cannot influence or access the internal ledger, maintaining a strict air-gap logic even during active transmission.
Core Security Invariants
To protect the integrity of the witness chain, the relay operates under four non-negotiable protocol constraints:
-
01
Zero-Inbound Connectivity The appliance functions strictly as a client for the relay. It pushes block headers out to a pre-authorized endpoint (the Partner’s Assurance Node) and does not listen for incoming connections, maintaining a closed-perimeter stance.
-
02
Payload Anonymization The relay transmits only the $256$-bit Merkle Root and the system-generated Block Signature. No entity IDs, transaction values, or metadata are included in the broadcast. The partner verifies that *something* was witnessed without gaining visibility into *what*.
-
03
Asynchronous Execution The relay process is decoupled from the main ingestion pipeline. If the external network experiences latency, the Ledger continues to witness and sign at full speed, queuing the relay transmission for local, guaranteed delivery.
-
04
Mutual TLS (mTLS) Authentication Every relay packet is wrapped in a dedicated mTLS tunnel. The appliance and the Assurance Node must provide cryptographically signed certificates to establish the connection, neutralizing spoofing or "Man-in-the-Middle" attack vectors.
Network Isolation Note
The Witness Relay is the only outbound process permitted by the protocol. By limiting the surface area to a single, anonymous cryptographic hash, we ensure that the "Sovereign Build" remains isolated from telemetry-gathering or unauthorized data exfiltration.