Contest Proposal: Tick-tock messages aka Timer smart contract

Ever TON Dev Experience Sub-Governance Contest Proposals
#1

Short description

Objective: Provide a fully on-chain time-based alarm service to be used by other smart-contracts developers and smart-contract systems.

Contest dates

November 10, 2020 - November 23, 2020 end of the day by timestamp in your location. There
will be a 24-hour countdown clock on the last day of possible contest submission entry.

Voting cycle:

7 days

Motivation

Certain time-bound smart-contract systems require a specific kind of interaction with an on-chain entity in order to fulfill their functional requirements. Time-lock might not be sufficient if the system has to perform a certain kind of action before a particular moment in time, and oracle-like mechanisms fetching off-chain data are unacceptable due to the low reliability.

One of the examples is decentralized staking pools (or DePools), bound to the Validator elections timeline.

Task

Implement an on-chain time-based alarm service.

Submission format and requirements

Interface: Timer should provide a programmatic mechanism for the client smart-contract to be notified upon the time expiration.

Reliability: Upon a valid request, the timer should communicate to the client smart-contract via callback mechanism.

Accuracy: Timer should call back within a certain time interval related to the specified timestamp.

Documentation: The contest submission should contain a description of the operation of the smart-contact or the smart-contract system.

Free software: The source code of smart contracts is published in an open Git repository on any public service (GitHub, GitLab, BitBucket, etc.) under any free software license.

Submitting for the contest, explicitly indicate the hash of the contest commit on master branch. All subsequent changes of the code will be ignored in voting stage. If the commit isn’t specified in submission, then the commit for voting is considered the actual commit of master branch at the time of submission filing.

Evaluation criteria

Considering the following criteria set, the submission score increases:

  • Compliance with declared in “Submission format and requirements” functionality
  • Supportability (quality of code, quality of documentation)
  • Quality of design and development
    • main criteria: the accuracy of the timer and the measurement error

Notes

Jury:

  • The juror must have a solid understanding of the described technology to provide a score and feedback. If not, the juror should choose to “Abstain”.

Voting:

  • The juror must have a solid understanding of the described technology to provide a score and feedback. If not, the juror should choose to “Abstain”.
  • Jurors is obliged to vote only the commit specified in the application. If the commit isn’t explicitly indicated, the jury is obliged to vote the actual commit of master branch at the time of submission filing.
  • Jurors or whose team(s) intend to participate in this contest by providing submissions lose their right to vote in this contest.
  • Each juror will vote by rating each submission on a scale of 1 to 10 or can choose to reject it if it does not meet requirements or vote “Abstain” if they feel unqualified to judge.
  • Jurors must provide feedback on submissions or lose their reward.
  • The Jury will reject duplicate, sub-par, incomplete, or inappropriate submissions.
  • The number of days for jury voting is hereby set at 7 days.

Contest Rewards

  • 1 place: 36,000 TONs
  • 2 place: 27,000 TONs
  • 3 place: 18,000 TONs
  • 4-7 place: 3,600 TONs
  • 8-15 place: 1200 TONs
  • 16-30 place: 500 TONs
  • Total amount: 112,500 TONs

Reward Distribution

  • Winners receive 50% of their rewards when contest results are evaluated.
  • Another 50% will be vested in equal parts over a 12-month period with monthly payouts.
  • To receive all 12 distributions, the solution should be supported for 1 year
    • The code should be updated within a reasonable timeframe - 1 month maximum, and according to main library changes.
    • Major GitHub Issues should be resolved within a reasonable timeframe - 1 month maximum.

Jury Rewards:

An amount equal to 5% of the total sum of all total tokens awarded to contest winners will be distributed among jurors who vote and provide feedback. This percentage will be awarded on the following basis:

  • The percentage of tokens awarded to the jury will be distributed based on the number of votes each juror casts. For example, if one juror votes 50 times and another juror votes 5 times, the juror who votes 50 times will get 10 times more tokens than the juror who votes 5 times.
  • Feedback is mandatory to collect any rewards.
  • In this particular contest, the contestants have a vesting period for their reward distributions. The jurors do not. Jurors will receive their rewards upon completion of the contest in one lump sum, i.e., no vesting period, and as a part of the cumulative 100% reward figure regardless of the long term outcome.

