Thinking about attestations
Based on a lot of conversations with Albert Ni, Barry Whitehat, Personae, ZKonduit, Axiom, and more. I mostly mean to put put forward my own tentative and incomplete framework for unifying some common themes we’ve been seeing.
I expect our answers to questions like “What are attestations” and “Why are attestations important” to evolve rapidly over time; here’s just my own very very rough first pass.
Attestations will be increasingly important infrastructure for the next generation of Internet communication, enabled by new cryptographic primitives like ZK proofs.
Attestations are self-evident claims that are portable and interpretable across platforms, networks, computing environments, or permissions systems, that can be produced and consumed permissionlessly (or as permissionlessly as possible). They are the closest thing we have to “theorems” about real-world data and entities.
-
Self-evident claims: I’m shifting slightly from my previous language of “credible” claims (https://0xparc.org/blog/zk-id-1), in favor of “self-evident” claims. Self-evident claims are claims whose validity requires no* context to assess (i.e. determining the validity of such a claim does not require us to go through a third party with permissioned auxiliary information, such as Facebook/Google/the government/etc). Oftentimes, this is achieved by coupling a claim with a cryptographic proof (see below).
- *Of course there is always some implicit context, but ideally it is minimal. In the best case, self-evident claims should be verifiable given only access to a library of pure cryptographic functions, as well as possibly publicly-accessible DNS records and/or Ethereum blockhashes.
-
Permissionless production and consumption: Ideally, attestations of arbitrary complexity can be generated and interpreted by anyone, with minimal reliance on third parties.
- Attestations about blockchain activity have effectively no third-party reliance.
- Attestations about activity on Reddit rely on Reddit to publish a signed Merkle root, and make private account data available to each user; but from here, attestations of arbitrarily complexity can be requested by any third party or generated by any client.
Attestations have two components:
- Claim: The statement itself. Like “I have at least 1500 karma on the r/cryptocurrency subreddit,” “I own a Dark Forest planet,” “I possess a fingerprint signed and timestamped by a trusted camera manufacturer that hashes to H,” “I hold at least $20,000 of cryptocurrency on Coinbase, and Binance, and in my own wallets, combined.”
-
Proof: A cryptographic artifact (signature from a trusted authority that serves as a root of trust, a ZK proof, Merkle proof of inclusion in a block header) that verifies the claim.
- Note that the proof can actually be a proof of a stronger claim. For example, a light client proof proving that I own a particular NFT in a collection is still a proof that I own some NFT in that collection.
Basically, attestations are pieces of data that “speak for themselves.”
Base vs. Composed Attestations
In my model I have found it useful to distinguish between “base” attestations vs. “composed” attestations.
- Base attestations are rigid, signed claims: a signed transaction or commit, a JSON of account activity or metadata signed by Reddit, a light client proof of an account balance as of a certain blockhash, etc. Generally, these are signatures of specific data, or proofs of inclusion in a publicly-accessible cryptographic accumulator root that we come to consensus on.
- Composed attestations are built from base attestations. For example, an attestation to a JSON of my karma across many different subreddits can be turned into an attestation that I have at least 1500 karma on some specific subreddit, using a ZK proof. Or, a proof that I have some specific reputation score based on a formula taking into account multiple different data sources, would be a composed attestation. Generally, these kinds of attestations either require you to present a bunch of base attestations all at once (which you probably won’t want to do because base attestations may contain extra unnecessary data), or else combine these base attestations with a ZK proof.
Attestation Lifecycles
To understand possible attestation lifecycles, I propose to think about five questions.
What will we produce attestations about?
Activity on various digital platforms. Here are a few that might be especially good to start with:
- Activity on social platforms, communication platforms
- Web2/permissioned, like Twitter or Reddit - attestations must be rooted in Twitter/Reddit as a trust root
- Web3-native, like Farcaster or Skiff - this platforms host cryptographically-signed data, so we don’t need to rely on a centralized root of trust
- Anywhere where we have cryptographically-secured data - for example, Github commits are signed by (usually) RSA keys that are publicly accessible. Emails are signed by mailservers.
- Financial service providers or custodians
- Coinbase or crypto custodians
- Banks
- Blockchains, like Ethereum
- On-chain or historical data
- Proof-of-consensus attestations also allow chain accumulators to be accepted in environments that can’t “query” for blockhashes in the same way that humans and servers can—for example, in smart contracts on other chains
- Eventually - attestations that are simply generated according to some neutral protocol that is not tied to a platform
- For example, ETHDos asks you to produce attestations that conform to a certain protocol (signing a message that says something like, “0xabcd is my friend”)
Who will produce attestations?
For activity on permissioned platforms, these platforms must produce the “base” attestations.
For activity on permissionless or cryptographic platforms, users can produce their own “base” attestations.
Once a user has base attestations, they can create their own “composed” attestations.
Where will attestations be stored?
The easiest but dumbest way in the case of permissioned attestations is for the permissioning platform to store the attestations. For example, I could query a signed Twitter API to get some attestation about my account data or some other account data.
But we would like to put storage and control of attestations (or attestation data) in the hands of users. In the short-medium term, this may look like a wallet or password manager browser extension. In the long term, this hopefully looks like browser standards, secure enclaves on phones, etc.
I think that ZKeeper or some future wallet-like browser extension like “EthPassport” would be critical infrastructure here. The ZKeeper presentation from Devcon is excellent as a demonstration for what may be possible.
How do we compose (compute on) base attestation to build more complex attestations?
Another question is in what execution environment base attestations will be composed or computed on, and what kinds of computations we’ll be able to use to compose base attestations. Here are some examples of ZK primitives that can be used:
- Merkle proofs / inclusion proofs allow us to go from a piece of data “I am a specific person with property X” to “I am some secret person with property X”
- Recursive proof composition or certain flavors of MPC (a la ETHDos, Blind Find, collaborative SNARKs, etc.) allows us to compute proofs on multiple secrets owned by multiple people—useful for generating attestations for social facts.
- Recursive proof composition also allows a single user to combine multiple predicates together from base attestations - for example, “EITHER I have a ZKP attestation from Coinbase that I hold 100ETH, OR I have a ZKP attestation to blockchain data proving that I have a wallet with 100ETH”
-
ZKML circuits allows us to prove that we have data that classifies to some class (”I have a picture of a bird in my database,” “I have just taken a selfie that matches a passport photo for some non-sanctioned person”)
- Note that there are still a lot of open questions here - for example, how to deal with adversarial attacks on models, when model weights are public.
Who will consume attestations?
The whole point of attestations is to enable third-party application developers to permissionlessly tap into the rich and complex datasets of digital activity and identity. A network of open attestation infrastructure is the next step beyond a network of open APIs.
In the short term, here are a few possible consumers:
- Permissioned base attestation producers may consume their own attestations, adopting a modular authorization infrastructure internally.
- Publishing and messaging platforms like Twitter, Mirror, Substack, Signal, etc.
- Smart contracts that gate certain functionality depending on being able to produce an attestation (of identity, of reputation, etc.)
- Services that care about rate-limiting and anti-sybil mechanisms (Gitcoin or anything that requires soft guarantees around accounts that vote on stuff, faucets, etc.)
- Autonomous Worlds and crypto-native games are a really interesting category here!
Meta: how will standards emerge around the interpretation of attestations?
This is a hard and important open question! What standards will emerge around what attestations are meaningful?
It’s especially important to prevent “capture” of these standards layers by entities that aren’t fully aligned with building the most open / interoperable ecosystems.