Skip to content

starknet_transaction_prover,tower_ohttp: OHTTP-unlinkable request-id for decapsulated content#14222

Open
avi-starkware wants to merge 1 commit into
avi/prover-v3/request-logsfrom
avi/prover-v3/content-id
Open

starknet_transaction_prover,tower_ohttp: OHTTP-unlinkable request-id for decapsulated content#14222
avi-starkware wants to merge 1 commit into
avi/prover-v3/request-logsfrom
avi/prover-v3/content-id

Conversation

@avi-starkware
Copy link
Copy Markdown
Collaborator

Tags downstream content logs with a request-id via a new RequestSpanLayer
placed below the OHTTP layer. For plaintext it reuses the envelope id from
RequestLogLayer; for an OHTTP-decapsulated request (marked with a new
tower_ohttp::Decapsulated extension) it mints a FRESH UUID and discards any
client-supplied inner id.

The fresh inner id is never echoed back, so the relay-visible envelope id and
the gateway's content-log id cannot be joined — preserving OHTTP unlinkability
while still giving every request's downstream logs a correlatable id.

Co-Authored-By: Claude Opus 4.7 (1M context) noreply@anthropic.com

@reviewable-StarkWare
Copy link
Copy Markdown

This change is Reviewable

@avi-starkware avi-starkware force-pushed the avi/prover-v3/request-logs branch from b74ee13 to 49a7855 Compare May 27, 2026 14:20
@avi-starkware avi-starkware force-pushed the avi/prover-v3/content-id branch 2 times, most recently from 4055121 to bfa94e0 Compare May 31, 2026 10:23
@avi-starkware avi-starkware force-pushed the avi/prover-v3/request-logs branch from 49a7855 to 112d26d Compare May 31, 2026 10:23
@avi-starkware avi-starkware marked this pull request as ready for review May 31, 2026 10:38
@cursor
Copy link
Copy Markdown

cursor Bot commented May 31, 2026

PR Summary

Medium Risk
Changes HTTP middleware ordering and privacy-sensitive request-id handling for OHTTP; mistakes could re-link relay and gateway logs or break request correlation.

Overview
Adds RequestSpanLayer below OHTTP in the prover HTTP/TLS middleware stack so downstream http_request tracing spans get a correlatable x-request-id without linking relay-visible envelope traffic to gateway content logs.

For plaintext, the layer reuses the same id as outer RequestLogLayer (or generates one when run alone). For OHTTP-decapsulated inner requests, tower_ohttp now tags rebuilt requests with a Decapsulated extension; RequestSpanLayer mints a new UUID, drops any client inner id, sets the header only on the inner dispatch, and does not echo that id on the encrypted inner response—so envelope ids stay unlinkable from content-side logs.

Unit and integration tests cover plaintext reuse, decapsulated fresh ids, log+span sharing, production layer ordering (including span inside OHTTP), and an end-to-end unlinkability check.

Reviewed by Cursor Bugbot for commit adf3407. Bugbot is set up for automated code reviews on this repo. Configure here.

@avi-starkware avi-starkware force-pushed the avi/prover-v3/request-logs branch from 112d26d to fef476a Compare June 1, 2026 08:17
@avi-starkware avi-starkware force-pushed the avi/prover-v3/content-id branch from bfa94e0 to 54145f3 Compare June 1, 2026 08:17
…for decapsulated content

Tags downstream content logs with a request-id via a new `RequestSpanLayer`
placed below the OHTTP layer. For plaintext it reuses the envelope id from
`RequestLogLayer`; for an OHTTP-decapsulated request (marked with a new
`tower_ohttp::Decapsulated` extension) it mints a FRESH UUID and discards any
client-supplied inner id.

The fresh inner id is never echoed back, so the relay-visible envelope id and
the gateway's content-log id cannot be joined — preserving OHTTP unlinkability
while still giving every request's downstream logs a correlatable id.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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