Vote-to-Exit at Block Height: Implementation Details

[pavitthrap]

This plan builds off of the discussion here: #2687.
This post covers some more specifics for how we plan on implementing the vote to exit at a particular block height. Feedback and comments are welcome!

Objective

Implement a voting mechanism that allows users to vote for when a network upgrade will occur.

Vote Implementation

• Users vote for a specific reward cycle. The magnitude of their vote is the amount of STX they have currently stacked.
• There will be a constant to determine a lower bound. We will not allow people to vote for a reward cycle below this lower bound. This will probably be around block 725,000.
• Only stackers may vote - the delegators can not vote for them.
• A user can manually revoke their vote [this withdraw function is tentative].
• A vote is a standing vote. Unlocking automatically revokes a user’s vote. At the time the vote is made, the field expiration-block-height is set to signify when the vote expires.
• I think I’ll also include an upper bound for how many RC’s in the future someone can vote for (max 2 years into future?)

Phases of the vote

• Stacker voting. Vote for for RC N goes through if:
  • RC N is at least x cycles in the future (equivalent of 15,000 blocks)
  • At least 50% of stacked STX has cast a vote
  • A consensus is achieved on some reward cycle. This means that (a) at least 50% of stacked STX cast a vote, and (b) that at least 50% of votes cast are able to agree on some RC.
• Vote tally:
  • Occurs at the end of each reward cycle in the chains coordinator, which will examine the smart contract state.
  • Will be doing an aggregated vote.
    • Before an exit height is chosen, a vote for RC N is interpreted as voting to exit at RC N or higher. If there is an equal number of votes for RC 10, 11, and 20, RC 11 will be selected as the exit height.
    • After some exit height H is chosen, the vote means, delay exiting at H, instead exit at or after some new block height x. In effect this means that any votes <= H will not be counted in the election.
  • Needs to occur before the pox unlocking logic - that logic will trigger the withdrawing of votes for stacks holders that are unlocking at the end of that cycle
• Miner veto period. If RC N is chosen as the exit height in RC R, the vetoes occur in RC R+1.
  • Miner can include veto transaction in their block (this would be a call to the veto function in the contract).
  • at least 80% of miners must veto to cancel the vote.
  • No further votes for RC N are allowed during reward cycle R +1.
• After veto period
  • If vote for RC N goes through, all votes are cleared from system, and RC N is set as the new exit block height
  • If vote for RC N is rejected, votes for RC N are cleared from the voting contract (votes for other reward cycles remain intact).

General Plan

• Create exit-at-block-height contract.
  • This will include both voting and veto related functions and maps.
• Integrate contract with blockchain code.
  • Once some RC is chosen, that value will be stored in the SortitionDB/ HeadersDB - I will add a column for exit_at_block_height - this will be a part of the BlockSnapshot.
  • Block processing should halt at the chosen RC. This will occur in the chainstate coordinator.
    • if block_height > exit_block_height && exit_block_height > curr_epoch_start_height: halt
    • The chosen RC should be confirmed by at least one reward cycle. This is necessary in order for the chains coordinator to be able to deduce the exit_block_height -- a vote cast in RC N won’t be “seen” until the end of RC N+1.
  • Add logic to tally votes at the end of each RC. This will occur in the chainstate coordinator (and not in the smart contract).

Edge Cases

• Let’s say that a vote for RC N occurs in RC R. In RC R+1, there will be a veto period, during which no further votes will be counted for RC N. In RC R+1, users vote for RC M. At the end of RC R+1, let’s say RC N is confirmed, which updates exit at block height. We would only want to enter the veto period for RC M if M > N. So, we will want to process the veto processing logic before the vote counting logic (the PoX unlock logic that causes votes to be withdrawn should follow both of these).
  • Solution 1: don’t make it fancy; just enter the veto period for M. Then have check in the confirmation function that the newly suggested value is strictly larger than the previous minimum value
  • Solution 2: if there’s a vote for N in progress, you can’t vote for M until the veto period for N clears. No need to pipeline concurrent votes; just have at most one outstanding vote at a time.

Leaning towards solution 1.

Contract Details [tentative]

Constants

• absolute-minimum-rc (uint): hardcoded in contract
• minimum_rc_buffer_from_present (uint): hardcoded in contract, # of RC for 15k blocks
• maximum_rc_buffer_from_present (uint): hardcoded in contract
• veto-percent-threshold (uint): hardcoded in contract to 80
• require-percent-stacked-stx-for-vote (uint): hardcoded to 50
• percent-for-vote-confirmation (uint): hardcoded to 50
• minimum-exit-at-rc (uint): hardcoded to be minimum rc value that can be accepted

Data maps

