Free TON

Developers Contest: Soft Majority Voting system

Stage I

Short description

TON Improvement Proposal (or TIP) for Soft Majority Voting contracts specification

Type

Contest

Dates

18.05.2020 - 01.06.2020

Motivation

We need a system of voting contracts to regulate governance and decision making in Free TON. This contract is a principal tool of decentralization. It is supposed to be used in many aspects of Free TON blockchain to provide mechanism for community governance.

As such it should meet the following requirements:

Transparency — everyone in the community should be able to verify the results of the Voting, review proposal and links to its description and how results are implemented.

Participation — the voting should work even in case of low participation by the community members

Ease of use — every community member should be able to participate even without a deep technical knowledge

Security — the highest level of security should apply

Flexibility — it should be flexible enough to serve many applications requiring voting mechanism in Free TON

General requirements:

Participants should provide a technical description — a TON Improvement Proposal (or TIP) for design and implementation of the Soft Majority Voting contracts

The description should be in clear technical language and sufficiently easy to understand

No off-chain mechanisms are necessary to describe at this stage (for instance how roles of proposer Initiator and Voters are obtaining their roles’ authentication off chain)

Contest Participants may use TIP-3 Distributed Token proposal, whole or in parts, for their inspiration.

Terms:

  • A Proposal should provide a clear technical specifications of a Smart Contract (or a system of smart-contracts) implementing Soft Majority Voting (SMV) algorithm
  • A Voting Proposal has exactly two possible options: “Yes” and “No” (or “For” and “Against”)
  • There should be at least two different SMV participant roles: Voting Creator ( initiator ) and a Voter ( voter ).
  • Anyone should be able to deploy SMV and to set up roles of Creator and Voter and should provide a possibility to authentication mechanism which proves a user possession of such role.
  • An initiator should be able to call createProposal function of an SMV contract passing parameters of a new Voting proposal. SMV should be able to check that the initiator indeed has a right to create such a Voting.
  • Voting Proposal Parameters should include at least: the Voting Proposal ID, start and finish time of the Voting, total number of participants and a string of Voting Proposal description (for which the Vote is calculated).
  • SMV contract should have a vote function, with which the Votes are received from other smart contracts with a voter role. SMV smart contract should ensure that a voter smart contract indeed has voting rights.
  • Voting smart-contract should not be able to vote more than once for the same proposal.
  • Calling vote function may result in a termination of a voting right of the voter after passing this vote .
  • Initiating a proposal may result in a termination of an ability to initiate any more Voting Proposals by the current initiator in the current SMV smart contract.
  • SMV Contract or any other contract in the system should not store voting participants ledger but only a counter of a unique “YES” and “NO” votes.
  • There should be a possibility to create a rule for distribution of Voting rights.
  • At the end of Proposal time SMV contract should notify a network about Voting results (for example by generating a outbound external message).
  • SMV contract could be reused for other Proposals and even may hold Voting for other proposals in parallel (but that is not mandatory).

SMV Algorithm

Soft majority voting (SMV) — a transparent voting process with due announcement and timing before deadline. If members don’t have an opinion and reluctant to vote it is assumed that they are neutral. Instead of making an attempt to force everyone to vote for every decision SMV allows decisions by those who care. The metric for passing a decision is the difference between % of Yes minus % of No. For example, if 10% of voters said Yes and no one said NO, then we it is assumed the decision is sufficiently supported and there are no objections. At the same time if all members voted than a simple majority rule applies — 50%+1 vote for a decision. When we connect those two dots on a graph with % of Yes and % of No axes we get a “soft” simple majority threshold line. For important decisions like amendment of constitutional community documents, we can draw a “soft” super-majority threshold line (please see Diagram below). Soft majority voting mechanism will be programmed on Free TON via an SMV Smart Contract.

Evaluation criteria and Winning conditions:

Proposals will be judged strictly on the merit of correctly addressing all Requirements and Terms.

Every participant that has got at least one jury vote will receive 1000 TONs.

The 3 winners TIP (the one that got most Jury Votes based) will receive 30000 TONs.

All proposals will receive jury comments.

Anyone will be able to compete for Stage II of the contest — to program SMV smart contract based on the winning TIP.

The Jury

Each of the Initial Validators will have a right to nominate 1 person to the jury.

Initial Validators whose teams are willing to participate in the Contest will loose their right to nominate a jury.

The jury membership will be public.

The Jury will provide feedback for all proposals

Jury members​ who vote will recieve 500 Tons each for doing their civic duty

9 Likes
3 Likes

Summary

The proposal for Soft Majority Voting system.

Abstract

Soft Majority Voting system is proposed using two smart contracts types. Creating proposals, voting, adding/revoking rights is possible. Multiple voting are possible at the same time.

Motivation

We need a system of voting contracts to regulate governance and decision making in Free TON. This contract is a principal tool of decentralization. It is supposed to be used in many aspects of Free TON blockchain to provide mechanism for community governance.

Glossary

PK - publick key

SK - secret(private) key

Voting System Owner - somebody who deploloyed SMV and thus can add/remove participants.

Voting Participant - Voting Initiator or Voter. Anyone who participate in voting in some way.

Voting Master Contract - smart contract used to create participants.

Voting Participant Contract - smart contract used by

Participant to initiate voting or vote.

Workflows

Roles are implemented by giving particular role to Participant.
Voting Creator role is implemented by granting initiator right to Participant.
Voter role is implemented by granting vote right to Participant. This approach allows simple adding of other roles e.g initiatorOnce - Participant can initiate voting only once.
Participant can be Creator and Voter at the same time.
Rights of each participant are stored in its VPC. They can be changed during voting. However revoking initiator right does not stop currently active voting.
Revoking voting right may revoke votes of this participant in currently active votings. To implement this VPC.withdrawVote function is added.

