Contest Proposal: Groth16 zkSNARK Proof Verification Use Cases
Submission period: May 1, 2021 00:01 UTC - May 31, 2021 at 23:59 UTC
Voting period: 20 days
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.
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: GitHub - NilFoundation/ton-proof-verification-contest: Telegram Open Network LSCS Examples
Advanced proof generation and circuit definition documentation is available at: Crypto3 Cryptography Suite.
- The use case implementation is a correctly functioning FreeTON LSCS.
- The use case is not a TONCash-alike or any anonymous transactions/token proposal. There is/will be a separate contest for that.
- The use case should involve VERGRTH16 TVM instruction usage.
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 jurors can develop their own tests, but it should reduce such a submission score.
- The solution should have an open source license.
- Jurors 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 juror will vote by rating each submission on a scale of 1 to 10.
- Jurors should provide feedback on each submission.
- The jury will reject duplicate, subpar, incomplete, or inappropriate submissions.
Only submissions with an average score equal to or more than 4.0 can get a reward.
1st prize … 80,000 TONs
2nd prize … 60,000 TONs
3rd prize … 40,000 TONs
4th-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.
An amount equal to 10% of all total tokens actually awarded will be distributed equally between all jurors who vote and provide feedback. Both voting and feedback are mandatory in order to collect the reward.
An amount equal to 1 % of the prize fund will be allocated to members who participated in organizing the contest, to be distributed equally among them:
- 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 jurors.
- Participants must submit their work before the closing of the filing of applications. If not submitted on time, the submission will not count.