On Zupass
I was first introduced to Zupass in November 2023, during the ProgCrypto conference in Istanbul. For a while, I’ve been interested in seeing more of cypherpunk values represented in Ethereum applications and I feel like this particular conference accomplished that goal.
One of the presentations by Vitalik focused on his philosophy: d/acc, where the “d” can stand for many things, mostly defensive, decentralization, democracy and differential. Similar to e/acc, there is still the need to build and to accelerate, but I empathize more with the direction that this philosophy guides us towards.
As a matter of fact, this “defensive” concept is perfectly aligned with the cypherpunk movement and values: the well-known 1993 Manifesto gives a strong emphasis to that: “We are defending our privacy with cryptography, with anonymous mail forwarding systems, with digital signatures, and with electronic money”. Thirty years later, here we are in Istanbul at the ProgCrypto conference, with an enthusiastic and young community of people who are starting to have a clear idea on how to build these systems with security and privacy, without compromising on other costs such as gas fees.
The cypherpunk spirit also advocates that we should create systems that should be much easier to defend than they are to attack, which deeply aligns with the d/acc philosophy – after 30 years, it feels like we’re experiencing one of those ‘full circle’ moments.
Cryptographic primitives
While “Internet cryptography” focus primarily on confidentiality and secure communication, “blockchain cryptography” focus mostly on data integrity. One of the most underrated cases of blockchains is that they allow us to create social structures with “digital hardness”.
In this context, gubsheep gave an introductory talk on “programmable cryptography”, where he presented some of the most relevant primitives that we can use to achieve this goal of having “cryptography as a defensive technology”. What was just a concept in 1993, is now becoming a reality and it’s just a matter of implementation – we can really have an open system with permissionless interoperability thanks to the power of cryptographic tools.
In short, programmable cryptography is the technology that allows the user to run arbitrary computations on arbitrary inputs. While ZK-SNARKs fit in with blockchains like a glove, providing both privacy and scalability, there are other primitives worth mentioning: encryption is useful for protecting your data privacy (e.g. FHE and witness encryption) and signatures protect us against impersonation.
I like to define programmable cryptography as a set of tools that provide the user with ownership and permissionless operability. Let’s break down each of these concepts:
- Users own their own data (ownership);
- Data is portable and interoperable across platforms (interoperability);
- Centralized actors can’t stop actions (permissionless).
Programmable cryptography unlocks a fundamentally new architecture for communication and decision-making on the Internet, where all data is interoperable and user-controlled, even allow the user to get minimal disclosure through zero-knowledge.
If we look at these primitives as “tools”, we can (and should) use them to build things. What things? Defensive technology.
Zupass as a great example of defensive technology
Once we realize the importance of building defensive software, there’s only one thing left to do: build it! In Istanbul, I got the chance to see some presentations on applications that follow the principles described above: I will particularly highlight Zupass.
Zupass was first conceived as a digital passport for Zuzalu, around early 2023. It’s currently described as “an experimental personal cryptography manager, powered by zero knowledge proofs”. However, what makes this application so special is that Zupass can store and manage any piece of proof-carrying data (PCD). Wow.
This leads us to the next question: what are PCDs? Any data whose well-formedness and validity are cryptographically verifiable. This way, Zupass can store things like signatures, zkSNARK proofs, Merkle proofs, attestations, hash commitments or keypairs (e.g. an Ethereum keypair, or a Semaphore secret and identity commitment).
Excited? Let’s break down how the world/the Internet operates today and how it can operate with an application such as Zupass (both cases inspired by gubsheep’s presentation on Zupass).
The reason why Zupass and PCDs are so exciting is that third-party applications can directly request any proof about the PCDs stored in Zupass. Some examples include Zupoll, Zucast and ZuKat, amongst others.
Zupass stamps can be keypairs, signatures or ZK proofs from arbitrary sources (or even arbitrary ZKPs about those stamps). These proofs and attestations (mentioned in green above) can be shown in-person (QR code), or digitally (e.g. only Devconnect ticket owners have access to a specific Telegram group that verifies that you own a ticket).
Using zkSNARKs, it is theoretically possible for third parties to make any query into a user’s Zupass, as long as they provide a zkSNARK circuit for that query. To quote Vitalik:
the programmability of zero knowledge proofs means that we can get past the false binary of “anonymous but risky” vs “KYC’d therefore safe”, and get privacy and many kinds of authentication and verification at the same time.
PCDs: Under the Hood
As we’ve seen, Zupass is all about storing and using PCDs. While “proof-carrying-code” is a concept that dates back from 1996, I believe the concept of “proof-carrying data” in the context of zero knowledge was introduced around 2010 by Alessandro Chiesa, in a paper in which the author points out the main differences between PCC and PCD, and even gives a definition/construction of a “PCD system”.
Let’s break down the 2 essentials parts of a PCD:
- a “claim”, which is an observation of the world (e.g. “I hold a Devconnect ticket”);
- a “proof”, which is a cryptographic/mathematical proof of the claim (e.g. “the claim is correct”).
Here’s an overview of how PCDs are used within Zupass (adapted from an ETHGlobal presentation by Ivan Chub):
Zupass is all about PCDs as we’ve seen – why are PCDs so useful?
- Easy to prove and verify statements;
- Easy to make zero knowledge proofs about a PCD, which allows to preserve privacy;
- Identity proofs are some of the simplest, most straightforward PCDs;
- PCD-based reputation systems are easier to integrate privacy.
Some examples containing Zupass integrations (via the PCD SDK framework) can be found here, which can be useful to get a better understanding of the kind of stuff you can do/build with PCDs.
Many PCDs are zkSNARKs. However, as mentioned before, not all PCDs are zkSNARKs – for example, one PCD that is not a zkSNARK is a piece of data signed by an RSA private key along with the corresponding public key.
Below is a representation of the PCD SDK internals, taken from a ProgCrypto presentation.
ZKEmail as an example…
There’s this project called ZKEmail that allows you to make zero-knowledge proofs about e-mails that you’ve received.
One potential use-case would be to enable ZKEmail into Zupass, which would allow you to prove things about many pieces of data. Zupass is brilliant in allowing to make claims/proofs about any signed data, with zero-knowledge proofs preserving the integrity of that data.
… and more 🐸
Another great example of using PCDs was the FrogCrypto experiment, in which each Frog was issued as a PCD – basically a block of data. You can make all sorts of claims and proofs about your Frogs, which opens up an entire design space (imagine claims such as “only owners of a certain Frog are allowed to join a Telegram group” or “only people who own more than 300 Frogs can get a POAP”).
For developers, there’s an excellent Starter Kit created by Austin Griffith that enables them to generate proofs and verify PCDs with Zupass.
In the future, I expect to see many more applications using Zupass to make claims and proofs about pieces of data – it’s the season for PCDs!
Final thoughts
As we’ve seen above, with Zupass we can have ways to connect off-chain attestations with on-chain actions, while preserving privacy.
It’s becoming increasingly easier to build privacy-preserving applications, and technologies such as Zupass and ZKEmail are great examples that we are on the right path towards a fairer, simpler world. Sometimes, we overestimate what we can accomplish in a 1-year period, and we underestimate what we can build over a 10-year period. I’m curious to see where these particular apps will stand in terms of adoption in 2034.
The best time to build is… now.