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.

We're pleased to share performance improvements in TLSNotary alpha.14. Through optimizations across the protocol stack, alpha.14 delivers speedups of 8% to 16% across real-world network scenarios.

In this post, we present detailed benchmarks comparing alpha.13 and alpha.14 across different network conditions, demonstrating how these improvements translate to real-world performance gains for both native and browser deployments.

The following article is a bit meaty, so for those who just want the key points, feel free to skip to the last section.

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.

Ethereum just turned 10. But before Ethereum, another protocol called TLSNotary was using cryptography to increase trust on the internet, to make the internet more peer-to-peer, censorship resistant, and verifiable.

In 2013, the internet was very different from today. Bitcoin was one of the most exciting and revolutionary ideas around. It wasn’t strictly a financial asset or “digital gold.” It was more open-ended. A potential gateway for other cryptographically enabled tools. This context formed the original motivation for TLSNotary, which was to build a mechanism to help free “Bitcoin from the harassment of the banks.” (https://bitcointalk.org/index.php?topic=173220.0)

TLSNotary aimed to do this by leveraging the same cryptographic protocol that secures the modern internet: TLS. It grew up alongside the web, working in parallel with the technology that powers most of today’s online activity.

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.

TLSNotary is a protocol which allows people to export data from any web application and prove facts about it to a third-party in a privacy preserving way.