General

This is the main workflow. It should work most of the times.

  1. VSO deploys VMC to Free TON blockchain using keypair (masterPk, masterSk). Each VMC MUST have unique masterPk.

  2. Participant is deployeds. (VMC.addParticipant or manually) Participant deployment is done in two steps:

    2.1 VPC contract is created using its code, participantPk, Signature(participantPk, masterSk) and no right.

    2.2 VMC grants rights to VPC. Spliting in two steps allows to make VPC address not dependent on initial rights.

  3. Participant(initiator) create new proposal (VPC.createProposal)

  4. Participants(voters) vote for proposal

  5. When time is expired notify the network

  6. Repeat steps 3-5 for voting if needed. Note: multiple voting may be done in parallel if set of participants is the same.

Change rights

Contracts

Voting Master Contract(VMC) - manages proposals, add/remove participants, change participant rights.

Voting Participant Contract(VPC) - manages participant. Check if participant has sufficient rights, …

Modifiers

onlyOwner - function should receive only external messages signed by owner. (For VMC signed by masterSk, for VPC signed by participantSk)

onlyMaster - function should receive only internal messages from corresponding VMC. (message sender address should be equal to stored address). Applicable only to VPC functions.

onlyParticipant - function should receive only internal messages from corresponding VPC. (message sender address should be equal to calculated address from VPC code, participantPk, Signature(participantPk, masterSk)). Applicable only to VMC functions.

Voting Participant Contract(VPC):

Responsible for saving participant related data.

Should store:

Rights rights - what this participant can do

bool wasRightsGranted - should store if some rigthts were explicitly granted. Is used by receiveInitialRights function.

uint256 vmcAddress - address of corresponding VMC

uint256 participantPk - participant public key

uint512 participantSig - signature of participantPk by masterSk. It should be normalised signature.

map(uint256 => YesOrNo) votes - votes of this participant for different proposals. Actual vote is saved to make it possible to withdraw vote.

VPC.createProposal


createProposal(

    uint256 proposalID,

    bytes proposalDescriptionHash,

    uint32 startVotingTime,

    uint32 endVotingTime

) onlyOwner

MUST check that sender has valid PK.

MUST check that sender has an initiator right.

MUST check that endVotingTime is in future.

After successful validation MUST call VMC.createProposal()

If some checks fail MUST fail operation.

VPC.vote


vote(

    uint256 proposalID,

    VotingResult result

) onlyOwner

MUST check that sender has a valid PK.

MUST check that sender has a voter right.

MUST check that no votes for this proposalID was done previosly.

After succesfull validation should call VMC.vote()

If some checks fail MUST fail operation.

VPC.changeRights


struct Rights {

    bool canVote,

    bool canInitiate

}

changeRights(

    Rights rights

) onlyMaster

MUST check sender address is correct.

If some checks fail MUST fail operation.

If voting right is revoked than it SHOULD withdraw votes for active proposals using VMC.withdraw().

VPC.receiveInitialRights


receiveInitialRights(

    Rights rights,

    uint512 signature

) onlyParticipant

Set initial rights. Can be called only once. signature must contain signature of rights by masterPk

VPC.getRights


getRights() onlyOwner

Voting Master Contract (VMC)

Responsible for storing general data.

Should store:

uint256 masterPk - public key of VSO

TvmCell vpcCode - code of VPC

map(proposalId => Voting)- all votings. Voting should include proposalId,
startTime, endTime, yesVotes, noVotes

VMC.createProposal


createProposal(

    uint256 proposalID,

    bytes proposalDescriptionHash,

    uint32 startVotingTime,

    uint32 endVotingTime,

    uint256 participantPk,

    uint512 signature // Signature(participantPk, masterSk)

) onlyParticipant

MUST check sender is valid participant contract:

  • sender MUST have correct address (calculated from its code and participantPk, signature)

  • signature MUST be valid

  • signature MUST be normalized

proposalID MUST be unique (there must be no proposals with the same proposalID)

endVotingTime SHOULD be in the future

If some checks fail MUST fail operation.

VMC.vote


vote(

    uint256 proposalID,

    VotingResult result,

    uint256 participantPk,

    uint512 signature // Signature(participantPk, masterSk)

) onlyParticipant

MUST check sender is valid participant contract:

  • sender MUST have correct address (calculated from its code and participantPk, signature)

  • signature MUST be valid

  • signature MUST be normalized

proposal startVotingTime MUST be in the past

proposal endVotingTime MUST be in the future

If some checks fail MUST fail operation. Otherwise MUST update voting numbers for proposal.

VMC.withdrawVote


withdrawVote(

    uint256 proposalID,

    VotingResult result,

    uint256 participantPk,

    uint512 signature // Signature(participantPk, masterSk)

) onlyParticipant

It is used only to withdraw votes when changing rights.

