AEGISProof Wire Format

ELI5

The AEGIS wire format is a shipping manifest with seven compartments: the proof itself, all the sealed envelopes (commitments), a cross-reference tag to the VEST ledger, an encrypted copy of the access log, an optional notary link to earlier proofs, and a metadata header. Every field except the consistency-proof compartment is required.

Technical Deep Dive

The canonical wire format is defined in proto/protocols/aegis.proto under package timechain.protocols.aegis.

AEGISProof Top-Level Fields

Packet Layout

---
config:
  packet:
    bitsPerRow: 8
---
packet-beta
  title AEGISProof proto3 field layout
  0-7: "proof_id (bytes, field 1)"
  8-15: "zk_proof.proof_system (enum, field 1)"
  16-23: "zk_proof.proof (bytes, field 2)"
  24-31: "zk_proof.public_inputs (repeated bytes, field 3)"
  32-39: "commitments.user (UserCommitment, field 1)"
  40-47: "commitments.document (DocumentCommitment, field 2)"
  48-55: "commitments.timestamp (TimestampCommitment, field 3)"
  56-63: "vest_reference.vest_op_hash + vest_proof_id"
  64-71: "encrypted_audit.ciphertext (bytes, field 1)"
  72-79: "metadata.created_at + proof_stats"

ZKProofSystem Enum

AccessCommitments Structure

classDiagram
    class AccessCommitments {
        +user: UserCommitment
        +document: DocumentCommitment
        +timestamp: TimestampCommitment
        +access: AccessLevelCommitment
        +scheme: CommitmentScheme
    }
    class UserCommitment {
        +commitment: bytes
        +nonce: bytes
    }
    class DocumentCommitment {
        +commitment: bytes
        +nonce: bytes
    }
    AccessCommitments --> UserCommitment
    AccessCommitments --> DocumentCommitment

EncryptedAudit

EncryptedAudit uses a AuditEncryptionScheme enum (field 2) and carries KeyEncapsulation (field 3) alongside the ciphertext (field 1). The AuditMetadata sub-message (field 4) is unencrypted and carries audit_type and severity. This allows compliance tools to filter by severity without decrypting the payload.

AccessLevel Enum (AccessStatement)

Key Terms

• AEGISProof → Top-level proto3 message; 7 fields, one optional (consistency_proof)
• ZKAccessProof → Embeds the raw ZK proof bytes, system enum, and public inputs
• AccessCommitments → Four typed commitments (user, doc, timestamp, access) plus scheme indicator
• VESTReference → Merkle link back to the VEST audit chain; carries op hash and proof id
• EncryptedAudit → KEM-encrypted audit record with unencrypted AuditMetadata for filtering
• ZKProofSystem → Five-value enum selecting proof backend; Halo2 = 1 is the primary choice

Q&A

Q: consistency_proof is optional in proto3 — what does a receiver do when the field is absent? A: The field deserialises as None. Receivers must check presence before accessing it; treating absence as an error would reject valid single-proof submissions.

Q: Can a single AEGISProof embed proofs from multiple ZK systems? A: No. ZKAccessProof.proof_system is a single enum value — one proof system per message. Multi-system attestation would require multiple AEGISProof messages.

Q: AuditMetadata is unencrypted inside EncryptedAudit — what fields does it expose to observers without decryption? A: audit_timestamp, audit_type (enum), and severity (enum) are visible. User and document identity remain encrypted in the ciphertext field.

Examples

Minimal Halo2 proof wire construction (pseudo-Rust with prost):

let aegis_proof = AegisProof {
    proof_id: proof_id_bytes,
    zk_proof: Some(ZkAccessProof {
        proof_system: ZkProofSystem::Halo2 as i32,
        proof: halo2_proof_bytes,
        public_inputs: vec![public_input_bytes],
        verification_key_id: "vk-001".to_string(),
        ..Default::default()
    }),
    commitments: Some(access_commitments),
    vest_reference: Some(vest_ref),
    encrypted_audit: Some(enc_audit),
    consistency_proof: None, // optional
    metadata: Some(proof_metadata),
};