Verifier Validation Registry - Proposal (Draft)

# Verifier Validation Registry - Proposal (Draft) > This proposal follows the [EIP template](https://github.com/ethereum/EIPs/blob/master/eip-template.md?plain=1). Details of the template can be seen in the **Edit** view of this document. [TOC] ## Simple Summary Verifier Validation Registry allows users to quickly check the validity of zero-knowledge proof (ZKP) verifiers. ## Abstract  For projects that employ ZKP systems, verifiers are critical in verifying the claims made by the provers. There are currently no standardized mechanisms for users to check the validity of verifiers easily. We propose a Verifier Validation Registry that enables users to quickly examine verifiers from projects and make judgements on whether they should use them. ## Motivation  Validating verifiers is an essential part of using ZKP systems and many projects let this responsibility fall on the user. Generating verifiers from the ZKP circuits is usually non-trivial and involves multiple steps with a separate library. This introduces an attack vector that allows malicious actors to temper with the verifier generation which results in an unsound verifier. Verifier validations are usually not the main customer-facing component and thus they don't get the same level of attention. This results in several issues including: - there is no guarantee from projects to provide information for users to validate - in cases where information is provided, it can be of varying quality and usually require a certain level of technical expertise to follow - users without technical expertise or resources have no means to validate and are forced to trust verifiers according to the project's claim blindly Projects that have been audited also suffer from the same problems because of their verifiers and any accompanying validation instructions: 1) are usually not part of the projects' auditing scope 2) the library generating the verifiers might not have been audited ## Specification  ### Registry The Registry: - must allow users, even those with little technical background, to be able to judge the validity of the verifiers without relying on trust in the projects - must be easily accessible by users or provide the means for others to do so (e.g. provide an API where others can build tools to access). - must be open and transparent - must log any changes along with their authors (similar to git) The Registry contains at least two types of records (it may contain more if necessary), Project Records and Verifier Records. These records can be added or updated by their respective, authenticated owners. ### Project Records Each Project Record: - is owned by one project - must list all the Verifier Records associated with the project ### Verifier Records Each Verifier Record: - must contain all necessary information to uniquely identify a deployed verifier - must contain instructions on how to validate the verifier The instructions should be standardized across projects to aid users' understanding and comparison between verifiers. ## Rationale  The registry brings under one roof all the information related to project verifiers. This allows for: 1. easier comparison of verifiers and validation instructions which encourages projects to put more resources into simplifying them and making validations more accessible 2. the setup of additional mechanisms to help users validate or assess verifiers (e.g. validators can log validation results) 3. the setup of additional mechanisms to help projects quickly gather feedback on their verifiers and make changes   ## Reference Implementation - Crowdsourced Validators  ### Summary This section details a minimal implementation that can serve as a proof of concept. It involves Validators who are tech-savvy users that individually validate the verifiers by following the instructions from the Projects. Validators have reputation scores that other users can base their trust on. Thus this implementation helps shift the trust of the verifiers from the Projects to crowdsourced social reputation. ### Actors #### Projects Projects use ZKP verifiers and list them in the Registry. They are responsible for: - creating and maintaining the Project Record and Verifier Record - setup and maintain incentives (if applicable) #### Users Users check the verifier they want to use is listed and valid in the corresponding Project Record and Verifier Record. They do not need to be logged in to view the Registry. #### Validators Validators are users who validate the verifiers. They are required to register an account in the Registry and keep their information updated. Validators go through the entire validation process and log the results in the Registry. Although the validation process consists of validation instructions provided by the project, validators are not limited by the instructions if they feel that there are better methods available. ### Records Verifier Validation Registry is comprised of four different types of Records, namely: - Project Record - Verifier Record - Validation Status Record - Validator Record #### Project Record The Project Record is set up by the project. It contains: - an overview of the project - a list of verifiers and related artifacts (e.g. verification keys) used by the project where each verifier has its own Verifier Record ##### Project Record Example ``` \reports\summa-kzg\project.md ``` ###### Overview **Project Title:** Example Project Title **Project Description:** Example Project Description **Project Team:** Example Project Team **Project Repo:** github.com/project/project_repo **Project Website:** project_website.com ###### Verifiers | Verifiers | Deployment Datetime | Commit | Block Explorer | | --------------------------------------------------------------------- | ------------------- | ---------------- | --------------------------- | | [VerifyingKey.sol](Link to `verifyingkeysol-validators.md`) | 2024-03-01 | [Link to Commit] | [Link to Deployed Contract] | | | 2024-03-04 | [Link to Commit] | [Link to Deployed Contract] | | [Summa.sol](Link to `summasol-validators.md`) | 2024-03-01 | [Link to Commit] | [Link to Deployed Contract] | | [GrandSumVerifier.sol](Link to `verifyingkeysol-validators.md`) | 2024-03-01 | [Link to Commit] | [Link to Deployed Contract] | | [InclusionVerifier.sol](Link to `inclusionverifiersol-validators.md`) | 2024-03-01 | [Link to Commit] | [Link to Deployed Contract] | ###### Validation Instructions Instructions to generate and validate the verifiers. #### Verifier Record The Verifier Record is set up by the project. It displays the Validation Status of the verifier. ##### Validation Status Summary A summary of all the Validation Status Records is displayed, this consists of: - rows of validation results that link to the corresponding Validation Status Record - number of successes and failures of validation by other validators - comments that accompany the validation successes and failures - brief profiles of the validators, including: - total number of validations done - reputation score or other metrics to help assess the validator quickly - links to their Validator Records A more concise view of this summary (e.g. the number of validation successes and failures) can be displayed by the verifier in the Project Record for convenience. ##### Verifier Record Example The following is an example of a Verifier Record that contains a list of Validation Status Records for the verifier. Each Record in the list should be linked to the corresponding Validation Status Record. ``` \reports\summa-kzg\verifyingkeysol-validators.md ``` | Deployment Datetime | Commit | Block Explorer | Validation Date | Validator | Result | Comments | | ------------------- | ---------------- | --------------------------- | --------------- | ----------- | ------- | ------------------------------- | | 2024-03-01 | [Link to Commit] | [Link to Deployed Contract] | 2024-05-02 | Validator 1 | Success | | | | | | 2024-05-03 | Validator 2 | Failure | Does not work on Apple Silicon. | | Successes | 1 | | | | | | | Failure | 1 | | | | | | | 2024-03-04 | [Link to Commit] | [Link to Deployed Contract] | 2024-05-04 | Validator 3 | Success | | | Successes | 1 | | | | | | | Failure | 0 | | | | | | #### Validation Status Record When a Validator completes a validation, a Validation Status Record is generated. This consists of: 1. **Validation Result** - Success. The validation process provided by the project produced the verification artifacts claimed by the project. - Failure. The validation process provided by the project did not produce the verification artifacts claimed by the project. 2. **Comments** - optional for Success, mandatory for Failure 3. **Link** to the corresponding Validator Record #### Validator Record A Validator Record is created for each validator. It contains: - brief information about the Validator - reputation score and/or links to profiles from third-party systems (e.g. Github, Twitter) - a list of validations completed (with links to the corresponding Validation Status Record) ### Platform The Registry can be stored on-chain which allows for: - access control through smart contract logic - data permanence - censorship resistance - git-style repo for tracking changes - cheap storage cost #### User Access Besides checking the Validation Statuses directly on the Platform, users can also check: - through an API - with a browser extension (e.g. something similar to [Betherscan](https://github.com/tiagofneto/betherscan)) - on other websites and apps that retrieve the relevant information through the API #### Project Authentication Projects can interact with the Registry after successfully passing an authentication process. This helps the Platform establish the projects' identification and create their Project Records. ##### Choosing A Project Authentication Method The choice of an appropriate authentication method depends on several factors, including: 1. implementation cost 2. authentication cost incurred by the validator 3. UX Some examples of possible authentication methods include: - [OAuth with smart contracts](https://blog.chain.link/oauth-and-api-authentication-in-smart-contracts-2/) - wallet signatures with smart contract - [Gitcoin Passport](https://docs.passport.xyz/overview/use-cases) - [Proof of Humanity](https://docs.kleros.io/products/proof-of-humanity) - [ZK Email](https://zkemail.gitbook.io/zk-email) #### Validator Authentication Similar to projects, the validators can interact with the Registry after successfully passing an authentication process. This helps the Platform establish the validators' identification and create their Validator Records. ##### Choosing A Validator Authentication Method The choice of the appropriate authentication method depends on factors similar to those in [Project Authentication](#Choosing-A-Project-Authentication-Method). ##### Reputation Score An optional reputation score based on the Validator's Record can be calculated to aid users' assessment of the validator. While the actual method for calculating the reputation is out-of-scope for the initial version, some ideas include: - [EigenTrust](http://ilpubs.stanford.edu:8090/562/1/2002-56.pdf) ### Incentives Certain projects or certain verifier releases might not have enough validators. In such cases, an incentive system can help attract validators to perform validation. These incentives can be social (ranks in a reputation system) and/or monetary (e.g. project tokens or other cryptocurrencies funded by the projects). The Verifier Validators Registry can have mechanisms to facilitate the distribution of incentives to validators. For social incentives, mechanisms can include: - a system that calculates the reputation points obtained by the validators for performing particular validations - a database that stores and displays the reputation points of all validators For monetary incentives, mechanisms can include: - a smart contract to store the tokens ready to be paid out to validators - automatic distribution of tokens to validators who complete validations ## Alternative Implementation - Automated Toolings An alternative implementation to using Validators crowdsourcing is to employ automated toolings that allow users to validate the verifiers themselves more easily. This introduces new challenges and we will highlight them here. ### Validation Standardization Building automated toolings to validate verifiers for multiple projects requires a certain level of standardization. This is difficult given the wide range of projects that employ ZKP and the differences in their ZKP architecture. Moreover, ZKP is an actively researched field and we expect many new ZKP architectures to be released in the near future. This poses pressure on the Registry to adapt existing automated toolings for these new ZKP systems. Failing to do this will risk denying projects incorporating new ZKP systems usage of the Registry because their verifiers cannot be validated with the existing toolings. On the other hand, Crowdsourced Validators doesn't suffer from these issues and helps keep the Registry adaptive to any new ZKP systems. ### Shifting Trust Back To Code A key idea in using Validators crowdsourcing is to shift the trust from Projects (for users who do not explicitly validate verifiers) to sophisticated users (users who validate the verifiers). When automated toolings are involved, the trust is shifted back to code. This might seem like we are back to the original problem where users without technical expertise are forced to blindly trust the automated toolings. However, this is not the case because: 1. whereas before the trust was on each individual Project, automated toolings place trust on a single codebase. The automated toolings can be audited and be used by many projects. 2. maintaining the Registry is the main purpose of the team. This ensures sufficient resources are available. 3. given the standardization, a more effective UX can be built to allow users to understand the validation process. ### Open Questions #### Validating the Validation - Is there a way for the validators to prove that they performed the validation process, either successfully or not, _without_ having yet another process to be validated? #### Validation Standardization - How to effectively standardize validation instructions given the wide range of ZKP projects? ## Other Efforts Shortly after this draft was written, L2BEAT released [ZK Catalog](https://medium.com/l2beat/introducing-the-zk-catalog-7ac6f22889c0), a repository of ZK verifiers for verification. Some of the major differences are: - ZK Catalog is centralized - ZK Catalog does all verification themselves - ZK Catalog includes extra information about the ZKP system including the number of verifiers and whether a trusted setup is needed