Pluto is an API for any web data, embed it in your app to authenticate users, share data and perform actions on their behalf for any site on the internet.

Zero-knowledge proofs are a complicated subject. It might take a background in advanced cryptography, theoretical computer science and mathematics to learn exactly 

 these zero-knowledge proofs (’ZKPs’) work. 

But ZKPs are really just another set of tools in a developer’s toolkit. 

Developers shouldn’t need to be cryptographers to use ZKPs in their applications, 

the same way developers can use hash functions without needing to understand the constructions of those hash functions.

In this primer, we’ll help you think through ZKPs from first principles, starting from the ‘

The explanations that are commonly used to describe ZKPs — from 

prove your age to a bartender without showing ID

rather than what you might do with this stuff once you’ve got it.

As an application developer thinking about how to build the next big application, it can be easy to miss the forest for the trees. The trees are all of the cryptography jargon, the advanced mathematics, 

and the ‘how’ of constructing a ZKP. 

But the forest is the ‘why’ — why would I even want to use this stuff in the first place?

Missing the forest for the trees, lunarpunk style — DALL-E

As far as tools in a developer’s toolkit go, ZKPs are a Swiss army knife. ZKPs can be used to:

Bring offchain state transitions onchain —

 ZK rollups bundle up transactions and bring the output of those transactions onchain.


 — Developers can do arbitrary computation offchain on some data, and then bring that verifiably-computed data onchain. Essentially, the “copy, paste” action, but for computation.


Bring prior onchain history back onchain —

 Developers can grab prior blockchain history and bring it back onchain to be used in smart contracts. This is the ‘state proofs’ category of ZKPs. 


data, either bringing blockchain data from one blockchain to another, or bringing the history of a blockchain back up to the top of the chain.  But ZKPs are much more expressive than just moving and verifying data on a blockchain.  

ZKPs can also be used as one approach to prove arbitrary data from internet sources in a verifiable way. We call these ‘Web Proofs’. 

, like ‘people that live in Florida', without revealing any other personal details.

A proof that you reached a certain rating (like >4.5 stars) on a platform (like Uber or Airbnb) without disclosing the personal details of your interactions on these services.

A proof that you have some badge, item, or accomplishment in a certain online game.

A proof that you received a certain type of email from a certain sender.

A proof that you have achieved certain financial milestones, like $X in a savings account or $Y in retirement accounts.

A proof of educational achievements or certifications.

You can think about  Web Proofs  as combining a ‘Proof of Data Existence’ plus a ‘Proof of Data Integrity’, rolled up into one useful package. And the generalization of all of these examples into a single holistic description of Web Proofs:

Proofs of arbitrary data served to end users by any internet server.

Besides ZKPs, there are other approaches to Web Proofs, but those come with slightly different trust assumptions. 

Regardless of whether a ZKP is being used to create a Web Proof or not, a ZKP itself has certain guarantees.

 is created, then that proof can be verified onchain, with the chain itself acting as the autonomous verifier of the proof’s correctness, or the proof can be verified independently offchain. So a more apt general description of ZKPs is that they enable developers to (1) perform a computation, (2) credibly commit to the correctness of that computation, and (3) share a succinct proof that any party can use to verify its correctness. All of this can be accomplished while preserving the privacy of the data, which was used as input for the computation.

And this is the answer to the question of ‘why use ZKPs at all?’ — ZKPs are an incredibly expressive tool for developers. ZKPs enable verifiable movement of arbitrary data across the internet, onchain or offchain, and using these tools effectively unlocks a bunch of cool stuff that developers can build for users.

That’s what we’re all here for, right? Build cool stuff that people will use?

Yes, build cool stuff. But how is this even possible?

Well, the data that ZKPs verify — blockchain data or otherwise — is really just a 

This flips the script on our traditional notions of online interactions with other users or with the applications that we use day-to-day. The data is there, fully operational and verifiable and real, but it is shrouded from prying eyes by the ZKP, preserving privacy while ensuring data integrity.

For the purpose of an application developer, the proofs can be just as good as the underlying data. 

If your application should only grant access to those users that own a certain token… A proof that a user owns that token is just as good as checking the user’s balances yourself.

If your application needs to anonymize users for 

… A proof that a user belongs to a certain set of people, like the first 10,000 people to join Farcaster, is just as good as checking every one of the first 10,000 Farcaster joiners manually.

If your application wants to add in a reputation score based on how many positive Uber reviews a user has… A proof that a user has a high Uber rating is just as good as reading all of the user’s Uber reviews yourself.

