Nakamoto v1

[jcnelson]

Nakamoto v1

Abstract

This document describes a moderate set of modifications to Stacks 2.4 that would implement the user-facing functionality promised by Nakamoto. This proposal’s complexity lies somewhere between the “aggressive” Nakamoto proposal which came out of the August hackathon, and the “conservative” Nakamoto proposed by Jude in late August. We estimate that this proposal would take between 50%-60% of the time required by the aggressive proposal.

Introduction

The Nakamoto release will add the following user-facing changes to the Stacks blockchain.

• Fast blocks: The time taken for a user-submitted transaction to be mined within a block (and thus confirmed) will now take on the order of seconds, instead of tens of minutes. This is achieved by speeding up the rate at which blocks are produced.
• Bitcoin finality: Once a transaction is confirmed, reversing it is at least as hard as reversing a Bitcoin transaction. The Stacks blockchain no longer forks on its own.
• Bitcoin fork resistance: If there is a Bitcoin reorg, then Stacks transactions which remain valid after the fork are re-mined in the same order they were in before. However, transactions that become invalid as a result of a Bitcoin fork are dropped. This is not a consensus-critical feature, and can be incrementally deployed in subsequent releases after the Nakamoto hard fork.
• No Bicoin miner MEV: Bitcoin miners do not have an advantage as Stacks miners; they must spend competitive amounts of BTC to have a chance of earning STX.

This priority ranking is the conclusion drawn from many discussions between core devs and Stacks builders. A fast blockchain with Bitcoin finality helps all Stacks projects – especially Stacks DeFi projects including sBTC – and thus should be the core devs’ top priority.
To do this, the system must confirm transactions fast enough that the risk of a price-change to the assets being traded is minimized. Moreover, it must ensure that it is at least as difficult to reorg the Stacks blockchain as it is to reorg Bitcoin. Finally, the system must resist Bitcoin miner MEV, which today enables Bitcoin miners to avoid competing with Stacks miners and win Stacks blocks for a de minimis PoX payment.

To achieve fast block times, this proposal advocates for decoupling Stacks tenure changes from Bitcoin block arrivals. A miner may create many Stacks blocks per Bitcoin block, and the next miner must confirm all of them. There are no more microblocks or Bitcoin-anchored blocks; instead, a new block type will be created.

To speed implementation, this proposal advocates for retaining Stacks miners as block producers, which execute a cryptographic sortition every Bitcoin block to decide which competing miner becomes the sole block producer until the next tenure change (triggered by a Bitcoin block arrival). The implementation would retain the SortitionDB system in the current Stacks node, with a few modifications described in this document. This differs from the original Nakamoto proposal, which called for a network of block producers to collectively mine blocks for a 10-Bitcoin-block tenure, and thus would have required substantial additional implementation work to achieve the same ends that this proposal describes.

To ensure that no forks arise, this proposal advocates for extending the StacksChainState system in order to ensure miners always know the canonical Stacks chain tip, and thus can be prevented from ever building atop any other block. This is achieved by decoupling Stacks tenure changes from Bitcoin block arrivals. In the proposed system, a cryptographic sortition only selects a new miner; it does not give them the power to orphan confirmed transactions as it does today in Stacks. Instead, a cryptographic sortition causes the Stackers to carry out a tenure change by (a) agreeing on a “last-signed” block from the current producer, and (b) agreeing to only sign blocks from the new producer which descend from this last-signed block. Thus, Stackers police miner behavior – Stackers prevent miners from mining forks during their tenure, and ensure that they begin their tenures by building atop the canonical chain tip.

To ensure Bitcoin finality, Stacks miners commit to the indexed block hash (a StacksBlockId) of the first block produced by the last Stacks miner in their block-commit transactions on Bitcoin. This anchors the Stacks chain history to Bitcoin up to the start of the previous miner’s tenure, and it anchored causally-dependent Bitcoin state to Stacks. This ensures that the history of tenure changes up to (but excluding) the most recent change is written to Bitcoin, and thus as difficult to erase as any other Bitcoin transaction. It further ensures that a node with an up-to-date copy of the Stacks chain state can identify which Stacks blocks are affected by a Bitcoin reorg, so it can begin recovering the affected Stacks transactions.

This proposal advocates for a Stacker-driven approach to Bitcoin reorg recovery. If a Bitcoin reorg happens, Stackers identify the sequence of now-orphaned Stacks transactions that miners must replay in order to preserve them in the Stacks blockchain across the fork. This can be implemented separately because it is not consensus-critical, and can be deployed incrementally because it only requires sufficient numbers of Stackers to cooperate.

Finally, this proposal advocates for adopting a Bitcoin MEV solution proposed by Jesse Soslow. These solutions have already been vetted for application with the current Stacks mining system, and are easily extended to work in Nakamoto v1.

The bulk of the work in this proposal will be in replacing Stacks blocks and microblocks with Nakamoto Stacks blocks. However, this proposal calls for a design that minimizes the amount of change that would need to be made in StacksChainState and PeerNetwork in order to keep relevant and reapply as many lessons learned from the Stacks 2.x system as possible. These lessons learned have accrued in the codebase over the past few years, and are based on real-world operational experiences. By keeping the overall data schemas and processing algorithms as close to the current system as possible, this proposal minimizes the risks of shipping too much untested code and shipping too late.

Specification

Chain Structure

As with the system today, Bitcoin finality is achieved through a block-commit transaction on Bitcoin. A Stacks miner sends one of these transactions in order to submit their candidacy to become the next block producer after the next tenure change. This proposal advocates for keeping block-commit transactions’ syntax, but calls for altering its semantics in one key way: the block_header_hash field is no longer the hash of a proposed Stacks block (i.e. its BlockHeaderHash), but instead is the index block hash (i.e. StacksBlockId) of the previous miner’s first-ever produced block (Figure 1).