Rationale

  1. Current scheme is most suitable when a given set of participants do multiple votings.

  2. The current scheme is not fully anonymous.

  3. The current scheme does not allow updating VPC code because its code is used to obtain a VPC address. This could be mitigated by storing addresses of participant’s contracts in VMC.

  4. The current scheme requires using ‘normalized’ signatures(approach when the signature is deterministically generated RFC6979 https://tools.ietf.org/html/rfc6979). It ensures that one participantPk corresponds to one VPC. Because different signature generates different VPC address. This is very similar to Bitcoin Signature Malleability.

    4.1 For every ECDSA signature (r,s), the signature (r, -s (mod N)) is a valid signature of the same message. Thus VMC should check that signature has s > 0. Otherwise, the Participant may create one more VPC contract and thus vote twice.

    4.2 For a given participantPk and masterSk VSO can generate multiple signatures. It is impossible to check that signature follows RFC6979(without knowing secret key). Thus VSO with bad intention can create multiple VPC (with the same participantPk) and forge voting. If VSO cannot be trusted than VMC should store addresses and public keys of VPC (same approach as in 3.).

  5. The current scheme allows multiple voting at the same time.

  6. It is possible to add a lot of participants which may or may not participate. Their pubkey are only needed. VSO signs their pubkeys, rights and sends to them. Participant deploys VPC and grant rights using receiveInitialRights.

2 Likes

SMV contract specification

Summary

Soft majority voting contract specification for Free Ton Community [2].

Status

This is an early draft and hence subject of further changes.

Abstract

Contract to support ton decision making processes.

Motivation

The system of voting contracts aims to regulate governance and carry decision making in Free TON.
It is a principal tool of decentralization and supposed to be used in many aspects of Free TON [2] blockchain [1] to provide a mechanism for community governance.

Architecture principles

  • Transparency — everyone in the community should be able to verify the results of the Voting,
    review proposal and links to its description and how results are implemented.
  • Participation — the voting should work even in case of low participation by the community members
  • Ease of use — every community member should be able to participate even without a deep technical knowledge
  • Security — the highest level of security should apply
  • Flexibility — it should be flexible enough to serve many applications requiring voting mechanism in Free TON

Voting procedure properties

Public verifiability

: election procedure is recorded in form of transactions and participating wallet internal states in ton network. As though everyone will be able to see the voting process,
and can verify the whole election’s outcome after the voting end time.

Individual verifiability

: each voter is able to verify individual voting procedure, e.g., whether her ballot has been cast and recorded successfully, counted in the final tally, etc.

Non-transparency of voting procedure during voting process

: During the voting phase it is not possible to derive information about current ballots outcome.

Double vote is not possible

: Voter will be able to vote only for one option and only once.

Pre-requirements and assumptions

This document covers the Soft Majority Voting Contract specification and supposed to be an TON Improvement Proposals (TIP) [2].
This documents addresses TON Developers and [Free TON] active community members.

This proposal based on prior works and provides adopted E-voting protocol for [TON BC]. See [4] and [5].

Off-chain procedures are not a subject of this specification.
Implementation should hence follow usual practices adopted in the [Free TON] community.
Implementation of Blind Signatures Verification based on elliptic curve cryptography should be audited from [Free TON] community.

Glossary

Voting Wallet Holder Role

: Holds the key pair for VW and governs the wallet life cycle.

Initiator Role

: [Free TON] participant that defines proposal and initiates voting procedure.

Voter Role

: [Free TON] participant eligible to vote for a particular proposal.

Inspector Role

: [Free TON] participant acting as independent party assuring voting consistency.

Wallet

: synonym to smart contract according to [1]

Soft Majority Voting Wallet (VW)

: Contract used to initiate new Soft Majority Voting Proposal Wallet (PW) and gather voting results after voting time frame ends.

Soft Majority Voting Proposal Wallet (PW)

: smart contract to collect the eligible Voter decisions regarding proposal subject.

Soft Majority Voting Proposal Inspector Wallet (IW)

: smart contract to support voting procedure during voting phase.

Soft Majority Proposal Audience

: [Free TON] members eligible for voting on particular proposal subject.

Soft Majority Proposal Audience Member Wallet (MW)

: smart contract created by the PW for each proposal audience member.

Bag of cells (BOC)

: Collection of cells according to the [7] 1.1 pp 2.

Description

Election procedure will be performed in sequence of steps as described in [5]:

  • Pre-Voting phase to setup the proposal and define proposal audience, initiator and inspectors roles. This Phase should end before voting start time.
  • Voting phase to collect votes and keep it secret. This phase begins at voting start time and ends at the voting end time.
  • Post-Voting phase to collect valid ballots, check possible complaints and publish the results as of [6] to the VW. This phase begins at the voting end time.

Pre-Voting

Voting Wallet will be initialized by composing from source code and initialized after transferring some funds to wallet account.
It will be used to initiate new proposals and link proposal subject to the particular PW.
Hence PW subject will be unique within the VW.
To prevent proposal pollution some minimal amount of funds will be required to call initiate request.
Existing VW can be reused for new proposal procedures.

Voting proposal will be initiated by calling VW createProposal method along with the proposal init parameters.
If the parameters are valid then new PW will be initialized and PW BOC will be returned to the initiator.
Initiator can not change the code and initial state of the wallet and will use BOC generated by the VW Wallet to initialize the PW.
Initiator supply enough funds for ‘initiate’ request to cover voting process network fees. See [7] 1.7 pp.27-28

Proposal inspector wallet will be initiated after corresponding PW will be created by using VW createProposalInspector and supplying inspector public key along with PW address.
VW checks the PW init parameters and validity of inspector public key and IW BOC will be returned to the inspector.

This validity prove is a subject of Free Ton community members consensus regarding the proposal subject verification protocol and is not a subject of this specification.

Inspector can not change the code and initial state of the wallet and will use BOC generated by the VW Wallet to initialize the IW.
Inspector supply some funds enough to cover proposal inspection process network fees. VW initiateInspector will fail if corresponded PW is not initialized.

Each proposal audience member will be associated with a public key according to [1].
Members should be added by initiator after PW initialization and before the voting start time.
Initiator add new members by calling ‘addMember’ method.
addMember method will fail if at least one defined IW is not initialized at call time.

addMember method returns BOC to create init MW message along with the corresponding MW address.
This BOC contains among others known voter public key used to prevent un-authorised voting.
Initiator should collect this information and distribute it to the Voters.
Distribution method is out of scope of this specification.

Voting

Vote process implies MW initialisation using the supplied BOC and composing ‘constructor’ message as in [7] 1.7.5 pp 28.
Constructor message contains prepared vote option as in [5] pp.7 signed with voter private key.
During the MW initialization constructor calls PW’s requestVoteSignature iff all following conditions are met:

  • voter can prove the owning private key by signing the voting option
  • voter initializes MW within voting time slot i.e start voting time < voting time <= end voting time

Successfully initialized MW state contains among others voting message as in [5] pp.7

MW initialisation ends with PW requestVoteSignature call. Call arguments contain initiator voting message.

PW requestVoteSignature checks vote message for existing pending or completed requests.
If this is the case voteSignature request will be silently discarded.
According to the public nature of [TON BC] signing should be performed off-chain.
PW exposes two methods to support this process:

  • collectPendingVoteSignatureRequests to get collection of valid pending requests
  • sendVoteSignature to send Vote Message signature back to the corresponded MW using MW’s ackInitiatorVoteRequest.

MW ackInitiatorVoteRequest method check validity of PW signature and save PW’s askMessage to the MW internal state.
Last action of ackInitiatorVoteRequest is preparing and calling requestVoteSignature for all proposed inspectors.

IW requestVoteSignature verifies vote message request in same matter as PW requestVoteSignature does.
Additionally IW calls PW’s isSigned method with the voting message argument to prove if message supplied is identical to the message used for PW requestVoteSignature call.
If it is not the case requestVoteSignature will be silently aborted and request - ignored.
Signing will be performed off-chain. IW uses same methods as PW to support this process.

IW and PW collect all pending and completed requests for verification procedure.

After all inspector requests are acknowledged by authorized parties off-chain Ballot Casting as in [5] pp. 8 will be performed.
MW provide getIinitiatorVoteSignature and collectInspectorSignatures methods to get necessary information.

Completed Voter ballot will be published to the PW via publishBallot method.
This method accepts only valid ballots according to the [5] pp.9 Algorithm 1 and internally stores published ballots encoded with the proposal public key.

Post-Voting

Initialized (used) MW will be frozen as in [7] to collect remaining funds back to initiator account by calling votingEnd method.
For uninitialized MW special constructor message will be sent.

PW counts ballots collected during the vote phase and publishes the proposal request decision as of [6] along with the proposal private key to the VW.
VW checks the correctness of vote counting using PW collectPublishedBallots and proposal private key.
If all ballots collected correctly and no complaints pending during complaint period will be accepted the decision will be finalized by VW and no further changes will be possible.
To reference proposal solution getProposalSolution VW method will be used.

Voter can complain if her vote missing in final PW collectPublishedBallots set by using VW complainMissingVote request. VW will accept the complain iff following met

  • MW with corresponded address exists
  • Vote Ballot is valid as of [5] pp. 9
  • corresponded publishBallot transaction exists

Accepted complains will be recorded within VW. Proposal Voting will be abandoned. VW getProposalSolution will return ‘abandoned’ solution option.

Information leaks

Implementation should not provide any methods intensionally of unintentionally that can lead to voting information leaks.
For example, implementation should not expose methods to return particular member vote choice or reveal voter identity.

Vote Costs

Voter will not be charged in any form for voting process.
All fees will be covered by initiator by supplying enough tokens for ‘initiate’ request.
Inspector funds IW independently.

Uninitialized MW’s should be collected by initiator after voting end time.
For this purpose ‘collect’ constructor Message will be used.

Initiator can withdraw remaining funds from PW but it should leave enough tokens to keep PW alive in terms of [7] at least until end of complaint period.

Inspector can withdraw remaining funds from IW but it should leave enough tokens to keep IP alive at least until end of complaint period.

Free TON community can reward Initiator and Inspector Roles by founding them after the proposal solution is final. Funding before the proposal init is also possible.
The Initiator and Inspector motivation is out of the scope of this specification.

References

[1] [https://docs.ton.dev/86757ecb2/p/822e19-2-ton-blockchain/t/824f8c] Ton OS

[2] [https://freeton.org/][Free TON] Free TON Community

[3] [https://docs.ton.dev/86757ecb2/p/60031b-overview] Smart Contract Lore

[4] [https://medium.com/coinmonks/implementing-an-e-voting-protocol-with-blind-signatures-on-ethereum-411e88af044a] Seres István Andrázs, Implementing an e-voting protocol with blind signatures on Ethereum, 2018

[5] [https://eprint.iacr.org/2017/1043.pdf] Yi Liu and Qi Wang, An E-voting Protocol Based on Blockchain, 2017

[6] [Developers Contest: Soft Majority Voting system] Soft Majority Voting system

[7] [https://ton.org/tblkch.pdf] N. Durov, Telegram Open Network Blockchain, 2019

2 Likes

Stage I

Abstract

TON Improvement Proposal (or TIP) for Soft Majority Voting contracts specification

Copyright

TON Labs

Motivation

We need a system of voting contracts to regulate governance and decision making in Free TON. This contract is a principal tool of decentralization. It is supposed to be used in many aspects of Free TON blockchain to provide mechanism for community governance.

As such it should meet the following requirements:

Transparency — everyone in the community should be able to verify the results of the Voting, review proposal and links to its description and how results are implemented.

Participation — the voting should work even in case of low participation by the community members

Ease of use — every community member should be able to participate even without a deep technical knowledge

Security — the highest level of security should apply

Flexibility — it should be flexible enough to serve many applications requiring voting mechanism in Free TON

We proposes a decentralized Soft Majority Voting system based in part on TIP-3 Token specifications presented earlier. The system takes care of the following user flow: a Super Root contract is deployed by any party which wants to initiate an SMV pool. Super Root contract is the only place where all initiated proposals are stored. This is useful for example as a record keeping of set of proposals. Additional logic of super root tree can be implemented if needed for a more complex governance process where a combination of proposals needed to advance certain matter.

In the current proposal an Initiator, a party which would like to submit a proposal for a voting pays certain amount of funds into a Super Root contract for proposal initiation.

The payment may act like an anti-spam measure or to be used as deposit in more advanced logic, involving prediction betting, which is beyond the scope of the current TIP.

The parameters of any Soft Majority system must include a voting timeframe and a total number of possible votes. Therefore the proposal must contain the rule by which Voters will receive their rights to vote.

Voters can receive (or request) voting tokens from Proposal Root Contract (think of Ballot). User is requesting a Ballot by depositing funds for each Ballot.

Specification

Glossary

Initiator - user who wants to create new proposal.

Initiator Wallet - any smart contract that can make transfers with payload.

Super Root - smart contract which creates new proposal and deploys new SMV contract.

Proposal Root - smart contract which implements rule for distributing votes, implements SMV algorithm and deploys Voting Wallets; based on Root Token Wallet (see TIP-3).

SMV contract - the same as Proposal Root.

Voting Wallet - smart contract deployed by Proposal Root; can vote for proposal on behalf of user; based on TON Token Wallet (see TIP-3).

User Wallet (Ballot) - any smart contract that can work like a wallet; required to request votes from Proposal Root.

User - any person who wants to vote for proposal.

Asset Collateral Tokens (ACT) — is some Token contract that holds an Asset as Deposit for Token Deployment

Design

Description

Soft Majority Voting system consists of 3 smart contracts:

  • Super Root

    • Deployed only once. Contains code of Proposal Root and some option parameters for vote distribution rule.
    • Contains createProposal function which creates new proposal by deploying Proposal Root contract with defined total votes, proposal timeframe and proposal description as a requirement
    • createProposal can optionally define a set of rules for ballot granting as for example pubKeys of Voters or other such scheme.
    • createProposal function can be called by any smart contract. Proposal Initiator Wallet must send tokens to cover for Proposal deployment and Super Root gas costs and optionally voters gas costs (but this scheme is not described int he current proposal).
    • Stores Proposal Root code.
    • Stores dictionary with created proposals.
  • Proposal Root

    • Deployed by Super Root.
    • Stores root key, Voting Wallet code.
    • Contains RequestBallot function that can be called by User Wallet. The function accepts User public key and value of tons deposit. The function can also accept Asset Collateral Tokens as deposits.
    • RequestBallot applies vote distribution rule to deposit value and calculates amount of votes that user will have. Then it deploys user Voting Wallet which will be controlled by accepted user public key. Deploy message also contains encoded deployWallet call with the following parameters: calculated amount of votes, User deposit value, User Wallet Address.
    • Generates User Voting Wallet address by constructing InitState structure with initial data and code. Initial data consists of Proposal Root key, Token Wallet code, User public key, zero amount of votes and zero deposit value.
    • Accumulates deposits of all users on its balance until the proposal is expired. When this happens User can request to return its deposit back by calling returnDeposit function using its Voting Wallet. The function must implement a Verification Check described in TIP-3 to be sure that the caller is a valid Voting Wallet and if the check is successful do simple transfer (with requested number of tons) to user wallet.
    • Can deploy as many wallets as requested by users.
    • Implements SMV algorithm and has vote function to receive ‘yes’ or ‘no’ votes from Voting Wallet. The function must verify that the vote sender is a valid Voting Wallet by implementing a Verification Check described in TIP-3.
    • Does not store addresses of voted Voting Wallets but only counts a total number of ‘yes’ and ‘no’ votes.
  • Ballot

    • Deployed by Proposal Root. When its deployBallot function is called inits variable with amount of user votes and variable with user deposit sent to Proposal Root.
    • Contains sendVote function that must be called by User to vote for proposal. The function can contain uint votes argument if Ballot will have more than 1 vote by design. sendVote must call vote function of Proposal Root and decrease amount of votes by 1 (or by votes value).
    • When proposal is expired User can call Voting Wallet’s requestDeposit function which must implement next algorithm:
      • throw exception if variable with user deposit isnt’ zero;
      • set user deposit variable to zero;
      • calls Proposal Root’s returnDeposit function;
    • (Optional) can transfer votes to another Voting Wallet by calling internalTransfer function of receiver wallet (see TIP-3 spec).
    • (Optional) can have internalTransfer function to receive votes from other Voting Wallet. internalTransfer must implement Verification Check to be sure that the sender is a valid Voting Wallet (check is described in TIP-3).

Functions

Super Root Interface

The contract must not have functions that can be called by external message. So no one must control it.

Anyone can deploy this contract thus deploying new SMV voting system.

Contract’s persistent data must store code of Proposal Root and Voting Wallet. They can be part of initial data or be initiated in constructor function.

Also contract must store a dictionary of created proposals: m_proposals (id ⇒ Proposal) which initially must be empty.

Proposal struct must have at least the following fields:

Proposal: {	
	root: address, // address of proposal root contract
	...
}

createProposal

Can be called by other contracts only.

Adds new proposal to m_proposals, prepares initial data for new Proposal Root contract, calculates it address and deploys it.

Proposal Root’s initial data must contain totalVotes, startime, endtime, description , random RootKey (uint256) and optionally other params necessary for vote distribution rule (e.g. the price in tons of 1 vote).

NOTE: function must check that inbound msg.value ≥ X tons, where X is a fee for creation of proposal. X must cover function gas fees and forward fees for sending outbound internal message.

function createProposal(uint256 id, uint256 totalVotes, uint32 startime, uint32 endtime, string desc)

The function sends an internal confirmation message back to caller in case of success.

getProposalRootCode

get-method

Returns code of Proposal Root smart contract.

function getProposalRootCode() public returns (cell propRootCode) 

getProposals

get-method

Returns a list with created proposals

function getProposals() public returns (Proposal[]) 

Proposal Root Interface

The contract must not have functions that can be called by external messages.

The contract must store:

  • Voting Wallet’s code walletCode;
  • rootKey (inserted into data by Super Root contract);
  • 2 counters: yesVotes and noVotes.
  • vote distribution parameters:
    • vote price votePrice;
  • Proposal status: true - approved, false - active;

requestBallot

Can be called by any smart contract.

Allows user to get a vote (or votes) for proposal.

Constructs Voting Wallet’s initial data (which contains zero votes, zero deposit value and Voting Wallet pubkey, calculates user its address and deploys it. Deploy message must also contains encoded deployWallet call with calculated number of votes and user deposit (see deployWallet function).

NOTE: the function calculates number of user votes from inbound msg.value according to vote price (see example below), thus user wallet must send enough tons to request a vote. For example, if 1 vote costs 100 tons, then to request 5 votes user wallet must send 500 tons. If wallet sends 120 tons then only 1 vote must by assigned and 20 tons must be returned back.

function requestBallot(uint256 pubkey, uint256 deposit) public

The function sends internal confirmation message with unused deposit back to caller if succeeded.

The caller must pay for gas consumed by this function.

vote

Allows a voting wallet to vote for proposal.

The function increases values of yesVotes and noVotes and implements SMV algorithm.

The function can change the status of proposal.

NOTE: the function must throw an exception if vote is received outside the start and end time of proposal.

NOTE: the function must do a Verification Check using pubkey , rootKey and walletCode and throw exception in case of failure.

function vote(uint256 pubkey, uint256 yesVotes, uint256 noVotes)

The function sends internal confirmation message back to caller if succeeded.

The caller must pay for gas consumed by this function.

returnDeposit

Allows to return user deposit after the end of proposal lifetime.

Must be called by user’s Voting Wallet.

NOTE: the function must do a Verification Check using pubkey , rootKey and walletCode and throw exception if it is failed.

function returnDeposit(uint256 pubkey, address userWallet, uint256 deposit)

The function sends internal message with a specified deposit to the specified address.

The caller must pay for gas consumed by this function.

getVoteParams

get-method

Returns a price value in tons that must be deposited for one vote.

function getVotePrice() public returns (uint256 votePrice)

getProposal

get-method

Returns full information about proposal.

getProposal() public returns (
		uint256 id,
		uint32 start,
		uint32 end,		
		string desc,
		bool status,
		uint256 totalVotes,
		uint256 currentVotes,
		uint256 yesVotes
)

Voting Wallet Interface

The contract is based on Token Wallet contract (see TIP-3).

deployWallet

Can be called by Proposal Root only.

Initializes wallet variables: number of wallet votes, user deposit value and user wallet address to return deposit to.

function deployWallet(uint256 votes, uint256 deposit, address userWallet)

sendVote

Can be called by external message only. The message must be signed with voting wallet’s key.

Sends defined number of votes to Proposal Root contract.

The function must call Proposal Root’s vote function and decrease votes counter by count value.

NOTE: the function must not accept message if wallet variable votes is zero.

function sendVote(uint256 count, bool yesOrNo)

requestDeposit

Can be called by external message only. The message must be signed with voting wallet’s key.

The function must set to zero deposit variable and call Proposal Root’s returnDeposit function.

NOTE: the function must not accept message if wallet variable deposit is zero.

function requestDeposit()

Implementation example

__interface ISuperRoot {
  __attribute__((external))
  void constructor() = 1;

  // Adds new proposal to m_proposals, prepares initial data for
  //  new Proposal Root contract, calculates it address and deploys it
  __attribute__((internal))
  void createProposal(uint256 id, uint256 totalVotes, uint32 startime, uint32 endtime,
                      bytes desc) = 2;

  // Returns code of Proposal Root smart contract
  __attribute__((getter))
  cell getProposalRootCode() = 3;

  // Returns a list with created proposals
  __attribute__((getter))
  dict_map<uint256, Proposal> getProposals() = 4;
};

struct ProposalInfo {
  uint256 id;
  uint32 start;
  uint32 end;
  bytes desc;
  bool_t status;
  uint256 totalVotes;
  uint256 currentVotes;
  uint256 yesVotes;
};

__interface IProposalRoot {
  // Allows user to get a vote (or votes) for proposal
  __attribute__((internal))
  void requestBallot(uint256 pubkey) = 1;

  // Allows a voting wallet to vote for proposal
  __attribute__((internal))
  void vote(uint256 pubkey, uint256 yesVotes, uint256 noVotes) = 2;

  // Allows to return user deposit after the end of proposal lifetime
  __attribute__((internal))
  void returnDeposit(uint256 pubkey, address userWallet, uint256 deposit) = 3;

  // Returns a price value in tons that must be deposited for one vote
  __attribute__((getter))
  uint256 getVoteParams() = 4;

  // Returns full information about proposal
  __attribute__((getter))
  ProposalInfo getProposal() = 5;
};

__interface IVotingWallet {
  // Initializes wallet variables
  __attribute__((internal))
  void deployWallet(uint256 votes, uint256 deposit, address userWallet) = 1;

  // Sends defined number of votes to Proposal Root contract
  __attribute__((external))
  void sendVote(uint256 count, bool_t yesOrNo) = 2;

  // The function must set to zero deposit variable and call Proposal Root's
  //  returnDeposit function
  __attribute__((external))
  void returnDeposit(uint256 count, bool_t yesOrNo) = 3;
}
3 Likes

Extensible Voting System Architecture for Developer Contest: Soft Majority Voting system

Summary

Soft Majority Voting proposal as implementation of Extensible Voting System.

Abstract

It is proposed to implement an Extensible Voting System for voting in community with the support of various vote counting schemes and voter sets.

Motivation

The community needs a decentralised transparent tool for collective decision making. The Extensible Voting System proposed for consideration can become the main tool for solving this problem, moreover, not only within the framework of decision-making for the perfection of the network, but also as a tool for solving similar problems within the framework of applications of the whole ecosystem.

Main Idea and Key Advantages

We believe that solving various issues requires different ways of making decisions. The key idea of ​​our proposal, in its extensibility. We sure that such an instrument is necessary not only within the framework of the SMV, yes/no options and a unified model for appointing voters. The Expandable Voting System should realise the possibility of making a lot of different scenarios, choosing various options for counting votes and appointing voters. The key advantages of this idea are that the Expandable Voting System can be used not only in the framework of decision-making to improve the platform, but also the whole ecosystem. For example, an application in the Free TON ecosystem requires a transparent voting tool, but the SMV does not suit it, or it needs more options for an answer or its own system for issuing voting tickets. A well-designed system will allow this to do it, thereby satisfying the needs of all.

We understand that the condition of this contest is to implement the specifications of the SMV contract with yes / no options. Therefore, within the framework of the system exclusively special cases with a similar implementation will be considered.

Special Data Types

TVotingVariant

Every voting has options and result which is uint8.
Value 0 is reserved for undefined semantic.

For Yes/No voting Yes == 1, No == 2.

TProposalData

Structure describes attributes of proposal

begin: timestamp
end: timestamp
description: bool

TProposalResult

Structure describes attributes of proposal with voting result
Contains all attributes from TProposalData and:

result: TVotingVariant
finished: bool

Architecture

VotingSystemRootRegistry

The root registry of the system. It contains information about other components and essences of the system, in particular, the conducted and conducted voting. It controls voting rights similar to voting rights, and is also the primary access point for creating a vote.

VotingSystemRootRegistry::createProposal

Call IVotingSystem::createProposal; upon successful creation, call IVotingScheduler::ensureEnd

VotingSystemRootRegistry::checkProposal(id: TVotingId): TProposalResult

Method for obtaining the voting result. It can be used with active voting.

VotingSystemRootRegistry::getSufrageProvider(votingId): ISufrageProvider

The method is required to obtain an ISufrageProvider instance for voice or other needs.

VotingScheduler

The entity is to track the completion of voting and call the completion function, if necessary.

VotingSystemRootRegistry::ensureEnd(voting: IVotingSystem, end: timestamp)

nearestEnds update method

IVotingSystem

Interface for each voting system. Any VotingSystem must implement this interface in order to work on the system.

IVotingSystem::createProposal(id: TVotingId, proposal: TProposalData, sufrage: ISufrageProvider)

The method creates new voting with TProposalDraft attributes and id.

IVoting

Voting interface describes vote method

IVoting::vote(votingId: TVotingId, resolution: TVotingVariant)

Simple voting with wallet Public Key

IVoting::voteByTicket(votingId, ticket: uint256, resolution: TVotingVariant)

Voting with any uint256 ticket.

SoftMajorityVotingSystem

SMV implementation in this situation is a special case containing a counter and no counter. Accepts vote and voteByTicket (implemented by IVotingSystem) only from its SufrageProvider with which it was created

ISufrageProvider

The subsystem interface for handle voting right. It is inherited from IVoting to work as a proxy, that is, the provider can interact with other components of the system and can pretend to be a voter to check voting rights, but not to vote real and transfer the call further to the counter. It is assumed that it can be used for several votes, i.e., the same instances can be used multiple times for different IVotingSystem implementations

ISufrageProvider::getVotersCount(votingId): uint256

Returns number of voters who may vote or did it already.

ISufrageProvider::addVoting(votingId, voting: IVoting) onlyRootRegistry

The method for registration new voting in sufrage (auth) subsystem.

ISufrageProvider::disposeVoting(votingId) onlyRootRegistry

The method for cleanup unneeded storage then voting ends.

SimpleListSufrageProvider

A special case of the implementation of ISufrageProvider. It is a predefined list of wallets with voting rights. This list is given as an example of implementation, but can be used with a small number of participants.

TicketSufrageProvider

A special case of the implementation of ISufrageProvider. It is proposed for voting with a large number of voters. TicketSufrageProvider may be used as gateway for external authentication system. In this proposal, just as in the case of SMV, the specific implementation of this provider is not considered. The objective of this instance is the creation of the issuance and verification of voting rights and is given here as an ideological example for the implementation of ISufrageProvider

VoterWallet

Any VoterWallet implementation can be used.
Voting must be implemented through the call of ISufrageProvider::vote in VoterWallet

VoterWallet::vote(voting: IVoting, resolution: TVotingVariant)

Simple voting with wallet PK

VoterWallet::voteByTicket(voting: TicketSufrageProvider, ticket: uint256, resolution: TVotingVariant)

Description

VotingSystemRootRegistry is the main entry point of the system. Further, there are three implicit subsystems (logical blocks) - vote counting, voting rights and task planner.

The key element of the vote counting subsystem is IVotingSystem. implementations of this interface can be either SMV or other flexible counting systems.

The key element of the voting right subsystem is ISufrageProvider, the implementations of which provide the right to vote for a certain set of addresses, which is determined depending on the implementation of the interface, some ideas for a possible implementation were given above. The main workflow is that ISufrageProvider has a vote method to check voting rights, but it is a proxy to IVoting and transfers the call to the real voting system.

Things that need to be improved

  • Description of specific scenarios
  • Definition of rights to create a new vote (via createProposal), should work similarly with voting rights
  • Deployment and administration process (adding subsystems). As an example, To launch the System, a minimum set of smart contracts is required: VotingScheduler, one IVotingSystem (e.g. SoftMajorityVotingSystem), one ISufrageProvider (e.g. SimpleListSufrageProvider). After that, you can deploy VotingSystemRootRegistry by passing the previous ones to the constructor for initialisation
2 Likes

вот отличительные особенности моего предложения
for Developer Contest: Soft Majority Voting system

Voters list - an array of TON addresses (for example, the first 200 of the top stacking holder rating).
Ballot box - TON address designed to accumulate votes cast.
ballot box “yes” - TON network address intended (mainly *) for accumulating votes for
ballot box “no” - TON network address intended (mainly *) for accumulating votes against

Voting in two ballot boxes is such an innovative type of voting in which each participant who takes the vote in accordance with his position on the issue put to the vote sends his Main vote (2 tokens) to the corresponding ballot box, and the auxiliary (in the amount of 1 token) must send to another (second) ballot box.
The rule of comparing two TON addresses is to prevent the substitution of yes and no ballot boxes and to easily check which ballot box yes or no the main vote was cast, the rule should be accepted and observed: "when organizing a vote by the Initiator, big/higher address TON is assigned a ballot box for votes yes, but for a smaller/ lower address TON ballot box no "
Comparison of two TON network addresses - in order to identify a higher / higher address, it is necessary to develop a permanent applied principle out of two possible ones:
a) to identify a higher-lower one by using ordinary alphabetical sorting starting with the first character
b) the identification of a larger - smaller address by applying the mathematical function of comparison> <(more less) to the sums of all characters of each address
Voting ballot - consists of three coins (tokens) received by a participant from the voters list as part of a smart voting contract
The process of expression of the will of the voter is the completion of two! transactions to the address of the corresponding ballot box in the amount of 2 tokens and sending 1 token (control echo) to the opposite ballot box.

Double counting (or correspondence of two ballot boxes) is a type of voting based on the completion of two voting transactions (main transaction and a small echo transaction) in which the contents of the ballot boxes are identical but mirror-opposite. Thus, we have two counters that are independent of each other, but mirror-opposite. - which makes it easy to identify compromised voting results - it’s almost impossible to deceive two counters at once, and it’s certainly much more complicated than in other vote counting systems in which the counting is done using a script .Here we see the balance (or transit in another embodiment) of each ballot box. Ballot box with a large balance of the winner in the vote. at the same time, the verification equalities must be fulfilled: (balance1box + balance2box) / 3 = the number of voters.
Filter on ballot boxes - implemented by a smart contract and ensures the acceptance of tokens only in the amount of 1 or 2 coins; from the address only from the voters list; checks in the history of the address (on the wallet) that the transaction has not yet arrived from this address of the voter.
Smart contract of the voter - allows the process of expression of will; provides 3 tokens to the voter; limits the ability to use the provided tokens only in the form of pre-approved transactions to the address of 4 TON network addresses set in advance: 1 ballot box address “for” 2 ballot box address “3” address of passive voters accumulation 4 address of the Central Voting Authority Free TON.
Passive voters accumulation address is the wallet to which unused tokens are automatically collected (revoked) after the end of the time allotted for voting. 3 pieces from each abstained from voting but included in the voters list. balance sheet on this account / 3 = number of liabilities. verification equality must be fulfilled: the number of liabilities + the number of voters = the number of voters
The address of the Central Voting Authority is the address for receiving complaints by the supreme body and blocking the voting on the principle of “against all”. In case of disagreement with the legitimacy of the vote, violation of the fundamental principles of the network, the voter sends to this address 3 tokens received for voting with an appropriate short comment and a link to a detailed justification and discussion.

2 Likes

Last Minute Voting - Potential attack vector on SMV

If no one vote on proposal or we have a proposal with a small amount of stake that was voted, there is a risk that attacker will vote in last block and will change the result of voting.

Solution
We can have a window in the end of the voting for example 24 hours, and if during this time the result of voting will be changed, the voting is extended for 24 hours.

1 Like

мягкое голосование предполагает наличие некого буфера( площадь закрашенная красным цветом ) при котором выборы признаются не состоявшимся ( решение не принимается)
.мягкость2
но и идея с дополнительным временем для голосования( при пограничном состоянием результатов) или подачи протестов тоже возможна к реализации!

1 Like

The jury members have been selected. They have been and are continuing to review all submissions for the following contests:

Airdrop Mechanics 1
Developers Contest: Soft Majority Voting system
Validator Contest: DevOps tools
Decentralized Support I – Present Supporters
Decentralized Promotion
Idea Management System Contest

Please understand that this is not an easy task given that there are almost 200 submissions in total; however, the jury is determined to do their very best to cast all of their votes by the end of the day, Monday, June 22, 2020.

Thank you for your patience!

1 Like