Proxy-based TLSN

[th4s]

This PR adds the proxy-based approach to TLSNotary.

• Core config (crates/core): Extends TlsCommitProtocolConfig with a Proxy variant and adds ProxyTlsConfig
• Dependency wiring (crates/tlsn/src/deps/): Replaces the old monolithic mpz.rs with a deps/ module that has ProverDeps and VerifierDeps enums, each with Mpc and Proxy variants, encapsulating setup/allocation logic per mode.
• Proxy TLS client (crates/tlsn/src/prover/client/proxy/): A new ProxyTlsClient implementing the TlsClient trait. Uses custom rustls CryptoProvider wrappers (InterceptingKxGroup, InterceptingPrf) to intercept the pre-master secret, verify-data, and handshake hashes during a real TLS 1.2 handshake.
• Proxy protocol logic (crates/tlsn/src/proxy/): Core proxy module with ProxyProver and ProxyVerifier (ZK-based PRF verification and key derivation), plus a TlsParser that parses raw TLS records to reconstruct the TlsTranscript.
• Prover/Verifier refactoring: Both Prover and Verifier now branch on the protocol config to instantiate either MPC or proxy dependencies. Tag verification is moved out of the MPC client into the shared finish() path. ProverFuture gains a Finishing state to handle the now-async finalization.
• Verifier proxy forwarding (crates/tlsn/src/verifier.rs): In proxy mode, the Verifier connects to the server, forwards TLS traffic bidirectionally, parses the TLS records, and then runs ZK verification of the verify_data.
• Tests, examples, harness, WASM: Adds a proxy integration test, a proxy example, harness benchmark/test plugin support, and wasm bindings for proxy mode configuration.

[th4s]

Benches

Config used: bench.toml (or bench_proxy.toml)

[[group]]
name = "cable"
bandwidth = 20
protocol_latency = 20
upload-size = 1024
download-size = 2048

[[bench]]
group = "cable"


[[group]]
name = "mobile_5g"
bandwidth = 30
protocol_latency = 30
upload-size = 1024
download-size = 2048

[[bench]]
group = "mobile_5g"


[[group]]
name = "fiber"
bandwidth = 100
protocol_latency = 15
upload-size = 1024
download-size = 2048

[[bench]]
group = "fiber"

Results

MPC Native

cable [mpc] (20 Mbps, 20ms latency, 1KB↑ 2KB↓):
Median: 14.51s

fiber [mpc] (100 Mbps, 15ms latency, 1KB↑ 2KB↓):
Median: 3.65s

mobile_5g [mpc] (30 Mbps, 30ms latency, 1KB↑ 2KB↓):
Median: 10.38s

MPC Browser

cable [mpc] (20 Mbps, 20ms latency, 1KB↑ 2KB↓):
Median: 15.79s

fiber [mpc] (100 Mbps, 15ms latency, 1KB↑ 2KB↓):
Median: 4.98s

mobile_5g [mpc] (30 Mbps, 30ms latency, 1KB↑ 2KB↓):
Median: 11.64s

Proxy Native

cable_proxy [proxy] (20 Mbps, 20ms latency, 1KB↑ 2KB↓):
Median: 1.57s

fiber_proxy [proxy] (100 Mbps, 15ms latency, 1KB↑ 2KB↓):
Median: 0.94s

mobile_5g_proxy [proxy] (30 Mbps, 30ms latency, 1KB↑ 2KB↓):
Median: 1.55s

Proxy Browser

cable_proxy [proxy] (20 Mbps, 20ms latency, 1KB↑ 2KB↓):
Median: 2.04s

fiber_proxy [proxy] (100 Mbps, 15ms latency, 1KB↑ 2KB↓):
Median: 1.40s

mobile_5g_proxy [proxy] (30 Mbps, 30ms latency, 1KB↑ 2KB↓):
Median: 1.95s

[th4s]

TODOs before merge

• Review and merge fix(zk): account for non-executable circuits privacy-ethereum/mpz#378 and adapt mpz dependencies in Cargo.toml to correct tag/rev.
• Review and merge feat(prf): add support for EMS mode #1121 and rebase.

[th4s]

Ideally we want to write, close and then read. I did not find the right solution to do this, so left it at write, read and close for now.

The problem: Even though packets arrive in the correct order on the server side (I checked) namely first app_data then close_notify_alert, the server parses it in one go and because he sees the close_notify he does NOT answer the app_data request.

The problem is not visible on the MPC test I guess, because there is an async latency overhead because of the network topology. The server parses the records one after the other and thus sends a response.

Not clear what the best approach here is? Introducing artificial time-based delays seems wrong and would not be a proper solution. The right fix is on the server side I think, but the question is how do we want to handle this on the client side?