Release discussion for Stacks 2.1 as a freeze of next

[wileyj]

discuss what changes in 2.1 could reduce the limitations to integrating a bridge.
@MarvinJanssen

[xanbots]

Pasting the relevant information in here. One thing worth thinking about is if it's worth pushing a much more targeted upgrade to enable these bridges and partnerships first, and then pushing a wider 2.1 upgrade later. In addition to the partners mentioned below, I have 1-2 other bridge providers who would integrate if we solved these blockers. The current situation is as follows:

Right now Ozy's, Allbridge, ALEX, and some others are all running into the same issue. It all ties into what is described in SIP018 as well. In essence, bridges, (some) oracles, and any protocols with an off-chain component want to sign actionable messages that can be verified on-chain. That means you have to be able to produce a hash of those messages and sign them. Right now there can be some workarounds depending on the project. Some of these messages are quite simple. Example: RedStone oracle price messages. You can see how @MarvinJanssen built a message verification contract for it in Clarity. (Complete with the eth personalSign prefix.) https://github.com/MarvinJanssen/redstone-clarity-connector/blob/c79eb1581861abd361512979fda302d6885be058/contracts/redstone-verify.clar#L34-L36

And sometimes a workaround is ok, but in addition principal-of is also broken right now, which makes any workarounds even more difficult. Some projects, like those mentioned above, however, cannot really get around these two limitations. What bridges want in their signed messages (whatever the format) is a target address to send the tokens to. Right now there is no way to assemble a principal properly on-chain. So you might think the message poster can just resort to submitting native types to the contract directly, but then there is no way to verify if the that principal is the same as the target in the signed message.

Link to SIP018 proposal: stacksgov/sips#57

[kantai]

What is the minimum set of consensus changes to satisfy bridge and other off-chain implementations? In SIP-018, only

to-consensus-buff

Is proposed, but I'm also gathering from the discussions that an improved to-principal would also be required in many cases (though it may have workarounds unlike to-consensus-buff), and I'd guess that in many cases a from-consensus-buff would also be helpful.

Is there a way to know definitively that those three functions are the minimum set? Maybe this is a question for @MarvinJanssen, but would testing a contract with, say, a version of clarity-repl that included those functions tell us whether or not they are sufficient?

[jcnelson]

It is my understanding that we only need principal-of to be fixed. to-consensus-buff and from-consensus-buff would help a lot, but strictly speaking they are not necessary, since once you can (1) verify the signature of a buff and recover the public key, and (2) convert the public key into a principal, you can then parse the buff into a Clarity value within Clarity.

Converting principal types to/from buffs and parsing buffs into Clarity values would be helpful (and would likely significantly reduce runtime costs and code complexity), but they're not strictly necessary to get bridges working.

[kantai]

Serializing and deserializing within clarity is immensely painful, and I'm not sure those two functions would add significantly to the work of a network upgrade. Basically, my question is, is there already a good example contract for a bridge that someone could point to and definitively say "hey, here's this advanced thing, that 3-4 major projects want to do, and is achievable with just these new functions"?

[jcnelson]

cc @MarvinJanssen @wileyj

[MarvinJanssen]

@kantai it is indeed immensely painful. Here is one such example for a very simple structure https://github.com/MarvinJanssen/stx-signed-structured-data/blob/main/contracts/money-orders-legacy.clar.

There are more complex one, but these are not public yet as far as I know. And of course any structure involving a principal is impossible. I know AllBridge, ALEX, Orbit Chain, and others are largely blocked due to the lack of conversion functions (not necessarily consensus buff in each case) and principal-of being broken.

[MarvinJanssen]

Thanks for posting @xanbots. I would be very happy with a SIP012 style upgrade that fixes principal-of at the bare minimum. But I can see scope creep. I'd want more Clarity features sooner rather than later, ha!

[jcnelson]