Figure 1: Overview of the relationship between Bitcoin blocks (and sortitions), Stacks blocks, and the inventory bitmaps exchanged by Stacks nodes. Each winning block-commit’s BlockHeaderHash field no longer refers to a new Stacks block to be appended, but instead contains the hash of the very first Stacks block in the previous tenure. These tenure start blocks each contain a TenureChange transaction (not shown), which, among other things, identifies the number of Stacks blocks produced since the last valid start block (numbers in dark orange circles).

The reason for this change is to both preserve Bitcoin finality and to facilitate initial block downloads without significantly altering the inventory state synchronization and block downloader state machines. Bitcoin finality is preserved because at every Bitcoin block N+1, the state of the Stacks chain as of the start of tenure N is written to Bitcoin. Even if at a future date all of the former Stackers’ signing keys were compromised, they would be unable to rewrite Stacks history for tenure N without rewriting Bitcoin history back to sortition N+1.

Chain Synchronization

This chain structure is similar enough to the current system that the inter-node synchronization procedure remains roughly the same as it is today, meaning all the lessons learned in building out inter-node synchronization still mostly apply. At a high-level, nodes would do the following when they have all of the Stacks chain state up to reward cycle R:

1. Download and process all sortitions in reward cycle R+1. This happens largely the same way here as it does today – the node downloads the Bitcoin blocks, identifies the valid block-commits within them, and runs sortition on each Bitcoin block’s block-commits to choose a winner. It does this on a reward-cycle by reward-cycle basis, since it must first process the PoX anchor block for the next reward cycle before it can validate the next reward cycle’s block-commits.

2. For each sortition N+1, go and fetch the start block of tenure N if sortition N+1 has a valid block-commit and the inventory bit for tenure N is 1. This requires minimal changes to the block inventory and block downloader state-machines. Each neighbor node serves the node an inventory bitmap of all tenure start blocks they have available, which enables the node to identify neighbors that have the blocks they need. Unlike today, only the inventory bitmap of tenure start blocks is needed; there is no longer a need for a PoX anchor block bitmap nor a microblock bitmap.

3. For each start block of tenure N, identify the number of blocks between this start block and the last prior tenure committed to by a winning block-commit (note that this may not always be tenure N-1, per figure 1). This information is identified by a special TenureChange transaction that must be included in each tenure start block (see next section). So, the act of fetching the tenure-start blocks in step 2 is the act of obtaining these TenureChange transactions.

4. Download and validate the continuity of each block sequence between consecutive block commits. Now that the node knows the number of blocks between two consecutive winning block-commits, as well as the hashes of the first and last block in this sequence, the node can do this in a bound amount of space and time. There is no risk of a malicious node serving an endless stream of well-formed but invalid blocks to a booting-up node, because the booting-up node knows exactly how many blocks to expect and knows what hashes they must have.

5. Concurrently processes newly-downloaded blocks in reward cycle R+1 to build up its tenure of the blockchain.

6. Repeat once the PoX anchor block for R+2 has been downloaded and processed

This bootup procedure is amenable to starting Nakamoto from Stacks 2.x, as long as it happens on a reward cycle boundary.

When the node has synchronized to the latest reward cycle, it would run this algorithm to discover new tenures within the current reward cycle until it reaches the chain tip. Once it has processed all blocks as of the last sortition, it continues to keep pace with the current miner by receiving new blocks broadcasted through the peer network by Stackers once they accept the next Stacks block.

Block Structure

Nakamoto Stacks blocks will have a different wire format than Stacks blocks and microblocks today. In particular, the header will contain:

• A version number
• The length of the chain as of this tip
• The total BTC spent producing this tip
• The StacksBlockId of the parent Stacks block
• The Bitcoin block hash of the Bitcoin block that triggered the start of the tenure in which they were mined
• A recoverable ECDSA signature from the tenure’s miner
• The root of a SHA512/256 Merkle tree constructed over all of its contained transactions
• The SHA512/256 root hash of the MARF once all of the contained transactions are processed

As before, the Stacks blockchain will continue to calculate a consensus hash for each sortition. The StacksBlockId of a Stacks block would simply be the SHA512/256 of the block’s associated sortition’s consensus hash and the hash of the block header.

Absent from this header is the VRF proof. Instead, this information will be put into the Nakamoto Coinbase transaction.

Block Storage

The Nakamoto system is expected to produce a Stacks block on average once every five seconds. This is 120x the rate of the current system. Because of the high volume of blocks, the block storage system in Stacks will need to be upgraded to store blocks as rows in a sqlite database instead of files, lest the host run out of i-nodes.

The block data will be stored in a wholly separate database from the chainstate, so that storing newly-downloaded blocks and loading them up again for processing never results in lock-contention arising from block-processing. This is because block-processing opens a transaction for the duration of the processing time, which would prevent concurrent storage of downloaded blocks if they lived in the same database.

The primary key of each Stacks block row will be its StacksBlockId. Each row would need the following indexed columns. Note that this schema is subject to change if something better is thought of.

• The StacksBlockId of its parent
• The StacksBlockId of the tenure-start block.
• The StacksBlockId of the highest tenure-start block for which there is a valid block-commit. For example, all blocks in tenures N+1 and N+2 have the StacksBlockId of the first block in tenure N+1 as this column’s value.

In addition, the following non-indexed columns will be needed:

• The number of blocks between this block and the highest tenure-start block for which there is a valid block-commit.
• The sortition height of the block-commit that references the tenure-start block, if it exists. This is used to calculate the inventory bitmap.

Given this data, it will be possible to efficiently do the following:

• Fetch any tenure-start block, given its StacksBlockId. This is needed for step 2 of the chain synchronization algorithm.
• Construct a StreamCursor variant that can incrementally load up all Stacks blocks between the tenure start blocks any tenures N and N + k (k > 0). This is needed for step 4 in the chain synchronization algorithm.
• Calculate the inventory bitmap for a reward cycle for reward cycle R. This is the act of selecting the sortition heights of all tenure-start blocks that belong to reward cycle R, and setting the ith bit to 1 if and only if tenure i has a sortition height i + 1.

Tenure Changes

