Prototype - Proof of Stake Voting

[thepiwo]

Basis Proof of Stake Voting

Idea

Let accounts, make on-chain transactions representing votes to a given question. The mechanism for counting votes should be the amount of tokens held by the account determining the weight of the vote.

Implementation Proposal

Question Transaction Any account can create a transaction, asking a question to hold the vote over. It should specify an question as plain text, as well as an close_block_height at which the voting on this is closed. Otherwise the transaction should include the normal fee, nonce and from_account fields and signature. These questions can either be boolean, yes - no questions or the transaction could include an array of possible answers.

These questions can be indexed in the chain_state for easy referencing and providing apis.

Vote Transaction Any account can vote on previously opened questions using a vote transaction. This should include the hash of the question transaction, as well as the answer, either boolean or referencing one of the possible answers. Otherwise the transaction should include the normal fee, nonce and from_account fields and signature.

These answers can be indexed in the chain_state for easy referencing and providing apis.

Closing Vote (Proposal 1) The account that created the question transaction, creates an close vote transaction after the close_block_height of the transaction, publishing the results of the question. In counting the results he consideres vote transactions by weight of tokens held in the block of close_block_height.

Closing Vote (Proposal 2) It is each clients task to count the results by the chain_state in the block of close_block_height.

Advanced Topics

• delegating voting power (but not tokens) to other accounts, for all/specific votes or timeframe

[meivantodorov]

What this prototype does:

Add three new transaction data structures: VotingQuestionTransaction, VotingAswerTransaction and VotingTansaction.

VotingQuestionTransaction

We are registering new question in chainstate by his hash.

VotingAnswerTransaction

We are registering new answer for a question by providing his hash

VotingTransaction

It is a wrapper for the VotingAnswerTransaction and VotingQuestionTransaction. We are makeing SignedTx from VotingTransaction

Registering voting question

Any account can register a question. The requester has to provide:

• answers: it is array of possible answers;
• start_block_height: it tells from witch block the requester wants the question to be available for answers;
• stop_block_height: it tells when the voting for this questions ends;
• fee: any requester has to has enough balance to register a voting question;
• from_acc: the public key of the requester;
• possible_answers_count: how many possible answer the voters can give, must be greater than 0;
• question: string;

Registering voting answer

Any account can register an answer. The voter has to provide:

• hash_question: the has of a registered question;
• answer: array of possible answers;
• from_acc: the public key of the voter;
• fee: any voter has to has enough balance to register a voting answer;

Voting mechanism

This is very simple voting mechanism where after question has been registered there is time interval specified with start_block_height and stop_block_height. During this interval users can give their votes. After each new block has been added to the chain, the result for all opened questions is recalculated. The idea is the voters to check whats the current state of a voting. When the question is closed, then the last result is considered as final. The result is map that has all answers and the tokens for each of them.

Each registered question is stored into the chain state in map structure looks like that: %{hash_question1: %{data: %VotingQuestion{}, answers: [%VotingAnswer{}], result: %{answer, tokens} }}

Each registered answer will be added into the other answers that belong to this question hash

Validation

Json schema validation is used to ensure the correct structure of the requests.

Examples

• Register question : HTTPoison.post "peer:port/voting/register/question", Poison.encode!(%{question: "Is blockchain the future ?", possible_answer_count: 1, answers: ["Yes","No"], from_acc: "some account", start_block_height: 2, close_block_height: 7, fee: 10}) ,[{"Content-Type", "application/json"}]

• Register answer: HTTPoison.post "peer:port/voting/register/answer", Poison.encode!(%{hash_question: hash, answer: ["Yes"], from_acc: from_acc , fee: 20}) ,[{"Content-Type", "application/json"}]

• All registered questions HTTPoison.get "peer:port/voting/show_registered_questions"

Deadline : 09.02.18

[thepiwo]

What does the VotingTransaction wrap, whats the purpose?

[meivantodorov]

The purpose is not to check for many voting transactions but only for one. Otherwise we will need to pattern match more.

[thepiwo]

@meivantodorov @Artur64 whats the progress here?

[thepiwo]

@DanielaIvanova @Artur64 whats the progress here? you set yourself the deadline on 09.02. could yourself a new one? Maybe the end of the week?

[DanielaIvanova]

Ivan told as to fix:

