Nakamoto Activation: 8 Weeks of Additional Development Time Expected
Hey fellow Stackers, with the successful Instantiation step of the Nakamoto upgrade behind us, this update will cover a significant change to the Activation timeline. With the benefit of more information and practical experience with aspects of the new network, the core developers have identified the need for a more advanced Signer resiliency/recovery system, something initially scoped for a later release.
As a result, they are projecting an additional 8 weeks of development time, plus time for testing, before the second hard fork that brings us Nakamoto features. Code complete on the new Signer resiliency features is expected July 15th and Activation starts August 28th.
Shifting dates this late in the game is not fun and I recognize this is disappointing - fast blocks just can’t get here fast enough! However, this change is being made to ensure the safety and liveness of the network upgrade. Let’s dive into the dynamics at play here, the primary benefits of the shift, and even a look at sBTC.
As a result, they are projecting an additional 8 weeks of development time, plus time for testing, before the second hard fork that brings us Nakamoto features. Code complete on the new Signer resiliency features is expected July 15th and Activation starts August 28th.
Shifting dates this late in the game is not fun and I recognize this is disappointing - fast blocks just can’t get here fast enough! However, this change is being made to ensure the safety and liveness of the network upgrade. Let’s dive into the dynamics at play here, the primary benefits of the shift, and even a look at sBTC.
Signer Resiliency/Recovery
The original plan for Nakamoto was to ship with a basic Signer resiliency system and then build a more advanced one later this year to be included in a future upgrade. With the benefit of more real-world data and Signer participation though, core developers no longer feel comfortable shipping without this more advanced system.
The basic version is proving inadequate in testing so core developers are making the tough, but safer call of building the more advanced system before Activation. In a worst-case scenario, without the more advanced resiliency features the network could halt entirely if too many Signers go offline or are unable to recover in a timely fashion.
The new work and timeline will offer some key benefits such as better miner resiliency to signing timeout and bad responses from Signers, better handling around Signer responsiveness and key loss scenarios, improvements to how Miners produce and handle tenure extensions, and network anti-entropy and flash block handling.
For the technical folks, you can find the specific issues in Github here. Further, they are broadly categorized by: Miner Resiliency, Signer Resiliency, and other related resiliency issues.
The basic version is proving inadequate in testing so core developers are making the tough, but safer call of building the more advanced system before Activation. In a worst-case scenario, without the more advanced resiliency features the network could halt entirely if too many Signers go offline or are unable to recover in a timely fashion.
The new work and timeline will offer some key benefits such as better miner resiliency to signing timeout and bad responses from Signers, better handling around Signer responsiveness and key loss scenarios, improvements to how Miners produce and handle tenure extensions, and network anti-entropy and flash block handling.
For the technical folks, you can find the specific issues in Github here. Further, they are broadly categorized by: Miner Resiliency, Signer Resiliency, and other related resiliency issues.
Timeline
~Date
Milestone
May 15-29th
Original Activation Date Range
July 15th
Code complete on new Signer resiliency features
↕
Testing, auditing
August 28th
Nakamoto Activation starts
+4 weeks
sBTC on mainnet (Rollout Overview)
The Orange Lining:
With the extra time, core developers can not only ensure a safe launch, but will also have the opportunity to take some consistent integration partner feedback about the current state of testnet into account as well. As you may know, the Bitcoin testnet the Stacks testnet has historically depended on has been largely unusable for the past 2-3 weeks, in turn making the primary Stacks testnet unusable. This appears likely to be an ongoing issue, and several weeks of time have already been lost to troubleshooting this. A permanent change to this testnet is being worked on that will decouple the Stacks testnet’s dependency on the Bitcoin testnet. You can follow this work here.
In addition to upleveling the testnet options Signers and others have been asking for, a key add for Bitcoin DeFi builders with quite a bit of support in the community is getting added into the release: Timestamps. Other straightforward features may also make their way into the release depending on how exactly development bandwidth shakes out.
In addition to upleveling the testnet options Signers and others have been asking for, a key add for Bitcoin DeFi builders with quite a bit of support in the community is getting added into the release: Timestamps. Other straightforward features may also make their way into the release depending on how exactly development bandwidth shakes out.
Bitcoin for a reason
With an upgrade as exciting and anticipated as Nakamoto, it can be hard to hear we must wait longer, but building any software is complicated, and building on Bitcoin even more so. I credit the core developers for taking in new information and making sensible adjustments despite it not being what anyone wants to hear. Ultimately, the Stacks ecosystem is committed to shipping an upgrade that stays true to the whole point of building on Bitcoin: Security and stability. I applaud their integrity and trust the judgment they have demonstrated over many years.
Stacks has always been a project that takes the time to build things that last, while doing everything possible to protect builders and users. Nakamoto will be no different.
Stacks has always been a project that takes the time to build things that last, while doing everything possible to protect builders and users. Nakamoto will be no different.
Core Developer Corner
As we hit the home stretch for Nakamoto, I’d like to surface opportunities for the community to hear directly from core developers. These bi-weekly sessions will get into the nitty gritty of progress on their sprints so everyone has a window right into how things are moving. Understanding everything core devs consider and how they handle challenges will be a great thing for all of you to see directly and the sessions will offer an opportunity for you to ask questions and have an open dialogue with key contributors.
sBTC
Contributors have been working on sBTC in parallel with Nakamoto, so the additional development time before the Nakamoto Activation is not expected to directly impact the sBTC rollout. In fact, the good news is that it ends up shortening the time after which sBTC can follow Nakamoto by about one month. Further details on this can be found in this sBTC rollout update.
Next steps:
If you’re wondering what this shift means for you, here is a breakdown of how you might take advantage of this change:
- Signers: This will allow ample Testing and Monitoring time on mainnet during the 2.5 epoch. This additional testing period will further help ensure network stability before signing becomes consensus-critical in 3.0 Activation.
- Builders: You will have long to test your apps against fast blocks on testnet before activation. Standby for updates to the docs on testnet fixes/upgrades and adjustments.
- Users: In the meantime, the network remains fully operational. We realize you are eager for the user experience improvements from Nakamoto and Stacks developers are working to complete this upgrade safely, as soon as possible. Also, don’t forget to restack your STX for Cycle 84 to continue earning BTC rewards!