Hendrik Eeckhaut

Users want their apps to be fast and don't like waiting for proofs. So "make TLSNotary faster" has been the number one request since forever. We've answered it by picking the fastest crypto we can find (without compromising on security) and trimming overhead out of the implementation release after release.

When the situation allows, we can do even more: things like deferred decryption and the full-reveal fast path. The full-reveal fast path has been available since alpha.13 (PR #1010), but we've never really explained what it does or measured what it buys you. This post fixes that.

We recently announced Proxy mode support in TLSNotary as a faster zkTLS protocol and discussed the security assumptions. In this post we bring the benchmark results.

We ran the benchmark harness across the same network profiles, sweeps, and payload sizes that anchored our August 2025 and alpha.14 posts, in both native and browser builds, and added Proxy mode side-by-side with MPC mode. The headline finding lives below; the rest of the post is about when each mode is the right choice, because faster is not always better. A full alpha.14-vs-alpha.15 comparison is coming with the alpha.15 release post; this post is the mode comparison only.

Today we're introducing proxy mode: a fast, lightweight way to prove the authenticity of web data using TLSNotary. It complements our existing MPC-TLS approach, giving developers a choice between maximum security and maximum speed, and you can switch between the two with a simple toggle.

Testing and benchmarking a multi-party computation (MPC) protocol like TLSNotary presents unique challenges. Three parties, Server, Prover and Verifier, must communicate over a network, and the protocol's performance is highly sensitive to real-world network conditions: multiple communication rounds make it latency-sensitive, while significant data transfer makes it bandwidth-sensitive. Add network failures and browser/WASM support to the mix, and things get even more interesting.

In this post, we'll walk through how we built a test and benchmark harness that provides reproducible network conditions for both native and browser-based testing. This is the same harness we use to produce our performance benchmarks.

Over the past months, we’ve made major performance leaps in TLSNotary. We implemented the VOLE-based IZK backend (QuickSilver) and introduced control-flow and MPC optimizations across the stack.

Starting with v0.1.0-alpha.8, QuickSilver replaced the older garbled-circuit proof backend, reducing bandwidth usage and sensitivity to latency. Subsequent releases added transcript hash commitments, low-bandwidth modes, faster APIs, and more. (https://github.com/tlsnotary/tlsn/releases)

These changes yield significant performance gains in both native and browser builds.

In this post, we share results from our new benchmarking harness and highlight how different network conditions (bandwidth, latency, response size) affect real-world performance.

This blog post contains the instructions for the TLSNotary workshop we present at DefCon 2025. The workshop aims to introduce participants to TLSNotary, covering its use in both native Rust and browser environments.

We are publishing these instructions beforehand so you can prepare (see Pre-Workshop Setup), and they are also very useful for people who can't attend in person.

This blog post contains the instructions for the TLSNotary workshop we presented at DevCon 2024. The workshop aimed to introduce participants to TLSNotary, covering its use in both native Rust and browser environments.