Contest Proposal: Rollup Verification Support

Cryptography Sub-Governance
#1

Contest Proposal: Rollup Verification Support

Submission period: September 25, 2021 00:01 UTC - October 25, 2021 at 23:59 UTC
Voting period: 14 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.

Crucial application for such a verificaiton instruction is to verify rollups which often consist of transactions/replication packages/votes signatures etc.

Verifying transactions, votes etc. is all about verifying its signatures. Widespread signatures (EdDSA, ECDSA) are defined over non-pairing friendly curves (Ed25519, secp256k1) which have no twisted curves and induce high verification costs and timings. In case of FreeTON verification timings are required to be kept as low as possible.

Ths document proposes a contest results of which are supposed to introduce the way to efficiently verity non-pairing friendly curves-based signatures over BLS12-381-based Groth16 SNARK proof which would result in the introduction of a way to verify zk-rollups on FreeTON.

Instructions for participants

Participants are expected to introduce the way to efficiently verify EdDSA over Ed25519 signatures with the newly introduced VERGRTH16 instruction to make it possible to verify outside protocols zk-rollups inside the TVM.

General requirements

Solutions provided are expected:

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:

  • Reproduce use case scenario (verification of batches with various amount of signatures)
  • Confirm the solution complies to the architecture description.
  • Confirm the solution complies to protocol requirements.
  • Compare the performance of submissions. Better performance means better score.
  • Compare the nature of solutions provided. Purely technical circuit crafting solutions are less welcome than scheme modification-based ones.

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 5.0 can get a reward.

  • 1st prize (score >= 7.0) - 300000 TONs
  • 2nd prize (score >= 6.0) - 150000 TONs
  • 3rd prize (score >= 5.0) - 50000 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 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.

Governance rewards

An amount equal to 5% of the prize fund will be allocated to members who participated in organizing the contest, to be distributed equally among them:

  • @nemothenoone
  • @nbering

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.
1 Like
#2

I would suggest to use different reward for different places as more fair and more clear way to motivate participants.

#3

And I would add to use such system for places like this:
To get 1st place - average score should be more than 9.0(for example)
To get 2nd place - more than 8.0
To get 3rd more than 7.0
4th-10th place more than 6.0
This prevents from different type of situations when for example we will have only 1-3 works, and first will be excellent and deserve 1-2 place and others rather good and deserve 8-9 place

1 Like
#5

Since this particular contest has several possible solutions, this approach is definitely worth using.

#6

Good idea! 9.0 though is an extremely high requirement. If we have 15 jurors, even if non of them abstain, all of them give 9 (you almost always have some comments so 10 out of 10 is rare) except for one who gives 8 and you won’t make it.

#7

What? Was that mistakenly copied from another contest?

#8

within a single replication packet production interval.

Can we change this into something more easily measurable? Wouldn’t it be easier if give a limit to number of constraints/variables?

Also:

You should include wallet addresses

#9

Exactly why I push so hard for every contest description to be reviewed by several people.

Yes, I forgot to replace use case scenarios. Verification of signature batches of different sizes should be there instead (so we could estimate the solution efficiency).

#10

Ah. The whole point of this contest is to fit the verification time of huge signature batches which zk-rollups are full of in a reduced cluster replication time. Now it is 0.2 sec. Might become even tighter with alternative FreeTON protocol implementations coming.

#11

Since the advertising campaign has already started, here is a proposal to add the following to the contest description:

Contest announcement and attracting new members rewards

The reward consist of the two parts:

First part: 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, to be distributed equally among them:
● @anovi
● @Alex770
● @lesnik13utsa
● @Kronchs
Second part: 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.

In case a winner is the old member of community and took part in the contests before, the second part of the advertisement reward (amount equal to 5% of his reward) will not be rewarded and considered void.

Update. Some clarification was added

1 Like
#12

Who are these people?

#13

We have been promoting Dev ex contests since July and our nicknames are in every proposal, now we have been asked to advertise Cryptography contests

#14

And what to do if this is an old participant who, for example, did not want to take part in new competitions or did not know about them, but we reminded him and brought him (and he indicated this in the application). Will there be a payout for this?

1 Like
#15

Contest Prolongation Proposal: Rollup Verification Support

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

Voting period: 14 days

1 Like
#16

I don’t think so for two reasons:

  1. We have contacts of old participants already so it looks like a simple task to send announcement to them.
  2. If somebody who was invited by you one time will indicate you as a referrer person every time so this could be kind of passive income. This is outside of the idea of contests as I understand it.
#17

Contest Prolongation Proposal: Rollup Verification Support

Submission period: September 25, 2021 00:01 UTC - December 25, 2021 at 23:59 UTC

Voting period: 14 days

#18

Contest Prolongation Proposal: Rollup Verification Support

Submission period: September 25, 2021 00:01 UTC - March 14, 2021 at 23:59 UTC

Voting period: 14 days

#19

Продление отражено в лендингах и текстах по ресурсам: https://rvs.freeton.today