Integrate proximity signatures for DA-bound work report verification

[hitchho]

Summary

Angeris & Gurkan's Proximity Signatures (April 2026) solve a key binding problem in our verifiable execution design: how to cryptographically verify that DA-encoded data was signed by the claimed guarantor, without downloading the full blob.

Currently our design uses separate fields (proof_hash, commitment_root) to bind the Ligerito proof to the work report. Proximity signatures subsume both — the guarantor's signature covers the DA encoding directly, and verification piggybacks on the existing ZODA proof with zero additional encoding cost.

How it maps to JAM

JAM mapping:
  Signer i     = guarantor i (one per core)
  Slot j       = timeslot j
  Message m̃_ij = work package data for core i, slot j
  Matrix X_j   = DA-encoded block (all 341 cores)
  
  ZODA proof   = already used for DA encoding check
  Prox sig     = guarantor's signature on the encoded data
  
  Key insight: ZODA's random linear combination y_j = X̃_j r_j
  can be REUSED for signature verification — zero additional
  encoding work. The signature verification piggybacks on the
  DA proof for free.

What changes

Remove from VerifiableFields:

• proof_hash (replaced by proximity signature)
• commitment_root (subsumed — DA encoding IS the commitment)

Add to work report:

• Σ_ij: proximity signature per guarantor per slot (48 bytes, BLS12-381)
• Uses the many-slot construction (Section 3.2 of the paper)

Verification (batched, per slot):

Equation (2) from paper:
  Σ_i (r_j)_i ⟨Σ_ij, PK_i⟩ = ⟨(r_j^T 1)H(0,s_j) + Σ_k (y_j)_k H(k,s_j), g2⟩

  Left side: n+1 pairings (342 for JAM)
  Right side: reuses y_j from ZODA proof (already computed)
  
  Cost: ~342 pairings, batchable to ~684ms
  On 16 cores: ~43ms per slot

Security:

• Many-slot proximate existential unforgeability (Section 2.3)
• If signer signs two different messages in same slot → signature malleable (detectable, slashable)
• Proof in AGM + ROM, reduces to (1,1)-dlog (Section 3.3)

What this gives us

1. Binding without downloading: light nodes verify work package signatures by sampling ~64 DA rows + checking proximity signature. No full blob download.
2. Remove proof_hash/commitment_root: the proximity signature binds the guarantor's identity to the DA encoding directly. Simpler protocol.
3. Payment for inclusion: the paper's motivating problem — verify that every DA blob was paid for (signed by someone who paid). Directly applicable to JAM work packages.
4. Reuse ZODA work: the random linear combination from ZODA DA proof is reused for signature verification. Zero additional encoding overhead.

Implementation plan

1. Add ProximitySignature type to Jar.Verifiable.Types
2. Implement Sign (guarantor side): Σ_ij = κ_i(H(0,s_j) + Σ_k (m̃_ij)_k H(k,s_j))
3. Implement Verify (validator side): batched pairing check using ZODA's y_j
4. Remove proof_hash and commitment_root from VerifiableFields
5. Integrate with grey-crypto (BLS12-381 pairings already available)
6. Benchmark: 342 pairings per slot

References

• Proximity Signatures — Angeris & Gurkan, April 2026
• ZODA — the DA encoding proof we already use
• The Accidental Computer — DA = commitment
• Linear Subspace Signatures — Boneh, Freeman, Katz, Waters 2009
• OOPS — Gurkan, Jovanovic, Novakovic 2025
• Branch: ve-clean on hitchhooker/jar
• https://github.com/rotkonetworks/romio