Seeking Clarity on L2 Transaction Continuity After Bitcoin Reorgs

Apps
#1

I’m developing an app on Stacks and need to understand how L2 transactions are managed after a Bitcoin reorganization. My main concern is ensuring that transactions dropped during a reorg are automatically reprocessed with their original parameters, crucial for the app’s functionality.

For instance, if a market maker’s transaction to move stablecoin to a vault (representing a synthetic long Bitcoin position) fails due to a reorg, it could disrupt their hedging strategy, leaving them with an unintended exposure.

How does Stacks ensure the continuity of such L2 transactions? Insights into mechanisms like taint analysis for reprocessing L2-only transactions accurately post-reorg would be highly valuable.

This question is prompted by Muneeb’s insights shared on Twitter, and I’m looking for additional information or examples to understand how Stacks currently handles, or plans to handle, dropped L2 transactions. Here’s the reference to Muneeb’s tweet for context: https://twitter.com/muneeb/status/1752009319569072139

Any insights or experiences you could share would be incredibly helpful. Thank you in advance for your time and assistance.

3 Likes
#2

Muneeb distinguishes between low and high-value transactions towards the end of his discussion. Yet, significant capital exchanges, like P2P transactions of sBTC for stablecoins, could occur as L2-only transactions. Is this suggesting that such transactions wouldn’t make sense? Thanks for chiming in and providing your take on this.

Users can choose to just run with fast confirmations for low-value “tainted” tx (given how infrequent Bitcoin forks are in practice), but for high-value “tainted” tx, it’d make sense to wait for a few Bitcoin confirmations. In other words, if you are aping into some new NFT or memecoin, you can enjoy the fast blocks (L2-only tx), but if your tx reads DLCs from L1 then it is better to wait for a few Bitcoin confirmations.

1 Like
#3

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.

Pre-Nakamoto

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:

  1. Stacks forks on its own relatively frequently
  2. Stacks forks can diverge for several blocks in a row before reconverging
  3. 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.

Post-Nakamoto

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:

  1. 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.

Replaying Transactions

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,
Ashton

5 Likes
#4

Thank you, Ashton, for your detailed explanation. Let me briefly illustrate my understanding to ensure I’ve grasped the concepts correctly and then ask for your opinion on it.

Imagine I have two reserves: a stablecoin reserve held in a smart contract and an sBTC reserve in a wallet. Both reserves have been anchored to the Bitcoin blockchain for over six blocks. Now, consider a transaction on L2, where sBTC is exchanged for stablecoins. The transaction fixes the price and amounts at the time of the exchange.

Suppose a Bitcoin reorganization occurs, leading to a subsequent Stacks reorganization. Given that 70% of stackers are informed about the Stacks state before the reorg, they could, in theory, ensure that L2 transactions like mine are replayed in the same order they were initially validated, unaffected by the reorg. This suggests that my L2 transaction, being considered “untainted,” would proceed successfully, honoring the originally agreed-upon exchange conditions due to the unchanged reserve amounts in both the smart contract and wallet.

Here’s where I seek your insight: Does this scenario imply that entities involved in such L2 transactions could anticipate their transactions to remain unaffected (or “untainted”) in the event of a reorg? I’m curious to hear your thoughts on whether my interpretation aligns with the technical realities and whether there might be nuances I’ve overlooked.

1 Like
#5

Unrelated question to the OP @AshtonStephens.

For those of us currently running nodes. What’s the expectation of node requirements with Nakamoto?
When you say

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”.

Is this implying computation and storage will be significantly higher than they are currently?
Given 5 seconds blocks, I can’t imagine this isn’t the case unless throughput is throttled.
Thanks for the clarity.
Jake

2 Likes
#6

Quick (easy) question for you @AshtonStephens: I heard Chan Han from Alex saying they can immediately mint aBTC after the BTC transaction goes through, without having to wait. In the case of a reorg, will both the BTC and L2 aBTC mint transactions fail, making it safe for Alex to mint aBTC instantly, as opposed to waiting for 6 blocks like it will be the case for all other layers? Replayability on Stacks only applies to L2-only transactions. Since minting aBTC depends on an L1 transaction, replayability doesn’t apply in this case. I want to confirm if my understanding of Chan Han’s statement is correct.

#8

What’s the roadmap for implementing L2-only transaction replayability? This feature could significantly enhance UX for projects like ours at Jing.cash by eliminating the 6-block cool-down period, reducing wait times from over an hour to none.

1 Like