Under Nakamoto Stacks transactions won’t impactfully reorganize due to a Bitcoin fork. Not only is reorging relatively infrequent, but transactions on Stacks that got reorganized due to a Bitcoin fork behave just as reorganized Bitcoin transactions do. With some future analysis, transactions purely on the L2 chain may one day be entirely unaffected.
I’m going to respond to what I perceive to be the fundamental confusion around the finality on the Stacks chain post Nakamoto. This is both a complicated and an impactful concept so it makes sense that there are a lot of questions about it.
Let’s quickly consider the current state of the Stacks blockchain before we look at the forking behavior of the Nakamoto release. There are a few big pain points in regard to transaction finality and forking right now:
- Stacks forks on its own relatively frequently
- Stacks forks can diverge for several blocks in a row before reconverging
- Bitcoin forks cause the Stacks chain to fork
The top two together can make the Stacks chainstate hard to grok. The Bitcoin piece is so infrequent compared to the other two that we don’t often talk about it. The issue here is that the Stacks blockchain forks a lot more than Bitcoin does and forks for longer.
Under Nakamoto the Stacks chain won’t realistically fork on its own. It is designed not to fork with only special exceptions, and it’s entirely infeasible for Stacks to fork on its own if even 31% of Stackers don’t want it to fork, and even then it would likely only happen within the span of a single tenure. I can explain why this is somewhere else, but for the rest of this explanation let’s assume it can’t (though the rest of the explanation here is enough for you to figure out why).
Here are the cases in which Stacks forks post Nakamoto:
- Bitcoin forks cause the Stacks chain to fork
Under Nakamoto, instead of winning the right to make a block miners win the right to make a ton of blocks, and during that time we say they’re under “tenure”. Every single Stacks block produced in a tenure requires at least 70% of Stackers to approve (sign) it for it to be included in the Stacks blockchain. The Stackers are watching the Bitcoin blockchain and will only sign blocks from the miner that won the latest sortition.
When the SIP talks about Bitcoin finality it’s referring specifically to transactions on the Stacks blockchain being exactly as final as those on the Bitcoin blockchain within a given tenure because the only way for Stacks to fork is for Bitcoin to fork.
Now, let’s imagine that Bitcoin reorganizes itself and the Stackers were watching a Bitcoin fork that is now sub-optimal. The Stackers would essentially go back in time to the latest common sortition between the fork that it was watching and the new best Bitcoin fork and start signing the blocks within the tenures from there. Note that 70% of the Stackers will be doing the same thing all at once, and the moment 70% agree to start signing from the latest tenure on the new Bitcoin fork there’s a new singularly optimal Stacks blockchain.
So what happens to the transactions that were confirmed on the tenure that got reorganized? Nothing. Still in the mempool as if the reorganized tenure didn’t happen. If you used a transaction to do something irreversible off chain then you’ve got a problem on your hands, but for anything within the Stacks blockchain everything is fine. I cannot stress enough, this is 1-1 with a Bitcoin fork reorganizing a Bitcoin transaction. You shouldn’t consider a transaction on Bitcoin final if it’s near the chain tip, and you shouldn’t consider a Stacks transaction final if it’s near the tenure tip.
Since 70% of the signers have to sign any Stacks block included in the chain at least 70% of signers know the state of the chain before and after a Bitcoin fork causes a Stacks reorg. It’s conceivable that the signers could be implemented to refuse to sign any blocks from the new tenure that don’t explicitly replay the transactions that just got reorganized.
There’s a catch to this that makes enforcing it difficult: if a transaction were dependent on something on the Bitcoin blockchain that also got reorganized (a peg-in, for example), that transaction would now be invalid. Taint analysis is when you attempt to answer the questions “which transaction interacted with the now-orphaned Bitcoin blockchain in a way that makes them invalid (tainted) in the new chain” and then also “which transactions interacted with the now invalid (tainted) transaction such that they are now also invalid”. There’s a cascading effect, but enforcing any kind of replay requires that the Stackers and the Miners can identify which transactions can get replayed at all.
Taint analysis, and subsequently replay enforcement, can be added some time down the line. For now, Nakamoto explicitly ties the Stacks blockchain to the Bitcoin blockchain such that there’s only one optimal Stacks fork tied to Bitcoin at any given point. This is completely 1-1 with the Bitcoin Blockchain behavior, but on the tenure scale.
Let me know if this answers your questions,