Remote ATtestation procedureS D. Condrey Internet-Draft Writerslogic Inc Intended status: Informational 6 February 2026 Expires: 10 August 2026 Proof of Process: VDF Proof Aggregation Extension draft-condrey-rats-pop-aggregation-00 Abstract This document defines optional mechanisms for aggregating Verifiable Delay Function (VDF) proofs in Proof of Process Evidence packets. Aggregation enables O(1) or O(log n) verification of entire checkpoint chains that would otherwise require O(n) sequential VDF recomputation. This extension supports Merkle tree aggregation and SNARK-based proof compression for high-volume verification scenarios. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 10 August 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Condrey Expires 10 August 2026 [Page 1] Internet-Draft PoP VDF Aggregation February 2026 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Aggregation Proof Structure . . . . . . . . . . . . . . . . . 3 4. Merkle VDF Tree Aggregation . . . . . . . . . . . . . . . . . 4 4.1. Tree Construction . . . . . . . . . . . . . . . . . . . . 4 4.2. Verification Procedure . . . . . . . . . . . . . . . . . 4 4.3. Merkle Aggregate CDDL . . . . . . . . . . . . . . . . . . 4 5. SNARK-Based Aggregation . . . . . . . . . . . . . . . . . . . 5 5.1. Circuit Definition . . . . . . . . . . . . . . . . . . . 5 5.2. SNARK Verification . . . . . . . . . . . . . . . . . . . 6 5.3. Trust Assumptions . . . . . . . . . . . . . . . . . . . . 6 5.4. SNARK Aggregate CDDL . . . . . . . . . . . . . . . . . . 6 6. Verification Mode Selection . . . . . . . . . . . . . . . . . 7 7. Aggregation Proof Example . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 1. 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 [I-D.condrey-rats-pop]. 1.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. 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. Condrey Expires 10 August 2026 [Page 2] Internet-Draft PoP VDF Aggregation February 2026 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. 3. Aggregation Proof Structure The VDF aggregate proof is an optional extension to the vdf-proof structure, identified by integer key 9. ; VDF aggregate proof extension ; Key 9 in vdf-proof (optional) vdf-aggregate-proof = { 1 => 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 } Condrey Expires 10 August 2026 [Page 3] Internet-Draft PoP VDF Aggregation February 2026 4. 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. 4.1. Tree Construction For N checkpoints with VDF proofs: Leaf{i} = H(VDF_input{i} || VDF_output{i} || iterations{i}) Internal nodes computed as standard Merkle tree: Node{parent} = H(Node{left} || Node{right}) Root = final tree root Aggregate proof contains: - Root hash - Total iterations across all checkpoints - Optional: Merkle proofs for sampled checkpoints 4.2. 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. 4.3. Merkle Aggregate CDDL Condrey Expires 10 August 2026 [Page 4] Internet-Draft PoP VDF Aggregation February 2026 ; Merkle VDF tree proof structure merkle-vdf-proof = { 1 => 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) } 5. 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. 5.1. Circuit Definition The SNARK circuit proves the following statement: Public inputs: - VDF_input{0} (genesis input) - VDF_output{N-1} (final output) - total_iterations - checkpoint_count Private inputs: - All intermediate VDF_input{i} and VDF_output{i} - All iteration counts per checkpoint Circuit constraints: For each checkpoint i in 0..N-1: (1) VDF_output{i} = SHA256^iterations{i}(VDF_input{i}) (2) VDF_input{i+1} = H(VDF_output{i} || content-hash{i+1} || ...) (3) sum(iterations{i}) = total_iterations A valid SNARK proof demonstrates that there exist valid intermediate values satisfying all constraints, without revealing those values or requiring recomputation. Condrey Expires 10 August 2026 [Page 5] Internet-Draft PoP VDF Aggregation February 2026 5.2. SNARK Verification SNARK verification is constant-time regardless of checkpoint count: def verify_snark_aggregate( proof: bytes, vdf_input_genesis: bytes, vdf_output_final: bytes, total_iterations: int, checkpoint_count: int, verification_key: bytes ) -> 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. 5.3. 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). 5.4. SNARK Aggregate CDDL Condrey Expires 10 August 2026 [Page 6] Internet-Draft PoP VDF Aggregation February 2026 ; SNARK proof structure snark-vdf-proof = { 1 => 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 ) 6. Verification Mode Selection Verifiers SHOULD select verification modes based on the assurance level required by the Relying Party: +================+===============+================+=============+ | Mode | Complexity | Trust Required | Use Case | +================+===============+================+=============+ | Full VDF | O(n * | None | Litigation, | | recomputation | iterations) | | forensics | +----------------+---------------+----------------+-------------+ | Merkle + full | O(k * | Statistical | Academic | | sample | iterations/n) | | review | +----------------+---------------+----------------+-------------+ | SNARK | O(1) | Setup ceremony | High-volume | | verification | | | processing | +----------------+---------------+----------------+-------------+ | Signed | O(1) | Aggregator | Real-time | | aggregate only | | | display | +----------------+---------------+----------------+-------------+ Table 1: Verification Mode Comparison Attestation Results MUST document which verification mode was used and any associated trust assumptions. 7. Aggregation Proof Example Condrey Expires 10 August 2026 [Page 7] Internet-Draft PoP VDF Aggregation February 2026 vdf-proof = { 1: 1, 2: {1: 1, 2: 8500000}, 3: h'genesis-input...', 4: h'final-output...', 5: h'', 6: 3600.0, 7: 30600000000, 8: { ... }, 9: { 1: 150, 2: 1, 3: h'merkle-proof-bytes...', 4: { 1: "witnessd-aggregator-1.0", 2: 45000, 3: 2048, } } } 8. 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 [I-D.condrey-rats-pop]. 9. 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. Condrey Expires 10 August 2026 [Page 8] Internet-Draft PoP VDF Aggregation February 2026 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . 10.2. Informative References [I-D.condrey-rats-pop] Condrey, D., "Proof of Process: An Evidence Framework for Digital Authorship Attestation", Work in Progress, Internet-Draft, draft-condrey-rats-pop-00, . Author's Address David Condrey Writerslogic Inc United States Email: david@writerslogic.com Condrey Expires 10 August 2026 [Page 9]