As mentioned earlier, the reason why continuing to rely on microblocks is not good enough for our goals in Nakamoto is because in the current system (and in Conservative Nakamoto), microblocks may be orphaned. This is fundamentally unavoidable because the current Stacks miner can continue to produce microblocks well after the next miner produces a Stacks block. This happens due to two data races. First, Stacks miners race the current miner to confirm their microblock stream – the current miner produces microblocks on top of the stream that the next miner confirms via a Bitcoin transaction. Second, the Bitcoin and Stacks peer network block propagation races the current miner to tell it to stop making microblocks – the current miner can continue to produce microblocks well after the next Stacks block is announced (which would not confirm them).

The reason this happens is because system _tenure change_s in Stacks today are triggered by a new Stacks block being discovered, which may not confirm all of the previous miner’s produced microblocks. This violates the promise Nakamoto makes to users, which is that their transactions, once confirmed, remain confirmed forever so long as Bitcoin does not fork.

This is a problem that would need to be addressed in all proposed Nakamoto designs. This design calls for a Bitcoin block arrival to trigger a tenure change, and calls for Stackers to execute the tenure change (Figure 2).

Figure 2: Tenure change overview. When a new Bitcoin block arrives, Stackers begin the process of deciding the last block they will sign from miner N. When they reach quorum, they announce this data in a FROST-signed specially-crafted data payload in their StackerDB message. This information serves as a record of the tenure change, and must be incorporated in miner N+1’s tenure-start block. In other words, miner N+1 cannot begin producing Stacks blocks until Stackers inform it of block X – the block from miner N that it must build atop. Stacks-on-Bitcoin transactions are applied by miner N+1 for all Bitcoin blocks in sortitions N and earlier when its tenure begins.

A Stacks miner produces blocks until Stackers declare that they will no longer sign their blocks, or until they run out of execution budget – whichever comes first. In the former case, Stackers will encode the tenure change as a novel Stacks transaction, called a TenureChange transaction, which encodes the following data:

• The StacksBlockId of the last block from miner N that they will have processed (this is “X” in figure 2)
• The number of blocks produced by miner N and prior miners, back to the last non-empty sortition (required by the chain bootup algorithm).
• A flag to indicate which of the following triggered the tenure change
  • A valid winning block-commit
  • No winning block-commits
  • A “null miner” won the block-commit (see the MEV solution below)
• The ECDSA public key hash of miner N+1’s block-signing key
• A Schnorr signature from at least 70% of the Stackers
• A bitmap of which Stackers signed

When produced, the TenureChange transaction will be stored to the Stacker’s StackerDB instance. Miners N and N+1 will both monitor this StackerDB to observe its arrival. Once miner N sees it, it ceases producing blocks. Once miner N+1 sees it, it begins its tenure by doing the following:

1. It processes any currently-unprocessed Stacks-on-Bitcoin transactions up to (but excluding) the Bitcoin block which contains its sortition (so, up to sortition N).
2. It produces its tenure-start block, which contains the TenureChange transaction as its first transaction.
3. It begins mining transactions out of the mempool to produce Stacks blocks.

If miner N does not see the TenureChange transaction in the StackerDB, then it will keep producing blocks. However, Stackers will not sign them, so as far as the rest of the network is concerned, these blocks never materialized. If miner N+1 does not see the TenureChange transaction, it does not start mining; a delay in obtaining the TenureChange transaction can lead to a period of chain inactivity. This is mitigated by the fact that the miner knows the set of Stackers’ reachable Stacks nodes in advance (as part of StackerDB), so it can directly query them if the data does not arrive at its node in a timely fashion.

The Nakamoto Stacks blockchain has exactly one TenureChange transaction for each and every tenure, even if the tenure is empty.

Empty Tenures

Sometimes, a tenure can be empty. The miner and Stackers may fail to sign any Stacks block. This can happen for banal reasons, such as (but not limited to):

• The next Bitcoin block arrived before the miner could produce a block (e.g. a flash block occurred)
• The miner crashed before it could mine a block, and remained offline for the duration of its tenure
• The miner never produced a valid block

In all cases, the tenure would be empty (Figure 3).

Figure 3: Tenures N+1 and N+2 are empty. Stackers recover from this by requiring the next non-empty tenure to include the empty tenures’ TenureChange transactions, to prove that these tenures were in fact empty and no blocks were signed for them. Because the tenures are empty, the inventory bitmap would mark them as 0’s – there’s no block data to fetch.

To recover from this, Stackers would still produce TenureChange transactions for the empty tenures, and require the start block of the first non-empty tenure to include them. In other words, Stackers always produce a TenureChange transaction for each tenure; it just might not be included by the tenure’s sortition-selected miner.

Stacker tenure Changes

A miner tenure change happens every Bitcoin block. In addition, there are Stacker tenure changes, which happen once every 2100 Bitcoin blocks (one reward cycle). In a Stacker tenure change, a new set of Stackers are selected by the PoX anchor block (see SIP-007).

Because Stacks no longer forks, the PoX anchor block is always known 100 Bitcoin blocks prior to the start of the next reward cycle: it is simply the the start block of the 2000th tenure in the current reward cycle.

The PoX anchor block identifies the next Stackers. They have 100 Bitcoin blocks to prepare for signing Stacks blocks. Within this amount of time, the new Stackers would complete a FROST DKG for signing blocks (among other things, such as the sBTC peg wallet hand-off). The PoX contract will require Stackers to register their block-signing keys when they stack or delegate-stack STX, so the entire network knows enough information to validate their FROST Schnorr signatures on blocks.

PoX Failure

In the event that PoX does not activate, the chain halts. If there are no stackers, then block production cannot happen.

Changes to PoX

To support tenure changes, the .pox-4 contract would be altered to enable the following:

• Stackers register a signing key when they call stack-stx and optionally delegate-stx.
  • In delegate-stx, Stackers may instead elect for the delegate to supply the signing key
• .pox-4 implements the StackerDB trait. Each Stacker receives a number of slots equal to the number of reward slots, into which they will write their FROST cryptographic state. This enables Stackers to both perform DKG as well as signing rounds.
• The stacking minimum is abolished. If there is at least one stacker that is able to claim one reward slot, then PoX activates.

