paint-brush
DAO Core Bases on Leo Smart Contractsby@encipher
356 reads
356 reads

DAO Core Bases on Leo Smart Contracts

by encipherJuly 19th, 2022
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

ZKP has been highlighted as an advanced way to enhance privacy in distributed ledgers. But the standardization of programming can facilitate the subsequent implementation of different projects. This is exactly what is needed in the management sector. Therefore, having studied Aleo Studio, I realized that I could simply describe and then programmers  easy can implement the DAO management system. Implementation doesn't have to be complicated.

Company Mentioned

Mention Thumbnail

Coins Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - DAO Core Bases on Leo Smart Contracts
encipher HackerNoon profile picture


Abstract

The whole world is closely following the development of technologies used in the blockchain sphere. Recently, ZKP has been highlighted as an advanced way to enhance privacy in distributed ledgers. However, ZKP protocols are still insufficiently studied in the context of blockchain technologies and, moreover, not standardized for use. Projects such as ALEO, Ethereum, ZCash, Mina, Aztec are doing a lot of protocol research and are interested in standardizing ZKP protocols for financial and government applications.


Recently, Ethereum creator talked about the “large and silent technological revolution” that has occurred due to the use of zero-knowledge proof protocol in the blockchain. This technology allows solving one of the most pressing problems facing the blockchain community, namely ensuring the confidentiality of transmitted data, when the details of the operation and the correctness of transactions must be confirmed by network participants. In particular, this problem prevents the widespread use of the blockchain by corporations and states.


Researching the possibilities of Aleo and the LEO programming language, I made several important conclusions. The most important conclusion is that the standardization of programming can facilitate the subsequent implementation of different projects. This is exactly what is needed in the management sector. Therefore, having studied Aleo Studio, I realized that I could simply describe and then programmers  easy can implement the DAO management system. Implementation doesn't have to be complicated.


1. Specification of Voting on the essence of proposals.

  • Registration in INTERFACE, obtaining an address for voting.


  • There must be at least 500 tokens on the address (this is the number under discussion = “Mmin”) - it is assumed that active users either have them for a long time and keep them in their wallets, or in life have a sufficiently qualified job to afford to buy 500 tokens.


  • A smart contract (hereinafter referred to as SC), for a certain time, depending on the "type of voting", must check randomly once a day for the presence of tokens on the wallet so that a person cannot move tokens to activate other wallets.


  • For the current year, in order to quickly retrieve data, the SC keeps lists of addresses, and the days on which the amount on the address was more than “Mmin” - a database of snapshots.


  • At the moment when it is necessary to start voting, all candidates who meet the conditions are notified in the INTERFACE of their acceptance or rejection of voting.

    The SC, after drawing up a list of judges, randomly gives each judge an equal number of comparisons of two works from the set.


  • Since the SC randomly gives out pairs for comparisons, it makes no sense to make multi-accounts, since it is not known to whom and what task will fall for evaluation / comparison.


  • All the time since the creation of the DAO, the SC accidentally checks the number of tokens on the judges' wallets, thereby creating obstacles to moving and creating multi-accounts.


  • The SC takes information about the so-called "locked funds" or "snapshots" from the blockchain for a certain amount of time ago.


  • Depending on the type of voting, the size of the “voting stake” may be increased.


User categories and where they can participate:


Category

Prerequisites by retention time tokens at the address./ days ago before start submitting a proposal

The necessary conditions in count withheld tokens at the addressMmin

Options in which can participate address(user)

1

period (from 14 to 7)

500

Submission of any proposal Judging the competition essence

2

period (from 60 to 30)

1000

Refereeingpartnership proposals,or competition approvalor creating a subgroupor appeal the decision including options cat.1

3

period (from 90 to 30)

1000

Choice of judges, including options cat. 1,2

4

period (from 365 to 5)

10000

Change configuration networks including options cat. 1,2,3

Table 1


Thus, these funds can:

  1. Participate in staking, bringing profit to your owners
  2. Stimulate the growth of the token by limiting circulation on exchanges
  3. To identify the most loyal and dedicated community members to the project
  4. Encourage communities to preserve and accumulate for subsequent participation in life project, expanding the ecosystem and the ability to use additional funds (rewards) from staking in real life.


2. Mathematical model of voting for SС


n - Number of judges

m - Number of jobs

k - Number of comparisons in total

x - the number of works (proposals), which is given for evaluation to each of the judges

(or " y " if " x " is not an integer, or " z " for the last member of the jury)


The total number of comparisons can be calculated using the formula:

k_m^2=m!/((m-2)!*2)


The number of works (proposals) that will be provided to each judge is calculated by formula:

x=k/n

If "x" is an integer, then we take it unchanged, if "x" is not an integer, then we use "y" which is === (x + 1)== - for the number of judges equal to: n-1

