Hey folks,
With Stacks 2.0 right around the corner, I thought I’d take a moment to explain what happens afterwards. Not all of the features we wanted to ship in 2.0 will be ready by then, so if the community recommends it, we’re going to execute a staggered release and add the remaining features in a 2.1 release. Nearly all of the features we wanted to ship in 2.0 will ship by then, but a few non-trivial (but non-blocking) ones will have to be deferred until they have been adequately tested.
The staggered release proposal, if adopted, would work as follows. Stacks 2.0 will be designed to run for a fixed amount of Bitcoin blocks (to be determined, but no more than a year), after which it will halt. By this point, the feature-complete version of the blockchain will be ready; we’ll call this Stacks 2.1. Stacks 2.1 will take over from where Stacks 2.0 left off, so there ought to be no disruption in service. The upgrade process isn’t something that miners will be able to disrupt or delay without modifying the Stacks 2.0 code directly (thereby creating a separate miner-induced hard fork), so everyone’s balances and state will automatically be transferred from 2.0 to 2.1 when 2.0’s end-of-life Bitcoin block passes.
What would go into Stacks 2.1 that won’t be in Stacks 2.0? Right now, there are a few backwards-incompatible features we’re hoping to ship in 2.1 that we think will make the chain even better:
-
A more equitable PoX lock-up algorithm. The current PoX lock-up algorithm will work, but there is some room for improvement. Namely, we’d want to make it so that the STX/reward-address lock-up price ascends automatically with each block (instead of increasing in response to Stackers stacking), and structuring Stacking operations to place a maximum lock-up bid per reward address. Then, Stackers receive reward addresses so long as they are the highest bidder for them, and Stackers (and miners) can’t manipulate the lock-up rate by reordering or delaying Stacking transactions. However, we would want to get this proposal reviewed by economics experts, and give it adequate testing on the testnet. Further details on the proposal are here: https://github.com/blockstack/stacks-blockchain/issues/1857, and a deeper explanation of the differences between the current PoX lock-up algorithm and this proposed improvement can be found here: https://github.com/blockstack/stacks-blockchain/issues/1846.
-
Second-price auction for transaction fees. Transaction fees can be thought of as an auction protocol where users bid on the unit cost for a block’s compute capacity. In a first-price auction, which is what most blockchains today use, the highest bid wins — people who pay the highest unit cost for block capacity get their transactions mined sooner. While this will work, the problem is that it can cause people to overpay. To avoid this, we wanted to implement a second-price auction protocol for transaction fees (where the bidder with the *nth-*highest bid pays some (n-k)th-highest bid). But implementing this correctly in the context of the Stacks blockchain has proven more challenging than we thought (full discussion here: https://github.com/blockstack/stacks-blockchain/issues/1190). We’d want to defer an implementation until after the community has had time to work through the implications of a second-price auction for transaction fees.
-
Native mining pools with user-burn support transactions. SIP-001 describes a process called “user-burn supports” whereby non-mining users can support miners by sending Bitcoin transactions that increase the likelihood that their preferred miner wins the block sortition. While this code is mostly tested in unit-tests, it has not received adequate testing on the testnet (and there is no miner code written that I know of that can use it). Therefore, in order to give it the testing it deserves, we want to defer releasing it until 2.1.
This does not mean that users can’t form mining pools! It just means that doing so happens through one extra step: users would pool their Bitcoin to create a multi-sig block-commit transaction, and mine a block whose coinbase transaction funds a multi-sig Stacks address that these users control. In addition, users would be able to form pools in the usual way — they’d contribute BTC to the pool operator, and the pool operator would disburse STX proportional to the user’s contributions.
When we did an economic audit of the system back in April, the economists found that user-burn supports would likely go unused, since it’s cheaper for users to pool their BTC through the multi-sig block-commit scheme described above. But nevertheless, we’d want to ship this feature at some point as a back-up plan in case forming such mining pools proved challenging.
-
More Clarity functions. While Clarity can be extended during mainnet with new functions through an on-chain voting process, there are still a few nice-to-have language features that can only be shipped as part of a VM upgrade. A partial listing can be found here: https://github.com/clarity-lang/reference/issues.
It’s our hope that giving some breathing room between 2.0 and 2.1 will give the community the opportunity to discuss and implement any/all of the above extra features, as well as give us all a chance to detect and repair any other issues that may arise in production. That said, I wanted to give a big shout-out to everyone who’s running a testnet node and participating on hackathons — y’all helped us uncover and fix some pretty nasty bugs!
Other than that, we’re on-track to ship the remaining large mainnet issues described here: https://github.com/blockstack/stacks-blockchain/issues/1866.
Happy Stacking!