Dynamic Runtime Budgets

To support fast blocks, it will be necessary to ship Nakamoto v1 with a means of ensuring that no matter how long it takes for the next tenure change to execute, the current miner will be able to keep producing blocks at a fixed cadence.

Previous Nakamoto proposals advocated for using a verifiable delay function (VDF) for allowing block producers to prove that they have waited for the expected tenure window in order to earn additional runtime budget allocations. However, there is a simpler way to do this in Nakamoto v1: Stackers themselves can simply vote to grant the current block producer additional tenure runtime budgets.

To achieve this, Stackers each keep track of the elapsed wall-clock time since the start of the tenure. Once the expected tenure time has passed (e.g. 10 minutes), they vote to grant the miner an additional tenure execution budget. This is achieved by having Stackers collectively produce a TenureExtension Stacks transaction, which the miner would include into their block stream.

When a node validates a block stream today, it keeps track of how much runtime budget the transactions have consumed since the tenure’s start. In Nakamoto, if it sees a valid TenureExtension transaction, then the tenure’s so-far-consumed execution budget would simply reset.

New Block Validation Rules

Under Nakamoto, a block is valid if and only if the following are true:

• The block is well-formed
  • It has the correct version and mainnet/testnet flag
  • (NEW) Its header contains the same Bitcoin block hash as the Bitcoin block that contains its tenure’s block-commit transaction
  • The transaction Merkle tree root is consistent with the transactions
  • The state root hash matches the MARF tip root hash once all transactions are applied
  • (NEW) the block header has a valid ECDSA signature from the miner
  • (NEW) the block header has a valid FROST Schnorr signature from the set of Stackers
• (NEW) All Bitcoin transactions since the last valid sortition up to (but not including) this tenure’s block-commit’s Bitcoin block have been applied to the Stacks chain state
• In the case of a tenure start block:
  • (NEW) The first transactions are the TenureChange transactions for any tenures not represented by Bitcoin block-commits, and they are present in order by sortition.
  • (NEW) The first non-TenureChange transaction is a Coinbase.
• All transactions either run to completion, or fail due to runtime errors. That is:
  • The transaction is well-formed
  • All transactions’ senders and sponsors are able to pay the transaction fee
  • The runtime budget for the tenure is not exceeded
    • (NEW) The total runtime budget is equal to the runtime budget for one tenure, multiplied by the number of valid TenureExtension transactions mined in this tenure.
  • No expression exceeds the maximum nesting depth
  • No supertype is too large
  • (NEW) The PoisonMicroblock transaction variant is not supported anymore

Block Reward Distribution and MEV

The Nakamoto system will use the Assumed Total Commitment with Carryforward (ATC-C) MEV mitigation strategy described in this document to allocate block rewards to miners. Unlike Stacks today, there is no 40/60 fee split between two consecutive miners. Each miner nominally receives the entire coinbase and transaction fees before the MEV mitigation is applied.

In the ATC-C algorithm, Nakamoto would use the document’s recommended assumed total commitment function: the median total PoX spend across all miners for the past 5 Bitcoin blocks. It would additionally use the document’s recommended carryforward function for missed sortitions’ coinbases: the coinbase for a Bitcoin block without a sortition would be available to winning miners across the next five tenures. That is, if a miner whose tenure begins during the next five tenure-changes manages to produce a Stacks block with a Coinbase, then they receive a 20% of the coinbase that was lost.

The reason ATC (and ATC-C) were not considered as viable anti-MEV strategies before is because a decrease in the PoX total spend can lead to a Bitcoin block with no sortition. This is a deliberate design choice in ATC-C, because it has the effect of lowering the expected return of MEV mining. In ATC-C, the probability of a miner winning a sortition is equal to (i.e. no longer proportional to) the miner’s BTC spend, divided by the maximum of either the assumed total commit (median total BTC spend in the last 5 blocks) or the total BTC spend in this Bitcoin block. This means that the sum of each miners’ winning probabilities is not guaranteed to be 1. The system deals with this by creating a virtual “null” miner that participates in each sortition, such that its probability of the null miner winning is 1 - sum(probabilities-of-all-other-miners). If the null miner wins, then the sortition is treated as empty.

While the existence of a null miner was a liveness concern in Stacks today, it is not a concern in Nakamoto. If the null miner wins tenure N, then the last non-null miner continues to produce blocks in tenure N. They receive transaction fees, but no coinbase for N.

Bitcoin Fork Recovery

The Bitcoin chain can fork. This is a problem for Nakamoto, because Stacks transactions can be causally dependent on the now-orphaned Bitcoin state. For example, any Stacks transaction that uses (get-burn-block-info?) may have a different execution outcome if evaluated after the Bitcoin block state from which it was mined no longer exists.

Earlier proposals had called for re-mining all Stacks transactions in the same order in which they originally appeared in the chain history, and treating the failure of re-mined but now invalid transactions as runtime errors (meaning, including them in a block will not invalidate the block). While this could be made to work, it would be very time-consuming for questionable benefit. Namely, the system would need to recognize transactions that would invalidate a block if included (e.g. they cannot pay their transaction fee, or they exceed the block’s runtime budget), and continue to process them as runtime errors if and only if Stackers indicated that this particular transaction was included to recover from a Bitcoin fork. To achieve this, the Nakamoto chain would need to require miners and Stackers to prove that the state which made these transactions previously-valid actually existed, but on an orphaned Bitcoin block.

While this could be done, we do not believe that we have time to do so. Instead, this proposal calls for dropping any previously-mined but now-invalid Stacks transactions from the Stacks chain history, but re-mining the set of Stacks transactions which remain valid across the Bitcoin fork in the same order in which they were previously mined. That is, transactions that were not causally dependent on lost Bitcoin state would remain confirmed on Stacks, in the same (relative) order in which they were previously mined.

