Free TON Governance 2.0: An Overview Of The Second Part Of The Contest. From Abstractions To Specifics
The work of the RSquad team, which submitted a solution for the second part of the Free TON Governance Contest, was the only one on the list of participants, but this alone did not guarantee victory.
As a reminder, the team was already the winner in the first part of the contest, submitting a detailed scheme for the bids to be made and approved by a soft majority vote (SMV).
The contest for the development of the platform for Governance 2.0 was held in two stages. The first concerned the smart contract system for soft majority voting in decentralized governance. In the second part of the contest, participants were required to develop a system for organizing the work of the jury and all stages of judging.
So, despite the lack of competition, RSquad’s victory is well-deserved. Judging by the comments, the members of the jury carefully studied the content of the work before giving it a score — a high 8.87 points.
The RSquad development team received 300,000 TON Crystal for first place.
As one of the judges commented: “The work was done at a high technical level. Almost all the requirements of the competition were met. Hopefully the system you have developed will become a solid foundation for Gov2.0”.
Review And Features Of The Contest Work
In its work, RSquad presented a detailed description and visual solution of the full cycle of contests based on smart contracts.
The developed system provides for automation of the decentralized governance of the Free TON community through voting.
The main use case scenario shown in the scheme begins with the submission of an application and ends with transferring a portion of the received reward to the DePool.
Purpose Of The Main Smart Contracts In The System
- Contest smart contract — collects contest entries, records the jury’s evaluations, evaluates judging in accordance with the contest regulations, calculates rewards for contestants and jurors, and distributes rewards to the winners.
- JurorContract smart contract — is deployed by the Demiurge smart contract for each member of the jury. With it, a judge can vote with a hidden vote, reveal their votes, and manage their balance in the JuryGroup.
- JuryGroup smart contract — provides information on the jury members, allows the Demiurge to collect the jury of the contest by tags.
- ContestGiver smart contract — developed to give prize pool to the contest.
- Demiurge Smart Contract — is the main entry point to the system, deployed first.
- ContestDebot smart contract — allows you to view information about the Contest, submit applications and vote for them using JurorContract.
Scenario
The scenario can be divided into 6 parts:
Application submission
Contest deployment
Work acceptance
Voting
Results revealing
Reward distribution
Application Submission
Once the system is deployed, the user creates proposals for the contest through the system’s central smart contract. The process is standard and runs according to the selection algorithm described by Mitja Goroshevsky.
Demiurge smart contract receives information about the contest parameters: duration, tags, prize pool, etc. The user then follows the “Proposal Creation Scenarios” and the “Base Voting Scenarios” to accept the ContestProposal.
The formula given in the work describes a majority vote, a soft majority vote, or a super majority vote, where y = votes For, n = votes Against, t = total number of votes.
Deployment
If approved, the contest is automatically deployed. Smart contract selects jurors by tags, namely: by contacting those judges in the JuryGroups whose tags match those attached to the contest. As the developers explain, all the judges are selected by their tags and their stakes are reviewed. The top 90% (by stake size) of all potential jurors, but at least 5 people, are selected. If there are enough candidates, then the actual jurors for the current contest are randomly selected from them.
“Why 90%? So that you can not put one coin and pass in the jury.”
In parallel, there is a request for the prize pool.
Work Acceptance
Once the contest receives the jury list and prize pool, it automatically begins accepting submissions.
Voting
Once the acceptance stage is complete, the system calculates a voting period that depends on the number of submissions received and proceeds to the voting stage. During the voting phase, all judges involved through tags send their votes through a personal JurorContract. A vote consists of a voting hash and chacha20-encoded voting text. If previously a jury would come in and just sign their message, now each jury has its own special contract.
If previously a jury would come in and just sign their message, now each jury has its own special contract.
Results Revealing
After the completion of the voting stage, the reveal stage begins, which lasts one day. Only at the reveal stage, the results of the vote become visible, including to the other members of the jury.
How does reveal work?
The JurorContract of each of the judges sends a revealed vote. The contract will take the hash and compare it with the original hash. If they converge, the vote will be registered.
Why would judges send a chacha20 encrypted vote?
According to the creators of the system, this is done solely for the purpose of convenience. The contract does not have any crypto functions. The vote is encrypted so that the person does not have to remember his long comment, which will be revealed at the reveal stage. After all, the text of the commentary must be saved somewhere or every comment must be written down on paper. Because at the reveal stage, everything has to match — right down to every letter and dot. And if a judge has 100 submissions pending, it’s not that easy to do.
The developers suggest an original approach: send an encrypted vote to the system, and when a person uses the interface or DeBot to reveal his voice, he simply downloads this encrypted vote, enters his password and the DeBot or interface will decrypt his vote and send an already decrypted one. He will only need to remember the password. By the way, the password can be the same for all votes and comments from the same jury member.
All jury members who do not reveal their votes at the reveal stage will not be counted in the final tally.
Reward Distribution
After the reveal stage, the system calculates the number of points and makes reward tables. If earlier the prize places were locked now, the prize is formed from the number of received points multiplied by the value of the vote, which is counted from the number of submissions, the size of the contest and other criteria.
At this stage, participants are rewarded and can stake a piece for participation in new contests as part of the jury. The participant will select the tags (only attached to the contest), which will be used in the further search of the jury.
Once the funds are reserved (locked), the system calls the Demiurge contract. The demiurge checks whether the participant has a personal JurorContract, creates it if necessary, and transfers funds there.
Similarly, the Demiurge contract registers new participants in the JuryGroups by tags. If JuryGroup does not exist, Demiurge will deploy it. Next, the JuryGroup moves on to communicating with the DePool. Thus, the complete cycle of the scenario is closed.
Demiurge Transformation
The concept of the Demiurge smart contract has changed a lot since its presentation in the paper for the first part of the contest. The Demiurge mechanism allows you to create contest proposals. Helps members of the system communicate with each other.
The demiurge is present at two points in the system — at the time of submission of the contest proposal and at the time of registration of new members of the jury.
A new level of system development
According to RSquad participants, the second part of the contest was much more difficult than the first, as the amount of working design increased, and the amount of advice the team requested and received from active members of the DGO sub-governance increased.
An additional challenge was to adjust the SMV system developed for the first part of the contest to current tasks.
Why refine the SMV system?
In between the stages of the contest, the DeBots changed at the engine level — switched from actions to interfaces. And the development team had to rewrite the old DeBots on the new engine.
The program came out monolithic. Now the RSquad team has the task to make it modular.
The BFTG will be further refined. In particular, the concept of price pool should become a thing of the past. Previously, when the contest was created, the total amount allocated for the contest was specified based on which the cost per point was calculated. In the long run, the general price pool will disappear. The amount will be displayed depending on the number of submissions and the duration of the contest.
From Abstractions To Implementation
At the time of the contest, many of the processes regarding the voting cycle, staking, and price provider existed at the level of abstraction. And the contest requirements assumed the development of a system in which these abstract concepts would be implemented technically. That is, in the design and implementation, the developers systematically reduced the level of abstraction.
Changing the level of abstraction is not a challenge, but part of the normal development process.
In order to fill descriptions with mechanics, the RSquad team developed in their work new smart contracts and mechanisms for interaction between participants and the jury with DePools.
======================================
The system developed during the contest is extremely large. The team had to apply all their knowledge gained during their work with Free TON, from writing simple contracts to DePool, TIP-3 and DeBot.
The total source code size of the contracts is close to 200 KB, over 20 contracts, and the same number of interfaces has been developed. It is worth noting that this is one of the largest systems developed in the Free TON network.
In the near future, the RSquad team plans to continue working on improving the system according to the published roadmap of DGO projects. In the future, the system will be consistently implemented as part of the Governance 2.0 implementation.
