Stacks Streets: Tour the Stacks Ecosystem and win!
Nakamoto is Now ‘Code Complete’, Final Testing Ahead
Your favorite Bitcoin L2’s upcoming upgrade reached another important milestone today, with core developers reporting they are now "code complete" for Nakamoto Activation, aka Step 2 of 2 of the upgrade. The full Nakamoto codebase, including the new code to increase Signer resiliency that was scoped after the first step in Nakamoto’s launch (Instantiation) is now written and ready for auditing, testnet deployment, and robust continued testing.
Once activated, Nakamoto will enable fast transaction confirmations, full Bitcoin finality, and set the stage for the upcoming release of sBTC. This update comes ahead of the July 15th target date for code complete, leaving development on track for Activation to start at the end of August.
It’s already been an incredibly productive spring and early summer for the Stacks layer, this post will cover the new work which has reached code complete as well as some other key developments driven in the ecosystem since Instantiation.
Once activated, Nakamoto will enable fast transaction confirmations, full Bitcoin finality, and set the stage for the upcoming release of sBTC. This update comes ahead of the July 15th target date for code complete, leaving development on track for Activation to start at the end of August.
It’s already been an incredibly productive spring and early summer for the Stacks layer, this post will cover the new work which has reached code complete as well as some other key developments driven in the ecosystem since Instantiation.
Nakamoto is Code Complete
All issues required ahead of Nakamoto Activation were finished, below are some highlighted issues you can dive into for more detail:
- Sortition state tracking in Signer: A new module chainstate in the signer binary tracks the most recent sortitions from the stacks-node. It obtains this information from a new RPC endpoint in the stacks-node. More details here.
- New process_event path for v0 signer now handles v0 message types: MinerMessages, BlockValidationResponses, StatusCheck, NewBurnBlock, and BlockSignature. Learn more.
- Updated the current signer module to signer_v1 and created a new signer_v0 module that has an analogous Signer struct. Learn more.
- Nakamoto block header now uses Vec<MessageSignature> rather than an aggregate signature. Learn more.
- Miners now handle tenure extend transactions: Miners now handle tenure extensions if subsequent bitcoin block didn’t choose a sortition winner.
- No block dead time between 2.5 -> 3.0 transition
- Mock mining config parameter is now hot-swappable
- Nakamoto Miner now produces frequent and smaller blocks across different cost dimensions
Nakamoto block headers have a timestamp:
Nakamoto 3.0 miner now retries when signature collection times out: If a miner times out when waiting for signatures, it doesn’t end its tenure, instead it just retries.
- (get-block-info? time block-height) uses this new timestamp in Clarity 3, instead of using the timestamp from the burn block. The signers will validate that this timestamp is a) Greater than the timestamp of the previous block and b) Less than 15 seconds into the future (according to their local clocks)
Nakamoto 3.0 miner now retries when signature collection times out: If a miner times out when waiting for signatures, it doesn’t end its tenure, instead it just retries.
Stacker liveness enforcement in the stacks-node
- Implemented the punish/reward scheme for PoX block commits in Nakamoto by checking the produced block's bitvectors for compliance.
- This works by allowing PoX reward addresses to be replaced with burn outputs in all cases
- For now: signers will eventually be responsible for choosing their own punishment scheme
- Updated the mempool GC behavior in nakamoto from using the block height to using the age of the transaction (measured in time since accept_time).
- The sets the age limit to be the same as prior limit when translated with 10 minute block times (as was expected prior to 3.0).
SIPs & Governance developments:
SIP-021 Amendment
SIP-025, Iterating towards WSTS
SIP-02x, non-sequential multi-sig transactions
- An amendment to SIP-021 to memorialize updates to the Clarity function get-block-info. This SIP has passed CAB review and has been activated. Learn more.
SIP-025, Iterating towards WSTS
- An incremental step towards the full WSTS signature scheme. Learn more.
- This SIP has passed CAB vote and will be voted on by Signers
SIP-02x, non-sequential multi-sig transactions
- This user experience improvement has already been approved by the relevant CABs and will be subject to a community vote. Learn more.
- The community vote is likely to begin at the start of Stacking cycle 89 and run until the conclusion of stacking cycle 90.
Other notable developments and progress:
- Work to add timestamps to block headers is complete, Github issue here.
- Primary Testnet operation was fully restored. Please jump to this section of the docs if you would like an overview of the testnets to help you decide which you’d like to use.
- Bitcoin L2 Labs introduced a new security initiative to support Stacks applications and brought in a new security resource in Hypernative, a solution that offers builders real-time exploit prevention powered by AI.
- Hiro released several Signer dashboard updates that help the community and Signers better understand network activity,
- The Degen Labs team released Stacking.tools which will become a suite of tools for Stackers. The first release is already live, providing a tool for Stackers and pool operators to generate signatures.
- Another high-impact cohort of Critical Bounties were also recently awarded and are already in development. Several of these community-built, Foundation-supported projects complement the enhancements shipping with Nakamoto Activation, including research into the next iteration of the WSTS signer schema (Fast Paxos BFT), the sBTC Bridge, and a heavy focus on improving the user experience for key ecosystem participants, including Signers, Stackers, and Miners. You can read about all of the awarded projects here
What’s next?
Up next, the new code will see multiple internal and external audits, extensive testing, and other bug fixes and performance enhancements as needed. Signers, miners, and other network participants will work with new releases on testnet to prepare for mainnet release in August.
In parallel, other core developers are hard at work on the sBTC release, which is still expected to follow the Nakamoto release as soon as 4 weeks after, depending on network behavior and user/developer feedback post-Nakamoto.
In parallel, other core developers are hard at work on the sBTC release, which is still expected to follow the Nakamoto release as soon as 4 weeks after, depending on network behavior and user/developer feedback post-Nakamoto.
Don’t miss these programs and updates:
- 1Bitcoin Builders ConferenceIn just a couple weeks, Bitcoin builders are taking over Nashville. Join all the leaders and brightest minds from the Bitcoin ecosystem at the Bitcoin Builders Conference: https://bitcoinbuilders.io
- 2Keep your eye out over the next two weeks for:
- Major new partnership announcements, follow @Stacks
- An exciting way to win prizes in July and August just by supporting Bitcoin builders and their apps, follow @StacksOrg
- 3Code for StacksSend every developer you know the ‘Code for Stacks’ program, which rewards builders for doing what they do best, building! Shout out to June’s 2500 STX winner! You can learn more here: https://stacks.org/code-for-stx