I'm not opposed to doing a SIP012-style upgrade that fixes principal-of if there's strong community support for it (it's not up to me whether or not this happens in Stacks 2.1 or in a separate upgrade; I'm just a facilitator for the community's wishes here). Call it Stacks 2.06 if you want. But I'd like to scope out exactly what else we need to do in order to get bridges to work. Do we need to-consensus-buff from SIP018? Do we need principal-construct (still a PR)? How much of what these partners ask for is out of necessity vs. convenience for them?

[MarvinJanssen]

Those two would definitely be convenient but not strictly necessary. to-consensus-buff would allow for full support of SIP018 by being able to hash the principal and string-utf8 types.

[xanbots]

@jcnelson how would you like us to gather the support from the community to push this forward? Comments on this issue?

[kantai]

What you describe would be an abuse of the process. The SIP must describe what's going into it before it gets advanced to Recommended status.

I don't think this is an abuse of process. I think it would produce a much better process for all involved. The goal would be to set a target date for the SIP to be finalized with "Draft" status -- in this draft status, it would contain all and only the functions actually implemented by the target date. The authors wouldn't add or edit the SIP except for any changes proposed by reviewers during the process as it moves towards "Accepted" or "Rejected". There would be no ambiguity during the review how much work still remains, whether or not the core contributors have bandwidth, etc., the implementation would already be largely done.

I'm not proposing that the SIP process be shortened. I'm proposing that the process for the "2.1 SIP" use a time target to figure out what should and should not be included in it. The alternative (i.e., what's happening now) requires the SIP authors to make that trade-off by themselves with no clear boundaries for when a SIP should be opened (or when an opened SIP "Draft" is actually ready to start to move to accepted).

it's just a deviation from a normal release process

It's not a deviation -- it's the norm for breaking changes.

I'm not sure there's actually a disagreement here. I'm not at all saying that vote-to-exit shouldn't be required for breaking changes. In fact, I absolutely think that it should be. When I used "normal", I was referring to the release processes used by software in general, and of course vote-to-exit is not normal in that sense. All I'm trying to convey in the discussion of vote-to-exit is that as far as planning is concerned, vote-to-exit requires a buffer in the timeline-- I can't think of how else could it impact the process: implementation must be done before the network could usefully vote to upgrade. Obviously, a "non vote" could occur and prevent an upgrade entirely, but that's not really something worth reasoning about when talking about release timing (because a non-upgrade doesn't require any planning).

I'm not advocating for any specific date-- I'm advocating for some date to be picked. It may not even be necessary to work backwards: instead a date could be picked for a next freeze, and then SIP-015 would be updated to contain only what is in next at that time.

I think this is worthwhile, because otherwise, what criteria could be used to know when a 2.1 upgrade is ready? The current 2.1 SIP is still a draft, and it contains proposals for features that still haven't been implemented. If implementation of the remaining features takes another few months, what if other features are proposed? Should they be added to the SIP while it's still a draft? What if the implementation of the features takes longer than expected? Should the SIP be pared down before it moves forward in the review process? Answering these questions is hard and contentious and, on top of all that, requires estimating unknowns about implementation times. If instead, we set a deadline for SIP-015's draft at date X, such that at that point, SIP-015 would be ready for the review process, and contain all and only the implemented features in next, then at least the time estimation is removed from the process. The task of reviewers would be simpler: they are now deciding, "does this set of features warrant a network upgrade?". It would also provide network participants much clearer insight into what is actually slated, and everyone involved would have a clearer timeline.

[jcnelson]

The goal would be to set a target date for the SIP to be finalized with "Draft" status -- in this draft status, it would contain all and only the functions actually implemented by the target date. The authors wouldn't add or edit the SIP except for any changes proposed by reviewers during the process as it moves towards "Accepted" or "Rejected". There would be no ambiguity during the review how much work still remains, whether or not the core contributors have bandwidth, etc., the implementation would already be largely done.

The SIP process currently requires that all SIPs have an Activation section that describes to the Steering Committee a falsifiable procedure to use to determine whether or not the proposal has been accepted [1]. That procedure can mandate a date by which the SIP must be activated. If the Activation section cannot be executed -- i.e. the deadline has passed -- then the SIP will be rejected per the SIP lifecycle [2]. As a convention, the technical consideration advisory board [3] (which, admittedly, right now is just myself; you're welcome to join it if you want) always requires that an Accepted SIP has an Activation section that includes a reasonable expiry date before voting to advance the SIP from Accepted to Recommended status. So, enforcing a target date is certainly doable.

I'm not proposing that the SIP process be shortened. I'm proposing that the process for the "2.1 SIP" use a time target to figure out what should and should not be included in it. The alternative (i.e., what's happening now) requires the SIP authors to make that trade-off by themselves with no clear boundaries for when a SIP should be opened (or when an opened SIP "Draft" is actually ready to start to move to accepted).

The "2.1 SIP" should include a date (in Bitcoin blocks) at which the network must vote for a target reward cycle via the "vote-to-exit" smart contract. Also, the Activation section should require that the "vote-to-exit" contract logic and kill-switch should be merged to master and deployed on Hiro's and the Foundation's infrastructure before the SIP transitions to Recommended status.

In general, opening a SIP can be done at the drop of a hat. A SIP transitions from Draft to Accepted one a SIP Editor [4] determines that the SIP is in-scope and well-formed (this is easy). A SIP that's in Draft or Accepted status can be revised arbitrarily -- we did this in SIP-012, for example. Once it's Recommended, however, the Steering Committee will either transition the SIP to Activation-in-Progress or Rejected, the latter of which triggers a revise-and-resubmit. This latter path hasn't been taken yet, since so far, SIP authors have been good at incorporating feedback from the various consideration advisory boards.

So, to do what you're suggesting with the second planning mode, I need you to take the following steps:

1. Write and submit a Draft-status SIP. This is the act of opening a PR against the stacksgov/sips repository, with the lowest unused SIP number.

2. Once SIP has had a read-over by a SIP Editor (currently just me -- again, looking for more members on the SIP Editor Committee), it gets transitioned to Accepted status. You're still free to make changes until the various consideration advisory boards do a review pass. You can control when this review happens simply by:

   a. Not listing any considerations in the Preamble section, and/or

   b. Explicitly ask that the relevant consideration advisory boards hold off their review until you're ready. They'll more than likely simply give you feedback as comments on your PR, as has been done in the past.

3. Once you're done making changes, the consideration advisory boards will each vote to advance the SIP to Recommended status. No more changes can be made without a Reject/resubmit. In SIP-012, for example, both the governance and technical consideration advisory boards voted to advance the SIP.

4. The Steering Committee takes it from there. They'll either reject the SIP if they disagree with the recommendations (this hasn't ever happened), or they'll advance the SIP to Activation-in-Progress. Once the Activation criteria are all met, they'll transition the SIP to Ratified. To date, all SIPs that have made it to Recommended status have been Ratified (and we'd like to keep it that way), so from the perspective of a SIP author, this step is a formality.

To answer your specific questions:

I think this is worthwhile, because otherwise, what criteria could be used to know when a 2.1 upgrade is ready? The current 2.1 SIP is still a draft, and it contains proposals for features that still haven't been implemented. If implementation of the remaining features takes another few months, what if other features are proposed? Should they be added to the SIP while it's still a draft? What if the implementation of the features takes longer than expected? Should the SIP be pared down before it moves forward in the review process?

• No back-dating changes after the SIP is Recommended. Get these done while the SIP is in Draft or Accepted status. This includes both paring down the SIP, or adding new features.

• Don't ask for the various consideration advisory boards to do an official review until after the feature-freeze in next. But, do ask them for unofficial feedback, such as Github comments.

• Add a target date to the Activation section by which the SIP must be ratified. You can do this after the next freeze.

Hope this clarifies how this can all be done within the SIP process.

[1] https://github.com/stacksgov/sips/blob/main/sips/sip-000/sip-000-stacks-improvement-proposal-process.md#overseeing-sip-activation-and-ratification

[2] https://github.com/stacksgov/sips/blob/main/sips/sip-000/sip-000-stacks-improvement-proposal-process.md#sip-workflow-1

[3] https://github.com/stacksgov/sips/blob/main/considerations/technical.md

[4] https://github.com/stacksgov/sips/blob/main/sips/sip-000/sip-000-stacks-improvement-proposal-process.md#sip-editor-duties

[diwakergupta]

If there's something Hiro wants by August, Hiro should start by writing and submitting the SIP as soon as possible. That's what happened in SIP-012.

Not sure why Hiro is getting called out here :) I think the discussion points @kantai brought up are more general, not specifically in reference to a given SIP. And yes, if Hiro wants something by a specific date, we will indeed put up a SIP as soon as reasonably possible (as in SIP-012). Meanwhile, there are a number of different community members working on several new SIPs: I think some amount of discussion, soliciting feedback and building alignment prior to sending a SIP is totally fine and even desirable (just like with SIP-012).

[diwakergupta]

Also, this particular discussion thread isn't specific to the original discussion topic, so I might suggest moving it to its own discussion, if further discussion is needed.

[jcnelson]

Also, this particular discussion thread isn't specific to the original discussion topic, so I might suggest moving it to its own discussion, if further discussion is needed.

The topic was on how to gather community feedback, and this conversation is how to use the SIP process to do just this. I think it's very relevant.

[diwakergupta]

Heads up that the original title of the discussion ("Clarity bridge limitations") wasn't descriptive -- especially for people new to this discussion and lacking prior context -- so I took the liberty of updating it for clarity (pun intended). I'm sure others can come up with better titles; please feel free to tweak as needed.

The general consensus from the latter two camps is that because the delta between getting this hypothetical network upgrade out the door and getting the whole of 2.1 out the door are about the same (i.e. within one quarter), it might make more sense to just aim to ship 2.1.

@jcnelson was this discussed in the architecture meeting? Might be worth reviewing the current known set of work items for 2.1 in today's Monday meeting and pressure-test timeline estimates?

[cargocultscience]

One advantage that I can see to doing this upgrade before the whole of 2.1 is that it would force miners upgrade to a release that has known performance improvements. We see performance issues consistently. If we believe that this is in some part due to miners not running code with improvements or suboptimal settings, using this code change as a forced sync event, may have value.

[jcnelson]

Thanks for your input, but I don't think this is a good enough reason to do a network upgrade.

First, while we have seen a couple of bursts of activity in the past couple weeks, miners have successfully cleared the mempool. While it is the case that sometimes less-than-full blocks got mined, in the last burst it was the case that blocks were either over 95% full or were empty (and empty blocks were much rarer). We know that empty blocks are caused by Bitcoin flash blocks -- more specifically, by miners not having had a chance to scan through the mempool in time to RBF their empty block-commit with a full block-commit. With the 2.05.0.2.0 release, they will get rarer still, since it substantially improves the mempool scan time (by at least a factor of 6, and this measurement is a lower bound). Also, miners are already incentivized to upgrade to the latest release since they get more transaction fees that way, so miners that don't upgrade will get priced out of mining and disappear on their own.

Second, blockchains do not scale by design. In a successful blockchain, it will never not be the case that there is sustainably more block supply than demand. If there is, it's a bad sign -- it means that the blockchain is either not growing its userbase or is shrinking. Network upgrades to increase the block capacity are a Red Queen's Race -- even if you increase block capacity by a million-fold, users will find a way to congest the network. Efforts to increase the overall system capacity in a sustainable way necessarily require multi-layer systems like hyperchains and appchains.

[aulneau]

I think there should be more weight given to upgrades that will improve the overall experiences that users have when interacting with the network. One of the biggest downfalls of stacks currently is the perceived (and real) limitations around transaction speed and finality. It's true that blockchains do not scale, but i don't think that's a good reason to not try and make things better.

I find that often there are two camps here: one, the users who just want to use the network and participate in apps built on top of it. They run into real downsides and negative experiences, and the very small amount of folks who are aware of where and how to communicate these things are often met with answers like "blockchains do not scale."

The other camp are the devs and engineers who are working on the core code. The things that they are focused on are very deep in the weeds when it comes to the overall structure/architecture of the software that powers the network.

For me, personally, it feels like there is a huge disconnect from the folks who have the most power to affect change to the network and the end users. I wish there could be a better understanding of what users are experiencing, and rather than shutting down requests or feedback with a few different answers, or pointing to potential abstraction layers that are likely years away from being a realistic option, they take them into deeper consideration.

I personally think we should be doing everything we possibly can to quickly ship upgrades to the network that improve the end user experience of people using and participating in the network.

[muneeb-ali]

I personally think we should be doing everything we possibly can to quickly ship upgrades to the network that improve the end user experience of people using and participating in the network.

A big +1 to @aulneau. In my view, any upgrade that improves the user experience needs to go live with a sense of urgency. The no. 1 feedback that I receive from people is that they love the idea of Bitcoin DeFi or Bitcoin NFTs but when they actually try using the apps they're sort of disappointed by the experience currently.

The Stacks open-source project (like any startup) has some sort of a window of opportunity where either people are going to get really behind it or they'll get disappointed and move elsewhere. The early times in the window of opportunity are more important as you want to build developer momentum. It's absolutely critical that key bottlenecks (like bridges) and speed/capacity are addressed with a strong sense of urgency. Once a project is a lot more mature, making changes becomes that much harder. Stacks is not at that level of maturity yet and needs to be more nimble. Also, we have the two layer design where Bitcoin is the stable money layer that is hard to change and Stacks the programming layer can upgrade more frequently. There are developers and startups built on top of the open source Stacks project that are hitting fundamental limits (like lack of bridges to bring liquidity), and they can't move forward unless the network upgrades at the blockchain level can move forward.

The SIP process sort of puts the speed in the hand of (a) people who're willing to write SIPs and steer them through the process and (b) the folks who vote on the network upgrades. I think people in both (a) and (b) are motivated and want to move with a sense of urgency. I think a lot of us are feeling the same thing but it's good to have this discussion and hear opinions!

[jcnelson]

Breaking changes in the Stacks blockchain are proposed, considered, and ratified through the SIP process. If you want a breaking change to happen, then you'll need to submit a SIP.

I don't understand why this is suddenly controversial. We did it with SIP 012. Where's the SIP for unblocking bridges?

[muneeb-ali]

Breaking changes in the Stacks blockchain are proposed, considered, and ratified through the SIP process.

We're in agreement here. The general sentiment in my comments and some others I've read is that the SIP process should be used more frequently and at faster speeds. I don't think that anyone is suggesting not using the SIP process.

[jcnelson]

Is there something preventing hyperchains from implementing bridges? Like, could the hyperchains implementation ship with a fixed principal-of function, which would in turn permit bridges to be built between hyperchains and other blockchains? The wrapped assets on the hyperchain could settle to the Stacks chain if the owner desires -- the peg-out code could instantiate the wrapped asset (instead of unlocking a pegged-in asset) when the user does this.

Implementing and shipping the necessary bridging functionality on hyperchains could be done faster than a targeted upgrade to Stacks. If we look at SIP 012, it took nearly 2 months to go from the SIP 012 PR to SIP 012 ratification. So if we dropped a similar SIP for Stacks today, we could expect it to take until the end of June. If hyperchains are going to ship sooner than that, then why not just do the necessary work there? Then, the Stacks 2.1 upgrade could happen later this year, as planned, and bridge implementations would be unblocked.

Thoughts?

[kantai]

Hyperchains are kind of relevant in a few different ways here. One is that hyperchains themselves would benefit immensely from the same serializing/deserializing features that bridges would. Notably, the withdraw support (basically, "write-back-to-L1" support) would benefit from it. There's an issue that kind of discusses some of the trade-offs here (hirosystems/stacks-subnets#60), but even with a merkle-tree hashing scheme tailored to making the verification of a withdraw easier in Clarity, it is still painful. Basically, you want in Clarity to represent something like:

(define-private (get-buffer-for ((recipient principal) (token-name (string-ascii 20)) (amount uint))
  ...)

This is really painful to do, and it's not clear it's even possible without some kind of like registration scheme (basically, on L1, would-be recipients claim a nonce from the L1 contract, which is used to identify them in the withdrawal merkle tree).

The other point is that hyperchains are themselves not that close to widespread adoption on mainnet -- it'll take time to gain confidence in any such implementation. Finally, I'm not sure that hyperchains solve much for bridges: on some level, a hyperchain is basically just a bridge-to-its-own-chain, so it needs to solve the same problem that bridges are trying to solve, and any bridge operator is probably better served without that intermediary.

[jcnelson]

Thanks for the context. Am I to understand that hyperchains are blocked on a hypothetical targeted upgrade for bridge support?

[MarvinJanssen]

@kantai great point regarding the registration scheme. We ended up doing pretty much the same thing. (Principal registers can gets a user ID which is used for identification.) Kind of wasteful too since you get a read dimension hit you wouldn't otherwise. And the solution doesn't work for most cases. Imagine if any bridge recipient first needs to register with the bridge before it can receive tokens. That would be pretty bad UX.

[jcnelson]

I spoke with a few more folks in the ecosystem about this idea. The thing is, right now next has a lot of the other goodies we've promised in 2.1 -- namely, improvements to Stacking and mining that I don't think should be put off if we can help it. Instead of doing a targeted upgrade, what if we instead got next to a point where it (a) is in a runnable state, and (b) included the features that unblocked bridges, and (c) released that as a hard fork? This would leave a lot of the remaining reliability improvements slated for Stacks 2.1 on the table, to be completed likely by the end of the year, but it would get the ball rolling on things like bridges, mining pools, stacking pools, Bitcoin transaction interaction, and so on.

The work stream would look like this:

• Get next into a runnable state

  • Finish all remaining items for .pox-2. This is PoX Updates: stack-unlock #2534 and PoX Updates: .pox-info contract for native information getters #2538.

  • Finish the decentralized mining pool workstream. This is [chainstate] Add support for pay-to-contract in coinbase transaction variant #3101 and PoX: native segwit support #2586.

  • Add a .costs-3 contract for the new Clarity built-ins ([Clarity] need a .costs-3 contract for Stacks 2.1 and associated benchmarking #3115).

  • Add Clarity contract version pragma ([Chainstate] SmartContract tx wire format to indicate which Clarity version to use #2719)

  • Decide and determine the VM behavior when calling code across Clarity version and epoch boundaries ([Clarity] rules for determining which Clarity version to run #3131)

• Finish Feature request: allow hashing functions to hash other Clarity types #2693 and merge feat(Clarity2): Parse and assemble principals #2756, which are the only remaining items for bridges

• Freeze next and release it as Stacks 2.06.

What do you think?

[diwakergupta]

I spoke with a few more folks in the ecosystem about this idea. The thing is, right now next has a lot of the other goodies we've promised in 2.1 -- namely, improvements to Stacking and mining that I don't think should be put off if we can help it. Instead of doing a targeted upgrade, what if we instead got next to a point where it (a) is in a runnable state, and (b) included the features that unblocked bridges, and (c) released that as a hard fork?

Hmm, on paper this seems reasonable (even desirable), but IMO it would boil down to exactly what's in next today, and in particular, what implications would it have for various ecosystem stakeholders. Specifically, does next currently include any breaking changes to Stacking or mining (that is, without extra work on the part of Exchanges or other integrators, what is working today would stop working)? Based on the workstreams here, I think not, but would be good to confirm (cc/ @kantai )

The other consideration is the time to test: the larger the surface area, the more testing would be required. I'd be especially worried about Stacking / PoX changes, because those will require very thorough testing. Same for additional Clarity benchmarking.

Let's name the 2 options:
O1: cherry pick specific changes the community wants to package as Stacks 2.06
O2: get next into a runnable state; finish implementing above work items; freeze next

O2 makes sense if you believe time to finish work, test and roll out O2 is only marginally greater than (say no more than 4 weeks) time to finish work, test and roll out O1. Based on past experience with blockchain releases, I'm skeptical -- I worry we're underestimating the delta between O2 and O1.

Would love to hear from other stakeholders!

[wileyj]

The other consideration is the time to test: the larger the surface area, the more testing would be required. I'd be especially worried about Stacking / PoX changes, because those will require very thorough testing. Same for additional Clarity benchmarking.

I second this concern - particularly now that there is a bug bounty program with financial incentive to find issues with those core contracts, thorough testing (ideally with an external review as well) would be required.

[jcnelson]

Specifically, does next currently include any breaking changes to Stacking or mining

As @kantai explained below, it does change Stacking. The Foundation is more than happy to take the lead in walking exchanges and stacking pools through the process of re-locking their tokens into the .pox-2 contract.

Same for additional Clarity benchmarking.

This is going to happen regardless, because unlocking bridges is achieved by adding new Clarity built-ins.

O2 makes sense if you believe time to finish work, test and roll out O2 is only marginally greater than (say no more than 4 weeks) time to finish work, test and roll out O1. Based on past experience with blockchain releases, I'm skeptical -- I worry we're underestimating the delta between O2 and O1.

I strongly suspect that the community would prefer O2, even if it takes longer than an additional 4 weeks, because there are other projects besides bridges that would be unblocked by O2. A different way to frame this is, what makes bridges so special that they deserve a targeted hard fork (O1) that bumps everyone else back by at least 6 months?

[kantai]

Specifically, does next currently include any breaking changes to Stacking or mining (that is, without extra work on the part of Exchanges or other integrators, what is working today would stop working)? Based on the workstreams here, I think not, but would be good to confirm (cc/ @kantai )

Yes, next does include breaking changes to Stacking and mining. Any consensus change is a breaking change for miners, but there aren't any changes to mining in next that would require miners do anything but update their software. The changes to Stacking are much more like traditional breaking changes: there is a new pox-2 contract, which is configured to take over as the PoX-governing contract after some number of blocks after the network upgrade. Anyone that wants to participate in Stacking after that switch over needs to invoke methods (like stack-stx, etc.) on the pox-2 contract rather than the current pox contract. next already has an implementation for extending a lock without the "cooldown" period required in the current pox contract, and using this extend behavior would allow anyone currently stacked in pox to "re-stack" in pox-2 so that they don't miss reward cycles during the switch over. However, Stacking participants, pools, other integrators would absolutely need to make changes to work with the new PoX.

(Edit: meant this to be a reply in this thread, not a new message in the discussion topic)

[jcnelson]

Notes from the blockchain call:

• We need a "Clarity version selection" top-level pragma, so you can publish a Clarity1 contract in Stacks 2.06 or later. The use-case is using a trait that uses a previously-allowed but now-forbidden keyword in the definition -- we'd want to make it possible to write a shim contract in Clarity1 so a Clarity2 contract could use it. Could achieve this with either an in-language pragma, or a version byte in the "publish" transaction payload (the latter is easier since it doesn't add to the Clarity parser).

• Rigorously test (at-block) behavior across epoch boundaries.

• next is not blocked on "vote-to-exit" contract. We can use SIP-012's voting procedure here if we don't feel like this contract will be ready in time (but we do want to use this approach long-term over SIP-012).

• Next item is to get a timeline for testing and voting where there are no more unknown-unknowns

[jcnelson]

I renamed this discussion to "Release discussion for Stacks 2.1 as a freeze of next", since that appears to be what the general consensus going forward is. I'd be in favor of doing the following:

1. Finishing all the "high" and "very high" pain points on this checklist: Time estimates for remaining 2.1 work items #3096

2. Freezing next

3. Fleshing out SIP-015 to describe what's in next, and how to test it and activate it

4. Executing a SIP-012-like vote to decide when SIP-015 activates, thereby releasing Stacks 2.1.