This guarantee is much simpler to implement, and can even be deferred until after the Nakamoto v1 hard fork. To do so, Stackers would first observe that a Bitcoin fork has occurred, and vote on which Bitcoin block(s) were orphaned (even if it means sending the orphaned data to each other, since not all Stacks nodes may have seen it). Once Stackers agree on the sequence of orphaned Bitcoin blocks, they identify which Stacks blocks would be affected. From there, they each replay the affected Stacks blocks’ transactions in the same order, and in doing so, identify which transactions are now invalid and which ones remain valid. Once they have this subsequence of still-valid transactions, they advertise it to miners, and only sign off on Stacks blocks that include a prefix of this subsequence that has not yet been re-mined (ignoring Coinbase or TenureChange transactions). This way, the Stacks miners are compelled to replay the still-valid Stacks transactions in their same relative order, thereby meeting this guarantee.

Importantly, this transaction replay feature is directed exclusively by Stacker and miner policy logic. It is not consensus-critical, and in fact cannot be because not all miners or Stackers may have even seen the orphaned Bitcoin state (which precludes them from independently identifying replay transactions; they must instead work together to do so off-chain). Therefore, this feature’s implementation can be deferred until after the Nakamoto v1 hard fork. Shipping the implementation itself is not a hard fork either; it can instead be incrementally rolled out.

Implementation Milestones

Helium: Mockamoto v1

Goal: bring the Nakamoto node online.

This milestone would see the following functionality implemented:

• There is a single miner, and no stacker. It produces one block about once every five seconds.
• It runs against a Bitcoin regtest node, which produces Bitcoin blocks once every 60 seconds.
• The miner sends the new style of block-commits. The block header hash field contains the StacksBlockId of the last tenure’s first block.
• The TenureChange transaction is synthesized by the miner, but is present in the block stream.

Neon: Mockamoto v2

Goal: Bring the Nakamoto stacker daemon online

This milestone would see the following additional functionality implemented:

• There is a single miner, and a single stacker. The stacker signs Stacks blocks. It synthesizes the TenureChange transactions, which it shares with the miner via StackerDB.

Argon: Mockamoto v3

Goal: Bring the Nakamoto network state machines online

This milestone would see the following additional functionality implemented:

• There is a single public Bitcoin regtest node, but multiple miners and a single stacker. The stacker signs miner blocks, but the miners compete via cryptographic sortition and ATC-C to become the next tenure’s miner. The stacker synthesizes TenureChange transactions to execute tenure changes.
• There is a new inventory state machine and downloader state machine. Miners can download blocks and inventories from one another, and stay in sync.

Krypton: Mockamoto v4

Goal: Bring the Stacker network’s FROST DKG online

This milestone would see the following additional functionality implemented:

• There are multiple Stackers participating in PoX, as well as multiple miners. Stackers collectively sign TenureChange transactions.
• Stackers collectively sign TenureExtension transactions, which are picked up by the current miner.

Xenon: Public Testnet

Goal: Bring sBTC online

This milestone would see the following additional functionality implemented:

• The system runs on Bitcoin testnet, and is able to handle flash blocks and block storms without service disruption
• Nakamoto sBTC is online and works as expected (progress on this is tracked in a parallel workstream)

Appendix: Why Conservative Nakamoto was Not Good Enough

The key deficiency in Conservative Nakamoto is its continued reliance on the existing microblocks system for achieving low transaction confirmation latency. While this proposal did take steps to ensure that miners would always need to produce microblocks at a steady cadence, it did not properly address two key problems:

• Microblock forks break the no-forks promise in a bad way. Conservative Nakamoto kept the current tenure-change system in place, whereby the arrival of a Stacks block could orphan some number of the previous miner’s produced microblocks. This orphaning behavior is unavoidable due to several factors outlined in the old proposal. In any case, this would render any microblock-based system too unreliable for Nakamoto’s goals. The fundamental problem, which this proposal addresses, is that both the current Stacks system and Conservative Nakamoto continued to couple tenure changes to cryptographic sortitions with no regard to how that could lead to the loss of previously-confirmed transactions.
• Microblocks are second-class citizens. The current system does not treat microblocks the same way as it does Stacks blocks, which makes them unsuitable for smart contracts and wallets to do meaningful Bitcoin-related things with them. In particular:
  • Unconfirmed microblock state is best-effort. Queries against the the last Stacks anchored block act on stale data, but queries against the unconfirmed sequence of microblocks can vary on a node-to-node basis depending on how up-to-date the node’s tenure of the currently-produced microblock stream is.
  • Clarity needs (at-block) to work in microblocks. Because processing a microblock does not produce a new trie in the Stacks MARF, it is currently impossible to use (at-block) on a microblock. This imposes severe and confusing constraints on the ability for smart contracts to recent historic chain state – they can only do so at Stacks blocks (i.e. at cryptographic sortitions).
  • Microblocks cannot reference the most-recent Bitcoin block. This was a design oversight in the current Stacks chain, but would need to be rectified either way in order to ensure that the latest confirmed transaction can always reference the highest Bitcoin tip. This will be necessary to implement Bitcoin DeFI in a way that minimizes price risk.

[will-corcoran]

@jcnelson @kantai @muneeb-ali

Thanks for all of your hard work on this! I've compiled some questions (a batch for each section of the Specification) that I will post below. The intention is to just illicit a dialog. Hopefully, this can play a small part in scoping out more concrete deliverables / milestones.

😅

[will-corcoran]

Chain Structure:

1. How would altering the block_header_hash field to reference the previous miner's first-produced block impact block production and Stacks-Bitcoin synchronization?

2. How does this block_header_hash change affect Bitcoin finality preservation and the Stacks chain's integrity?

3. Could you explain the role of the TenureChange transaction and how it relates to Nakamoto's significance in the Stacks blockchain?

[jcnelson]

1. It achieves two things: (a) it snapshots the state of the Stacks blockchain to Bitcoin every Bitcoin block (so it can never be rolled back without doing a Bitcoin reorg), and (b) it assists the block-download logic in identifying the first and last blocks of a tenure as well as the quantity in-between. Because the first block of the tenure contains a TenureChange transaction, the node is able to determine the quantity, first block hash, and last block hash of each tenure. This, in turn, allows the node to safely query untrusted Stacks nodes for a tenure's blocks -- the Stacks node cannot feed the requesting garbage data, since the requesting node learns enough data from Bitcoin to authenticate the blocks before processing them.

