Free TON

Contest Proposal: Smart Contract Debugger (Phase 1: Specs)

Free TON Dev Experience Subgovernance
#1

Contest Proposal: Smart Contract Debugger (Phase 1: Specs)

Dates

Start: November 20, 2020, end of day UTC
End: December 3, 2020, end of day UTC

Motivation and goal

Smart Contract Debugger is a highly anticipated toolchain component. Developer Experience with Debugger means visualization of the code execution context, deeper developers’ understanding of platform specifics, and better developer productivity.

The goal of the contest is to find the best principal design solutions and describe specifications for further smart contract debugger development.

Task

The best design solution for Smart Contract Debugger is a combination of the following qualities:

  • Platform Context. Consideration of TON Protocol unique features and restrictions.
  • Usability. The design should take into account the most typical needs of a smart contract developer.
  • Composability. Clear protocols of communication between compilers, the debugger and virtual machines. A new compiler or a new virtual machine if it implements the corresponding protocol should easily (ideally, automatically) integrate with the debugger.
  • Reuse of Ideas and Code. Reuse of existing open-source codebases / standards / formats rather than reinventing the wheel is merit. But the rationale for this reuse should be explained as well as its applicability.

Evaluation Criteria

Author should consider the following structural points.
If a submission lacks some of these points, a submission may be rejected or its grade decreased.

  1. Description of use cases and restrictions. Scenarios of usage of the debugger or the tasks you can solve with the debugger. Describe restrictions of proposed solution (if any).

  2. Functional Specifications. Detailed description for each scenario from a programmatic point of view: i.e. what are inputs and outputs, what are the formats for the information exchanged between tools (debug information is usually generated by a compiler and the debugger only processes it), what components of the toolchain are involved in each scenario, what are the algorithms the debugger use.

  3. Reasoning for principal technical decisions. Each author’s technical decision should be supplied by a concise overview of existing solutions (in the scope of related Computer Science topic) and provide pros and cons for the proposed solution. Example: It is not good to propose that exact debug info format should be used. Such decisions must be backed up by reasoning. To support his/her decision, the author may analyze pros / cons of the proposed format, highlight related components’ interfaces / implementation parts, etc. In other words - provide all information by which the author was led while designing the Debugger Specs

  4. Dependencies and Blocker Issues. Identify, describe and prioritize what TON OS Components’ specifics or TON Protocol implementation details should or should not be changed to use the proposed specs as basis for further Debugger development.

  5. Illustrations. For ease of understanding one may supplement complex abstractions with graphics: component relation schemes, UML, data flow diagrams, etc. Each supplied visual should match the related part of the proposed specs.

  6. References. Every reference to facts, specifications, existing solutions / findings should be supported by the relevant document link (URL, page, chapter) where this information could be easily verified.

Optionally, author may cover additional important topics:

  1. Roadmap. At least a high-level view of further tasks (contests) to be done along with priorities + approximate timeline.

  2. API. How 3rd party tools like visualizers, IDE, etc can interact with the debugger.

  3. Additional materials. Implemented components / classes, algorithms or useful implementation details.

Reward Structure

1.    💎 20 000
2.    💎 15 000
3.    💎 10 000
4.    💎 7 000
5.    💎 5 000
6-10. 💎 1 000

Multi-stage Contest Notice

Please note that the results of this contest imply no restrictions on the further implementation contests, i.e. the final debugger specification for the next contest phase might be a mix and match of the design solutions provided by the competitors.

3 Likes
#2

I’m sorry I didn’t checked it on Friday but there are some points and sections missed, like:

  • Submission should be in form of PDF document. The reason of this is to avoid possibility to change the submission after the final contest date.

Voting

  • Jury members who vote in this contest must have a solid understanding of the technology. Those jurors who don’t, should not vote or choose “Abstain.”
  • Jurors 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 choose to abstain from voting if they feel unqualified to judge.
  • Jurors will provide feedback on your submissions.
  • The Jury will reject duplicate, sub-par, incomplete, or inappropriate submissions.

Jury rewards

An amount equal to 5% of the prize fund will be divided equitably between all jurors who vote and provide feedback based on their votes’ quantity and quality. Both voting and feedback are mandatory to collect this reward.

Procedural reminders to all contestants

  • 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 information . All submissions must contain the contestant’s contact information, preferably a Telegram username by which jurors can verify that the submission belongs to the individual who submitted it. If not, jurors may reject your submission.
  • Content . The content published in the forum and the provided PDF file should not differ, except for formatting. Otherwise, jurors may reject the submission.
  • Well-formed links . If your submission has links to the work performed, the content of those links must have the contestant’s contact details, preferably a Telegram username, so jurors can match it and verify whom the work belongs. If not, jurors may reject your submission.
  • Multiple submissions .
    • Each contestant has the right to provide several submissions if they contain different approaches to the contest problem’s solving. However, if works are not unique enough or differ just in insignificant details, jurors may reject such repeating submissions.
    • If the contestant wants to make an additional submission that overrides the one previously published, he must inform the Jury about this fact and indicate the correct revision to assess. In this case, only the indicated work will count. If the contestant hasn’t indicated the updated submission as the correct one, only the first one will count, the Jury will reject all the others.

Disclaimer

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