Need a crash course on Bitcoin layers?
→ READ OUR FREE GUIDE
Need a crash course on Bitcoin layers?
→ READ OUR FREE GUIDE
Need a crash course on Bitcoin layers?
→ READ OUR FREE GUIDE
Need a crash course on Bitcoin layers?
→ READ OUR FREE GUIDE
Need a crash course on Bitcoin layers?
→ READ OUR FREE GUIDE

Understanding Nakamoto’s Fast Blocks on Stacks

Since the Nakamoto launch on October 28th, block times on Stacks have averaged 28.9 seconds. Alongside that speed, all Stacks transactions also now have Bitcoin finality, and Stacks miners post data to the Bitcoin L1 every Bitcoin block. What exactly is going on under the hood that makes fast blocks on a Bitcoin L2 possible?

Type
Deep dive
Topic(s)
Stacks
Published
December 2, 2024
Author(s)
Lead Content Manager
A graphic showing Stacks blocks
Contents

A Post Nakamoto World

As a quick reminder, Stacks underwent the Nakamoto upgrade on October 28th. This upgrade brought several changes to Stacks, most importantly:

  1. It brought 100% Bitcoin finality to Stacks, increasing the security of the network.
  2. It enabled sBTC, an upcoming programmable BTC asset that is scheduled to launch in December.
  3. It increased the speed of Stacks blocks, reducing block times from minutes to seconds.

This last point is what we will focus on in this blog post: how exactly Stacks blocks went from being mined every ~10 minutes to being mined in 28.9 seconds on average without compromising on Bitcoin-grade security.

To understand how fast blocks work on Stacks post-Nakamoto, you need to understand the mining process on Stacks.

Stacks blocks have been de-coupled from Bitcoin blocks, enabling Stacks miners to mine many blocks between each Bitcoin block.

Stacks has its own consensus mechanism called Proof of Transfer, which comes with its own miners. This is not a form of merge-mining, and Bitcoin miners =! Stacks miners, though a miner could choose to mine both chains independently (and indeed, some do).

Before Nakamoto, Stacks blocks were mined at the same cadence as Bitcoin blocks. This is where Stacks slow block times came from: each Stacks block was anchored to Bitcoin, so Stacks blocks were only mined as fast as the next Bitcoin block (roughly every ~10 minutes).

After Nakamoto, Stacks blocks have been de-coupled from Bitcoin blocks, enabling Stacks miners to mine many blocks between each Bitcoin block. Let’s take a closer look at how mining works after the Nakamoto upgrade.

How Stacks Mining Works Today

Unlike popular consensus mechanisms like proof of work, in which a miner spends electricity in order to compute the next block, or proof of stake, in which miners lock up capital in order to mine new blocks, Stacks takes a slightly different approach with Proof of Transfer.

To mine new blocks on Stacks, miners bid with BTC for the right to mine the next Stacks block, and each Bitcoin block, a winning miner is chosen. You can think of this as an ongoing raffle, where every Bitcoin block, Stacks miners are buying a raffle ticket, and every Bitcoin block, a new winner is selected.

The raffle prize: mining all Stacks blocks until the next Bitcoin block is mined, thus earning all of the related STX mining rewards and transaction fees. This is why Proof of Transfer is sometimes called “recycled proof of work” - because the proof of work that supports Bitcoin is also being used to support Stacks.

More specifically, in order to mine Stacks blocks, miners bid BTC via a <code-rich-text>block-commit<code-rich-text> transaction on Bitcoin. That BTC bid is sent to two different addresses from a rotating set of Stacker addresses, and miners must monitor the Stacks chain to know which two addresses will be randomly selected via Proof of Transfer. We’ll get back to that BTC in a moment.

A VRF (verifiable random function) sortition then selects the winning miner from those bidders, and that winner becomes the sole miner for the duration of its “tenure”, which lasts until the next mined Bitcoin block. During that tenure, that solo miner will produce many Stacks blocks, and it will earn STX coinbase rewards as well as transaction fees for any transactions included in blocks it produces as payment for that work.

This ability to mine many blocks between Bitcoin blocks is where Stacks’ improved block speed comes from. Remember that Stacks miners are elected via a <code-rich-text>block-commit<code-rich-text> transaction on Bitcoin, which inherently limits the speed at which new miners can be elected to the speed of the mining of Bitcoin blocks. These transactions on BTC are also how Stacks establishes Bitcoin finality and posts Stacks data to the L1.

But now that Stacks miners can mine many blocks in succession during their tenure, that speed constraint no longer applies. However, this change does introduce a new protocol security vector that must be addressed: once a miner is elected to its tenure, how do we ensure that a miner behaves honestly? That’s where signers come in.

Understanding the Role of Signers

Signers play an equally important role as miners in Stacks consensus post-Nakamoto. Previously, Stacks consensus had two primary roles: miners and "stackers." Stackers were simply users who chose to lock their STX into the protocol to improve the security of the network. In exchange, they earned BTC rewards. Remember the BTC that miners bid in order to have a chance to be elected the next miner? That BTC went to stackers.

With Nakamoto, the ecosystem introduced the new role of signers. Signers now receive that BTC from miner bids as a reward for taking a much more active role in the network: signers are responsible for validating and accepting new blocks produced by miners. In that sense, signers are very similar to the role of “validators” on other chains.

