zkTLS / TLSNotary Integration — Full Recall

gistfile1.txt

  ---
  zkTLS / TLSNotary Integration — Full Recall

  Project Summary

  Newton is integrating TLSNotary (MPC-TLS) for verifiable web data proofs in Rego policy evaluation. Author: @sigrid-magiclabs
  (Linear: NEWT-490).

  PR Chain Status (as of ~6 days ago)

  ┌──────────────────────────────────────┬───────────────────────────────────────────────┬──────────────────────────────────────┐
  │                  PR                  │                     Scope                     │                Status                │
  ├──────────────────────────────────────┼───────────────────────────────────────────────┼──────────────────────────────────────┤
  │ PR #379 (newton-prover-avs)          │ Phase 2: TLSNotary proof fetching, stub       │ MERGED to main (2026-03-11)          │
  │                                      │ extension                                     │                                      │
  ├──────────────────────────────────────┼───────────────────────────────────────────────┼──────────────────────────────────────┤
  │ PR #380 (newton-prover-avs)          │ Phase 3: _newton namespace, pipeline          │ CHANGES_REQUESTED (review ID         │
  │                                      │ integration                                   │ 3927672587)                          │
  ├──────────────────────────────────────┼───────────────────────────────────────────────┼──────────────────────────────────────┤
  │ Regorus PR #3                        │ Real newton.crypto.tlsn_verify()              │ CHANGES_REQUESTED (review ID         │
  │ (newt-foundation/regorus)            │ implementation                                │ 3927753678)                          │
  └──────────────────────────────────────┴───────────────────────────────────────────────┴──────────────────────────────────────┘

  Architecture (Target Data Flow)

  Client creates TLSNotary presentation
    → Gateway injects proof_cid into wasmArgs._newton namespace
    → Operator extracts _newton directives, fetches TLS proof via CID
    → Operator calls newton.crypto.tlsn_verify(presentation, notary_key) in Rego
    → Extension verifies P-256 signature, Merkle proofs, extracts HTTP fields
    → Policy evaluates against verified {server_name, response_body, request_target}
    → BLS sign result

  Critical Blockers Found in Review

  1. policyData.push() breaks on-chain validation (PR #380) — fetch_and_inject_tls_proof() pushes a PolicyData entry with
  Address::ZERO, violating policyData.length == policyDataAddresses.length. Fix: same pattern as privacy layer — pass TLS proof via
  separate channel (ConsensusCommitRequest field), keep policyTaskData unmodified.
  2. Custom BCS serializer (Regorus PR #3) — ~400-line from-scratch reimplementation of BCS instead of using the tiny
  no_std-compatible bcs crate. Tests use custom serializer for both signing and verification, so they can't detect divergence from
  real TLSNotary presentations.
  3. No golden fixture test (Regorus PR #3) — All 9 tests use synthetic presentations. Need a hardcoded real TLSNotary presentation
  for wire-format compatibility validation.
  4. Challenger reproducibility gap (PR #380) — Challenger decodes _newton directives but does NOT fetch/inject TLS proof before
  evaluate_and_prove(), so it would produce different evaluation results and potentially raise false challenges.
  5. Extension stub in wrong location (PR #380) — tlsn_extension.rs placed in crates/core/src/rego/ instead of
  libs/regorus/src/extensions/. Adds unnecessary deps to core crate.

  Key Design Decisions

  1. No tlsn-core dependency in regorus — Parse presentation format directly for SP1 zkVM compatibility
  2. _newton reserved namespace — Protocol-level directives separate from user wasmArgs
  3. TLS proof data via separate channel, not policyTaskData — Same pattern as privacy layer
  4. Two serialization formats: bincode 2.x for presentation envelope, BCS for notary signature on attestation_header (NOT
  interchangeable)

  What's Solid

  - _newton namespace design in crates/core/src/common/wasm_args.rs — 9 tests, clean API
  - Regorus PR #3 placement: src/extensions/tlsn.rs with newton-tlsn feature flag
  - P-256 signature verification, Merkle proof verification, gap rejection, chunked transfer-encoding support
  - no_std compatible deps

  ---
  ★ Insight ─────────────────────────────────────
  The three memory systems provided complementary results:
  - Local auto-memory (zktls-integration.md): Most comprehensive — the structured reference doc with full architecture, component
  table, and phase roadmap
  - Supermemory (4 hits, 77-78% relevance): High-level summaries — good for team-wide context ("PR #380 is in review",
  "architectural issue in PR #379")
  - Recall-local (15 hits): Granular decision-level memories — surfaced the serialization format distinction, extension placement
  error, and design rationale with importance scoring
  ─────────────────────────────────────────────────

  Want me to check the current status of PR #380 or Regorus PR #3 on GitHub to see if anything has changed since the reviews?