2. In both systems, each block-commit binds the Stacks chain to the Bitcoin chain.

3. The TenureChange transaction is an attestation from the set of Stackers that they have collectively witnessed the next block-commit transaction, and thus know who the next miner is going to be. It is consumed by both the current miner and the next miner. When the current miner sees a TenureChange, it learns that it should stop producing blocks (since the act of producing a TenureChange is the act of Stackers promising to never sign any more blocks from the current miner in this tenure). When the next miner sees a TenureChange, it learns that it should start producing blocks off of the last miner's last Stacker-signed block. The TenureChange tells the next miner which block this is, so it can be sure to go and download that block and its ancestors if it does not yet have them. These actions -- Stackers agreeing to stop signing the current miner's block, Stackers agreeing to start signing the next miner's block, and the consensus rules ensuring that the next miner's first block contains the TenureChange and that the block it builds atop was the last-signed block from the last miner -- collectively prevent Stacks forks from arising while also ensuring anyone can join as a miner.

[will-corcoran]

Chain Synchronization:

1. Could you provide more insights into the PoX anchor block's mechanics and its role in synchronization, especially regarding new tenures and chain synchronization?

2. How does the removal of PoX anchor block and microblock bitmaps impact synchronization, and what led to this change?

3. How does the node ensure block validity when starting up after synchronization?

4. How does the node maintain real-time synchronization with the current miner after reaching the latest reward cycle?

5. Could you elaborate on the TenureChange transaction's role in identifying blocks between tenure start blocks in synchronization?

6. How does backward compatibility with Stacks 2.x affect synchronization when initiating Nakamoto from a reward cycle boundary?

7. What challenges does the synchronization process need to address concerning chain continuity and potential forks/disruptions?

[jcnelson]

1. This is mostly answered in SIP-007 already. The change Nakamoto brings is to require Stackers to register as block signers. They must register a signing key when they stack their STX, and communicate with other Stackers to create block signatures (i.e. via FROST).

2. (a) The PoX anchor block is not being removed! (b) Microblock inventory bitmaps are no longer needed because there are no longer any microblocks.

3. It processes the blocks as they arrive.

4. The same way it does today: (a) nodes run an epidemic flood protocol to replicate newly-discovered blocks to their neighbors, and (b) if for some reason a node does not receive a pushed block, it will pull the missing block(s) from its neighbors, and (c) if both of the above fail, the neighbor's nodes will detect from its advertised block inventory bitmap that it is missing blocks, and will incrementally push them again (but slowly, so that a node with one missing block does not get N copies of it from N neighbors).

5. The first block in a tenure must contain the TenureChange transaction (this is a consensus rule), which contains enough information for the node to identify the previous tenure's last block's hash and the number of blocks in the last tenure.

6. It doesn't materially affect it -- the node runs the old synchronization algorithm until the last Stacks 2.x reward cycle, and then switches over to the new synchronization algorithm at the start of the first Nakamoto reward cycle.

7. Stackers ensure that forks never arise, and because miners must send their blocks to Stackers for their signature, the Stackers also ensure blocks never get lost. If all Stackers crashed or collude to create a fork, then the chain halts -- a node will stop processing blocks if it sees two different Stacks blocks at the same block height that are signed by the same set of Stackers.

[will-corcoran]

Block Structure:

1. Could you explain the roles of the elements in the new block header format, such as the "total BTC spent" and the "SHA512/256 Merkle tree root," and how they impact Stacks blocks?

2. What's the rationale behind moving the VRF proof to the Nakamoto Coinbase transaction, and how does this change affect block structure and validation?

3. How do the new block header elements impact Stacks block validation and are there any added security considerations?

[jcnelson]

1. This is explained in SIP-005. Stacks blocks today have almost all of the same fields. The only new things are (1) the Stacks block now contains the hash of the Bitcoin block for the tenure in which it was mined, (2) the VRF proof is moved into the Coinbase transaction, and (3) there isn't a microblock public key hash (since there are no microblocks)

2. The block-commit continues to contain the hash of a VRF proof, which serves as the VRF seed in the subsequent tenure. The VRF proof must nevertheless still be published within the block that the block-commit commits to, which is the tenure's first block. The VRF proof only needs to be published once, so instead of creating two Nakamoto Stacks block variants (one with a VRF proof, and one without), we opted to just put it within the Coinbase transaction (which is meant to contain miner-related data already).

3. Not much -- they just need to be consistent with what's on Bitcoin.

[will-corcoran]

Block Storage:

1. Why switch from file-based to sqlite database block storage? How does this impact system performance and scalability?

2. What implications arise from isolating block data from the chainstate? How does this enhance system resilience during block processing?

3. How are indexed columns such as StacksBlockId utilized for efficient Stacks block retrieval and synchronization in the proposed Stacks block database schema?

[jcnelson]

1. To stop the block-processing logic from preventing the block-downloading logic from storing blocks while it is working (this happens today). It should speed up block synchronization.

2. There's less DB contention on bootup. No change in resiliency -- block data is stored separately today.

3. The indexes facilitate efficient calculation of a block inventory bitmap, which nodes exchange to identify what blocks each other node has (this is addressed in the "Block Storage" subsection)

[will-corcoran]

Tenure Changes:

1. Explain the FROST DKG during a Stacker tenure change. What are the key steps and cryptographic operations involved? (cc: @xoloki )

2. Ensure consistent PoX anchor block identification 100 Bitcoin blocks before the next reward cycle. What's the plan for potential delays?

3. In PoX failure with no Stackers, how is the chain halted, and what's the process for recovery to resume block production?

4. Explain the .pox-4 contract's handling of Stackers' key registration during stacking or delegate-stacking STX. Are there specific requirements? ( cc: @setzeus )

5. Discuss the significance of removing the stacking minimum and enabling PoX with one stacker claiming a reward slot. How does this impact PoX and network participation?

6. Explain how TenureChange transactions serve as evidence of empty tenures when not included by the sortition-selected miner.

