diff --git a/ERCS/erc-7812.md b/ERCS/erc-7812.md index c67ebb7d04a..dd3afe7016d 100644 --- a/ERCS/erc-7812.md +++ b/ERCS/erc-7812.md @@ -10,28 +10,28 @@ category: ERC created: 2024-11-08 --- -# Abstract +## Abstract This EIP introduces an on-chain registry system for storing abstract statements, where the state of the system can be proven in zero knowledge without disclosing anything about these statements. Developers may use the singleton `EvidenceRegistry` contract available at `0x` to integrate custom business-specific registrars for statement processing and proving. -# Motivation +## Motivation The standardization and aggregation of provable statements in a singleton on-chain registry significantly improves reusability, scalability, 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 +## 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 +### 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 +### General The proposed 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. @@ -45,7 +45,7 @@ In order to prove that certain data is or is not present in the `EvidenceDB` Mer 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 +### 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`. @@ -123,7 +123,7 @@ interface EvidenceDB { } ``` -## Evidence Registry +### 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: @@ -175,31 +175,31 @@ bytes32 isolatedKey = hash(msg.sender, key) Where the `hash` is secure protocol-wide hash function of choice. -## Hash function +### 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 +## Rationale 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 registry. The proposal is deliberately written as abstract as possible to not constraint 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](https://eips.ethereum.org/EIPS/eip-4337) confidential account identity management, a registrar for POAPs, etc. +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](./erc-4337.md) 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 +## Backwards Compatibility This EIP is fully backwards compatible. -# Deployment method +## Deployment Method The `EvidenceRegistry` is a singleton contract available at `0x` deployed via the “deterministic deployment proxy” from `0x4e59b44847b379578588920ca78fbf26c0b4956c` with the salt `0x`. -# Reference Implementation +## 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. @@ -499,7 +499,7 @@ template EvidenceRegistrySMT(levels) { component main {public [root]} = EvidenceRegistrySMT(80); ``` -# Security Considerations +## Security Considerations From security standpoint there are several important aspects that must be highlighted. @@ -507,6 +507,6 @@ The individual registrars are expected to provide the functionality for both man 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 Waiver +## Copyright Copyright and related rights waived via [CC0](../LICENSE.md).