In fact, the proofs are not ‘just as good’ as the underlying data — in many ways, having the proof is 

 than having all of the underlying data. Verifying a single proof of a user’s token balance is much more privacy-preserving than checking the user’s address yourself, and verifying a single proof of a user’s Farcaster ID is much faster and more efficient than going through all of the IDs yourself.

And verifying the proof of a user’s Uber rating onchain 

lets developers transfer trust from Uber into a smart contract

, where it can be used and accessed by other onchain applications.

That last point is an important one. While ZKPs have plenty of non-blockchain potential, bringing ZKPs of offchain data onchain represents our best chance at breaking down the Web2 data silos. 

So if you are an application developer that wants to use verifiable offchain data in your application, potentially in a privacy-preserving manner, ZKPs are the tool for you. 

We’ll walk through one in-depth example to demonstrate how ZKPs generally, and ZKPs for Web Proofs specifically, can expand the design space for onchain applications. 

Imagine an open communications protocol, where anyone can interact with the core protocol but different client implementations built on top of the protocol can choose what experience their users get. These clients differentiate themselves via their bespoke moderation of certain content, or their feature set and user experience, or really anything in-between. (This general idea might 

You are an entrepreneur building one of the clients on top of this open protocol. The appeal of your implementation over the others is that you are going to fix the onslaught of spammy posts from bots and airdrop farmers. So before users can post on your service, they will have to prove some reputation that shows that they aren’t bots or airdrop farmers. 

But you don’t want to just use ‘Sign in with Google’ — anyone can make a Google account, so bad actors will just make new accounts, and the spammy posts and phishing links will continue! No, that just won’t work. Instead, you’re going to take a scrappy approach and bootstrap reputation using other data sources. 

You’re going to ask users to show that they have achieved at least 2 (or 3, or 1, or 6 — ultimately, this is your call) of the following characteristics:

The user has received 5 positive reviews from drivers on Uber or Lyft

The user has received 3 positive reviews from hosts on Airbnb or VRBO

The user has completed a Coinbase identity verification

The user has verified their identity credentials using 

The user has sold at least $100 worth of items via a Shopify storefront

The user has an educational degree from one of the top 10,000 global universities

The user has at least 2 blog posts published on Medium or Substack before the year 2023

The user has had an active Spotify or Apple Music account for 2+ years 

Using Web Proofs, users can prove that they meet at least 2 of these characteristics. End users can prove these statements on their own devices (like their mobile phone or their personal laptops) and just show you a proof — and that’s it. They’re in. 

What did we achieve with this? Well, the burden for a bot farm or a motivated troll has just gotten a lot harder. On Twitter, we are told that the bot problem can be solved by charging us $8 a month. But as long as these bots / trolls can make more than $8 a month by scamming or phishing users, then it still makes sense for these bad actors to pay the $8 for verification! With this Web Proofs-powered reputation check, the challenge for bots and troll farms gets much much harder.

See, what we are really trying to do here is (1) make it hard for bad actors to create multiple fake accounts, (2) leverage the existing anti-sybil / anti-bot infrastructure of other companies, and (3) cover 99% of the surface area with 1% of the work. You could create a brand new identity verification product from scratch… or you could just borrow reputation from other internet sources and go back to building the application you wanted to build in the first place.

One of the most exciting applications of ZKPs is that onchain applications can get practical guarantees about the characteristics of their users without asking users to open up their entire digital history to the application. 

If you want to learn the intimate details of the ‘how’ — how to construct a ZKP from scratch — there are many great resources:

These resources can help guide you deeper down the path of the advanced cryptography and mathematics required to create ZKPs from scratch. 

But our goal at Pluto is to unlock the ‘why’ and to abstract the cryptographic complexity away for application developers. So to recap:

ZKPs can be used in many contexts, and many people are experimenting with onchain and offchain ZKP use cases. 

The ‘Web Proof Techniques’ series covers the technical implementations of various Web Proof protocols. This article focuses on MPC Mode — future articles in the series will cover Origo Mode and TEE Mode.

This article is a comprehensive introduction to the 

, which powers Pluto’s MPC Mode. Originally conceived of in 

, TLSNotary has been subsequently re-designed and 

 group with modern cryptographic components.

 are productionizing TLSN to enable smart contract developers to take advantage of any off-chain data sources in their smart contracts in a service that we are calling 

If you were to share the contents of your TLS transcript with a third party, that party would have no way to detect whether the transcript had been forged with faulty data. MPC Mode, powered by TLSN, is a protocol for 

— data with proof of origination from some particular server.

Why would you read this article instead of the well-written 

 This article aims to cover TLSN first from high level, then to give the requisite mathematical background to understand the protocol. We'll start off with a basic background of the architecture of TLSN, and provide design motivation, before opening each box and visiting cryptographic details.

We will assume a working background knowledge of the basic workings of TLS¹.

TLS (or Transport Layer Security) is a protocol for encrypting and authenticating communication between two parties: a Client (described elsewhere in this post as the Prover) and a Server. TLS Notary is a protocol that allows the Client to prove Data Provenance to a third party; in other words, TLS demonstrates that the Client honestly obtained the data from the Server, and did not interfere with the contents. 

The TLS Notary protocol aims to achieve the following properties:

 - the protocol should demonstrate that TLS transcript is not a forgery by the client

 - the protocol should authenticate the identity of the server via certificate chain verification--a valid transcript with a fake 

 - the Client should not have to sacrifice the privacy of their data or credentials to a third party

³ - The protocol should avoid enshrining a single service provider as intermediary

We'll begin with a simplified picture of TLSN, and work towards the complete architecture.

A simplified TLSN architecture with minimal cryptography

Figure 1 — a man-in-the-middle simplification of TLS Notary

In Figure 1, we introduce two new parties to the TLS Protocol: a 

, who observes and stores encrypted traffic between the Client and Server, and a 

, who is interested to verify the contents of the Client-Server transcript.

In this flow, the Proxy observes traffic between the Client and Server, and saves the encrypted TLS transcript. 

At the end of the session, the Client sends the Proxy:

 for the session, held by Client and Server

 the certificate chain, attesting to the Server's identity

 the TLS transcript with the Client's symmetric key

 the decrypted transcript, or signs the subset of the transcript that the client wants to share

The Proxy-signed TLS transcript data may then be passed to the verifier. The verifier checks the Proxy's signature, and is thereby convinced of 

Besides the sacrifice of privacy, the Proxy is an 

. The intermediary role of the Proxy bottlenecks the service, potentially limiting overall network traffic. Finally, a compromised Proxy may collude with a client to deceive the verifier. 

In the following sections, we will discuss how the TLS Notary architecture resolves these issues. First, a brief interlude to introduce the active cryptographic component in TLSN, multi-party computation.

 is the cryptographic problem of how to compute a function 

, each with knowledge of their corresponding private input to the function. Parties are interested in the output 

, but would also like to avoid leaking information about their secret data.

, where each party obtains some "share" of a secret shared by everyone; e.g. additive shares 

, where parties hold the shares, but neither party knows the value of 

, in some way the preserves the mathematical structure of the following step

if the output is not already in plaintext (i.e. if homorphic encryption is employed), a final 

 step may be required to obtain the result

In the context of TLSN, MPC is applied to constrain the Client's ability to exchange messages with the server. A secondary party, termed the Notary, performs MPC with the Client to 

 messages. Because of the privacy preserving nature of MPC, the Notary prevents the Client from forging messages, without ever observing the messages the client sends.

In a few sections, we'll put our cryptography hats on to discuss the mathematics of Garbled Circuits MPC, but first we'll update our simplified architecture model of TLS Notary, employing MPC.

In the updated architecture picture, we replace the Proxy server with a MPC partner for the client, who shall be called the Notary. The Notary performs MPC with the Client to perform TLS protocols, including key exchange, encryption, authentication, and decryption. However, via MPC, the Notary 

 of the Client's transcript, thereby preserving Client privacy.

Recall from prior discussion that the TLS Notary protocol aims to achieve:

 - The protocol should avoid enshrining a single service provider as intermediary

We've already discussed how client privacy is obtained. The protocol may be rendered 

 by allowing the Verifier to accept transcripts produced with other Notaries than the Pluto Notary. We are also investigating the security-performance trade-off of further decentralizing the Notary, from 2-party Client-Notary computation to 3-or-more-party Notary computation.

 of the Server's identity is obtained identically to our simplified protocol: by verification of the Certificate chain providing the Server's public key.

 is obtained by a cryptographic technique called 

. Blind signatures allow the Notary to sign commitments to the Client's messages. This prevents the client from later forging the content of their message, while the Notary never observes message plaintexts.

Blind signatures are also constructed over commitments to the Server's identification; that is, the Notary also never directly observes the identity of the Server.

We close our high level discussion of the TLS Notary Protocol with a mini-spec of the TLS Notary protocol, that we will expand on in greater depth in the next post.

Preprocessing step: Client and Notary perform Oblivious Transfer pre-processing, to allow for faster online proof computation.

Prior to Key Generation: Client obtains Server's public key and certificate chain, proving Server public key authenticity.

Key Generation: Client and Notary generate ephemeral key shares of the TLS shared secret (premaster key), for encryption and authentication with the server

Encryption and Authentication: Client wants to send a message to the server. Client and Notary use 2-party computation to encrypt and authenticate the message. Notary blind-signs the message, and client sends the encrypted message to the server.

Client and Notary use 2-party computation again to decrypt and authenticate the Server's message. These two steps repeat until the client's session is complete.

Proof generation: At the end of the protocol, the Client possesses a certificate chain of the server's identity, and the TLS transcript with signatures from the Notary. A proof may be generated to verify succinctly correctness of the signatures and certificate chain.

We may discuss selective disclosure in a further post.

In this post, we gave a high-level description of TLSNotary, starting with a simplified architecture and progressing through towards an overview of the TLSNotary protocol that includes multi-party computation.  

In a follow-on post, we will examine the protocol from a mathematical lens. If you’re interested in working on MPC Mode or related technologies, 

¹We may write a primer on TLS in the future, but have not yet.
²The term 

, used elsewhere, refers to the combination what we term Authenticity and Provenance.
³Non-Proprietary gets at the point that the service provider should be replaceable; but the term Non-Proprietary is slightly misleading. I came up with these terms on the fly, don't read them as gospel.

 is a Rust implementation of a collection of cryptographic primitives inspired by 

. This is technical content aimed at demonstrating theoretical properties of applied cryptography alongside a concrete application in a programming language well-suited for cryptography.

 is constructed from first principles so there is no assumed knowledge of external libraries or verbose dependancies (other than 

). Much of the code here is not optimized in efforts of mathematical transparency and simplicity. 

This work serves as a toy implementation of cryptographic primitives to help cultivate an understanding of the implementation details — therefore, much of the code is not optimized, not secure, and is not intended for commercial use. We started with implementing primitives to build KZG proofs and then kept building additional primitives from there. An outline of this content is presented below. 

Finite Fields are a core primitive used extensively in cryptography. This library has a Finite Field module. We use this to define a field of prime order 

, which we use as our base field in our KZG construction. Note that this prime came from 

100 \equiv -1, 50 \equiv  -\frac{1}{2}, 20 \equiv  -\frac{1}{5} 

The first curve group is defined over our base field. The library also supports the field extension 

 (we will explain this rationale later in the elliptic curve section) for our KZG construction. It’s common to denote the curve group over the field extension as 

. In order to build the extensions in general, we needed a polynomial module.

Polynomials are a ubiquitous construction with many applications. We use our polynomial module for our extension fields, Reed-Solomon encodings, and polynomial commitment schemes. A polynomial commitment scheme is another core cryptographic primitive that allows a prover to commit to a polynomial in a way that its evaluations at any point can be efficiently verified by others, ensuring the polynomial’s integrity. This is used later in our KZG polynomial commitment scheme.

Elliptic curves are beautiful primitives used both in asymmetric cryptography as well as zero-knowledge proofs. In asymmetric cryptography, elliptic curves provide a high level of security with relatively small key sizes, making them more efficient and faster than traditional methods like 

. We also use elliptic curves in pairing-based cryptography with KZG proofs. We support a handmade curve library with elliptic curve point addition over a finite field. We use a pairing-friendly curve in our KZG commitments of the form 

. We say the number of points in the largest elliptic curve group is the 

For our KZG construction the base field is 

, and the scalar order of our curve group is 

a point in our first cyclic curve subgroup 

and maps them to a third group such that a pairing:

 are both of the of same order (e.g., they have the same scalar field which implies they are isomorphic). The pairing is a map between these different subgroups. If this is not immediately clear, that is okay — give it some time. We will go into more details. 

Now that we have a rough idea of the abstract structure of a pairing, let’s look into how to construct  

To construct pairing friendly curves, we start by finding the first curve group’s scalar field. The scalar field of a curve is the curve order, or the amount of points in the cyclic group generated by our generator. For our curve group 

. Now that we have the curve scalar field we can find the curves 

The embedding degree is defined as the smallest number 

 such that our curve order (size of scalar field) 

, so the embedding degree of our first curve group is 

 with this new embedding degree and our second curve group over this extension field. All of the elliptic curve points of order 17 can be found using coordinates from 

. We have documented the pairing in detail in the 

In KZG, we need a trusted setup in the form of a 

. We generate an SRS from the generators of our two isomorphic curve groups 

. The SRS is a list of points on our two curves. The number of points in the SRS from 

 is  greater than or equal to the number of constraints we want to prove (degree of the polynomial we are proving), and the number of elements in the SRS from the second curve group 

 is greater than or equal to the degree of our masking divisor polynomial. We then pick a random number in our curve scaler field 

 is both the number of gates and number of coefficients in our polynomial. Once we have the SRS, we can make commitments that are both binding and hiding for our polynomials assuming the setup was created properly. We first commit to our polynomial that we want to prove by multiplying the coefficients of our polynomial with the points in our SRS and then adding them together to get a single point in our first curve group. 

 coefficient of the polynomial. We then pick a value to evaluate our polynomial at 

 with and the result of the evaluation of this polynomial 

. Note that our polynomial has the same order of our curve 

. We then commit to the evaluation and call the the result 

The pairing check then takes these inputs and checks these two pairings are equal while utilizing the bilinear properties of the pairing to achieve multiplication, while preserving hiding properties.

We also have implementations of some asymmetric cryptographic primitives (linked below) in which a different key is used to encrypt information than the key used to decrypt information. These primitives make up a good amount of 

 and are critical for blockchain accounts and wallets. 

Elliptic Curve Digital Signature Algorithm (ECDSA)

 Implementation (Thanks to our open source contributor 

!). Hash functions are crucial in computing for ensuring data integrity, as they convert input data into a fixed-size string of characters that uniquely represents the original data. They are used in various applications such as data storage, digital signatures, and password management, providing efficient and secure ways to verify data without storing the original data. Poseidon is unique in that it falls into a new family of hash functions: 

 hash functions which have desired properties in constructing zero knowledge proofs. 

Stay tuned as we continue to add primitives to the repository and feel free to reach out in the 

 with any questions. We are actively exploring MPC primitives. 

We’ve recently been experimenting with incorporating open-source contributors into our team and development process at Pluto. 

Today, we want to extend the invitation to others interested in contributing to the forefront of applied cryptography. 

In the rest of this short post, we explain why a developer might want to contribute to our open-source repositories, what we at Pluto want to achieve with an active and open contributor ecosystem, and what our experience has been like working with a few external contributors so far. 

TL;DR — Open-source is great for projects and for external contributors, and if you want to contribute to Pluto, go to our 

. For now, we’re opening up a handful of bounties in the 

 Circom JSON circuits, which are available as open issues labelled ‘bounty’. We have also open-sourced the 

 Circom circuits, which will have bounties in the near-term. In the coming weeks, we will be open-sourcing other core repositories and adding additional bounties across the codebase.

Open-source levels the playing field for developers by removing the barriers to participation. All you need is a computer, and you’re part of the global community shaping the future of software.

There’s a long history of independent developers making significant contributions to major open-source projects. From Linux to Mozilla to Bitcoin, contributors to open-source projects have been central to the evolution of software as we know it.  

 for the contributor. The ability to collaborate with other developers working on the same project provides a valuable learning experience that just can’t happen in closed-source projects. This is especially true at the forefront of new technological innovation, like applied cryptography research and development — there’s no better proof-of-work than contributions to the projects innovating at the frontier of a rapidly-changing field.

There’s an intangible social aspect to open-source too. Open software is a modern reflection of the most basic human instincts of shared culture and shared experience. We innately search for community, shared cultural values, and a place of belonging, and open-source helps us bridge the gap of geographical distances or mismatched time zones to create a shared ecosystem where anyone in the world can participate. 

We hope that by enabling open-source contributors to participate in Pluto’s development process, we can help others dip their toes into advanced cryptography R&D and further their own careers and life experiences. 

We at Pluto are building a developer tooling company. Fundamentally, we are here to serve developers. Working together with our community is our best way for us to stay connected to that goal. By working with open-source developers, we get to learn from fresh perspectives to improve how we present, prepare, and communicate our own work to the external audience that we intend to serve. 

External contributors also hold us to a higher standard of internal work — we’re forced to clarify our thinking, raise the quality of work we do, and think more carefully about collaborative development, instead of just focusing on our own individual contributions. External contributors provide a first-pass audit of our codebase and a fresh set of eyes on the work that we do, but more importantly, they push us to be the best versions of ourselves as software developers.  The involvement of independent contributors is fundamental to the growth and success of any open-source project, and we hope to continue to enable collaborative, positive-sum contributions.

We’re grateful for the experience of working with the small handful of external contributors we’ve had so far. Specifically, we want to mention the work that has been done by our closest collaborators and the work done by a few ambitious hackers at ZK Hack Montreal last month.

 has been a poster child for the relationships that open-source can create. Through his excellent contributions to Ronkathon over the past 3 months, he has been learning about specific implementations of applied cryptography primitives, and we’ve been able to bring Lonerapier closer to the team as the first part-time contributor of our continuing open-source effort. 

 is an excellent example of the collaborative development process at work.