Contest Proposal: Rollup Verification Support

Contest Proposal: Rollup Verification Support

Submission period: September 15, 2021 00:01 UTC - October 15, 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++ ( and Rust-y ( 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:

  • To reproduce every usecase scenario (voter registration, voting, vote count)
  • To confirm the solution complies to the architecture description.
  • To confirm the solution complies to protocol requirements.


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

  • 1st prize … TONs
  • 2nd prize … TONs
  • 3rd prize … TONs
  • 4th-10th place … 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
  • @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

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

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

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

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.

What? Was that mistakenly copied from another contest?

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?


You should include wallet addresses

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

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.