-
Notifications
You must be signed in to change notification settings - Fork 488
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
base: master
Are you sure you want to change the base?
Conversation
The commit bd71ab8 (as a parent of dda5f4c) contains errors. |
|
||
## 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. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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 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>`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 -->. |
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.