MightyKitty
on twitter, while being BraveBarbie
on discord, or uses address 0x7f7f7…abc
on EVM-compatible blockchains.
The phenomenon introduces a subtle challenge for designing a credential protocol: under what identity, should the issuer credential to? The design must allow a user to connect all his owned identities in order to reveal or generate zero-knowledge proofs against a comprehensive profile, while not leaking any privacy, e.g., the connections of accounts, to any other party.
One straightforward solution is to issue credentials under the ID of the domain that the issuer controls. That is, a credential showing that the user MightyKitty
has more than 1000 Twitter followers, should be issued to the MightyKitty
. However, this implementation can hinder the interoperability of credentials. When using credentials outside of the issuer’s domain, the user has to prove that he is the ID shown on the credential. This process can be done through a 3rd party, which introduces another layer of trust, or the user has to reveal his ID to the verifier, sacrificing privacy. Another choice is using a global identifier schema, where each user is assigned to a globally unique identifier and issuers shall create credentials to that identifier. However, when issuers collude, a unique identifier can be used to track down footprints of the user behind, by linking together different identities from different issuers.
We proposes an innovative schema that, by embedding identity commitments into credentials, allows a user to harness his credentials from different platforms, while preserving his privacy.
(type, context)
and an issuer
, there will be an attestation collection. Every attestation has a unique token id, which is the nullifier generated by the owner, and its properties represent some facts of the owner. The facts are automatically aggregated based on all past information revealed, during on-chain verification. Because fields are typed, aggregations are also type-aware. Taking an unsigned integer field as an example, its lower bound and upper bound that have been checked will be stored. For example, if there were two proofs that one says height > 100 && height < 150
, and the other says height < 123
, the attestation of height will be lower_bound: 101
and upper_bound: 122
. Note that the attestation will not leak any extra information about the owner, because when the verification happened, those facts have already been revealed publicly, at the owner’s will. For revocable credentials, the root hash of sparse merkle tree of revoked credentials that has been used during proof will be cached.
This attestation offers the potential for future verification at a reduced computational cost. On Ethereum, a ZK-SNARK verification of Groth16 on BabyJubjub curve generally costs around 300k gas. In contrast, querying an attestation property necessitates only a few thousand units. Because activities under the same pseudonym of the attestation will be public, protocol leaves the freedom to choose between the highest level of privacy and gas efficiency to verifiers and holders.