Skip to content

feat(specs): canonical-bytes diff fixture for v0.3.2#15

Open
desiorac wants to merge 1 commit intocorpollc:mainfrom
ark-forge:feat/canonical-bytes-diff-v032
Open

feat(specs): canonical-bytes diff fixture for v0.3.2#15
desiorac wants to merge 1 commit intocorpollc:mainfrom
ark-forge:feat/canonical-bytes-diff-v032

Conversation

@desiorac
Copy link
Copy Markdown

@desiorac desiorac commented May 2, 2026

Summary

Production-derived pre-fix/post-fix canonical-bytes diff from ArkForge Trust Layer's Merkle-chain execution attestation code path. One fixture, two failure surfaces:

  • Bilateral-delegation depth-walker (APS): shallow { signature, ...rest } spread-destructure exits after top-level proof, leaving intermediate authority attestation proofs intact
  • Merkle-chained execution attestation (ArkForge): root commitment verified, nested delegation path silently dropped

Same canonical-bytes diff catches both — the "class of bug, not an implementation-side artifact" pattern discussed in #7.

Fixture contents

Check Description
Pre-fix hash String-concatenation chain hash (legacy)
Post-fix hash Canonical JSON chain hash (v1.2+)
Divergence Confirms pre-fix ≠ post-fix
Preimage ambiguity Collision at field boundary (seller + upstream_timestamp)
Canonical immunity Canonical JSON rejects the collision class

Verification: python3 specs/test-vectors/verify_canonical_bytes_diff.py — all 5 checks pass.

Context

Per the v0.3.2 §6.x motivating-example discussion in #7 — targeting the mid-May inline-vector publish window alongside @aeoess/aps-conformance-suite mirror.

cc @kenneives @aeoess

….3.2

Production-derived test vector from ArkForge Trust Layer's Merkle-chain
execution attestation code path. Covers the "root commitment verified,
nested delegation silently dropped" failure class observed in two
structurally different recursive-attestation systems:

1. Bilateral-delegation depth-walker (APS)
2. Merkle-chained execution attestation (ArkForge)

Fixture includes:
- Pre-fix (string concat) vs post-fix (canonical JSON) hash divergence
- Preimage ambiguity collision proof (field-boundary exploit)
- Canonical JSON immunity verification
- Extended 7-field variant with upstream_timestamp

All 5 verification checks pass. Targeting v0.3.2 §6.x motivating-example
block alongside the inline-vector mid-May publish window.

Refs: corpollc#7

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@kenneives
Copy link
Copy Markdown

Independently verified — all 5 checks pass.

Cloned the PR head locally (/tmp/qntm-pr15/), ran python3 specs/test-vectors/verify_canonical_bytes_diff.py against the fixture file fresh from this PR with no other code path in scope:

All 5 checks passed.
  Pre-fix hash:  sha256:53cce2bf015723f6ffe2eb31cccae5de9237c69c4ae49e3900a9295be7d6a332
  Post-fix hash: sha256:040cfc8c93e252c8f9f524d9f947987a7a1e9bff7fc2952e0aa9ffe553811c69
  Collision confirmed: True
  Canonical immune:    True

The artifact is right. Three things worth pinning explicitly for the v0.3.2 spec text appendix:

  1. The preimage-ambiguity collision is the load-bearing piece. Two semantically different (seller, upstream_timestamp) pairs producing identical concatenation bytes (api.openai.com2026-04-28T14:23:06.001Z) is exactly the failure class that destroys cross-implementation determinism. The fixture demonstrates the bug at the byte level rather than describing it in prose. Spec implementers reading canonical-bytes-diff-v032.json see why canonical JSON is required, not just that it is.

  2. canonical_immune: true is the symmetric proof. The extended_with_upstream_timestamp block shows the canonical JSON form keeps upstream_timestamp as an explicit field (key-sorted, structurally distinguishable), so the same input that collided under string-concat produces a structurally different and unambiguous canonical form. Demonstrates the fix, not just the bug.

  3. Production-derivation provenance. The meta.source: "trust_layer/proofs.py (verify_proof_integrity, generate_proof)" field is the load-bearing audit pin — implementers reading the fixture see this came from real production code that hit the failure mode, not a synthetic constructed example. That's the framing that makes the fixture stick as a motivating example rather than a textbook case.

Approving for the v0.3.2 inline-vector publish window. Will pre-stage the harness aggregator entry tagging this fixture as the production-derived motivating example for the depth-first proof-stripping normative MUST. When cte-test-vectors.json v0.3.2 publishes mid-May, this fixture lands as a co-equal entry alongside multi_nesting_5_level_reentrant (synthetic re-entrancy) and multi_nesting_negative_partial_strip (negative-path), making the failure-class coverage triadic: production-derived + synthetic + negative-path.

For @aeoess on the APS-side mirror: this is the natural addition to aeoess/aps-conformance-suite cross-impl-receipts/ once the v0.3.2 vectors merge — same one-fixture-two-failure-surfaces shape covers the bilateral-delegation depth-walker code path on the APS side too.

For the A2A #1786 announcement post when v0.3.2 lands: the production-derivation framing + the canonical_immune: true symmetric proof is exactly what sponsorship reviewers need to see. "Two structurally different recursive-attestation systems hit the same failure class via the same canonical-bytes diff" is a categorically stronger argument than any single fixture would be on its own.

Looking forward to the merge alongside the v0.3.2 inline-vector publish. Tag me on the announcement when ready.

— Kenne

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants