< Home

Developer Docs

Events

POD stands for Provable Object Data, and is a new format and library enabling any app to flexibly create cryptographic data and make zero-knowledge proofs about it. Using PODs, developers can create ZK-enabled apps without the effort and risk of developing their own 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 a POD without revealing it all. 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.

What is a POD?

For 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 contain any data. The whole POD is signed by an issuer. Apps can verify the signature, and 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: "item.weapon" },
    attack: { type: "int", value: 7n },
    weaponType: { type: "string", value: "sword" },
    itemSet: { type: "string", value: "celestial" },
    owner: { type: "cryptographic", value: purchaser.commitment }
  } satisfies PODEntries,
  privateKey
);

What is a GPC?

GPCs allow ZK proofs to be created from a simple proof configuration. You can configure your proofs using a human-readable (JSON) format, which is used to generate the specific circuit inputs needed for the proof.

const weaponProofConfig: GPCProofConfig = {
  pods: {
    weapon: {
      entries: {
        attack: { isRevealed: true },
        weaponType: { isRevealed: false,
                      isMemberOf: "proficientWeapons" },
        owner: { isRevealed: false, isOwnerID: true }
      }
    }
  }
};

The GPC library has 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 in Zupass

PODs and GPCs are available as PCDs in Zupass, and can be issued and proven just like tickets. These PCDs provide developer-friendly functionality for tinkering with this experimental technology. Zupass tickets for new events are already being issued as PODTickets (in addition to the existing EdDSATickets) which developers can make use of. More POD-based use cases will be coming in future.

POD Project Examples

ZuKyc

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.

Zuum

Built by hackers at Edge 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.

ZK-Twitter

Hackathon demo from ETHBerlin which allows users to “Poast” a message and image which appear as a POD feed in a user’s Zupass.

Zupass Consumer Examples

A suite of example pages hosted here: consumer-client.onrender.com, code

Developer Resources

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.

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.

@pcd/pod

Links: NPM, tutorial, docs, code

Allows creation and signing of PODs, and manipulation of their keys and values.

@pcd/gpc

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.

@pcd/proto-pod-pcd-artifacts

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.

@pcd/gpcircuits

Links: NPM, docs, code

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.

@pcd/pod-pcd

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.

@pcd/gpc-pcd

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.

Stability Notes

POD and GPC libraries are experimental and subject to change. We encourage devs to try them out and use them for apps, but maybe don’t rely on them for the most sensitive use cases yet.

Compatibility

Security

These libraries should not be considered secure enough for highly-sensitive use cases yet. The circuits are experimental and 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



GitHub

Twitter