Procedural requirements:

Accessibility. All submissions must be accessible for the jury to open and view, 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. Each submission must have an identifiable contact that can be matched with your description. If you have not provided a forum description for discussion, then your application should contain links to your online persona, for example, a Telegram ID (preferred) or other direct contact information that can confirm that the submitted work is yours. In the absence of confirmation by the contestant of the authorship of the submitted work, the submission may be rejected.

Multiple submissions

  • Each contestant has the right to provide several submissions if they are all different from one another. If they are too similar, or in any way appear to be partially the same work done twice, or if they appear to be one whole body of work divided into parts to create the illusion of several submissions, jurors have the right to reject such submissions.
  • If the contestant wants to make an additional submission to replace a previously published submission, the contestant must inform the jury about this fact and indicate which submission is the one to be judged. In this case, only the indicated work will count. If the contestant fails to indicate which submission to judge, only the first submission that is uploaded by timestamp will count. The Jury will reject all others.

Disclaimer

Anyone can participate, but Free TON cannot distribute tokens to US citizens or US entities.

4 Likes
#3

i am also in deal, it is good practice for me, for write solidity smart-contracts

#4

I believe that cost per tick (internal timer) should be one of the main evaluation criteria. At the same time main criteria: the accuracy of the timer and the measurement error is something totally senseless: accuracy will be determined by block rate (thus by validators action) not by something that is under control of smartcontract.

2 Likes
#5

Hello, I’m participating in this contest.

Please find my submission in PDF in DevEx subgov interface

#6

Hello there!

I’m glad to present my submission for Tick-tock messages aka TImer smart contract contest developed at SVOI.dev labs!

This is Tick-Tock messages based Timer for smart contracts that allows you to shedule your smart contract call for desired time.

Please read PDF for more info, including info how smart contract works and it’s features as well as how it fits presented requirements, also be sure to check Roadmap for contract development and support.

Smart contract code can be found here: https://github.com/SVOIcom/TickTockContract
PDF will be linked to post.

Thanks for your attention :slight_smile:

This is post for submission #2: https://devex.gov.freeton.org/submission?proposalAddress=0:91ea1dcdfbaa2d9f869e07a04516addd8752eecd307157e8d4012e1a934094be&submissionId=2

Contacts:
Tg profile: @pafaul
FreeTon forum: Ftar
Github: https://github.com/Pafaul

1 Like
#7

TickTock Timer Contract

Submision PDF

Contacts

Telegram: @estonianavocado
Forum: @pirate

#8

Following discussion we had in devex telegram group, I submit two distinct solutions based on ticktock mechanism and based on loop message chain.
Let me cite my submission:

General scheduler which spends gas for work may be quite expensive. However anybody can deploy one without cooperation with anybody else. Alternative solution which based on tick-tock special contracts is available in the other repository. While special contract soultion doesn’t require gas for work, it however requires cooperation of validators to instantiate such contract. Thus while both solutions have pros and cons they are not mutually exclusive: both are suitable for their niches.

This post is devoted to looped chain based solution. I want to note that I came with this idea and developed first version literally more than year ago https://t.me/ton_overview/30 : 19 october of 2019. Since then contract was polished and made more economically robust.
https://github.com/EmelyanenkoK/freeton_scheduler

#9

This post is devoted to ticktock based solution:

1 Like
#10

Tick Tock? Ping-Pong!
Even smart contracts need to relax. And since in the current contest they are forbidden to sleep, then let them do something fun, for example, play ping-pong! As a bonus, the sound of the ball hitting the racket is sure to wake everyone up.
Sounds crazy? So this is another reason to look at the contract developed by SVOI.dev! {see links below}

