starknet_transaction_prover: relay opaque additional_data from check response

[avi-starkware]

The external check's allow response may carry a screening signature
({ allowed: true, signature: { issued_at, sig_r, sig_s } }) for screened
transactions. BlockingCheckResult::Allowed now carries it as an Option.
An allow response with a malformed signature fails envelope parsing and
maps to Inconclusive (deferring to the fail-open policy) — a corrupt
signed-allow means the screening path is misbehaving, so it is not
treated as a clean allow.

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

[reviewable-StarkWare]

This change is 

[avi-starkware]

• starknet_transaction_prover: bump starknet_specs rev for additional_data #14421
• starknet_transaction_prover: relay opaque additional_data on proveTransaction response #14411
• starknet_transaction_prover: relay opaque additional_data from check response #14410 👈 (View in Graphite)
• main-v0.14.3

This stack of pull requests is managed by Graphite. Learn more about stacking.

[cursor]

PR Summary

Medium Risk
Changes transaction-screening response handling and fail-open behavior when allow payloads are malformed; proving gating logic is unchanged but screening metadata plumbing is new.

Overview
starknet_checkTransaction allow responses can now include an opaque JSON object additional_data (e.g. screening signature metadata). BlockingCheckResult::Allowed is now Allowed(Option<Map<String, Value>>) instead of a unit variant, and the blocking-check client deserializes result.additional_data and stores it without interpreting keys—intended for verbatim relay on the prove response later.

Malformed additional_data (non-object JSON) fails envelope deserialization and maps to Inconclusive, so fail-open/fail-close applies instead of treating the tx as a clean allow. Tests cover empty allow, verbatim relay, missing additional_data, and invalid types. virtual_snos_prover only updates the Allowed match arm to Allowed(_); allow/deny behavior is unchanged in this diff.

^{Reviewed by Cursor Bugbot for commit f459598. Bugbot is set up for automated code reviews on this repo. Configure here.}

[remollemo]

@remollemo reviewed 3 files and all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on ittaysw and Yoni-Starkware).

[Yoni-Starkware]

@Yoni-Starkware reviewed all commit messages and made 1 comment.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on avi-starkware and ittaysw).

---

crates/starknet_transaction_prover/src/proving/virtual_snos_prover.rs line 56 at r1 (raw file):

    /// ECDSA signature `s` component.
    pub sig_s: Felt,
}

Why do you need to expose this in the proving service?
I was thinking about returning a dict from the interceptor ("additional_data") and outputting it as-is.
The prover should not be aware to the content (signature etc)

Code quote:

/// Screening signature the external blocking check service attaches to an allowed,
/// screened transaction. Relayed verbatim to the prover's client, which submits it
/// on-chain alongside the proven actions.
///
/// `issued_at` is unix seconds; the felts serialize as `0x`-prefixed hex strings.
#[derive(Debug, Clone, PartialEq, Eq, Serialize, Deserialize)]
pub struct ScreeningSignature {
    /// Unix timestamp (seconds) at which the signature was issued.
    pub issued_at: u64,
    /// ECDSA signature `r` component.
    pub sig_r: Felt,
    /// ECDSA signature `s` component.
    pub sig_s: Felt,
}

[Yoni-Starkware]

@Yoni-Starkware reviewed 3 files and all commit messages, made 1 comment, and resolved 1 discussion.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on ittaysw).