[jcnelson]

1. This is a @xoloki question, but first, I invite the reader to read the FROST paper

2. I don't understand the question? If the chain stalls for 100 Bitcoin blocks, we're already screwed. Note that we've never failed to identify a PoX block in the current system.

3. The nodes simply stop processing blocks if there is no PoX anchor block. They cannot proceed to download the next reward cycle's blocks anyway, since they need the PoX anchor block to validate the Stackers' block signatures.

4. It's just an extra argument to stack-stx and delegate-stx.

5. It de-risks the possibility that PoX gets disabled due to too few people stacking. This has never happened in Stacks 2.x.

6. The consensus rules require the miner to include TenureChange transactions for all prior empty tenures. If they don't, then not only will Stackers not sign it, but even if they do, nodes won't accept the block anyway. Per the proposal text, there is one TenureChange per Bitcoin block, and per SIP-007, nodes can independently authenticate block-commits. Therefore, a node can detect whether or not a tenure-start Stacks block does not have the expected number of TenureChange transactions.

[xoloki]

A DKG operation consists of several steps:

1. Prior to DKG, each signer must register an ECDSA key for sign/encrypt operations, and be assigned a set of key_ids proportional to their stacking weight, i.e. one key_id per reward slot.
2. Each signer first creates a private polynomial of degree (T-1), where T is the signing threshold, for each controlled key_id. E.g. if we have 4k reward slots, and require 70% approval, then T = (4000 * 0.7) = 2800. The coefficients of these polynomials are Scalars, which are 32-byte integers modulo the curve order.
3. Each signer then computes a public polynomial corresponding to each private polynomial, by multiplying each scalar coefficient by the group generator G.
4. Signers share their public polynomials with all other signers, with a proof of knowledge of the scalar corresponding to the constant coefficient of the polynomial. These are the DkgPublicShares.
5. All signers can now calculate the group public key, by summing the constant coefficients of all public polynomials
6. All signers now evaluate their private polynomials at every key_id. These private polynomial evaluations are encrypted using the ECDSA keys of the owners of the corresponding key_id, then shared with all signers. These are the DkgPrivateShares.
7. All signers collate the DkgPrivateShares, and decrypt the shares for their key_ids. Once decrypted, signers first validate the decrypted shares against the public polynomials from the sending signers. If all shares are valid, then the private shares for each key_id are summed up, and the sum is the key share for that key_id.

[will-corcoran]

Dynamic Runtime Budgets:

1. Explain how Stackers create a TenureExtension Stacks transaction to grant execution budget extension to the current miner and reach consensus.

2. Detail the security measures to protect Stackers' votes for extending budgets from manipulation or malicious influence.

[jcnelson]

1. When 10 minutes have passed since the start of the epoch, a Stacker will ask other Stackers to produce a TenureExtension transaction for the current miner to include in their blocks. If 70% of the other Stackers agree that 10 minutes have passed, then the transaction is created, and the current miner mines it.

2. We already trust that 30% of the Stackers are incorruptable for sBTC to work. We're not adding any additional trust assumptions; we're just putting these trust assumptions to use in block production. If 70% of Stackers will collude to produce TenureExtensions too early, then they can also collude to steal all of the BTC.

[will-corcoran]

New Block Validation Rules:

1. Describe the ECDSA signature generation and verification in Nakamoto for block validation and its role.

2. Explain how the network handles FROST Schnorr signatures from Stackers in the block header.

3. Discuss the importance of applying all Bitcoin transactions up to the tenure's block-commit's Bitcoin block to ensure blockchain integrity.

4. Address how the system handles conflicts or disputes related to the validity or execution of TenureChange and TenureExtension transactions.

5. Expand on the reasons behind removing the PoisonMicroblock transaction variant.

[jcnelson]

1. https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm

2. This is just a Schnorr signature verification, given the FROST signing set's public key and the hash of the block (minus the Schnorr signature itself of course!)

3. This is how Stacks-on-Bitcoin transactions get applied, including sBTC ones. How could it be otherwise? We can't just ignore them.

4. If Stackers can't reach 70% agreement to produce a TenureChange, then it calls into question whether or not they can agree to do anything else. If they somehow can do everything else but this (highly unlikely), then the last miner keeps mining blocks until the Stackers can agree. If they somehow can not agree to produce a TenureExecution transaction but can do everything else, then the miner stops mining when they run out of execution budget for their tenure. The chain temporarily freezes until the next tenure starts.

5. There are no more microblocks

[will-corcoran]

Block Reward Distribution and MEV:

1. What's the role of a "null" miner in ATC-C, and how does this help ensure fairness?

2. How does Nakamoto v1 keep miners motivated during periods with no sortition or MEV opportunities?

3. What are the implications of decreased PoX total spend and Bitcoin blocks without sortition in Nakamoto v1, and how are these challenges addressed?

[jcnelson]

1. This is addressed in the linked document by Jesse Soslow. Per the proposal, the probabilities of miners winning no longer sum to 1.0. Therefore, it's possible that no miner wins sortition, even if they all pay PoX outputs. This is equivalent to saying that there exists a "null" miner controlled by the system that wins in this event (it's just easier to reason about sortitions this way).

2. The last miner who won keeps mining through an empty sortition, and gets all the transaction fees for that additional tenure.

