search

bitshares / bsips

BitShares Improvement Proposals and Protocols. These technical documents describe the process of updating and improving the BitShares blockchain and technical ecosystem.
https://bitshares.github.io
63 stars 86 forks source link

Vote Proxies for Different Referendum Categories #177

Closed MichelSantos closed 4 years ago

MichelSantos commented 5 years ago 
BSIP: <BSIP number>
Title: Vote Proxies for Different Referendum Categories
Authors: Alex M, Michel Santos
Status: Draft
Type: Protocol
Created: 2019-06-18
Discussion: <url>

Abstract

Voting power by core token holders may be assigned to different proxies in each of the BitShares referendum categories: witnesses, committee members, and worker proposals.

Motivation

Some proxies can be more or less knowledgeable, wise, and trusted by token holders to vote on certain referendum categories than others. It is therefore desirable to empower token holders to select different proxies for each of the referendum categories.

Rationale

Holders of the core token of BitShares (BTS) have always had the ability to directly vote on three referendum categories: witnesses, committee members, and worker proposals. They have also had the option of delegating their voting power to another account (a "proxy") to vote on any of these referendum categories.

Rather than delegating voting power to a single proxy for each of three referendum, a core token holder might prefer to select different proxies for each of the referendum categories.

This more granular approach empowers core token holders with more options. A BTS token holder may choose to directly vote on any referendum category including the option to abstain. A BTS token holder may choose to select proxies for each of the referendum categories. Each of the referendum categories may have distinct proxies or may have common proxies. Some referendum categories may have assigned proxies while others may be unassigned.

Specifications

Whenever a proxy for a category is assigned, any direct votes by a core token holder within that category shall be ignored. Whenever a proxy for a category is unassigned, any direct votes by a core token holder for that category shall be counted during vote tallying process of the blockchain.

Discussion

Summary for Shareholders

Copyright

This document is placed in the public domain.

See Also

pmconrad commented 5 years ago

Proposed specification:

Vote Proxies for Different Referendum Categories

Specification

GRAPHENE_PROXY_PER_CATEGORY_ACCOUNT

A new special account GRAPHENE_PROXY_PER_CATEGORY_ACCOUNT with ID 1.2.6 is defined and added to the database at protocol change activation time.

account_options extension

Fields:

The account_options receives three new extensions:

Validation:

account_create_operation

If account_options.voting_account == GRAPHENE_PROXY_PER_CATEGORY_ACCOUNT, then the account's per-category voting proxies are set to the specified extension if present, or to GRAPHENE_PROXY_TO_SELF_ACCOUNT if absent. Otherwise, the voting proxy for all three categories is set to account_options.voting_account.

account_update_operation

If account_options.voting_account == GRAPHENE_PROXY_PER_CATEGORY_ACCOUNT, then the account's per-category voting proxies are set to the specified extension if present, or remain unchanged if absent. Otherwise, the voting proxy for all three categories is set to account_options.voting_account.

account_object

Note: this is an implementation detail and meant to be a hint for later development. The actual implementation may differ.

The account object will receive these new fields:

account_create_operation and account_update_operation will be modified to create these sets by filtering the account_options.votes field appropriately.

Vote tallying

The vote tallying algorithm will be modified to select the opinion_account per voting category, and use the current account's voting stake only for the opinion account's votes in the respective category.

Discussion

Performance impact

There will be a performance impact on account_create and account_update due to the filtering (if implemented as suggested). This impact should be small overall, because these operations are comparatively rare.

There will also be some overhead for vote tallying. Vote tallying happens only in the maintenance interval, so the operational impact should be negligible as well.

Note that the cumulative effect of both may be noticable during chain replay.

pmconrad commented 5 years ago

IMO it would make sense to bundle this together with #114 unless BPBV want to complete that themselves.

xeroc commented 5 years ago

IMO it would make sense to bundle this together with #114 unless BPBV want to complete that themselves.

Please go ahead and merge those two proposals!

And while we are at it, have we ever discussed allowing to "weight" a vote with something other than 0% and 100%? Like, I would like to only slightly bump a certain worker but not give all voting power to it?

oxarbitrage commented 5 years ago

Agree on the merge of the 2 proposals.

Regarding the other idea about the weight, i think is interesting and doable. Technically votes are stored in accounts as: 0:325 or 2:394, where the first number is the type(worker,committee, witness) and the second is the ID. This can have a weight number between 0 and 1 to be used as weight so it can be 0:325:0.5, 2:394:0.1 and so on.

Then of course, this weight haves to be used at db_maint.cpp when counting votes.

Note: https://github.com/bitshares/bsips/pull/114 will have a(positive) impact on how last_time_voted is obtained in vote decay proposal: https://github.com/bitshares/bsips/pull/153

MichelSantos commented 5 years ago

Proposed text for the merger is posted at #114

abitmore commented 4 years ago

Draft merged in https://github.com/bitshares/bsips/pull/114. Closing the issue.