POD SDK docs have now migrated to a new site: check out pod.org.
POD stands for Provable Object Datatype, and is a new format and library enabling any app to create zero-knowledge proofs of cryptographic data. Using PODs, developers can create ZK-enabled apps without the effort and risk of developing custom cryptography.
What Zupass has enabled with tickets, PODs will enable for all sorts of user data. A POD could represent your proof of attending an event, a secure message, a collectible badge, or an item in a role-playing game.
ZK proofs about PODs use General Purpose Circuits (GPC) which can prove many different things about PODs without revealing all details. GPCs use human-readable configuration and pre-compiled circuits so no knowledge of circuit programming is required.
PODs and GPCs can be used in Zupass, or in your own apps without Zupass.
To a user, a POD is a piece of cryptographic data attested by some issuing authority. For a developer, a POD object is a key-value store which can hold any data. The whole POD is signed by an issuer. Apps can verify the signature, to trust the authenticity of the values in the POD.
When a POD is issued, its entries (key-value pairs) are hashed as part of a Merkle tree. This allows GPCs to selectively prove about individual entries without revealing the whole POD.
const podSword = POD.sign(
{
pod_type: { type: "string", value: "myrpg.item.weapon" },
attack: { type: "int", value: 7n },
reach: { type: "int", value: 5n },
weaponType: { type: "string", value: "sword" },
itemSet: { type: "string", value: "celestial" },
isMagical: { type: "boolean", value: true },
owner: { type: "eddsa_pubkey", value: purchaser.pubKey }
} satisfies PODEntries,
privateKey
);
GPCs allow ZK proofs to be created from a simple proof configuration. You can configure your proofs using a human-readable JSON format (or equivalent TypeScript code), which is used to generate the specific circuit inputs needed for the proof.
const weaponProofConfig: GPCProofConfig = {
pods: {
weapon: {
entries: {
attack: { isRevealed: true },
reach: { isRevealed: false,
inRange: { min: 5n, max 10n } },
weaponType: { isRevealed: false,
isMemberOf: "proficientWeapons" },
owner: { isRevealed: false, isOwnerID: "SemaphoreV4" }
}
}
}
};
The GPC library inclues a family of pre-compiled ZK circuits with different sizes and capabilities. It will automatically select the right circuit to satisfy the needs of each proof at run-time. No setup is required, and you don’t need any knowledge of circuit programming (circom, halo2, noir, etc).
GPCs can prove properties of one POD or several PODs together. PODs can be proven to be owned by the prover, using their Semaphore identity. A GPC can constrain as many named entries as needed, whether revealed or not. For example, a proof might constrain two entries to be equal, constrain a third entry to be in a list of valid values, and reveal the value of a fourth entry.
PODs are the basis of new Zupass-enabled apps using the ZApp SDK. PODs and GPCs are integrated into Zupass via PCD packages. Newly-issued Zupass tickets use PODTicketPCD, while PODPCD can represent any other data such as collectible frogs. GPCPCD enables the creation of arbitrary proofs.
An end-to-end developer demo showing how PODs & GPCs can be used to apply for a loan by proving a borrower’s identity, age, and income. You can build and run the demo locally, or using the pre-deployed servers.
Built by hackers at Edge City Esmeralda, this app lets you use data from Strava to track your exploration of the town of Healdsburg, then issues a POD with your score and custom map.
Hackathon demo from ETHBerlin which allows users to “Poast” a message and image which appear as a POD feed in a user’s Zupass.
A suite of example pages hosted here: consumer-client.onrender.com, code
The POD and GPC libraries are available for JavaScript/TypeScript developers. Start by looking at the tutorial code here, then you can take a look at the specific packages listed below. See the note about package installation below if you run into any dependency issues.
All code is open-source and available in the Zupass repo. Detailed documentation is at docs.pcd.team. We hope you’ll give them a try and tell us what you think.
Links: NPM, tutorial, docs, code
Allows creation and signing of PODs, and manipulation of their keys and values.
Links: NPM, tutorial, docs, code
Allows creation of GPC proofs using high-level configuration. The config compiler picks the right ZK circuit, and generates the circuit inputs to prove or verify as needed.
Links: NPM, tutorial, docs, code
This package contains the binary artifacts (proving/verification keys, witness generators) needed for GPC proofs in the initial proto-pod-gpc family. These are large, but you’ll only need a few of them, not the whole package.
In browsers, you can provide a URL to download directly at proving or verifying time. For Nod deployments, you can you can fetch this package as a devDependency or download the files you need individually.
Contains the modular ZK circuits used to generate GPC proofs. You don’t need to look at this code to use GPCs, but you can use this code as the basis of your own ZK circuits using PODs.
Links: NPM, tutorial, docs, code
Allows PODs to be issued by Podbox, stored in Zupass, and requested and manipulated in all the ways enabled by the PCD framework. A PODPCD is developer/hacker friendly, displaying the POD entries directly.
Links: NPM, tutorial, docs, code
Allows GPC proofs to be generated about PODs in your Zupass. A GPCPCD is developer/hacker friendly, displaying the proof configuration and POD values directly.
The packages above can be fetched from NPM as usual, and will work either in browser or in a Node.js server. Packaging for a browser requires polyfill for some Node modules, including buffer and constants.
There is a known issue with a dependency fastfile which can be resolved by polyfilling constants as you can see in this example.
POD and GPC libraries are in beta and subject to change. We encourage devs to try them out and use them for apps, but be aware that updates will come in future.
These libraries should not be considered secure enough for highly-sensitive use cases yet. The cryptography, circuits, and configuration compiler have not been audited. The proving/verification keys were generated in good faith by a single author, but are not the result of a distributed trusted setup ceremony.
Table of Contents