Implement and ship vote-to-exit before Stacks 2.1, and push back Stacks 2.1 with network consent?

[jcnelson]

This proposal seeks to offer the Stacking community a way to vote to push back the launch deadline for Stacks 2.1 to give us some more time.

Background

One of the Stacks 2.1 features is to give STX holders the ability to vote to stop the network (#2612). This is meant to facilitate carrying out backwards-incompatible upgrades in the future. If the community of STX holders wants a new feature badly enough, they can implement a new minor version of Stacks with the breaking changes, make it compatible with the old Stacks chainstate, and then vote on a "flag day" at which point the new version must be ready.

Stacks 2.0 did not ship with this feature, because Stacks 2.0 is already hardwired to stop at Bitcoin block 700,000. Stacks 2.1 will have this voting feature, so that if there's ever a Stacks 2.2, the community decides when (or if) it must be ready.

The purpose of this document is to describe a way to ship #2612 before Stacks 2.1, as part of a Stacks 2.0 point-release. Then, the community can vote to push the Stacks 2.1 deadline back.

Rationale

For unrelated reasons, a few of the Stacks core developers are going to be unavailable for several weeks around the time of the Stacks 2.1 launch. As such, we're not confident that we can ship and adequately test all of the features that were proposed in the Stacks 2.1 upgrade thread. But, we don't feel like anyone has the right to decree when a network upgrade can happen, either (SIP-011 attempts to codify this further). Blockchains are meant to distribute this power among the users, so users should have a way to decide when the running system gets upgraded.

EDIT: Furthermore, the hard-stop at Bitcoin block 700,000 actually won't happen anyway -- there's a bug in the code that prevents the check to halt from activating. See #2737.

Voting to Exit at a Block Height

Issue #2612 calls for expanding the functionality of a testnet-only configuration flag called exit_at_block_height. This feature has been used in the past to make it so all testnet nodes stop running at a particular Bitcoin block height. During the days of the Argon and Krypton testnets -- in the days before the current testnet -- we used this feature to cause the testnet to restart periodically, so new changes could be pushed out for early testing.

If implemented, #2612 would move the exit_at_block_height functionality into a smart contract on mainnet. In this smart contract, users would be able to vote on a future Bitcoin block height at which the entire Stacks network would stop processing new blocks. If such a block was agreed upon, all mainnet nodes would stay online once they reached it, but they would simply cease downloading new Stacks blocks after it. This way, if there was a new version of the Stacks blockchain that was imminently available, users would use this feature to kill the old protocol in order to activate the new protocol (and moreover, decide at which point the new protocol starts getting used). Think of this as way to do hard forks by user consent.

How do users decide when the system should be upgraded? Historically, on-chain coin votes on other blockchains have been plagued with low participation -- even truly catastrophic cases, like the DAO incident, had only 4.5% turnout. So, a naive coin-based voting system is probably not the best way to gauge consent.

Since the launch of Stacks 2.0, it has become apparent that the two sets of users that have the most on-chain involvement (and most skin-in-the-game) in the evolution of the protocol are Stackers and miners. Therefore, any mechanism that gets used to vote to upgrade should be carried out with both these user groups' consent.

What I'm suggesting we do is create an on-chain smart contract similar to the .costs contract in which both Stackers and miners vote propose and affirm a Bitcoin block height at which the chain stops. Like the .costs contract, the vote would be carried out in two phases: (1) Stackers would vote on a Bitcoin block height, and if the vote is sustained, (2) miners would have a chance to veto it. So in order to vote on when the chain will be upgraded, you have to either be stacking STX (either by yourself or through a pool), or mining.

Once deployed, we'd release a version of Stacks 2.0 that implements #2612 that uses the contract. It would be set to initially cause the chain to stop at Bitcoin block 700,000, but with the option of being pushed back. Then, we'd ask that the stackers and users vote to give us some more time by pushing the Stacks 2.1 release deadline back to a new Bitcoin block height, to be determined via the SIP process.

Voting Details

This is something I welcome feedback on. In a bid to keep the system simple, I'm proposing the following voting system based on locked tokens. My goal is to make vote participation as painless as possible -- it should be a one-time thing.

Phase 1: Stacker Votes

Votes are tallied at the end of each reward cycle. During reward cycle R, an account with a non-zero locked token balance may vote for any block height B, where B is at least 700,000 (note that this means that in the case of pooled Stacking, it's the pool participant, not the delegate, that must vote). The account may vote on at most one B in R.

Votes are all-or-nothing. An account cannot split their locked STX across multiple values of B.

Votes are standing votes. Once a vote is cast for B in R, it remains cast for B in all future R+k while their STX are stacked. A voter can change or retract their vote during a reward cycle at any time; the tabulation only comes at the very end of the reward cycle (i.e. when a new anchor block is selected). When a user's STX are unlocked, they will need to re-vote when they re-stack them (i.e. unlocking retracts the vote).

A vote for B is sustained if all of the following are true:

• B is at least 15,000 Bitcoin blocks in the future (about 1 quarter, plus 1 reward cycle) at the time of tabulation.
• At least half of the stacked STX cast a vote
• Of the voting stacked STX, a majority of them back a particular value for B.

For example, there are 362,206,704.88 STX locked in PoX right now. So, over 181,103,352.44 of them must cast a vote of some kind in the current reward cycle for a vote to occur. If over 90,551,676.22 of them vote for the same B, then B is sustained.

The rationale of this majority-of-the-majority voting is that I expect a sizable portion of STX holders to be apathetic. I'm flexible on the exact thresholds or tabulation mechanisms.

Once a vote for B is sustained, it is locked in, and miners have a chance to veto. No subsequent votes for B will be considered until after the veto period passes.

Phase 2: Miner Veto

Once a vote for B is sustained in reward cycle R, miners may vote to veto the decision during R+1. To do so, a miner must include a transaction within their block that calls into the contract to veto the vote. If at least 80% of miners vote to veto the decision in R+1, then the vote for B is cancelled.

I chose 80% here because that's the threshold of miners who must vote to begin PoX in a prepare phase. If PoX gets disrupted due to a contentious upgrade vote, then that would be bad for everyone.

Multiple Rounds

Once a vote for B is sustained and not vetoed, it becomes the new exit-at-block-height value. All votes are then cleared from the system. Stackers and miners may vote again to push B further back if they desire -- i.e. if more time is needed to procure an upgraded version of Stacks.

Any attempt to select a new B must pick a B that is strictly higher than the previous value of B. For example, if the users voted for block 800,000 as the new exit-at-block-height, they could not later vote for 750,000. Any new vote for B would have to be greater than 800,000.

Proposed Procedure

I'm proposing the following high-level development roadmap to ship this:

1. We deploy an exit-at-block-height contract, which allows Stackers and miners to vote to upgrade the chain by voting on a new Bitcoin block height at which the Stacks network will stall, according to the rules above.

2. We modify the Stacks node in a backwards-compatible way to monitor the deployed exit-at-block-height contract (addressing In-band upgrades: vote on exit-at-block-height #2612). If a Bitcoin block height is agreed upon, then the Stacks node will stall once that Bitcoin block height is reached. If no height is agreed upon, then it will continue to behave as-is -- i.e. it'll stall out at Bitcoin block 700,000 as planned.

3. At the same time, we publish a SIP that describes all the features that will be present in Stacks 2.1, and proposes a to-be-determined Bitcoin block height at which the SIP may activate. This block height is what the SIP steering committee and its consideration advisory boards will recommend to the users as the block height to vote for. The SIP will not transition to activation-in-progress status until a Bitcoin block height can be agreed upon, or until Bitcoin block 700,000 is reached (whichever happens first).

[pavitthrap]

• The way the voting works, a particular stacker must choose a specific block height B. In order for B to be the new exit block height, a majority of the participating voters must vote on the same B. I understand we have a goal of making voting as easy as possible (voters need to vote for a singular number, which is easier than spreading their commitments across a range), but I feel like this level of strictness could "centralize" the process. People will probably select the B that either the Stacks Foundation/ Hiro endorses, or one that a large mining pool proposes. Perhaps a way around this is to bucket the votes on our end. For example, perhaps we could pool all the votes in the range 700,000 to 705,000. If there is a winning bucket, we can then take the median of that bucket to be the exit block height.
• Do we want to consider putting a cap on how large a B people can vote on successfully? We chose a minimum of N+15,000 for B (where N is the current height), but a considering any new B must be strictly higher than a previous B, perhaps a cap could make sense to mitigate a B that is too large.

[jcnelson]

Perhaps a way around this is to bucket the votes on our end. For example, perhaps we could pool all the votes in the range 700,000 to 705,000. If there is a winning bucket, we can then take the median of that bucket to be the exit block height.

I like this idea! What do you think about making it so people select a particular reward cycle at which the 2.1 roll-over happens, instead of a block height?

Do we want to consider putting a cap on how large a B people can vote on successfully? We chose a minimum of N+15,000 for B (where N is the current height), but a considering any new B must be strictly higher than a previous B, perhaps a cap could make sense to mitigate a B that is too large.

I'm not too worried about this because a very large B would simply mean that Stacks 2.0 continues as-is for a while. But considering that Stackers are the ones casting votes, and 2.1 enables continuous Stacking, I don't think they'd do this in practice. But I think a reasonable upper bound on B would be fine, just in case.

[314159265359879]

* For example, perhaps we could pool all the votes in the range 700,000 to 705,000. If there is a winning bucket, we can then take the median of that bucket to be the exit block height.

If you are planning an upgrade would it make sense to only upgrade after a stacking cycle has been completed? Would that dictate picking multiples of 2100 blocks to vote on from 666,050?

[jcnelson]

Yes, that's correct. The epoch switch to 2.1 would happen at the start of a reward cycle; Stackers would be voting for which one.

[gregorycoppola]

Just as a thought.. it seems like the problem with voting for individual block heights is that there is no understanding of how different heights relate to each other. I.e., if people vote for blocks 10, 11 and 20, there is no way of understanding that 10 and 11 are more similar votes.

But buckets have the same problem as individual integers, as the relationships between nearby buckets will not be taken into account. (In fact, using individual integer votes is simply using buckets with a bucket size of 1.)

An alternative you could consider is voters can vote for "a block to wait until", and then take the smallest block such that >50% of voters would be satisfied in their "wait until" requirement.

For example, if the votes were to "wait until" blocks 10, 11 and 20, we can satisfy a majority (2/3) voters by waiting until block 11.

[hstove]

What Pavi wrote about the "centralization" seems correct to me, but I don't think that's a bad thing. As Jude said, 2.1 is good for Stackers, so they want it as soon as possible. So, the most likely outcome is that the core devs say "we can get the intended 2.1 upgrades at block X", and then everyone votes for block X. But what's wrong with that?

[kantai]

I think this is a good idea!

EDIT: Oh, yes, the proposed voting system already is doing a per-reward-cycle vote.

[jcnelson]

Per your earlier edit, I clarified the text to say that the stacker would need to re-vote if they re-stack (and the STX unlocking would in effect cancel their vote).

[hstove]

Thanks for the detailed write-up Jude!

To me, it seems odd to ask stackers to just pick a block and vote on it, because the main rationale for the pushback is that it's not likely going to be ready at 700,000, due to resource constraints. The resource constraints are perfectly understandable, but doesn't that mean that voters need some guidance on a more realistic upgrade date?

Basically, I think the direction should be flipped. Instead of "pick a new block, any block after 715k", it should be more like "the core team believes that X is a more realistic date to ship the intended features of 2.1, please vote to allow delaying the hard fork". After all, the trade-off is that we don't change the date, get a half-finished release, and then need to do another hard fork later.

From my selfish perspective, I'm very excited about 2.1 and the proposed changes in it. I would like to have them as soon as possible (because it doesn't cost me anything). So I would much rather just agree on a date that can include the changes I'm excited to see, instead of needing to hard fork again.

[jcnelson]

Thanks for the feedback everyone! I like the idea of Stackers voting on a reward cycle number, instead of a block height -- makes it a lot less confusing.

I've given this some more thought. I'm particularly worried that if there's not enough participation, we'll be stuck with 700,000. So, what if we did the following instead?

• We release a version of Stacks 2.0 with this feature, but the 700,000 block height limit is removed. Stacks 2.0 continues indefinitely until there's enough votes for a particular reward cycle.

• We make it so that Stackers votes only count if they are for a reward cycle that is at least 6 reward cycles away (about 3 months). Votes for a reward cycle that are closer than this will be ignored.

• We structure the contract so that votes won't begin to be considered until Bitcoin block 700,000 hits anyway. This effectively buys us at least 3 more months, which I think we're gonna need. We can adjust this as well.

If we do these three things, then Bitcoin block 700,000 becomes the deadline for having rolled out nodes to miners with this contract enabled, as well as the deadline for shipping the Stacks 2.1 SIP which contains a recommended reward cycle number at which we expect the SIP to be ready to activate. The 2.1 SIP will require as part of its activation criteria that this contract is used to vote to kill the 2.0 chain.