As part of the integration of Groth16 zkp scheme into Free TON, it should be possible to generate proofs in DeBots.
The proof generation itself can be added as a TVM instruction, but to generate proof you must first generate an auxiliary (and sometimes public) input which satisfies the R1CS circuit.
This functionality is implemented in the c++ library crypto3-blueprint by =nil; foundation.
Since the auxiliary input generation differs significantly between different circuits it cannot be added as an instruction, instead it has to be done using in-TVM logic.
Fortunately, there’s a c++ to TVC (TVM bytecode) compiler. However, as it is it can’t be compiled, and various included file not found errors can be seen when trying to do so for example. This is a contest to patch the compiler sdk and the crypto3-blueprint or its dependencies in order to get it to compile.
In addition, since TVM works a bit differently than a regular processor it might be more efficient to use native TVM types and functions, this contest is not only about compiling the library but also optimizing it to utilize TVM capabilities where needed. Of course the patch to blueprint library should not prevent the library from being compiled using a regular compiler to machine code. (For example, you may want to use Preprocessor definitions).
Participants are required to write patches if needed to crypto3-blueprint (GitHub - NilFoundation/crypto3-blueprint: Component module for =nil; Foundation's Zero-Knowledge Cryptography) and its dependencies as well as the C++ compiler so that it would be possible to compile and run a C++ smart contract which uses this library. You are recommended to use a template repo as a basis.
It should be possible to use all the capabilities of the library which can currently be used, the library contains a few incomplete components, so if a file does not compile/run correctly with a regular C++ compiler to machine code, it is not required to patch it.
It should still be possible to compile the patched library with a regular C++ compiler to machine code and run it. Its performance should not be decreased.
- Making the library perform better in TVM would make your score higher, you might want to use native TVM types for that, for example, using Preprocessor Definitions.
- Apart from uploading a submission, a code should be submitted in accordance with https://github.com/freeton-org/readme
- A participant should do a presentation of her solution at a convenient time agreed with Cryptography SG 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.
- The solution should contain at least a draft of an architecture description. (There must be a better way to say it in this kind of patching contest).
- Submissions must differ from each other by at least 10%, or else they should be rejected.
Only submissions with an average score equal to or more than 6.0 can get a reward.
- 1st prize 200,000 TONs
- 2nd prize 100,000 TONs
- 3rd prize 50,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 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.
An amount equal to 5% of the prize fund, that is, 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.