Smart contract code: https://github.com/SVOIcom/PingPongTimerContract
PDF will be linked to post.

Contacts:
FreeTON forum: @ntn
Email: [email protected]

1 Like
#11

Did not have much time(

#13

https://github.com/pavelkhachatrian/freeton-timer
This timer consists of two contracts that work together, one written in Solidity, the other in low-level FunC. Solodity allowed for a simple user-friendly interface to control multiple timers, while FunC made it very economic Gas usage.

#14

Dear community,

rsquad take a part in this contest.

Telegram — @inyellowbus
Repository — https://github.com/RSquad/ton-aloof-timer
Contest branch — https://github.com/RSquad/ton-aloof-timer/tree/contest
Contest commit hash — b4b220ec9467766b0c468b7edca05963b5995e9c

Take a look to our submission in PDF at DevEx Subgov

Feel free to contribute, ask questions, test and use. Hope you will enjoy!

#15

Hello colleagues!
I’m taking part in this contest. Please, consider my solution as well.

Here is a repo: https://github.com/asnov/FreeTON_timer/tree/main
Telegram: @anovi

The benefit of my solution is that the transaction prices are shared between the clients. So when solution will be popular between 100 clients simultaneously, the price for each will be bellow 0,5 crystal per day (50/100 = 0,5) or less.

P.S. I wanted to do it in three days, as Mitya predicted, but it didn’t work out. So sorry for the “rapid development”. I can say only “the best documentation is the code” © :smile: I tried my best to give the identifiers self explanatory names. :slight_smile:

#16

Hi, I checked all contracts and want to share my comments. Will be glad to hear back if i missed something.
Disclaimer, i’m contest participant myself and thus (probably) am biassed.
A little bit about my terms: there are two types of smart contracts ticktock based (use ticktock mechanism for special contracts) and pingpong based (used loop of bouncing messages).
Those contracts may provide service for one user only or be multiuser, that is allow multiple users to schedule their event independently.
There can be arbitrary payload, that means when time comes timer may send arbitrary message (it is useful for generality, that way contracts which are not aware of timer still can be called that way).
And finally there can be zero cost when to timers scheduled: for pingpong contracts that means that there is no looped messages and thus fees when there is no timers. For ticktock contracts it is almost useless term, still i decided to put “~yes” for that property if contract do not iterate through whole table of scheduled calls.

Screenshot from 2020-11-29 20-43-03
Screenshot from 2020-11-29 20-43-031329Ă—307 64.2 KB

Update1: Fix: submission 8, zero costs when no timers. Should be yes, instead of no.

6 Likes
#17

Submission 6: “less” instead of “greater”, lol. I’ll fix it, thanks

1 Like
#18

Thanks for spending your time to check all the submissions :slight_smile:

#19

Good job! But this work is incomplete and may be misinterpreted in this form.

Why the work is not complete? Because only the results of functioning of smart contracts are considered (question: how are functional requirements fulfilled?). Non-functional requirements for contest submissions are not considered in principle - although they are given in the contest description and discussed at the DevEx subgovernance meeting.

Why is this important?
Because at the moment, the DevEx smart contract domain has exactly 2 goals (and this was also repeatedly discussed at DevEx meetings):

  1. give developers ready-made solutions

  2. to increase the number of Free TON developers by reducing the entry threshold (descriptions, templates, code, documentation)

That is why the contest description there are requirements for the sustainability&supportability of the solution (quality of code, quality of documentation, quality of the description of the environment, the quality of the system of tests, etc.).

If you will complement your table assessment of non-functional criteria of the contest works:

  • Documented code?
  • What percentage of the code is covered by tests?
  • Is there a description of the algorithm?
  • Is there a description of the environment and how to run the code

then your analysis will probably be excellent.

Now we have only a part of the analysis, and in this form it is unsuitable for complex use.

1 Like
#21

I think this is job of the jury members and not of enthusiasts. As long as there are NO votes at this moment we can at least get this. And i don’t think that i will get something longer than a oneliner from judges…