mirror of https://github.com/status-im/EIPs.git
171 lines
9.0 KiB
Markdown
171 lines
9.0 KiB
Markdown
---
|
|
eip: 1923
|
|
title: zk-SNARK Verifier Registry Standard
|
|
author: Michael Connor <michael.connor@uk.ey.com>, Chaitanya Konda <chaitanya.konda@uk.ey.com>, Duncan Westland <duncan.westland@uk.ey.com>
|
|
discussions-to: https://github.com/ethereum/EIPs/issues/1923
|
|
type: Standards Track
|
|
category: ERC
|
|
status: Draft
|
|
created: 2018-12-22
|
|
requires: 165, 196, 197
|
|
---
|
|
|
|
## Simple Summary
|
|
|
|
|
|
A standard interface for a "Verifier Registry"'" contract, through which all zk-SNARK verification activity can be registered.
|
|
|
|
## Abstract
|
|
The following standard allows for the implementation of a standard contract API for the registration of zk-SNARKs ("Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge"), also known as "proofs", "arguments", or "commitments".
|
|
|
|
TODO: Which functionality is exposed in this standard interface?
|
|
|
|
## Motivation
|
|
zk-SNARKs are a promising area of interest for the Ethereum community. Key applications of zk-SNARKs include:
|
|
- Private transactions
|
|
- Private computations
|
|
- Ethereum scaling through proofs of 'bundled' transactions
|
|
|
|
A standard interface for registering all zk-SNARKs will allow applications to more easily implement private transactions, private contracts, and scaling solutions; and to extract and interpret the limited information which gets emitted during zk-SNARK verifications.
|
|
|
|
:warning: TODO: Explain the motivation for standardizing a registry, other than simply standardizing the verifier interactions.
|
|
|
|
⚠️ TODO: Explain the benefits to and perspective of a consumer of information. I.e. the thing that interfaces with the standard verifier registry.
|
|
|
|
## Specification
|
|
The key words "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.
|
|
|
|
|
|
```solidity
|
|
pragma solidity ^0.5.6;
|
|
|
|
/// @title EIP-XXXX zk-SNARK Verifier Registry Standard
|
|
/// @dev See https://github.com/EYBlockchain/zksnark-verifier-standard
|
|
/// Note: the ERC-165 identifier for this interface is 0xXXXXXXXXX.
|
|
/// ⚠️ TODO: Set the interface identifier
|
|
interface EIP-XXXX /* is ERC165 */ {
|
|
|
|
event NewProofSubmitted(bytes32 indexed _proofId, uint256[] _proof, uint64[] _inputs);
|
|
|
|
event NewVkRegistered(bytes32 indexed _vkId);
|
|
|
|
event NewVerifierContractRegistered(address indexed _contractAddress);
|
|
|
|
event NewAttestation(bytes32 indexed _proofId, address indexed _verifier, bool indexed _result);
|
|
|
|
|
|
function getVk(bytes32 _vkId) external returns (uint256[] memory);
|
|
|
|
function registerVerifierContract(address _verifierContract) external returns (bool);
|
|
|
|
function registerVk(uint256[] calldata _vk, address[] calldata _verifierContracts) external returns (bytes32);
|
|
|
|
function submitProof(uint256[] calldata _proof, uint64[] calldata _inputs, bytes32 _vkId) external returns (bytes32);
|
|
|
|
function submitProof(uint256[] calldata _proof, uint64[] calldata _inputs, bytes32 _vkId, address _verifierContract) external returns (bytes32);
|
|
|
|
function submitProofAndVerify(uint256[] calldata _proof, uint64[] calldata _inputs, bytes32 _vkId, address _verifierContract) external returns (bytes32);
|
|
|
|
function attestProof(bytes32 _proofId, bytes32 _vkId, bool _result) external;
|
|
|
|
function attestProofs(bytes32[] calldata _proofIds, bytes32[] calldata _vkIds, bool[] calldata _results) external;
|
|
|
|
function challengeAttestation(bytes32 _proofId, uint256[] calldata _proof, uint64[] calldata _inputs, address _verifierContract) external;
|
|
|
|
function createNewVkId(uint256[] calldata _vk) external pure returns (bytes32);
|
|
|
|
function createNewProofId(uint256[] calldata _proof, uint64[] calldata _inputs) external pure returns (bytes32);
|
|
|
|
}
|
|
```
|
|
### Interface
|
|
``` solidity
|
|
interface ERC165 {
|
|
/// @notice Query if a contract implements an interface
|
|
/// @param interfaceID The interface identifier, as specified in ERC-165
|
|
/// @dev Interface identification is specified in ERC-165. This function
|
|
/// uses less than 30,000 gas.
|
|
/// @return `true` if the contract implements `interfaceID` and
|
|
/// `interfaceID` is not 0xffffffff, `false` otherwise
|
|
function supportsInterface(bytes4 interfaceID) external view returns (bool);
|
|
}
|
|
```
|
|
|
|
## Rationale
|
|
<!--The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.-->
|
|
|
|
⚠️ TODO: Add Rationale section.
|
|
|
|
### Backwards Compatibility
|
|
|
|
<!--All EIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The EIP must explain how the author proposes to deal with these incompatibilities. EIP submissions without a sufficient backwards compatibility treatise may be rejected outright.-->
|
|
|
|
⚠️ TODO: Add Backwards Compatibility section.
|
|
|
|
### Test Cases
|
|
|
|
<!--Test cases for an implementation are mandatory for EIPs that are affecting consensus changes. Other EIPs can choose to include links to test cases if applicable.-->
|
|
|
|
Truffle tests of example implementations are included in this Repo.
|
|
|
|
⚠️ TODO: Reference specific test cases because there are many currently in the repository.
|
|
|
|
|
|
## Implementations
|
|
<!--The implementations must be completed before any EIP is given status "Final", but it need not be completed before the EIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details.-->
|
|
Detailed example implementations and Truffle tests of these example implementations are included in this Repo.
|
|
|
|
⚠️ TODO: Update referenced verifier registry implementations so that they are ready-to-deploy or reference deployed versions of those implementations. At current, the referenced code specifically states "DO NOT USE THIS IN PRODUCTION".
|
|
|
|
⚠️ TODO: Provide reference to an implementation which interrogates a standard verifier registry contract that implements this standard.
|
|
|
|
|
|
## References
|
|
|
|
⚠️ TODO: Update references and confirm that each reference is cited (parenthetical documentation not necessary) in the text.
|
|
|
|
**Standards**
|
|
|
|
1. ERC-20 Token Standard. https://eips.ethereum.org/EIPS/eip-20
|
|
|
|
1. ERC-165 Standard Interface Detection. https://eips.ethereum.org/EIPS/eip-165
|
|
2. ERC-173 Contract Ownership Standard (DRAFT). https://eips.ethereum.org/EIPS/eip-173
|
|
3. ERC-196 Precompiled contracts for addition and scalar multiplication on the elliptic curve alt_bn128. https://eips.ethereum.org/EIPS/eip-196
|
|
4. ERC-197 Precompiled contracts for optimal ate pairing check on the elliptic curve alt_bn128. https://eips.ethereum.org/EIPS/eip-197
|
|
5. Ethereum Name Service (ENS). https://ens.domains
|
|
6. RFC 2119 Key words for use in RFCs to Indicate Requirement Levels. https://www.ietf.org/rfc/rfc2119.txt
|
|
|
|
##### Educational material: zk-SNARKs
|
|
|
|
1. Zcash. What are zk-SNARKs? https://z.cash/technology/zksnarks.html
|
|
2. Vitalik Buterin. zk-SNARKs: Under the Hood. https://medium.com/@VitalikButerin/zk-snarks-under-the-hood-b33151a013f6
|
|
3. Christian Reitweissner. zk-SNARKs in a Nutshell. https://blog.ethereum.org/2016/12/05/zksnarks-in-a-nutshell/
|
|
4. Ben-Sasson, Chiesa, Tromer, et. al. Succinct Non-Interactive Zero Knowledge for a von Neumann Architecture. https://eprint.iacr.org/2013/879.pdf
|
|
|
|
##### Notable applications of zk-SNARKs
|
|
|
|
1. EY. Implementation of a business agreement through Token Commitment transactions on the Ethereum mainnet. https://github.com/EYBlockchain/ZKPChallenge
|
|
2. Zcash. https://z.cash
|
|
3. Zcash. How Transactions Between Shielded Addresses Work. https://blog.z.cash/zcash-private-transactions/
|
|
|
|
##### Notable projects relating to zk-SNARKs
|
|
|
|
1. libsnark: A C++ Library for zk-SNARKs ("project README)". https://github.com/scipr-lab/libsnark
|
|
2. ZoKrates: Scalable Privacy-Preserving Off-Chain Computations. https://www.ise.tu-berlin.de/fileadmin/fg308/publications/2018/2018_eberhardt_ZoKrates.pdf
|
|
3. ZoKrates Project Repository. https://github.com/JacobEberhardt/ZoKrates
|
|
4. Joseph Stockermans. zkSNARKs: Driver's Ed. https://github.com/jstoxrocky/zksnarks_example
|
|
5. Christian Reitweissner - snarktest.solidity. https://gist.github.com/chriseth/f9be9d9391efc5beb9704255a8e2989d
|
|
|
|
##### Notable 'alternatives' to zk-SNARKs - areas of ongoing zero-knowledge proof research
|
|
|
|
1. Vitalik Buterin. STARKs. https://vitalik.ca/general/2017/11/09/starks_part_1.html
|
|
2. Bu ̈nz, Bootle, Boneh, et. al. Bulletproofs. https://eprint.iacr.org/2017/1066.pdf
|
|
3. Range Proofs. https://www.cosic.esat.kuleuven.be/ecrypt/provpriv2012/abstracts/canard.pdf
|
|
4. Apple. Secure Enclaves. https://developer.apple.com/documentation/security/certificate_key_and_trust_services/keys/storing_keys_in_the_secure_enclave
|
|
5. Intel Software Guard Extensions. https://software.intel.com/en-us/sgx
|
|
|
|
|
|
## Copyright
|
|
|
|
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
|