Hendrik Eeckhaut

Web proofs let a user prove a real-world fact (a bank balance, a payment, an identity) to an app that otherwise has no way to trust it. Each one rests on a guarantee: that the data is genuine, and that the user's secrets stayed private. That guarantee can be rooted in very different places.

Peer, a noncustodial fiat-to-crypto protocol and a prominent production zkTLS application, just moved its payment verification to a TEE running in AWS Nitro Enclaves. The reason is speed: in their words, from about thirty seconds down to under a second. That is a real win, and Sachin's public write-up is candid about the reasoning behind it.

To be clear, we are not neutral: we think zkTLS is the stronger approach and would like to see Peer keep it. For some applications the TEE trade is a defensible call. Either way, web proofs never remove trust; they relocate it. A TEE moves it onto a chip and the vendor that attests to it, but the user's privacy now rests on that attestation rather than on cryptography.

There's a common misconception that a zkTLS proof works like a zkSNARK on a blockchain: a self-contained Zero Knowledge Proof that anyone, anywhere, can verify, with no trust in anyone. You generate it, you publish it, the world checks it. Forever.

Unfortunately, that is not how zkTLS works, and it is a common source of confusion. This post is about what "publicly verifiable" actually means for a zkTLS proof, whom you're trusting when you check one, and why that turns out to be a feature rather than a flaw.

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.