Concepts
In this section, we provide a comprehensive overview of preliminary concepts, with a particular emphasis on notations used by this paper. We assume that readers are familiar with cryptographic concepts, including hash functions, asymmetric cryptography, digital signatures, sparse merkle trees, and basic understanding of zero-knowledge proofs.
Digital identity multiplicity problem
The term digital identity multiplicity emphasizes the multidimensional nature of modern digital identities, that a person can have multiple different identities across different platforms. For example, it is not uncommon that a user uses different nicknames, handles, and cryptographic IDs (namely addresses) for different platforms. A user might be called 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.
Nullifier
In the context of zero-knowledge proof cryptography, a nullifier is a value that prevents double-spending, without revealing which resource is being spent. Essentially, it is a value that ‘nullifies’ (voids) the underlying resource in a privacy-preserving way. It plays a critical role in the applicability of zero-knowledge proof methods to practical applications. The lack of the ability to generate nullifiers with proofs compromises the verifier’s ability to ascertain if a proof has been previously utilized. To draw an analogy, one may envision a scenario where a huge group of people is permitted entry into a concert event, but using a single ticket meant for only one person.
Identity commitment
An identity commitment is a public value, hiding two secret values: a secret identity and an internal nullifier. Both secret values are known only by the credential holder, while identity commitment can be public. In Galxe identity protocol, conceptually, identity secrets will be used by holders to prove the ownership of credentials, and internal nullifiers will be used, together with external nullifiers, to generate deterministic nullifiers per each verification.
Similar to Semaphore protocol, our protocol constructs identity commitment in the same simple way. It is a Poseidon hash of two secrets. Note that the order of two secrets is fixed when used as the inputs to the hash function. The first one is the identity and the second one is the internal nullifier, so that nullifiers and secrets can be distinguished in a zero-knowledge proof.
Compared with digital signatures, the power of identity commitment is actually smaller. You cannot use it for authentication without using a zero-knowledge proof, and secret values will have to be the inputs to the prover, unlike signatures where only public keys and signatures are required. However, this disadvantage can help to limit impersonation and fake profiles. For a credential, identity secrets cannot be shared without permanently sharing the ownership, while signatures can be shared with limited costs: one can temporarily transfer or lease the ownership of a credential to someone else, until the signature expires.
Verification stack
A verification stack is a set of instantiations of cryptographic algorithms that will be applied during credential issuance, proof generation and verification. Because the domain of zero-knowledge proof technology is witnessing a meteoric rise, with innovative techniques being invented rapidly, alongside the consistent refinement of implementations, the protocol is designed with a vision for future adaptability. The design de-couples the signature and verification schema from the core protocol, allowing versatile use cases and smooth upgrades.
The initial version of Galxe identity protocol will come with one simple yet powerful verification stack called ‘BabyZK’. It is a production-ready full-feature zero-knowledge tech stack that supports ultimate privacy protection, that can be used even publicly on blockchains, like Ethereum.
Credential schema
In Galxe identity protocol, credential schemas are defined by the two fields on credentials: type and context. Like types in programming languages, credential types are structs, specifying the list of typed claims. A type will be associated with a set of zero-knowledge circuits and verification parameters published on-chain. On the other hand, a credential context is used to construct a concrete instantiation from a credential type. Together, they form a credential schema, consisting of typed claims under a specific context. For example, assuming there is (there actually will be) a simple credential type with one unsigned integer field and we call this type ‘scalar’, different schemas can leverage this same type by linking different contexts, e.g., the number of loyalty points, the highest rank achieved in a game, or date of birthday expressed in UNIX timestamp. These credential schemas can all use the zero-knowledge circuits that have been created for the scalar type. This advantage allows issuers, holders, and verifiers to apply zero-knowledge proofs without writing any code.
Parametric on-chain attestation by aggregating public inputs
For on-chain verifications, users can mint an attestation that caches the revealed facts with auto aggregation. For each pair of (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.