Contest Proposal: Anonymous Token Protocol Implementation

Contest Proposal: Anonymous Token Protocol Implementation

Submission period: September 1, 2021 00:01 UTC - November 1, 2021 at 23:59 UTC

Voting period: 20 days

Background and Description

=nil; Foundation as an initial member of FreeTON community developed 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</t) and Rust-y (GitHub - NilFoundation/rust-ton: Cryptography-enhanced Telegram Open Network Protocol Rust Implementation<) ZK proof verification instruction-enhanced TON protocol implementations.

Recently, a VERGRTH16 TVM instruction use case contest was held, which intention was to find out bugs and issues regarding this implementation along with providing the community with several non-production use cases. The contest was accomplished successfully and the second part was launched afterwards.

Anonymous token design contest was held afterwards, a couple of designs were submitted, which means the contest was also accomplished successfully.

The time for the anonymous token protocol implementation part has come.

Instructions for participants

Participants are expected to introduce anonymous token protocol implementations according to designs introduced during this contest: https://devex.gov.freeton.org/proposal?proposalAddress=0%3A3791d482d9db624cb690c43cb8a81fb630d70c3e4e328a7a14d2026c9117e7f9. It is also possible for the participants to introduce some implementation of their own design.

General requirements

Solutions provided are expected:

  • To be a correctly functioning FreeTON virtualized application deployed either to https://main.ton.dev (https://ton.live) (in case the protocol gets upgraded) either to https://net.freeton.nil.foundation (https://nil.ton.live or https://live.freeton.nil.foundation) or to https://fld.ton.dev.
  • To be TIP-3 compatible.
  • To use VERGRTH16 instruction.
  • To hide the “sender”/“receiver” (in terms of application logic) address in a provable manner.
  • To hide the “transaction” (in terms of application logic) integral value in a provable manner.
  • To not to be a mixer of any kind, but to provide provable anonymity.
  • In case the design used was not presented during Anonymous Token Design Contest (Free TON Community), the participant is required to introduce a formal description (with formal proofs) of a protocol and its architecture.

Evaluation criteria and winning conditions

Instructions for jurors

Jurors are supposed to verify the correctness of the protocol submitted by the participant to the test cluster as follows:

  • To reproduce every protocol scenario (transfer, deposit, etc.)
  • To confirm the solution complies to protocol description requirements.

Voting

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.

Reward

Only submissions with an average score equal to or more than 6.0 can get a reward.

  • 1st prize 400000 TONs
  • 2nd prize 300000 TONs
  • 3rd prize 150000 TONs

Total prizes: 850000 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 jurors 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

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 jurors.

â—Ź Participants must submit their work before the closing of the filing of applications. If not submitted on time, the submission will not count.

â—Ź Submission description document format. Submission description should be formatted as a PDF document to avoid post-deadline submission changes.

â—Ź Accessibility. All the submissions must be accessible for the Jury, so please double-check your submission. If the submission is inaccessible or does not fit the criteria described, jurors may reject the submission.

â—Ź Timing. Contestants must submit their work before the closing of the filing of applications. If not submitted on time, the submission will not count.

● Contact information. All submissions must contain the contestant’s contact information, preferably a Telegram username by which jurors can verify that the submission belongs to the individual who submitted it. If not, jurors may reject your submission.

â—Ź Content. The content published in the forum and the provided PDF file should not differ, except for formatting. Otherwise, jurors may reject the submission.

â—Ź Well-formed links. If your submission has links to the work performed, the
content of those links must have the contestant’s contact details, preferably a Telegram username, so jurors can match it and verify whom the work belongs to. If not, jurors may reject your submission.

Nikita said in the chat group that NIL’s cluster is stopped but FLD network supports VERGRTH16 instruction. If so, the links to dapp server and blockchain explorer should be replaced.

1 Like