Contest Proposal: Groth16 zkSNARK Proof Verification Use Cases Part II
Submission period: Aug 1, 2021 00:01 UTC - Aug 31, 2021 at 23:59 UTC Voting period: 15 days
Motivation
This document is a proposal for an introduction of a Part II of “Groth16 zkSNARK Proof Verification Use Cases” contest.
Because we have contest participants who did not submit their works on time for some reasons but took an active part in discussing and helping other participants, at the weekly meeting of the DevEx SubGovernance on 07/22/2021 it was decided to repeat the competition on the same conditions, with the exception of:
- with smaller prizes so that it would be fair in relation to those who submitted work on time. And because, thanks to their work, the barrier to entry for new developers has decreased;
- with shorter application deadlines;
Background and Description
=nil; Foundation as an initial member of Free TON community developed an upgraded version of TON Virtual Machine, which includes cryptographic primitives required for usage zero knowledge proof verification within the virtualized applications. =nil; Foundation also prepared C++ (GitHub - NilFoundation/cpp-ton: Cryptography-enhanced Telegram Open Network Protocol C++ Implementation) and Rust-y (GitHub - NilFoundation/rust-ton: Cryptography-enhanced Telegram Open Network Protocol Rust Implementation) ZK proof verification instruction-enhanced TON protocol implementations.
A test protocol instance was launched using the C++ ZK proof verification instruction-enhanced implementation. Network configuration used for the contest is available at: ton-proof-verification-contest/testnet.config.json at master · NilFoundation/ton-proof-verification-contest · GitHub.
ZKP test network visualization is available at https://live.freeton.nil.foundation and at https://nil.ton.live.
Before the Free TON community will be able to patch a mainnet node-clients this ZKP clients should be tested for security and stability.
This document proposes the first in a series of “ZKP contests” aiming motivation of Free TON developer community to try prepared tools and to crowdsource simple ZKP use cases for testing purposes.
Instructions for participants
Participants are expected to create any trivial sample case which uses Groth16 proofs.
Contest repository (aka place to start) is available at: https://github.com/nilfoundation/ton-proof verification-contest
Advanced proof generation and circuit definition documentation is available at: Crypto3 Cryptography Suite.
General requirements
Solutions provided are expected:
● To be a correctly functioning FreeTON LSCS deployed on a test network (https://live.freeton.nil.foundation)
● Not to be a TONCash-alike or any anonymous transactions/token proposal. There is a separate contest for that.
● To involve VERGRTH16 TVM instruction usage.
● To contain circuit definitions done (preferably) with =nil; Crypto3 Blueprint library (GitHub - NilFoundation/crypto3-blueprint: Component module for =nil; Foundation's Zero-Knowledge Cryptography) or as a formal statement.
● To contain proving/verifying key and the statement being proved (primary and auxiliary inputs).
Evaluation criteria and winning conditions
● Apart from uploading a submission, a code should be submitted in accordance with GitHub - freeton-org/readme.
● A participant should do a presentation of her solution at a convenient time agreed with DevEx members. A solution should include tests with clear instructions.
● If a test does not cover some scenarios, then jury members can develop their own tests, but it should reduce such a submission score.
● The solution should have an open source license.
● The solution has to comply with formal requirements introduced by the instructions for jury members.
● Each submission should be rated by jury members based on its:
○ Easy to use
○ Suitability for real use
○ Innovativeness
○ Complexity
○ Tests completeness
Instructions for jury members
Jury members are supposed to verify the correctness of the proof submitted by the participant to the test cluster (in case it is not possible to trust the usual verification because that is exactly what is being tested). To achieve that it is required:
- To reproduce the proof generation the same way as the participant did it. Participants are expected to provide a proving/verifying keypair and circuit definition for that.
Circuit definitions are accepted in:
- =nil; Crypto3 Blueprint library format. Usually this is a set of C++ sources defined as the manual states:
https://crypto3.nil.foundation/projects/crypto3/d8/da7/blueprint_usage_manual.ht ml. Jury members are expected to simply compile sources provided by participants. This is an option preferred.
-
Formal statement. This will require for the jury members to implement the circuit definition himself with some tool available for that (=nil; Crypto3 Blueprint library, Bellman library, libsnark, ZooKrates DSL, etc). This is not an option preferred.
-
Generate the proof using participant’s proving key and make sure it is the same as the participant submitted to the test cluster. The process is the same as participants are supposed to perform: GitHub - NilFoundation/ton-proof-verification-contest: Entry point for TON Proof Verification Contest.
-
Verify the proof out of the TVM using participant’s verification key and some native verification mechanism. The easiest way to do that is to use =nil; Crypto3 ZK library
(GitHub - NilFoundation/crypto3-zk: Zero-Knowledge Cryptography for =nil; Crypto3 C++ Cryptography Suite) according to the instructions available in here: GitHub - NilFoundation/ton-proof-verification-contest: Entry point for TON Proof Verification Contest.
After each of these steps is completed successfully, the jury members can consider the particular participant’s proof generation and verification formally correct.
Voting
● Jury members whose team(s) intend to participate in this contest by providing submissions lose their right to vote in this contest.
● A jury from other sub-governance groups could be added to this contest to provide additional technical expertise.
● Each jury member will vote by rating each submission on a scale of 1 to 10.
● Jury members should provide feedback on each submission.
● The jury will reject duplicate, subpar, incomplete, or inappropriate submissions.
Reward
Only submissions with an average score equal to or more than 4.0 can get a reward.
1th place … 35,000 TONs
2th place … 30,000 TONs
3th place … 25,000 TONs
4th place … 20,000 TONs
5th place … 15,000 TONs
6th place … 10,000 TONs
7-10th place … 5,000 TONs
Note: If the number of winning submissions is less than the number of rewards available, any remaining rewards are not subject to distribution and are considered void.
Jury rewards
An amount equal to 15% of all total tokens actually awarded will be distributed equally between all jury members who vote and provide feedback. Both voting and feedback are mandatory in order to collect the reward.
Governance rewards
An amount equal to 2 % of the prize fund will be allocated to members who participated in organizing the contest, to be distributed equally among them:
● @nemothenoone
● @prigolovko
● @anovi
Procedural remarks
● Participants must upload their work correctly so it can be viewed and accessible in the formats described. If work is inaccessible or does not fit the criteria described, the submission may be rejected by jury members.
● Participants must submit their work before the closing of the filing of applications. If not submitted on time, the submission will not count.
Multiple submissions.
● Each contestant could provide several submissions if they are all different from one another. If they are too similar, or in any way appear to be partially the same work done twice, or if they appear to be one whole body of work divided into parts to create the illusion of several submissions, jury members have the right to reject such submissions.
● If the contestant wants to make an additional submission to replace a previously published submission, the contestant must inform the jury about this fact and indicate which submission is the one to be judged. In this case, only the indicated work will count. If the contestant fails to indicate which submission to judge, only the first submission that is uploaded by timestamp will count. The Jury will reject all others.
Adding Formal Verification Subgov team to the Jury members of contest
In addition to the regular DevEx Subgov Jury Members, it is proposed to add the following Formal Verification Subgov Initial Members to the contest jury list:
- Sergey EGOROV @sergeyegorovspb 67dd20b9a760ae538a7f24ebfbaaf09a7075b4617a7ad09c19503c2551f57d81 0:d0e20274758acb651930c5b9b7dfda330583624f0e4d0b8ffc63bc287c69c5e3 *
- Andrey LYASHIN @andruiman cec27f6cfdadadc5da135875d5988019bd8a760fe6e16fe1f49459cf6d18f9e7 0:0a98551dd36a5dc65f4510362f3528dd195862a054aa70fcdd7ca8925a54ece4 *
- Fabrice LE FESSANT @fabrice_dune 4aca372ed9695ab42cc8ba7fd7f56d11c2401611c2d513bbc28beb5c7f4363a1 0:24a44423bc7edc2598b50ae87267bd06bc53455328e837dae32b9b7592716de7 *
- Thomas SIBUT-PINOTE @ThomasSibutPinote 50384ec36bee19914526f436a0adf57d0c35389934b5aaca15db5b5e89f42aa0 0:95d0f87463175d9cfeb5fd62df6699d56de1fdecb5d823cae21de84aaba3ed12 *
- Evgeniy Shishkin @unboxedtype 6ff61c1a7bb09795f7b5d5514dd710efb72e9557654d362ef208fde545ba7a33 0:ef3813861e4717bc5b34bbdc13b3498ad2b0198100f87b9fa28cd080854c4ad8
Contest announcement and attracting new members rewards
An amount equal to 5% of the prize fund will be allocated to announcing partners who participates in announcing the contest in different media according with the following table: media list for technical contests announcements 6, to be distributed equally among them:
anovi 0:70759025778f37fd98ddb2b22aa8f6c54708a2917902cb3929e354d290b41d6a
Alex770 0:ffc7897f7d234cb24f958aac097e59e16dad3e5ea147b4a214807f9274369be2
moqub 0:a19bb3f75057490fd24c79f23c784db573bdf17dd75c955565b9ba3d439b5c3a
lesnik13utsa 0:75a60f6c9aff6ecb6e2ce52ab16924248b09e3e11d5b4adb98893b7967591047
Kronchs 0:a8b73825ef947fe5cc004761dc2eaf6400b23068df6c68859b7e7263dd7c02c5
Each participant of the contest, when submitting an application, will be asked through which announcing partner he/she learned about the contest. After the end of the contest, for each participant who won a reward, an amount equal to 5% of his/her reward will additionally be distributed:
- To the announcing partner who attracted him, if the referral was given during work submission;
- Or equally to all aforementioned partners of the announcement program, if the referral was not specified.