Signers validate and accept blocks produced by miners, keeping the elected miner honest during their tenure.

Note: signer power is dictated by how much locked STX is controlled by an individual signer, so the role of stacker still exists in a sense. Users can still lock up their STX and earn BTC rewards. However, users must now run a signer in addition to locking up their STX, or lock their STX into a signer pool that will distribute the pool’s BTC rewards proportionally to the individual’s amount stacked.

Once a miner produces a new block, that block is sent to signers, and those signers will either accept or reject that block. 70% of signers must accept a block in order for it to be added to the Stacks chain. Once accepted, the new Stacks block is broadcast to the network of Stacks nodes. That process repeats until the next Bitcoin block.

These signers ensure that:

  • The elected miner behaves honestly and is including valid transactions in their blocks. 
  • The elected miner builds off the most recent block from the previous tenure, ensuring chain continuity and removing Stacks’ ability to fork.

For this work validating new blocks, signers earn the BTC bids submitted by miners. This way both signers and miners are incentivized to behave rationally and maintain the Stacks network.

Today, there are 37 signers on the Stacks network. Those signers include apps, protocols, institutions, and individuals. This signer set is permissionless, and anyone can become a signer, provided they meet the minimum threshold for locked STX. You can view the signer network in the Stacks Explorer.

Changing Miners

We’ve talked about how a miner gets elected, and the power balance between miners and signers. Let’s dive into how miners exchange power and a new miner becomes elected during the bidding process.

As we discussed in an earlier section, miners bid BTC in a Bitcoin transaction for a chance to become the next elected Stacks miner. A VRF sortition randomly selects a new winning miner every Bitcoin block from this set of bidders.

Once the new miner selection occurs, the Signer network will recognize that election and issue a <code-rich-text>tenure-change<code-rich-text> transaction. The new miner is then required to include this transaction as the first transaction in the first block of their tenure. Otherwise, the signers will reject it.

Signers enforce continuity during miner tenure changes.

This <code-rich-text>tenure-change<code-rich-text> transaction from signers includes some important information about Stacks chainstate, including:

  • A tenure consensus hash, which identifies the current tenure on Stacks
  • A previous tenure consensus hash, which identifies the previous tenure
  • A burn view consensus hash, which is a hash of the last seen Bitcoin block
  • A previous tenure end, which is the index block hash of the last signed block from the previous tenure (this corresponds to the chain tip that the newly elected miner must build from)
  • And previous tenure blocks, the number of blocks mined in the previous tenure

This is how the Stacks chain establishes continuity between miners, disallows forking and puts Stacks in lockstep with Bitcoin, and ensures that new miners always build off the previous tenure’s chaintip.

If the miner doesn’t build from the previous tenure’s chaintip, as defined by the previous tenure end, then signers simply refuse to sign those blocks. If the miner doesn’t build from the current Bitcoin chain tip, as defined by the burn view consensus hash, then signers simply refuse to sign those blocks.

This is critical to establishing continuity across miner tenures and making fast blocks possible.

Upcoming Improvements to Stacks

Not all users have had a consistent experience with fast blocks (see this forum post and this GitHub issue for more details), and there’s still a lot of room to increase the overall throughput of the Stacks chain. Stacks core devs are cooking, and there’s a lot of updates around the corner.

Performance Improvements

First there are a number of improvements to Nakamoto that will increase network throughput. Stacks core devs prioritized stability and safety in the initial release of Nakamoto, and they already had some improvements in the hopper that they planned to roll out in the weeks following Nakamoto.

The first improvements are being targeted for release by December 16th at the latest and include:

  • Allowing miners to extend their tenure and refresh the computation budget of their tenure (this can happen between Bitcoin blocks)
  • Better utilization of block budget within a tenure
  • Addressing edge cases to make block production more consistent

You can learn more about those improvements in this blog post from Bitcoin L2 Labs. Alongside this first wave of performance improvements, engineers are also working on Clarity WASM, which will have performance implications for Stacks.

Future Network Upgrades

Improvements to Stacks don’t stop at these performance optimizations. There’s a lot more excitement coming to the biggest application layer on Bitcoin in the near future.

First, sBTC is slated to launch in December. This programmable BTC asset will help users deploy their BTC in apps across Stacks and Web3 more broadly.

Then SIP-029 was just approved by the community. This SIP adjusts the Stacks emission schedule to align with Bitcoin and ensure that there are adequate coinbase rewards right after the launch of Nakamoto and sBTC. This change will go live in December. To learn more, read this forum post and the SIP document.

Learn More About Fast Blocks

Stacks enables fast blocks while offering Bitcoin finality through its unique consensus mechanism, one that is permissionless and decentralized. Just like Bitcoin itself. If you’re curious to learn more about fast blocks and Stacks consensus, read through the following:

See you in the fast lane onchain.

Product updates & dev resources straight to your inbox
Your Email is in an invalid format
Checkbox is required.
Thanks for
subscribing.
Oops! Something went wrong while submitting the form.
Copy link
Mailbox
Hiro news & product updates straight to your inbox
Only relevant communications. We promise we won’t spam.

Related stories