Proof of Process: VDF Proof Aggregation Extension

Introduction This document defines optional mechanisms for aggregating VDF proofs to reduce verification cost. Aggregation enables O(1) or O(log n) verification of entire checkpoint chains that would otherwise require O(n) sequential VDF recomputation. This extension is defined as a companion to the main Proof of Process specification .

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Motivation The iterated-sha256 VDF provides strong temporal guarantees but requires verifiers to recompute the entire hash chain. For a document with 1000 checkpoints, each with 10 million iterations, full verification requires 10 billion hash operations. While this verification cost is acceptable for high-stakes scenarios, it creates barriers to adoption:

Publishers processing thousands of submissions cannot afford O(n) verification per document.
Mobile devices and web browsers may lack computational resources for full verification.
Real-time verification scenarios require sub-second response.

VDF aggregation addresses these challenges by providing efficiently-verifiable proofs that attest to the correctness of the underlying VDF chain.

Aggregation Proof Structure The VDF aggregate proof is an optional extension to the vdf-proof structure, identified by integer key 9. uint, ; checkpoints-covered 2 => aggregation-method, ; method 3 => bstr, ; aggregate-proof ? 4 => aggregate-metadata, ; metadata } aggregation-method = &( merkle-vdf-tree: 1, ; Merkle tree over VDF outputs snark-groth16: 16, ; Groth16 SNARK proof snark-plonk: 17, ; PLONK SNARK proof stark: 18, ; STARK proof recursive-snark: 19, ; Recursive SNARK composition ) aggregate-metadata = { ? 1 => tstr, ; prover-version ? 2 => uint, ; proof-generation-time-ms ? 3 => uint, ; proof-size-bytes ? 4 => tstr, ; verification-key-id ? 5 => bstr, ; verification-key } ]]>

Merkle VDF Tree Aggregation The simplest aggregation method constructs a Merkle tree over VDF inputs and outputs, enabling selective verification with O(log n) proof size.

Tree Construction

Verification Procedure Merkle aggregation supports three verification modes:

Full verification:: Recompute all VDFs and verify Merkle root matches. O(n) time.
Sampled verification:: Randomly select k checkpoints, verify their VDFs, and verify Merkle inclusion proofs. O(k * VDF_iterations/n + k * log n). Provides probabilistic assurance.
Root-only verification:: Trust the prover, verify only the Merkle root signature. O(1) time. Requires trusted aggregation service.

The verification mode SHOULD be documented in the Attestation Result.

Merkle Aggregate CDDL hash-value, ; root-hash 2 => uint, ; total-iterations 3 => uint, ; checkpoint-count ? 4 => [+ merkle-sample], ; sampled-proofs ? 5 => cose-signature, ; aggregator-signature } merkle-sample = { 1 => uint, ; checkpoint-index 2 => [+ hash-value], ; merkle-path 3 => bool, ; vdf-verified (by aggregator) } ]]>

SNARK-Based Aggregation For constant-time verification, SNARK (Succinct Non-interactive ARgument of Knowledge) proofs can attest to the correctness of the entire VDF chain.

Circuit Definition The SNARK circuit proves the following statement: A valid SNARK proof demonstrates that there exist valid intermediate values satisfying all constraints, without revealing those values or requiring recomputation.

SNARK Verification SNARK verification is constant-time regardless of checkpoint count: bool: public_inputs = encode_public_inputs( vdf_input_genesis, vdf_output_final, total_iterations, checkpoint_count ) return snark_verify(verification_key, public_inputs, proof) ]]> Verification complexity: O(1) for Groth16, O(log n) for PLONK with logarithmic verification.

Trust Assumptions SNARK-based aggregation introduces additional trust assumptions:

Trusted setup (Groth16): The verification key MUST be generated through a secure multi-party computation. A compromised setup allows forged proofs.
Cryptographic assumptions: SNARK security relies on hardness of discrete logarithm and pairing assumptions.
Implementation correctness: The circuit MUST correctly encode the VDF verification constraints.

For maximum assurance, implementations SHOULD support both SNARK verification (for efficiency) and full VDF recomputation (for trust-minimized verification).

SNARK Aggregate CDDL snark-scheme, ; scheme 2 => bstr, ; proof-bytes 3 => bstr, ; verification-key-id 4 => [+ bstr], ; public-inputs (encoded) ? 5 => tstr, ; circuit-version ? 6 => bstr, ; setup-ceremony-hash } snark-scheme = &( groth16-bn254: 1, ; Groth16 on BN254 curve groth16-bls12-381: 2, ; Groth16 on BLS12-381 plonk-bn254: 3, ; PLONK on BN254 plonk-bls12-381: 4, ; PLONK on BLS12-381 ) ]]>

Verification Mode Selection Verifiers SHOULD select verification modes based on the assurance level required by the Relying Party: Verification Mode Comparison

Mode	Complexity	Trust Required	Use Case
Full VDF recomputation	O(n * iterations)	None	Litigation, forensics
Merkle + full sample	O(k * iterations/n)	Statistical	Academic review
SNARK verification	O(1)	Setup ceremony	High-volume processing
Signed aggregate only	O(1)	Aggregator	Real-time display

Attestation Results MUST document which verification mode was used and any associated trust assumptions.

Aggregation Proof Example

Security Considerations VDF aggregation introduces security trade-offs:

Merkle aggregation: Security equivalent to underlying hash function. No additional cryptographic assumptions. Sampled verification provides probabilistic (not cryptographic) assurance proportional to sample size.
SNARK aggregation: Security depends on discrete logarithm hardness in pairing-friendly groups. Groth16 requires trusted setup; PLONK uses universal setup. Post-quantum security is NOT provided.
Aggregator trust: Signed aggregates require trust in the aggregation service. Verifiers SHOULD verify aggregator identity through established PKI.

Full security considerations for the Proof of Process format are specified in .

IANA Considerations This document has no IANA actions. The aggregation extension uses key 9 within the vdf-proof structure as defined in the main architecture document.