TVM ChallengeThe contest for smart contract developers with a prize pool of 30,000 TON.
About the contest
We’re excited to announce a new contest for all smart contract developers on TON titled TVM Challenge. This competition aims to explore and showcase the new features and opcode use cases introduced in the upcoming TVM update. As a smart contract developer, this contest allows you to delve into the latest advancements in TVM and discover new possibilities for creating innovative products on TON.
How to apply
- Project name
- A short description of up to three sentences. If necessary, an additional explanation of why new TVM operations are needed
- Link to GitHub or project web-page
- TON address
More details about the process of proposals will be published on the Telegram channel.
We have allocated a total prize pool of 30,000 Toncoin (TON) for this contest. The prize money will be distributed among the participants who showcase the best utilization of the new TVM features. A panel of esteemed jury members will do the evaluations.
The jury will evaluate each project submitted to the contest. The jury will use a combination of different criteria to score each project on a scale from 0 to 3.
The criteria include the following:
- Relevance: The jury will assess how much the project addresses a genuine need for new TVM instructions in smart contracts.
- Efficiency: The jury will evaluate the optimization of the project and the use of gas, exploring ways to improve and optimize implementation.
- The uniqueness of the idea: The jury will consider the originality and novelty of the project, taking into account the possibility of applications that the committee may not have been aware of previously.
- Technical difficulty: The jury will assess the level of technical complexity involved in the project’s implementation.
For each criterion, the jury will assign a score ranging from 0 to 3 based on the following scale:
- 0 points: The solution does not satisfy the given criteria.
- 1 point: The solution barely satisfies the given criteria.
- 2 points: The solution fits the given criteria but requires improvements.
- 3 points: The solution fully meets the given criteria.
It is important to note that the score for technical difficulty carries a weight of 1.5, giving it additional significance in the evaluation process. The maximum score a project can achieve is calculated as 3 (assuming that each project is assessed by 3 judges) multiplied by the sum of the scores for the other criteria plus 1.5 times the score for technical difficulty, resulting in a maximum score of 40.5.
- Andrey Tvorozhkov - Disintar / dton
- Steve Korshakov - Independent TON evangelist, Tact Lead
- Tim - TON Diamonds
- Dan Volkov - TON Whales
- Nikita Kuznetsov - OpenMask
- Shahar - Orbs
- Amin Rezaei - Skyring Foundation / Rift framework
- Andrey Pfau - TON Foundation
- Nick Nekilov - DeDust
- Vladimir Lebedev - Independent TON Researcher
- Dario - STON.fi
- Dr. Awesome Doge - TonX Studio
To participate in the contest and familiarize yourself with the new TVM update, please refer to the following resources:
- List of all new opcodes from the upcoming TVM update
- Git source code with the new TVM update
- Official TON Docs
- Blueprint/Sandbox with upgraded TVM
We encourage you to explore these resources thoroughly to gain a comprehensive understanding of the changes introduced in the upcoming TVM update.
If you find vulnerabilities or bugs in new TVM features on the testnet, you may be eligible for a bug bounty. We wish all participants the best of luck. Our jury is looking forward to seeing your ideas.
|Rank||Project name||Judge 1||Judge 2||Judge 3||Judge 1||Judge 2||Judge 3||Total||Reward in TON|
|1||snarkjs-func||It is awesome that in addition to the working examples and Groth16 / Plonk tests there is an integration in snarkjs. Although the project template can be greatly improved, at the moment it is static and not very convenient.||11.5||11.5||11.5||34.5||5 691|
|2||Snarkjs TVM Integration||This is good work, but project of hrmon is more complex.||The project is compatible with common phase 1 for any zk-snark project to start their circuit-specific phase 2 ceremony. It's high-performing and can be used directly in the browser or in node.js, with the low-level cryptography executed in wasm. Overall, it seems like a well-thought-out project with a detailed outline of its features.||I'm not very familiar with zk, but to me the addition in this project over the original is pretty basic. It does use new opcodes for BLS, seems like in a basic way.||9||10.5||9||28.5||5 053|
|3||Wallet v5||1. Making all functions inline is not the optimal way if you call them in different parts of code. 2. Plugins and continuations in signed messages are considered by trusted sources and called without isolation but they should not be trusted. 3. Timestamp of the signed message does not have upper limit, delayed message attack is possible.||9||10||9||28||4 268|
|3||Clean.ton||The project has single contract that stores all pools, I'm seeing a bit of scalability and efficiency issue here. Contracts repository should've had testing suites and running examples. Also ring signatures are a bit of controversial topic, there has been a lot of discussion that through probabilstic models one can trace back identities using EAE attacks. Large ring sizes may decrease the chance signifcantly but they also decrease practicallity and efficiency.||RIST255, HASHEXT||9||10||9||28||4 268|
|4||Tonnel Network - Tornado implementation on TON blockchain||The contracts are equivalent to tornado-core, and they seem to work properly. However, the code can be heavily optimized and there are more efficient solutions than sha256 that can be used for the project.||The code could be optimized and written in more readable and efficient manner. Looks good overall.||9||9||9||27||3 359|
|5||Circom integration||Project use PLONK (it can be less efficient in certain cases but more flexible)||Project use and test BLS12-381 and Hashes||7||9.5||8||24.5||2 391|
|6||Merkle Proof for Bridging||The efficiency of such a project would primarily depend on the execution of the cross-chain transactions and the data verification procedures implemented. An efficient implementation should minimize unnecessary computational steps and optimize data storage and retrieval.||6||6||5.5||17.5||1 476|
|8||TBDt & TDA Concept — Tokenized Decentralized Backend template & Tokenized Decentralized App Concept||The project is implementation of a special structure. The general expediency of the project and what benefits can be obtained by implementing the project in the blockchain and not in a simple database are not clear.||Further performance optimization may be necessary due to the potential involvement of significant data storage, retrieval, and updating operations in this model.Overall, the "TDBt" project appears to be an innovative and technically complex project with the potential to advance the use-cases of NFTs and expand the scope of decentralized applications. However, a closer look at the project's efficiency, particularly in its contract optim ization and gas usage, would be beneficial for a more thorough evaluation.||5||6||1||12||281|
|9||evm-over-ton-vote||The front-end is not implemented as well, it's just a starter without ton-connect implementation and without filling page content. The idea is reasonable but project implement <5% out 100. The project generally not needed new instructions.||All elements are partially implemented||The project seems to only provide a frontend, while the contract itself is almost unimplemented!||2.5||2||0||4.5||71|