3. PoX spend by honest miners does not decrease. Instead, if a Bitcoin MEV miner excludes all block-commits from their Bitcoin block and sends a single block-commit with a de minimis PoX payout, then they have a very low chance of winning sortition (instead of 100%, which it is today). When a Bitcoin MEV miner mines STX, they forfeit a Bitcoin tx fee from some other Bitcoin user in order to add their single block-commit. Today, the ROI on each block-commit is about 500 dollars (1000 STX * 0.5 USD/STX), which is much, much higher than the typical Bitcoin tx fee.

   Let's consider what happens to F2Pool, who spends 200 sats on PoX and zero sats on transaction fees for their block-commit. Suppose the median total BTC spend over the last five Bitcoin blocks was 500,000 sats (about what it is right now). With ATC-C, their probability of winning sortition would be 200 / max(500,000, 200), or about 0.04% chance. The miner would need to send 2,500 such block-commits before winning a Stacks coinbase (worth about 500 USD). F2Pool had 13.89% of Bitcoin's mining power over the past three months, so it would take them about 4 months to win a single STX coinbase (which is a very long time horizon). Right now, it costs 22 sats/vbyte to get a Bitcoin transaction mined in the next Bitcoin block; this is what Stacks miners pay. A block-commit tx is about 250 vbytes, so that's 5500 sats, or about 1.41 USD with today's BTC price. So, F2Pool would lose money by MEV mining at their current rate if prices stay the same over those 4 months -- they'd forfeit about 3,525 USD in Bitcoin transaction fees (lost by excluding other Bitcoin transactions in order to include their block-commit) for a Stacks coinbase worth 500 USD. They'd have to pay about 1410 sats per block-commit just to break even, and they'd only recoup their investment on average once every 4 months.

   We can probably do better than this too, now that Nakamoto guarantees that block production continues even if there's no block-commit. We could additionally require that a Stacks miner has to have mined in at least 3 of the past 6 Bitcoin blocks in order to have a chance of winning sortition at all, even if there are no other Stacks miners in the given Bitcoin block. This would effectively force F2Pool to drop out or participate honestly, since the odds of them winning 3 Bitcoin blocks in a row at 13.89% mining power are only 0.26% -- of all sequences of 3 Bitcoin blocks, 0.26% of them would all be by F2Pool. They basically have no chance of winning a coinbase with the MEV strategy with this tweak. If we did this, then F2Pool would need to continue their MEV strategy for longer than Bitcoin has been around -- about 961,532 Bitcoin blocks before an expected Stacks coinbase!

[jcnelson]

@muneeb-ali @kantai What do you think of the above tweak?

[will-corcoran]

Bitcoin Fork Recovery:

1. How do Stackers and miners work together to identify valid Stacks transactions after a Bitcoin fork? What ensures accuracy in this process?

2. What makes a Stacks transaction dependent on lost Bitcoin data, requiring re-mining after a fork? Are certain transaction types or data more affected by Bitcoin forks?

3. What are the practical benefits and drawbacks of excluding previously-mined, now-invalid Stacks transactions from the chain history, instead of re-mining them as initially planned?

4. What challenges and considerations come with delaying the implementation of the transaction replay feature for Bitcoin fork recovery until after Nakamoto v1's hard fork, and how does this affect the upgrade timeline and adoption?

[jcnelson]

1. Stackers identify a Bitcoin fork by STX-weighted vote (just as they do anything else). If 70% agree, then a fork happened. This is the best that can be done, because there's no guarantee that all Stacks nodes see the Bitcoin fork (so there's no safe way to do this via a consensus rule).

2. Any transaction that is causally-dependent on Bitcoin state. For example, if your account received STX from a transfer-stx on Bitcoin, then any transactions you send from your account after that are causally-dependent on that transfer-stx Bitcoin transaction. If that transfer-stx Bitcoin transaction gets orphaned, then all of your transactions since could get dropped, if you no longer have the requisite STX balance to pay for their fees. As another example, a transaction that calls (get-burn-block-info?) for something is causally-dependent on the Bitcoin state it references.

3. The benefit is that you can continue to prove that you sent a transaction forever -- it's a question of availability. However, these now-invalid transactions would not execute on the Stacks chainstate even if they were re-mined; they could only be included as data.

4. By not having this feature on day 1, we invite Stacks miner/stacker MEV on transaction reordering every time there's a Bitcoin fork. But the ROI of this is pretty small, since Bitcoin forks are rare as it is. However, it's worth doing because longer-term, the revenue from Stacks miner/stacker MEV could exceed the cost of creating a Bitcoin fork, which is something we do not want. We don't need to hold up Nakamoto v1 to implement this because the MEV ROI on Stacks DeFi is nowhere near high enough for this to happen, but it could be in the future.

[andrerserrano]

If Bitcoin fork resistance isn't consensus critical and can be delayed until after the v1 hard fork, I would suggest doing this. Anything we can do to scope down the v1 feature set to help ensure we hit our target delivery date should be strongly considered.

[will-corcoran]

Helium: Mockamoto v1

1. Have all of the issues for this milestone been created already? Could you please update the OG Mockamoto milestone to reflect the work that needs to be completed for Helium?

2. Can you identify any opportunities for other ICs to contribute towards this milestone?

3. I believe the new Block Structure and Block Append are top of mind for this milestone. Is this correct?

4. How will the single miner be configured to produce blocks approximately every five seconds? Are there specific parameters or settings that need to be defined?

5. Can you provide more details about the integration with the Bitcoin regtest node? Are there any specific challenges or considerations when syncing with Bitcoin blocks produced every 60 seconds?

6. Regarding the new style of block-commits, are there any specific changes or requirements in the implementation that differ from previous versions?

7. Could you elaborate on the process of synthesizing the TenureChange transaction by the miner? Are there any particular data or calculations involved in this synthesis?

[jcnelson]

1. No.

2. Not at this time

3. @kantai is working on this

4. At a minimum, the miner software will need to be modified to produce Nakamoto Stacks blocks instead of microblocks. Also, the unconfirmed state tracking system will need to be refactored to use Nakamoto Stacks blocks instead of microblocks.

5. There shouldn't be if we do this right

6. I don't understand the question? This is a new kind of block-commit, so yes, there are specific changes and requirements that differ from previous versions which the document above lists -- namely, the interpretation of block_header_hash (but I don't think that's what you meant to ask).

7. The miner mocks the behavior of stackers. In the real system, Stackers create this transaction's payload. In Helium, the miner just puts mocked data.

[cuevasm]

Seems 2 should be a priority to jam with engineering leads like @saralab and Tyler on so we don't have wasted bandwidth and everyone can generally accelerate with more clarity. It's great that we now have so many more contributors so let's not waste it!

What things can be taken off your plate that are blocking bandwidth to parcel out more work for other contributors?