(Edition 3. Changes were made in accordance with the meetup’s decisions dated 04 Feb 2021)
General description
This document suggests an implementation of on-chain sub-governance for Free TON Dev Experience as a separate interface with all the functions that the main Free TON governance has, based on freeton.org/contests as an additional bookmark.
The mission of Free TON Dev Experience governance is to develop the Free TON services, tools, and software for developers with the goal of enhancing the Free TON ecosystem and making Free TON more attractive for software developers.
Sub-governance proposal specification
It is proposed to create on-chain sub-governance integration for Free TON Dev Experience within which the following will be available:
-
Free TON Dev Experience Initial Members are to form the initial Free TON Dev Experience Jury.
-
The initial Free TON Dev Experience Jury is:
- to run the Free TON Dev Experience Jury Contest to choose the Free TON Dev Experience Jury to be active until 15th February 2021.The description of the contest is given below.
-
The Free TON Dev Experience Jury has the the following characteristics:
- the max number of members is 15, the min number is 5;
- the jurors are split into topic-based Free TON Dev Experience Jury groups (a juror can
be a member of several groups); - the topic-based Free TON Dev Experience Jury groups have to consists of at least 3 members;
- the topic-based Free TON Dev Experience Jury groups make decisions on the relevant thematic proposals, including their review, and judge the relevant thematic contests;
- the decisions within the Free TON Dev Experience Jury groups are to be taken by 50% + 1 vote from a number of jurors within a group;
- the decisions within the Free TON Dev Experience Jury are to be taken by 50% + 1 vote from a number of jurors.
-
The Free TON Dev Experience Jury has to ensure:
- smooth running of the Free TON Dev Experience governance;
- running of Contests;
- development of Contest Proposals (CP);
- review of CPs;
- assessment of submissions for Contests;
- choosing the winners of the Contests;
- distribution of funds to everybody involved in the Free TON Dev Experience governance.
-
The Free TON Dev Experience Jury members can’t judge the submissions from themselves, organisations they belong to/companies they work for. It’s the responsibility of the Free TON Dev Experience Jury members to declare the affiliation and withdraw from assessment. The Free TON Dev Experience Jury members have to participate in the activities of the Free TON Dev Experience governance on a regular basis. The Free TON Dev Experience Jury makes decisions on dismissal of the jurors based on their inability to fulfil their responsibilities.
-
Any Free TON Dev Experience Jury member can join the Free TON Dev Experience Org. The Free TON Dev Experience Org has to assume the responsibilities for:
- development of CPs (including attracting any qualified third-party to draft the CPs);
- administrative work such as running of Contests, including announcing Contests, inviting developers to apply for Contests, consulting developers, announcing results of Contests, reminding winners about submission deadlines, consulting jurors, ensuring the timely payouts to the winners, jurors, etc.
-
The Contests that are to be run by Free TON Dev Experience governance have the following characteristics:
- to be on the topics mentioned below;
- could be multistaged with the limited access to the 2, 3, N stage for the winners from earlier stages;
- to be launched by accepting CPs by Free TON Dev Experience Jury groups;
- can be running in parallel;
- to set the remuneration criteria for the participants, the winners, and the jurors on case basis.
-
Submissions assessment
-
Quorum
-
Assessing the submissions is considered legitimate if at least 50 % + 1 of jurors have cast their votes, be it “Accept”, “Reject” or “Abstain”, to the submission with the least number of votes.
Example. If a group consists of 9 jurors, then at least 5 of them must assess the submissions. -
If the number of jurors who have voted “Accept” or “Reject” (altogether) will not exceed 3 (three), the contest submissions assessment is not considered legitimate and must be repeated from scratch.
-
-
Scale. Juror of each group must assess a submission on a scale of 1 to 10 (10 is the highest score, 1 is the lowest score) or vote as “abstain” or “reject”.
-
The “abstain” vote means that a juror is not qualified or eligible to assess the submission. Such a vote is not taken into account when a rating score is calculated.
Example. If a submission was assessed by 3 jurors as follows: “10, 2, abstain”, then the resulting score will be equal to (10 + 2) / 2 = 6. -
The “reject” vote means that a submission does not meet at least one of the contest conditions. “Reject” is not related to a score, but is taken into account when calculating a rating of the submission.
Example. If a submission was assessed as follows: “3, 3, reject” then its resulting score will be equal to (3 + 3) / 3 = 2. -
If a number of “reject” is at least 50 % + 1 of a total number of voted jurors, then the submission cannot be qualified for a prize.
Example 1. If a submission was assessed as follows: “6, abstain, reject, reject”, the resulting score will be equal to 6 / 3 = 2. -
If a juror considers that submission is useless, although it meets contest requirements, he/she must notify its author and clearly state in review a reason for low rating.
-
Any conflict situation that occurs when calculating a resulting submission score should be resolved at DevEx weekly call.
-
These statements can be clarified in relation to a specific contest.
- Regulation on signing a multi-signature transaction
- Only the initial group can sign a multi-signature transaction for awarding the winners, jurors and organizers of a contest.
- Signing a multi-signature transaction is a responsibility of each initial group member.
- If anyone refuses to sign a transaction, then he/she is obliged to notify other initial group members about it. Otherwise, this member will be considered inactive.
- Conflict resolution
Questions on conflict situations should be discussed at the weekly call.
Jury rewards
Jurors are rewarded for assessing the contest submissions.
By default, the amount of funds allocated for each jury group should be 5 % of the total amount actually paid to winners (not from the amount originally stated in a contest). Amount of funds allocated to a juror is calculated by the following formula:
Components of the formula:
— amount of funds allocated to i -juror;
— average cost of assessing one submission;
— number of submissions assessed by i -juror (minus “abstain”).
Average cost of assessing one submission is calculated by the following formula:
Components of the formula:
— amount of funds allocated to jurors;
— total number of ratings (minus “abstain”) given by all jurors who voted. It is calculated by the following formula:
Components of the formula:
— number of jurors who rated contest;
— number of contest submissions;
— total number of “abstain” votes of all the jurors.
The more jurors participate in assessment of works, the more correctly winners are determined. An increase in the number of jurors leads to a decrease in i -juror’s award, since the total amount of funds allocated for assessing submissions is fixed.
Free TON Dev Experience Initial Group Members
You can find the current list of Free TON Dev Experience Initial Group Members on this page:
Free TON Dev Experience Jury Members
You can find the current list of Free TON Dev Experience Jury Members on this page:
Contest specification
The contest specification should be described in a common English language and should contain at least the following sections:
- Abstract - a short summary of the specification including the objective of the contest and desired results
- Dates of submissions acceptance and voting
- General contest requirements - what key elements we expect to see in a submission and which criteria the work should meet
- Evaluation criteria and winning conditions
- Winners’ reward: mechanics, prize places, and amounts
- Jury rewards
- Initial group rewards
- Procedural remarks for contestants
- Procedural remarks for jurors
Some parts of the specification are described in this document and should be referenced accordingly in the contest specification, e.g.: “As per Procedural remarks on contests”.
Free TON Dev Experience Costs Estimate
This estimate is based on a forecast of the total Tons required to run up to 9 (nine) Free TON Dev Experience Contests until 15th February 2021 after the Free TON Dev Experience Subgovernance is launched .
Topics of the Contests
The topics of the nearest Contests mentioned according to their priority.
SDK Contests
- Bindings for TON Client library (proposal)
- Proofs - library that provides functions to proof account, message, transactions so that developers can use them to prove that the specified object is valid. Library should retrieve all the necessary data for proofs from GraphQL API.
- TON OS DApp Server Bug Bounty Contest
- Web3-like wrapper over ton-client-js + migration instructions for developers, so that Ethereum developers can migrate their applications from Ethereum to TON or develop DApps from scratch in a familiar way.
- Graphql API bug bounty contest - validate API
- Object/business oriented bindings contest - write handy high-level libraries that will use low level bindings
- Service that provides access to parsed contracts data (including ABI-compatible and other contracts) and parsed messages data and allows data searching and data aggregating
- Analytics services - service that collects blockchain data from GraphQL API and provides different analytics
Toolchain Contests
- Transaction debugger:
- UI
- representation: In order to debug transaction step-by-step, we need to extract instruction sequence for its compute phase and present it in human-readable form.
- format: [No] [Opcode] {args]
-
Option 1 (preferable): obtain from the VM trace stashed at execution.
Option 2 (fallback): use assembly code from the contract compilation.
Requirements: standalone. repeatable. console. batch mode processing. Use annotations provided by other Experience, if available: gas consumption, account state change. -
Disassembler:
Standalone CLI utility to translate TVM bytecode to TVM assembly. Requirements: standalone. repeatable. console. batch mode processing. Support multiple levels: function, file. Should keep symmetry with TON disassembler when used for the same scope. APIs for sub-file level translation. Store results in file or in memory. tests, help, usage docs, API reference. Special modes to operate on TON objects associated with TVM execution, e.g. transactions. -
Assembler:
Standalone CLI utility to translate TVM assembly to TVM bytecode.
Requirements: standalone. repeatable. console. batch mode processing. Support multiple levels: function, file, multiple translation units. Store results in file or in memory. API for sub-file scope calls. Tests, help, usage docs, API reference. - Static analyser
-
IDE
An easy to use on-line IDE for creating, deploying and debugging TON Smart Contracts and DeBots in Solidity, C or C++.
Node Contests
Decentralized RTDB for Dapp Server (extremely important).
Research is needed may be use:
Based upon:
- https://hypercore-protocol.org/
- GitHub - hypercore-protocol/hypercore: Hypercore is a secure, distributed append-only log.
Requirements:
- Sparse replication. Only download the data you are interested in.
- Realtime. Get the latest updates to the log fast and securely.
- Performant. Uses a simple flat file structure to maximize I/O performance.
- Secure. Uses signed merkle trees to verify log integrity in real time.
- Browser support. Simply pick a storage provider (like random-access-memory) that works in the browser
Design the following protocols and solutions is needed:
- Research and develop workchain based solution architecture
- Search
- Interaction with Smart Contract which implements application business logic
Economics:
- Designing incentive for validator storage and distribution of data replicas
- Should tackle data availability problem
- Support incentive for p2p interactive sessions (containers)
Smart Contracts
Formally verified smart contracts libraries to be served as building blocks for different applications:
- Formal verification of
- TIP-3 Distributed Tokens (fungible, non-fungible and UTXO)
- Multi Ballot SMV contract
- Design and Implementation of
- Auth/Login/Signup user Identity
- Tracking, digital asset life-cycle management
- Loyalty and gamification mechanics
Other topics
- Workchain support — add support for additional workchains (1, 2, n…).
- Blockchain visualization (example: https://graphviz.org/Gallery/undirected/networkmap_twopi.html 1).
- Writing docs and tutorials: smart contract development, debots, dapps, sdk usage.