Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ERC: ZK Identity Registry #710

Open
wants to merge 10 commits into
base: master
Choose a base branch
from
Open

Conversation

Arvolear
Copy link
Contributor

@Arvolear Arvolear commented Nov 8, 2024

Would love to see our recent work as an ERC!


ZK Identity Registry - Singleton registry system for storing abstract provable identity statements.

The complete reference implementation can be found here.

@eip-review-bot
Copy link
Collaborator

eip-review-bot commented Nov 8, 2024

File ERCS/erc-7812.md

Requires 1 more reviewers from @g11tech, @SamWilsn, @xinbenlv

ERCS/erc-xxxx.md Outdated Show resolved Hide resolved
ERCS/erc-xxxx.md Outdated Show resolved Hide resolved
ERCS/erc-xxxx.md Outdated Show resolved Hide resolved
@Arvolear Arvolear changed the title Add ERC: ZK Identity Registry Add ERC-7812: ZK Identity Registry Nov 10, 2024
@github-actions github-actions bot removed the w-ci label Nov 10, 2024
@eip-review-bot eip-review-bot changed the title Add ERC-7812: ZK Identity Registry Add ERC: ZK Identity Registry Nov 10, 2024
Copy link

The commit bd71ab8 (as a parent of dda5f4c) contains errors.
Please inspect the Run Summary for details.

@github-actions github-actions bot added the w-ci label Nov 10, 2024
@github-actions github-actions bot removed the w-ci label Nov 10, 2024

## 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.
Copy link

@silasdavis silasdavis Dec 5, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the benefit of centralising these generic provable statements into a single registry? How does it ease the implementation of the other things?

Versus, for example, a separate register per specific domain using similar code via a library? It seems like there would need to be some interaction between the different statement/registry types for this aggregation to be of benefit, can you give an example of where the benefit might arise?

More concretely, as a user, if I was wishing to prove a claim based on a passport, what benefit is there to me that the same registry also stores POAP claims?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @silasdavis, may you please repost this on the forum so we could discuss it in more details?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have a slight preference for SVG diagrams, but if you cannot provide one PNG is acceptable. Do keep in mind that some people (myself included) use light mode.


## 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<TODO>` to integrate custom business-specific registrars for statement processing and proving.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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<TODO>` to integrate custom business-specific registrars for statement processing and proving.
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<TODO>` <!-- TODO --> to integrate custom business-specific registrars for statement processing and proving.

If you use HTML-style comments, the linter will make sure you replace them before going into Review.


## 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<TODO>` to integrate custom business-specific registrars for statement processing and proving.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd like to see a bit more technical meat in your abstract. I have zero zero knowledge knowledge, so I'm probably a good guinea pig for the average ERC reader. You could answer questions like: why do you need a registry to prove zk statements? Why does it need to be a singleton?


### 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.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't say "proposed" in the body. Once the document goes to Final/gets adoption, it isn't really "proposed" anymore; it's ready for adoption.


## 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.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This EIP stemmed from the need to [...]

Content like this belongs in the motivation section, because it's describing the document as a whole. Motivation should justify the proposal as a whole, while the rationale should explain choices made within the document itself. My pet analogy is:

Motivation: We need to build a shed because...
Rationale: We chose to paint the shed red because...


## 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.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.
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 constrain the possible business use cases and allow `Registrars` to implement arbitrary provable solutions.


### Deployment Method

The `EvidenceRegistry` is a singleton contract available at `0x<TODO>` deployed via the “deterministic deployment proxy” from `0x4e59b44847b379578588920ca78fbf26c0b4956c` with the salt `0x<TODO so that the ER address starts with the EIP number>`.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The `EvidenceRegistry` is a singleton contract available at `0x<TODO>` deployed via the “deterministic deployment proxy” from `0x4e59b44847b379578588920ca78fbf26c0b4956c` with the salt `0x<TODO so that the ER address starts with the EIP number>`.
The `EvidenceRegistry` is a singleton contract available at `0x<TODO>` <!-- TODO --> deployed via the “deterministic deployment proxy” from `0x4e59b44847b379578588920ca78fbf26c0b4956c` with the salt `0x<TODO so that the ER address starts with the EIP number>` <!-- TODO -->.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants