ERC-7812: ZK Identity Registry

Abstract

This EIP introduces an on-chain registry system for storing and proving abstract statements. Users may utilize the system to store commitments to their private data to later prove its validity and authenticity via zero knowledge, without disclosing anything about the data itself. Moreover, developers may use the singleton EvidenceRegistry contract available at 0x781246D2256dc0C1d8357c9dDc1eEe926a9c7812 to integrate custom business-specific registrars for managing and processing particular statements.

Motivation

This EIP stemmed from the need to localize and unravel the storage and issuance of provable statements so that future protocols can anchor to the standardized singleton on-chain registry and benefit from cross-reuse.

The aggregation of provable statements significantly improves reusability, portability, and security of the abundance of zero knowledge privacy-oriented solutions. The abstract specification of the registry allows custom indentity-based, reputation-based, proof-of-attendance-based, etc., protocols to be implemented with little to minimal constraints.

The given proposal lays the important foundation for specific solution to build upon. The more concrete specifications of statements and commitments structures are expected to emerge as separate, standalone EIPs.

Specification

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Definitions

• A "Sparse Merkle Tree (SMT)" is a special Merkle tree that works by deterministically and idempotently storing key/value pairs in the given locations leveraging a hash function. The Poseidon hash function is often used to optimize the compatibility with ZK.
• A "statement" is an accepted structured representation of some abstract evidence. A statement can range from a simple string to a Merkle root of some SMT.
• A "commitment" is a special public value resulting from blinding a statement to conceal it. Commitments allow the authenticity of a statement to be proven in ZK without disclosing the statement itself.
• A "commitment key" is a private salt mixed with the statement to obtain a commitment to that statement. The commitment key must be kept private to maintain the confidentiality of statements.

General

The on-chain registry system consists of two subsystems: the EvidenceRegistry with EvidenceDB and Registrar components. This EIP will focus on describing and standardizing the former, while the Registrar specification may be amended as the separate proposals.

The on-chain evidence registry system entities diagram.

The EvidenceRegistry acts as the entrypoint to a protocol-wide provable database EvidenceDB where arbitrary 32-byte data can be written to and later proven on demand. The Registrar entities implement specific business use cases, structure the provable data, and utilize EvidenceRegistry to put this data in the EvidenceDB.

In order to prove that certain data is or is not present in the EvidenceDB Merkle proofs may be used. Understanding how a specific Registrar has structured and put data into the EvidenceDB, one may implement an on-chain ZK verifier (using Circom or any other stack) and prove the inclusion (or exclusion) of the data in the database.

The Circom implementation of a general-purpose SMT-driven EvidenceDB verifier circuit together with the Solidity implementation of EvidenceRegistry and EvidenceDB smart contracts may be found in the "Reference Implementation" section.

Evidence DB

The EvidenceDB smart contract MAY implement an arbitrary provable key/value data structure, however it MUST support the addition, update, and removal of elements. All of the supported write operations MUST maintain the property of idempotence (e.i. addition followed by removal should not change the state of the database). The data structure of choice MUST be capable of providing both element inclusion and exclusion proofs. The functions that modify the EvidenceDB state MUST be callable only by the EvidenceRegistry.

For reference, the EvidenceDB smart contract MAY implement the following interface:

Evidence Registry

The EvidenceRegistry smart contract is the central piece of this EIP. The EvidenceRegistry MUST implement the following interface, however, it MAY be extended:

The addStatement, removeStatement, and updateStatement methods MUST isolate the statement key in order for the database to allocate a specific namespace for a caller. These methods MUST revert in case the isolated key being added already exists in the EvidenceDB or the isolated key being removed or updated does not.

The EvidenceRegistry MUST maintain the linear history of EvidenceDB roots. The getRootTimestamp method MUST NOT revert. Instead, it MUST return 0 in case the queried root does not exist. The method MUST return block.timestamp in case the latest root is requested.

Before communicating with the EvidenceDB, the key MUST be isolated in the following way:

Where the hash is secure protocol-wide hash function of choice.

Hash Function

The same secure hash function MUST be employed in both EvidenceRegistry and EvidenceDB. It is RECOMMENDED to use ZK-friendly hash function such as poseidon to streamline the database proving.

In case ZK-friendly hash function is chosen, EvidenceRegistry MUST NOT accept keys or values beyond the underlying elliptic curve prime field size (21888242871839275222246405745257275088548364400416034343698204186575808495617 for BN128).

Rationale

During the EIP specification we have considered two approaches: where every protocol has its own registry and where all protocols are united under a singleton registry. We have decided to go with the latter as this approach provides the following benefits:

1. Cross-chain portability. Only a single bytes32 value (the SMT root) has to be sent cross-chain to be able to prove the state of the registry.
2. Centralization of trust. Users only need to trust a single, permissionaless, immutable smart contract.
3. Integration streamline. The singleton design formalizes the system interface, the hash function, and the overall proofs structure to simplify the integration.

The proposal is deliberately written as abstract as possible to not constrain the possible business use cases and allow Registrars to implement arbitrary provable solutions.

It is expected that based on this work future EIPs will describe concrete registrars with the exact procedures of generation of commitments, management of commitment keys, and proving of operated statements. For instance, there may be a registrar for on-chain accounting of national passports, a registrar with EIP-4337 confidential account identity management, a registrar for POAPs, etc.

The EvidenceDB namespacing is chosen to segregate the write access to the database cells, ensuring that no entity but issuer can alter their content. However, this decision delegates the access control management responsibility solely to registrars, an important aspect to be considered during their development.

The EvidenceRegistry maintains the minimal viable (gas-wise) history of roots on-chain for smooth registrars integration. In case more elaborate history is required, it is RECOMMENDED to implement off-chain services for parsing of RootUpdated events.

Backwards Compatibility

This EIP is fully backwards compatible.

Deployment Method

The EvidenceRegistry is a singleton contract available at 0x781246D2256dc0C1d8357c9dDc1eEe926a9c7812 deployed via the "deterministic deployment proxy" from 0x4e59b44847b379578588920ca78fbf26c0b4956c with the salt 0x04834e077c463de76a20df3770a7b96a5e5eb826922d1514f943cd5b41ccaed0.

Reference Implementation

The reference implementation of EvidenceRegistry and EvidenceDB Solidity smart contracts together with the evidence registry state verifier Circom circuit is provided in the proposal.

The low-level Solidity and Circom implementations of SMT can be found here and here.

The height of the SMT is set to 80.

Please note that the reference implementation depends on the @openzeppelin/contracts v5.1.0 and circomlib v2.0.5.

EvidenceDB Implementation

EvidenceRegistry Implementation

EvidenceRegistry Verifier Implementation

Security Considerations

From security standpoint there are several important aspects that must be highlighted.

The individual registrars are expected to provide the functionality for both management and proving of statements. The proving will often be carried out by ZK proofs, which require trusted setup. Improperly setup ZK verifiers can be exploited to verify forged proofs.

The getRoot method of EvidenceDB SHOULD NOT be used on-chain by the integrating registrars to check the validity of the database state. Instead, the required root SHOULD be passed as a function parameter and checked via getRootTimestamp method to avoid being frontrun.

Copyright

Copyright and related rights waived via CC0.