Proposed details for BSIP-22 specifications (vote decay)

bsip-0022.md

@@ -37,34 +37,202 @@ Currently within Bitshares DPOS system, an user's votes for committee/witness/pr
 * Regarding consensus on this topic, the past BSIP-0005 by Dan Larimer & Fabian Schuh was not well received and was previously defferred due to a lack of sufficient detail in the BSIP.
   * The informal proposal for [expiring votes within the Steem network](https://github.com/steemit/steem/issues/953) has been well received however it has not yet been implemented.
 
+## Vote Decay on Other Blockchains
+
+### <div id="eos-vote-decay" /> Vote Decay on EOS
+
+Vote decay was [introduced into the EOS blockchain with Dawn 4.0](https://medium.com/@auroraeos/understanding-eos-vote-decay-e50c58b56658).  The maximum voting power of an account is a function of [the core tokens that are staked by that account](https://github.com/eosio/eos/eosio.system/blob/bfd1793032ed69bba8047b4807f692eaed2ed5e5/eosio.system/src/voting.cpp#L228).  This maximum effectively [step decays](https://github.com/eosio/eos/eosio.system/blob/bfd1793032ed69bba8047b4807f692eaed2ed5e5/eosio.system/src/voting.cpp#L122-126) every week [by 1.34%](https://www.eoscanada.com/en/how-is-your-vote-strength-calculated-on-eos) unless the account re-casts its votes.  The vote "decay" is technically implemented by [strengthening newer votes](https://github.com/eosio/eos/eosio.system/blob/bfd1793032ed69bba8047b4807f692eaed2ed5e5/eosio.system/src/voting.cpp#L122-126).  The age of the last casted vote [affects the voting power for all referendums](https://github.com/eosio/eos/eosio.system/blob/bfd1793032ed69bba8047b4807f692eaed2ed5e5/eosio.system/src/voting.cpp#L200-319) on the platform.  The decaying of votes for block producers [reduces the amount of pay](https://github.com/eosio/eos/eosio.system/blob/bfd1793032ed69bba8047b4807f692eaed2ed5e5/eosio.system/src/producer_pay.cpp#L153-171) received by [standby block producers](https://medium.com/eostribe/how-eos-block-producers-are-paid-7b2a1216eb2b).
+
+### <div id="peerplays-vote-decay" /> Vote Decay on Peerplays
+
+A [proposal for Peerplays](https://github.com/peerplays-network/pips/blob/master/pip-0002.md) introduced vote decay as an element of its Gamified Proof of Stake (GPOS).  Voters receive rewards from a portion of the operation fees and "rakes" that are collected by the blockchain.  The reward is contingent on [the amount of stake that is vested by the voter](https://github.com/peerplays-network/peerplays/blob/78dcc7df7316a0fcae8c14b7b648b88caa956326/libraries/chain/db_maint.cpp#L1072-1080), and [the age of last casted vote by the voter](https://github.com/peerplays-network/peerplays/blob/78dcc7df7316a0fcae8c14b7b648b88caa956326/libraries/chain/db_maint.cpp#L726-791).  The age of the last casted vote [also decays the voting power](https://github.com/peerplays-network/peerplays/blob/78dcc7df7316a0fcae8c14b7b648b88caa956326/libraries/chain/db_maint.cpp#L1446-1447) for all referendums on the platform.
+
+
 # Specifications
 
-## Committee controlled variables
+## <div id="referendum-categories" /> Referendum Categories
+
+BitShares has four categories of refereundums that core token holders may vote on: witnesses, committee members, worker proposals, and proxy delegation.  Prior to this proposal, any vote within any category applies until changed or until the proxy assignment had been assigned.  The removal of proxy assignment re-instates a core token holders' prior voting selection for witnesses, commitee members.
+
+This proposal shall retain the ability of every core token holder to vote on all referendum categories and the optional selection of a single proxy.
+
+Vote for three of the referendum categories shall be "decayable": witnesses, committee members, and proxy delegation.  Votes for worker proposals [shall continue to be tabulated as they were prior to this proposal](#out-of-scope) because they are generally fixed in length.
+
+
+## <div id="account-voting-stake" /> Voting Stake of an Account
+
+The full power of an account's vote equals the [the sum of](https://github.com/bitshares/bitshares-core/blob/bf7ff54d9a17aa43f4663521e371b8c0ddfc2284/libraries/chain/db_maint.cpp#L1184-1186) an account's liquid core tokens (BTS), core tokens in vesting balances, and core tokens in open orders including [collateral that is used for shorting smart assets into existence](https://github.com/bitshares/bitshares-core/blob/bf7ff54d9a17aa43f4663521e371b8c0ddfc2284/libraries/chain/market_evaluator.cpp#L234-245).
+
+_The full power of an account's vote will automatically be updated to reflect any changes to the liquid balance, vesting balance, or core tokens in open orders_.
+
+This proposal shall retain the calculation for the maximum voting stake of an account.
+
+
+## <div id="vote-decay-function" /> Voting Power Decay Function
+
+![Qualitative decay of voting power](bsip-0022/general-vote-decay.png)
+
+The voting power of an [account's voting stake](#account-voting-stake) shall be set to full voting power whenever an account's vote is re-cast for _any_ [referendum category](#referendum-categories).  The voting power shall remain at 100% for each of the referendum categories for the entire ["full-power period"](#vote-decay-parameters).
+
+After the full-power period, the voting power shall begin to decay towards zero during a "decay period" for every decayable referendum category.  Decay shall occur in a stepped fashion (TODO: pending confirmation by Customminer) during the decay period.  The [quantity of decay steps (n) shall be determined by the BitShares Committee](#vote-decay-parameters).  There shall be (n - 1) decay periods.  The duration of each stepped voting period (sub-period) shall equal the total vote decay duration divided by the number of decay periods.  The voting power (P<sub>i</sub>) during decay period i shall be
+
+P<sub>i</sub> = (n - i) &div; n = 1 - (i &div; n)
+
+After the last decay period has expired, the voting power shall reduce to zero until either the account re-casts its votes, or the [vote decay parameters are adjusted](#vote-decay-parameters) such that the age of the account's last vote within that category possibly moves from "expired" to the the "decay age" or "full-power age".
+
+In summary, the age of a category vote by an account will typically decay from "full-power" through "decaying" to "expired" unless and until the account re-casts its voting slate in any referendum category.
+
+---
+<center>**Example of Vote Decay**</center>
+
+The vote decay parameters for witness voting have been set to 365 days for the full-power duration, 180 days for the total vote-decay duration, and 3 vote decay steps.  Each vote-decay sub-period has a duration of 60 days.
+
+A voter changes their vote for witnesses on December 31, 2019, and then does not vote again until December 31, 2025.
+
+|Date Range|Voting Power|
+|-|-|
+|January 1, 2020 through December 31, 2020|100%|
+|January 1, 2021 through March 2, 2021|75%|
+|March 3, 2021 through May 2, 2021|50%|
+|May 3, 2021 through July 2, 2021|25%|
+|July 3, 2021 through December 31, 2025|0%|
+|January 1, 2026 through December 31, 2026|100%|
+
+---
+
+## <div id="separate-decay-rates" /> Separate Decay Rates
+
+This proposal shall [decay]((#vote-decay-function)) the voting power for [each referendum category](#referendum-categories) at different rates of decay that can be [adjusted by the BitShares Committee](#adjustable-vote-decay-parameters).  Consequently the voting power of an account for different referendum categories may, depending on the decay parameters, decay to zero before others.
+
+A vote in any referendum category will reset the [latest vote date](https://github.com/bitshares/bitshares-core/blob/bf7ff54d9a17aa43f4663521e371b8c0ddfc2284/libraries/chain/include/graphene/account_object.hpp#L73) which will reset the "vote decay clock" across each of the referendum categories.
+
+---
+<center>**Example of Different Vote Decay Rates**</center>
+
+An account with a balance of 200 BTS votes both for a slate of witnesses and a slate of comittee members.
+
+The decay parameters for these two referendum categories are shown in the table below.
+
+|Referendum Category|Full-Power Duration|Decay Duration|Number of Decay Steps|
+|-|-|-|-|
+|Witnesses|75 days|50 days|2|
+|Committee Members|200 days|100 days|4|
+
+
+The voting power since the date of last vote is shown in the table below.
+
+|Age of Last Vote|Voting Power for Witnesses|Voting Power for Commitee Members|
+|-|-|-|
+|0 days|200|200|
+|25 days|200|200|
+|50 days|200|200|
+|75 days|200|200|
+|100 days|100|200|
+|125 days|0|200|
+|150 days|0|200|
+|175 days|0|200|
+|200 days|0|200|
+|225 days|0|150|
+|250 days|0|100|
+|275 days|0|50|
+|300 days|0|0|
+
+The voting power for these two referendum categories will remain at 0 until the account re-casts its votes at which time it will return to 100%.
+
+---
+
+## <div id="proxy-power" /> Cumulative Voting Power of a Proxy
+
+A core token holder (a "delegator") may choose to delegate their voting power to another account (a "proxy").  The weight of the delegator's voting power passes through as a supplement to the proxy's voting stake for as long as the delegation is active.  The cumulative voting stake of a proxy is therefore the aggregate of the proxy account's own voting stake with the decayed voting power of its delegators.  This cumulative voting stake shall further [be decayed](#vote-decay-function) based on the last voting date of the proxy account to avoid the effects of a situation where diligent delegators are selecting an "absentee proxy".  Consequently the cumulative voting power of a proxy can decay over time due to infrequent vote re-casting by its delegators _and_ by the proxy account.
+
+---
+<center>**Example of Vote Decay with a Proxy**</center>
+
+Account A has a [voting stake](#account-voting-stake) of 1000 BTS.  Account B has a voting stake of 500 BTS.  Account C has a voting stake 20 BTS.
+
+Account A has selected Account C to be its voting proxy but [sufficient time has elapsed since this proxy assignment](#separate-decay-rates) such that the effective delegation has decayed to 75%.
+
+Similary, Account B has selected Account C to be its voting proxy but [sufficient time has elapsed since this proxy assignment](#separate-decay-rates) such that the effective delegation has decayed to 50%.
+
+Account C, the proxy, voted for committee members long enough ago such that his [voting power for the committee membership category has decayed](#separate-decay-rates) to 25%.
+
+The cumulative voting power of Account C is shown in the table below.
+
+|Account|[Voting Stake](#account-voting-stake)|Proxy Voting Power|Proxied Votes|Commitee Membership Voting Power of Proxy at 25%|
+|-|-|-|-|-|
+|Account A|1000 BTS|75%|750 BTS|187.5 BTS|
+|Account B|500 BTS|50%|250 BTS|62.5 BTS|
+|Account C|20 BTS|N/A|N/A|5 BTS|
+|**Cumulative**||||**255 BTS**|
+
+If the proxy, Account C, then re-casts his vote for any referendum category, his voting power for Committee Membership will get updated, and his updated cumulative voting power will increase as shown in the table below.
+
+|Account|[Voting Stake](#account-voting-stake)|Proxy Voting Power|Proxied Votes|Commitee Membership Voting Power of Proxy at 100%|
+|-|-|-|-|-|
+|Account A|1000 BTS|75%|750 BTS|750 BTS|
+|Account B|500 BTS|50%|250 BTS|250 BTS|
+|Account C|20 BTS|N/A|N/A|20 BTS|
+|**Cumulative**||||**1020 BTS**|
+
+If Account B also immediately renews his proxy delegation to Account C, then the cumulative voting power for Commiteee Membership will increase as shown in the table below.
+
+|Account|[Voting Stake](#account-voting-stake)|Proxy Voting Power|Proxied Votes|Commitee Membership Voting Power of Proxy at 100%|
+|-|-|-|-|-|
+|Account A|1000 BTS|75%|750 BTS|750 BTS|
+|Account B|500 BTS|100%|500 BTS|500 BTS|
+|Account C|20 BTS|N/A|N/A|20 BTS|
+|**Cumulative**||||**1250 BTS**|
+
+---
+
+## <div id="vote-decay-parameters" /> Adjustable Vote Decay Parameters
+
+The BitShares Committee shall be able to adjust the three voting parameters that affect vote decay calculations across the [decayable referendum categories](#referendum-categories).  The three parameters within each referendum category are: full-power duration by referendum category; total decay duration by referendum category; total quantity of decay steps.  There will consequently be a total of 12 parameters that can be altered by the Committee.
+
+TODO: Absolute minimum or maximum durations; absolute minimum or maximum decay steps
+
+### Changing the Decay Duration of a Referendum Category
+
+![Changing decay parameters can affect an account's voting power](bsip-0022/changing-decay-parameters.png)
+
+A reduction of either full-power duration or the decay duration could have the effect of reducing the voting power of an account by effectively aging an account's vote to "expired" status from either "full-power" or "decaying" status.  A qualitative example of this can be seen in the figure if the decay parameters are changed from Settings A to Settings B.
+
+Similarly, an increase of either the full-power duration or the decay duration can increase the voting power of an account by effectively rejuvenating an account's vote from "expired" status to either "decaying" or "full-power" status, or from "decaying" to "full-power" status.  A qualitative example of this can be seen in the figure if the decay parameters are changed from Settings B to Settings A.
+
+
+### Changing the Decay Steps of a Referendum Category
+
+Changing only the quantity of decay steps can potentially change the voting power of accounts _whose voting age fall within the decay period_.  The change in voting power for these accounts is a function of both the change in the quantity of decay steps, and the account's voting age.
+
+
+## <div id="initial-voting-power" /> Initial Voting Power
+
+Vote decay will have no effect on any account prior to the activation of this proposal with a hardfork date ("activation date").  After this proposal is activated, the **effective** [latest vote date](https://github.com/bitshares/bitshares-core/blob/bf7ff54d9a17aa43f4663521e371b8c0ddfc2284/libraries/chain/include/graphene/account_object.hpp#L73) for the purpose of vote decay calculations, shall be considered to be the activation date.  The activation date will effectively become the [start of the full-voting period](#vote-decay-function) for every account.  All votes that exist at the time of the activation date will initially have maximum voting power across every referendum categories.
+
+Any subsequent voting by an account will set a new latest vote date for an account that will reset the [vote decay clock](#separate-decay-rates) for that account.
+
+
+## Comparisons
+
+|Element|Proposal|[Peerplays GPOS](#peerplays-vote-decay)|[EOS](#eos-vote-decay)|
+|-|-|-|-|
+|Decay Rate|Full-power during initial period followed by stepped decrease during decay period until reaching zero power|Full-power during initial sub-period followed by stepped decrease until reaching zero power|Full-power during initial period followed by stepped increase of newer votes by other accounts|
+|Effect of decay rate on referendum issues|Separate decay rates for every _decayable_ referendum category|Single decay rate shared by every referendum category|Single decay rate shared by every referendum category|
+|Effect of decay rate on other issues|None|Decays the share of blockchain profits that are received by an account|Decays the share of payment for standby block producers|
+
+## Software Specifications
+
+TODO
 
-* Rate of vote weight decay.
-  * Once the vote has aged past the 'max vote age' what length of time should pass before the vote is worth 0 BTS?
-* Max vote age (before votes begin to decay).
-  * Separate age variables for: Comittee, Witness & Proxy votes (proxies should potentially age at a slower rate than comittee/witness, as these users have opted to delegate their voting power to an active user).
-* Accounts blacklisted from voting (exchanges/services/scam accounts).
 
-## Decay function
+# Risks
 
-To keep things simple, we should start with a linear decay function. If this proves too aggressive/passive, the rate of decay could be modified or the formula could be changed at a later date to potentially be exponential.
+- [Vote decay](#vote-decay-function) can negatively impact voters (a) who lost the keys to their account but have been content with how their old votes were cast, (b) who are _unaware_ of its existence and who are expecting the effects of their votes to apply perpetually, or (c) who are _aware_ of its existence but cannot easily determine the age of their last vote.
 
-Example linear vote weight decay function: (note: pseudocode!)
-```
-//Assuming this function only triggers once the vote has passed the set 'max vote age' set by the committee, hence we don't check for the vote tx not having aged past the 'max_days_decay' in this example.
+- The effects of vote decay, especially during the decay of the [initially "grandfathered" votes](#initial-voting-power), may result in sudden changes to the elected witnesses, and committee members.  This sudden change could be  disruptive to those witnesses, and committee members that are suddenly voted out.
 
-let max_days_decay = 30; //Set by committee
-let start_decay_date = vote_date()
-let days_since_decay_began = todays_date() - ()
+- Core token holders who select [a proxy account that fails to re-cast its own votes periodically will have their effective voting power decay over time](#proxy-power) despite re-casting their own votes for that proxy.
 
-if (days_since_decay_began > max_days_decay) {
-    decaying_vote_weight = 0; //Or nullify the vote
-} else {
-    decaying_vote_weight = original_vote_weight - ((original_vote_weight/max_days_decay)*days_since_decay_began)
-}
-```
 
 # Discussion