the remainder for the last judge will be: z = k- (y * (n-1))


All judges will be given a choice in the interface, where the two will be compared work, and you only need to choose one. Thus, one of the works is recognized as the best and gets "+". And so on until the judge makes all comparisons ( x or y or z )


After the voting, the "+" marks are summed up (superiority indicator) for each work. In fact, this number can be represented as a number of points. "+" = 1 point

So, with such a system, all possible comparisons will be made “each with everyone“.


With a sufficient number of judges and submissions, the same score is unlikely.


In case of the same score, round 2 begins.

All judges "n" are sent exactly the same pairs for comparison, only from works with

the same estimates. The distribution of work follows the same principle as

presented above.

Further, the calculation of points and the distribution of tokens.

This procedure will be needed only in case of a dispute over prize places, the number of which will initially be recorded in the SC.




3. Submission of an offer

The feed will take place in the Interface.

Any (see table. 1) for a certain number of tokens "F" can supply sentence.

"F" will be frozen pending a positive or negative decision on proposal.

"F" will differ depending on the category of the offer.


Offer categories.

The system of rewards and penalties for submitting an offer.


Suggestion about:

«F»

Accepted

NOT Accepted

1

Competition

100

х10

х0

2

PartnershipsCreation of subgroupAppealing the decision

700

х2

х0

3

Election of judges

1000

х1,5

х0

4

Changing parameters networks

10000

х1,5

х0

table 2


Voting for proposals of categories 1 and 3 takes place in 2 stages:

  1. Approval or rejection of the proposal, token reservation. (Vote for approval can only certain categories) (see table. 1).
  2. Voting in essence (see point 2). (for work in the competition, for the candidates of the jury, decisions on the merits)

Voting for proposals of categories 2 and 4 proceeds directly to stage 2. The interface will offer an "accept" or "not accept" button, 51% is required from all voters to make a decision, otherwise the proposal will be rejected


For each competition, authors can indicate in the submission form how the refereeing

  1. usually for the system from table 1.
  2. closed, consisting of members of a certain subgroup, for an exclusive professional assessment.


4. Reward system


A system of awards and penalties will apply to all judges.

At the time of submission of his candidacy, funds in the amount of " Mmin " ( see paragraph 1) freeze and subsequently increase or decrease depending on the quality of the work done.


The coefficient "r", which shows the efficiency of the judge's work, calculates the SC:


"q" is the number of comparisons made by each individual judge.


r = (q / x or q / y or q / z ) , the performance of the judge for each specific case.


w - Coefficient by which  " Mmin " is multiplied to obtain the final payment for

refereeing.


The system of awards and punishments for judges.

«r»

«w»

1

x1.5

0,9

x1.4

0,8

x1.2

0,7

x1.1

0,6

x1.0

0,5

x0.9

0,4

x0.7

0,3

x0.5

0,2

x0.3

0,1

x0.1

0

х0

Table 3


To improve the quality of the comparison evaluation at the time of the proposal creation, the author can indicate the time that will be given to view the offer, or rather it

the minimum number before voting can begin, a kind of "freezeime". This will improve the quality of the evaluation of the work or proposal and not will allow thoughtless scrolling. The timer will count down only when the screen is on, if there is a lot of time to evaluate technically complex works, then a window will appear to stop the timer to make sure the referee is present and his involvement in the voting process. Naturally, this "time" will be selected in the process of discussing the proposal, and will be adequate to each task.


Combined with limited time for the entire voting, tasks for comparison of works or task for consideration of proposals will be evenly distributed in a time interval, not allowing to speed up too much or vice versa delay the voting process.


5. Calculation and distribution of tokens.


SC distributes automatically all funds according to the data specified in the form, which the author contributes. He can schedule rewards for each place or indicate automatic distribution from 0 to 100% to all locations.

The budget can be requested from the grant program or from the fund collected by ordinary users. SC will calculate the amount of tokens by itself necessary for remuneration and to cover commissions,

The data for the calculation will consist of:

  1. Data on the desired remuneration from the submission form

  2. Coefficient "R", which shows the efficiency of the work of judges

  3. The size of the commissions spent on the work of the SC

  4. Remuneration of the author for accepting his proposal.


It will also be possible to set part or all of the proposal (competition) budget from its own funds. All the above expenses will be debited from a certain wallet, and this amount freezes at the moment acceptance of the proposal.



Conclusion

Summing up, we can say that the use of ZKP protocols goes well with the blockchain, such an alliance will increase the privacy of users and at the same time create trust in the data used, since the blockchain guarantees the immutability of the information written to it. The attention of the regulator to this technology suggests that more and more players are interested in this solution and in the future we may see many new projects using ZKP, for example, a system for managing corporations or states that I tried to describe in this article.