• rc-proposal-votes
  • key: (proposed_rc: uint, curr_rc: uint)
  • value: (votes: uint) -> this is amount of stx locked by principals that voted for this rc
• vote-confirmed-rc-proposal
  • key: (rc: uint)
  • value: (expiration-block-height: uint,
• rc-proposal-veteos
  • key: (proposed_rc: uint, curr_rc: uint)
  • value: (vetos: uint) -> this is the # of vetos
• exercised-veto -> to prevent a miner from sending multiple veto transactions in 1 block
  • key: (rc: uint, veto-height: uint)
  • value: (vetoed: bool)
• rc-voters -> maps principal to the rc they voted for (if at all)
  • key: (address: principal)
  • value: (rc: optional uint, amount: uint, expiration-block-height)

Functions

• submit-rc-for-consideration -> add rc to be considered
  • Can call get-check-delegation in pox.clar
• vote-for-rc -> checks tx-sender is a stacker, modifies rc-proposal-votes and principal-rc-proposal
• veto-rc -> checks tx-sender is the miner of previous block, checks that block height is before expiration block height for voting (info which will be in thevote-confirmed-rc-proposal map
• withdraw-vote-for-rc -> removes vote from tx-sender for a particular rc

[friedger]

Only stackers may vote - the delegators can not vote for them.

What is the motivation here? Will stackers be able to vote using ledger?

80% miner veto

Just for info, for 6 miners, this is 5 of 6 vote to cancel the stackers vote.

Before an exit height is chosen, a vote for RC N is interpreted as voting to exit at RC N or higher. If there is an equal number of votes for RC 10, 11, and 20, RC 11 will be selected as the exit height.

Why is RC 11 selected? Not clear to me.

[pavitthrap]

(1) This was a specification Jude laid out. My guess is that the reasoning for this is to prevent an oligarchal vote. You can imagine a case where a few large pools might have all the voting power.

(2) Not sure if we should be lowering this number to make a veto more convenient for the current number of miners, because this will be used for future upgrades as well.

(3) A vote for RC 10 is in effect, a vote for RC 10 & up, likewise for the other votes. So, we have the following distinct voting buckets in the scenario I made up:
- An equal number of votes for RC 10 & up
- An equal number of votes for RC 11 & up
- An equal number of votes for RC 20 & up
Given the meaning of the votes, that means 2/3rd of the voters would be happy with an exit height of 11, since the third of voters that voted for RC 10 & up would also be happy with an exit height of 11 by definition.

This voting logic definitely would tend to favor later block heights in the vote. If we want to mitigate this, maybe we can include a range to the vote. For example, a vote for RC 10 could a vote for a range from RC 10 to RC 30. By default, we could add some constant (here it is 20) to add some flexibility to the vote, while also better preserving the intention of the original vote.

@jcnelson - thoughts on these answers?

[jcnelson]

(1) yup -- this is an anti-oligarchical design stance. If users want to delegate their voting power, they'd have to also transfer their STX to the stacking pool (which is something that could be done, but it ought to make the user feel far less comfortable about it).

(2) I think the lowest possible percentage of miner votes we should consider to be a "true" quorum is the Byzantine fault-tolerance threshold, which is at least 66% of miner agreement. In open-membership single-leader blockchains, this threshold is a little higher due to selfish mining (I think for Bitcoin in particular, it's about 75%). I'm not sure what it is for Stacks, but I suspect it's similar. I put 80% to add a safety buffer on top of Bitcoin's threshold, but it was not selected rigorously.

(3) Yup, that's right -- the reward cycle chosen should be the earliest reward cycle that satisfies the requests of the majority of the majority (i.e. at least 50% of the stacked STX that vote at all, where the number of stacked STX that vote at all is at least 50% of the total number of STX stacked). Regarding vote range, this is already implicitly enforced by the fact that a stacker's vote expires when their tokens unlock. They already need to re-cast a vote when they re-stack their tokens, so there's an implicit upper bound of voting for a range of up to 12 reward cycles.

[pavitthrap]

for the vote design (question 3), the fact that a stacker's vote expires when their tokens unlock puts a temporal bound on the vote validity, it does not impose an upper bound for an exit RC the voter would be happy with (which is what I was proposing in my answer)

[pavitthrap]

Would like input on data storage implementation for the results of voting/vetoing.

Right now, if consensus is reached for some exit reward cycle, I am storing that information in a table in the sortition DB. My implementation is not "fork-aware". If a block is processed with a successful vote, and then the canonical chain switches to a different fork (and the previously mentioned block is orphaned), I currently still maintain the chosen exit reward cycle in the database (and it is still considered valid).

Given that voting at all and reaching consensus is "hard", I was thinking that while unconventional, this behavior would be alright.

Thoughts - @kantai @jcnelson ?