• VotingTx serilizations
• Peer to peer communication with VotingTx
• Merkle tree root problems
• Apply txs to chain We are working on peer to peer communication with voting txs. We are not sure that we will be ready by the end of the week.

[thepiwo]

As this is your (@DanielaIvanova and @Artur64) task, I'd like you to be self-sovereign about finishing it, as Ivan is on holiday now. What new deadline would you like to give yourselves?

[DanielaIvanova]

We will try to finish with Voting Prototype by 28.02.

[DanielaIvanova]

Voting Prototype and How to use it

The Voting Prototype provides a possibility to register voting question/answer transactions on the chain. Every account who wants to answer the question and has enough money to pay a fee can make an answer transaction on the chain. The mechanism for counting votes is the amount of tokens held by the account.

Registering voting question

Any account can register a question. Question structure:

• question: should be a string;
• possible_answer_count: possible answers count that can be given. It should be less than the number of answers and greater than 0;
• answers: list of possible answers. Each answer type in the list of possible answers should be a string;
• from_acc: the public key of the account in binary;
• start_block_height: from witch block the requester wants the question to be available for answers. Should be non negative integer;
• close_block_height: at which block the given question will be "closed". Should be non negative integer and greater than start_block_height;
• fee: is the price that the account should pay for the transaction. Should be non negative integer;
• nonce: unique tx number;

  Registering voting answer

  Any account can register an answer. Answer structure:

• hash_question: the hash of a registered question;
• answer: list with the answer/s. Answer's type in the list should be a string;
• from_acc: the public key of the account in binary;
• fee: is the price that the account should pay for the transaction. Should be non negative integer;
• nonce: unique tx number;

  Validation

  Json schema validation is used to ensure the correct structure of the requests.

  Example

  We have to start the miner to produce some money to be able to register the transaction on the chain.

  Start the miner:

  Aecore.Miner.Worker.resume

Stop the miner:

Aecore.Miner.Worker.suspend

Check the chain state:

Aecore.Chain.Worker.chain_state

Registering voting question:

pubkey = elem(Aecore.Keys.Worker.pubkey(), 1)
data = %{question: "Is it raining?", possible_answer_count: 1, answers: ["yes", "no"], from_acc: pubkey, start_block_height: 2, close_block_height: 13, fee: 10, nonce: Map.get(Aecore.Chain.Worker.chain_state, pubkey, %{nonce: 0}).nonce + 1} Aecore.VotingPrototype.Manager.register({:question, data})

Check the pool:

Aecore.Txs.Pool.Worker.get_pool

Start mining a block:

Aecore.Miner.Worker.mine_sync_block_to_chain

Check top block:

Aecore.Chain.Worker.top_block

Check the chain state:

Aecore.Chain.Worker.chain_state

Registering Voting Answer:

q = Aecore.Chain.Worker.all_registered_voting_questions [q] = Map.keys(q)

pubkey = elem(Aecore.Keys.Worker.pubkey(), 1)
data = %{hash_question: q, answer: ["no"], from_acc: pubkey, fee: 10, nonce: Map.get(Aecore.Chain.Worker.chain_state, pubkey, %{nonce: 0}).nonce + 1} Aecore.VotingPrototype.Manager.register_answer(data)

Check the pool:

Aecore.Txs.Pool.Worker.get_pool

Start mining a block:

Aecore.Miner.Worker.mine_sync_block_to_chain

Get Voting Results for a question:

Aecore.Chain.Worker.get_voting_result_for_a_question q

Example p2p communication

You have to have two copies of the project.

First copy (node_0) of the project you should run: iex -S mix phx.server

In the second copy (node_1) in the project you have to change dev.exs file in node_1/apps/aehttpserver/config/dev.exs

port = case System.get_env("PORT") do nil -> 4001 env -> env end

And after that you should run: iex -S mix phx.server

We have to connect both nodes together. On node_0 you should run:

Aecore.Peers.Worker.add_peer "localhost:4001"

Now both nodes are connected and you can test the core and p2p communication.

[thepiwo]

good documentation, is this prototype finished?

[DanielaIvanova]

We found something that is not working properly and we will try to fix now.

[thepiwo]

can you mention cytadela8 and me, once you are done?

[DanielaIvanova]

@thepiwo @cytadela8 At this moment we are ready with Voting Prototype.

[thepiwo]

this prototype is finished (excluding PR #245 comments), but will be abandoned