Motivation
Throughout the past few years 0xPARC has been experimenting with various ZK and ZK Identity projects. As part of this experimentation we developed and funded the development of many apps, such as Dark Forest, double-blind, ETHdos, zk-email and ZKonduit. In early 2023, we identified an internal need for a unified framework that would help us build, and connect these and other experimental cryptographic applications to each other.
Working backwards from our desire to build a broad set of cryptography-enabled applications, we surveyed existing âidentityâ frameworks. To make sense of what we saw, we settled on a tier system that let us categorize these solutions based on their expressiveness:
- Tier 1: Signatures and attestations.
- This is the lowest tier of expressiveness, and allows you to make statements like âEntity X attested to data Yâ.
- Tier 2: Specific SNARK-ID protocols. This tier subsumes Tier 1.
- The functionality of signatures can be fully encapsulated by some particular ZK schema, but SNARK-ID protocols can also do more things. For example, they let you prove group membership without revealing your identity, or selectively reveal only a portion of an attestation.
- Tier 3: General-purpose cryptographic protocols. This tier subsumes Tier 2.
- This is the highest tier of expressiveness, as it is not locked into a particular ZK Protocol, but rather provides a substrate in which many different protocols that belong to Tier 1 and Tier 2 could co-exist, interoperate, and communicate with each other.
We saw many examples of solutions that belong to the first two tiers. However, we found that none of the existing solutions were flexible enough to support the types of cryptographic claims we want to use in our applications, as they all use either signatures, or a particular ZK Protocol. This realization led to the conception of the third tier of expressiveness.
To give an example of a type of claim that is not representable in existing identity solutions: zk-email lets people make privacy-preserving yet verifiable claims about emails that they received. Concretely, one could make a verifiable claim like âI received a password reset email from Twitter, which contained the twitter username XYZâ, without revealing the entire email, which could contain sensitive information like the recipientâs email address. This claim could then be used as proof of ownership of a particular twitter account, or as part of a scheme that lets users prove they own an account from some set of accounts. ZK Email proofs are not possible to represent in Tier 1 systems given the fact that they are ZK proofs, not signatures. They are also not possible to represent in existing Tier 2 systems, given the fact they are themselves particular SNARK-based protocols that are not compatible with the SNARK-based protocols embedded in the Tier 2 identity solutions.
To summarize, we did not see a framework supporting Tier 3 expressiveness, which is the tier we needed for the types of apps that we want to build. As a result, we decided to build a Tier 3 system ourselves.
PCD Framework
To bring our vision of a Tier 3 framework to life, we developed three new pieces of technology that interlock to create a maximally expressive system for representing and working with cryptographic proofs and attestations:
-
A new primitive weâre calling PCD (proof carrying data). At its core, a PCD is a self-evident and cryptographically verifiable claim. PCDs can be attestations, ZK proofs - anything that can be âprovenâ and subsequently âverifiedâ. Any cryptographic primitive can be wrapped in a PCD and thus encapsulated in a uniform interface. In short, âPCDâ is the general purpose atomic unit of cryptographic data that our framework operates on. Some examples of current and future PCDs are:
- A Semaphore Protocol identity.
- A Semaphore Protocol group message proof. To create this PCD, one would need a Semaphore Group, a Semaphore Identity, and a message that is being âsignalledâ.
- A WebAuthn authentication as specified by the W3C protocol.
- A ZK Machine Learning proof that proves knowledge of an image that classifies to a bird using a deep neural network.
- An Ethereum signature of a string.
- A framework for developing programmable cryptography applications that weâre calling the PCD SDK. The PCD SDK defines the software interfaces needed to actually use and define new types of PCDs. For example, the SDK enables developers of cryptographic primitives (various ZK proofs, signature-based schemes, etc.) to wrap their primitives in âPCD Packagesâ, that contain all the functionality needed to instantiate (i.e. âproveâ) and verify these primitives. It also enables developers of programmable cryptography applications that depend on these cryptographic primitives to use them via simple and uniform interface, which greatly simplifies the development of this class of applications. For example, a developer that wants to incorporate ZK-Email PCDs into their application would be able to import the corresponding PCD package from npm, and easily request and interpret ZK-Email PCDs from users without having to understand how its underlying cryptography works.
- A cryptographic secret manager/wallet for PCDs. The first version of this app is called Zupass, and was developed for Zuzalu. Zupass is a web-app that lets users store PCDs, and perform operations on them such as instantiating âderived PCDsâ. Given that it is built for the PCD framework, it supports arbitrary signature and proof schemes, with no lock-in into any specific cryptographic protocol. Third parties, such as a physical event host or a digital website can request arbitrary cryptographic proofs (such as signatures or zkSNARK proofs) about data in a userâs secret manager using the PCD interface.
The strength of this PCD-based framework lies in its flexibility. We believe that it is a sufficiently general framework such that it could encapsulate existing identity protocols. Not only that, it could greatly expand the surface area for experimentation within âprogrammable cryptographyâ applications by being a tractable and legible substrate into which cryptographic primitives that donât fit into existing identity frameworks could be incorporated.
If the PCD framework is successful, it could bring about the following outcomes:
- The PCD abstraction could serve as a common language for communicating cryptographically meaningful data between existing identity frameworks, other data silos, and applications.
- More broadly, it could give individuals the power to own and move their data between any digital systems - social media platforms, digital banking networks, peer-to-peer messaging apps, biometric registries, blockchains, and more.
We are hoping to nudge the future of the World Wide Web in a direction where all data is universally accessible, interpretable, verifiable, and semantically meaningful - a Web without artificially-gated APIs, built on neutral and privacy-preserving mechanisms for user data.
Deployment of the Framework
Our first use-case for the PCD abstraction and associated software was a community event called Zuzalu, which was a âfirst-of-its-kind pop-up city communityâ that took place in Montenegro between March 25 and May 25, 2023. You can think of Zuzalu as a long conference or âpop-up Stanfordâ for members of the extended Ethereum community. It is similar to Devconnect in its decentralized and self-organizing nature, but also different from Devconnect in that the community was smaller, and the event itself lasted for two months rather than a single week.
For Zuzalu, we built Zupass: the first iteration of the cryptographic secret manager mentioned earlier; under the hood, Zupass is a general-purpose PCD manager. At Zuzalu, Zupass was the primary method of digital and physical authentication. It was used daily to access gated physical event spaces and venues via a QR code. It was also used to authenticate into online digital experiences via an OAuth-like integration flow. For example, event participants could login to the official Zuzalu website using their Zupass, much like one is able to login to the Devcon forum using their Google account. Once logged in, participants were granted access to a private portion of the website - the Zuzalu schedule. There, participants could view the schedule, and add events to it. 100% of all Zuzalu residents (~200 users) and Zuzalu visitors (~600 users) onboarded onto Zupass, and used it daily for ZK-based digital and physical authentication over two months.
We designed Zupass with ecosystem development in mind, and seeded/facilitated other identity and community experiments on top of the infrastructure that we built. Hereâs a list of some of the projects that emerged on top of/alongside Zupass:
- Zupoll (https://zupoll.org/) - an anonymous voting platform restricted to just Zuzalu participants, where residents could create straw polls, and organizers could create referendums. One notable use-case for these polls was as a way to measure the communityâs sentiment towards Zuzalu and its programming during weekly in-person âtown halls.â These official community referendums regularly drew 30%+ voter turnout across all Zuzalu residents.
- Zucast (https://zuca.st/) - an anonymous farcaster-like forum. This was built in a week during Zuzalu by a community member that wanted to experiment with the affordances of anonymous social media. Zuzalu community members made nearly 700 posts over 3 weeks.
- Rubber Ducky - a telegram bot built and maintained by a community member that used GPT-4 to answer questions about Zuzalu. It used Zupass anonymous login to restrict its usage to just Zuzalu participants.
- PCD Stamps - a NFC-based PCD distribution mechanism that allowed community members to distribute POAP-type attestations to attendees of Zuzalu.
Itâs important to note that Zupass is âpermisionlessly interoperableâ - developers of third party applications do not need our permission to integrate with the PCD framework. The entire thing is open source, and exposes easy-to-understand and easy-to-incorporate APIs.
Overall, we were very impressed with the variety and amount of experimentation our framework led to throughout Zuzalu. We believe the future of this framework is promising, and we will continue to develop and experiment with the PCD abstraction, the PCD Passport (known currently as Zupass), and the PCD SDK.
Proposal for Devconnect
Thus, we are proposing that Devconnect adopt Zupass for some of its ticketing needs (which we are planning to rebrand to not reference Zuzalu, letâs call it PCDPass for now).
Here is an outline of a possible integration between PCDPass and Devconnect:
- Similar to Zuzaluâs event spaces, we could make it possible to check in to the Devconnect coworking space using PCDPass.
- PCDPass would transition from being just a web app to a suite of versions: a mobile app, a set of browser extensions, and potentially a PWA (progressive web app).
- Purchasers of tickets to the coworking space would be able to instantiate a PCDPass account using the same email they purchased their ticket to create a new anonymous identity that is granted ticket-holder permissions. To check in to the coworking space, a user would show their PCDPass QR code to event staff in exchange for a wristband that lets the come and go as they please.
- Alternatively, we could require a QR code scan every time an attendee visits the coworking space. This would require us to build features that prevent QR codes from being reused, which could be challenging to do securely.
- In addition to ticketing the coworking space, 0xPARC is going to be using PCDPass for ticketing its own Devconnect subevents. The implementation would be almost equivalent to the one the coworking space uses, made possible by a shared Pretix instance.
- Finally, we are going to make available our PCDPass ticketing solution to other subevents at Devconnect, so that their attendees can plug in to the broader PCD application ecosystem.
In addition to being able to check in to physical event spaces at Devconnect, holders of PCDPass would also be able to sign in to online digital experiences such as the ones we saw built for Zuzalu - Zupoll and Zucast in particular.
Apart from maintaining Zupoll and Zucast, we are excited about facilitating the development of other digital experiences by third party developers, and about designing/developing other apps ourselves, with the intention to make Devconnect more fun and interconnected for its attendees. Additionally, because of the flexibility of the PCD abstraction, other cryptographic attestation schemes can easily be made interoperable with PCDPass and a wider ecosystem of applications and tools emerging around it.
To conclude, we believe a collaboration between the PCD efforts at 0xPARC and Devconnect would be beneficial to both sides. On our end, we believe that this project would be a great opportunity to get further feedback on PCDs and our tools/apps. On Devconnectâs end we believe this ticketing solution is more powerful and extensible than existing ticketing solutions, and would be a great opportunity for the event to dogfood an impactful piece of technology.
All code for the PCD project can be found here: GitHub - proofcarryingdata/zupass: Zuzalu Passport
