Skip to content

Instantly share code, notes, and snippets.

@jcnelson
Created November 16, 2021 13:50
Show Gist options
  • Star 4 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save jcnelson/802d25994721d88ab7c7991bde88b0a9 to your computer and use it in GitHub Desktop.
Save jcnelson/802d25994721d88ab7c7991bde88b0a9 to your computer and use it in GitHub Desktop.
How Stacking Helps the Network

PoX can't occur unless the network is sufficiently stable. The only way to get PoX to start for a reward cycle is to confirm a PoX anchor block with 80% confidence within a 100-block window called the "prepare phase." Miners collectively determine the anchor block when they mine blocks that descend from it -- if PoX begins, there will be exactly one Stacks block in which at least 80 of the 100 sortitions in the prepare phase are its descendants. By deciding on an anchor block, miners collectively determine what the PoX reward set will be. But in order to choose an anchor block, they have to have it in their chainstate; otherwise, they'd be unable to mine a block that descends from it. Miners don't know what the anchor block will be until the end of the prepare phase, so this means that they need all of the Stacks blocks in order to begin the next PoX reward cycle (since any Stacks block can be the anchor block -- even one from many reward cycles ago).

At the same time, because Stacks blocks are stored and propagated via a separate p2p network from Bitcoin, there exists the possibility that a Stacks miner can be missing Stacks blocks that actually exist somewhere. The node will know that they exist because they'll see the winning sortition's block hash on the Bitcoin chain, but be unable to find the block itself from its peer neighbors. For example, suppose someone mines a block but shuts down before propagating it (this has happened). The rest of the network will see the sortition for that block, but they may either never see the block itself, or they may see it very far into the future (e.g. suppose the node that mined it turns back on at a later date) The point is, there's no way to distinguish a block that is truly missing from a block that simply hasn't propagated yet.

Now, what happens if the PoX anchor block goes missing like this? SIP-007 describes a recovery procedure whereby miners would "fork around" it by mining a chain through PoB that does not descend from the missing anchor block. Any/all forks descending from the anchor block will be overtaken by a PoB fork, and the network will recover. From the perspective of the rest of the network, it will look like miners built a chain descending from a missing block, and then built a different chain that does not descend from it. Miners need to do this, because without the PoX anchor block, there's no way to validate any blocks that descend from it, which means that there's no way to validate any blocks in the subsequent reward cycle that pay to any Bitcoin addresses besides the burn address.

A miner can't distinguish between a sortition that corresponds to a block that is truly missing, and a sortition that corresponds to a block that exists but they cannot reach. The latter is particularly devistating to miners, because it prevents them from making forward progress on the chain that the rest of the miners are working on. Worse, the miner's ISP and/or the miner peer's neighbors may be deliberately preventing the miner from finding this block via an eclipse attack.

This is where Stacking comes in. While there's no programmatic way to determine if a block is truly missing or just hasn't been propagated yet, the act of Stacking provides a hint as to whether or not other network participants know about a missing block's existence. Because PoX can only activate if blocks more-or-less reliably propagate, economically-rational Stackers would only lock their STX if they had reason to believe that blocks were reliably propagating. If PoX couldn't occur, Stackers would instead keep their STX liquid, so they could do other economically-profitable things with them that keep working even if the network isn't stable enough for PoX (e.g. trade them, mine CityCoins, etc.). So, if a miner sees that a lot of STX are getting locked in the history of blocks leading up to the missing block, the miner can infer that other people think that the network is sufficiently stable for PoX. If this is the case, then the miner can further deduce tha the block they think is missing is actually being hidden from them -- it's not truly missing; it just hasn't been propagated to them.

A miner looks at the history of Stacking in the .pox contract to deduce whether or not a missing block is actually available in the network. Each miner makes their own decisions as to how to interpret this history, but the point is that Stacking gives them some extra information to help them figure out what's going on with a missing block. PoX rewards can be thought of as a financial incentive for Stackers to help miners deduce the stability of the network in this way.

An alternative system design would be for miners to directly communicate with one another to advertise the (un)availability of blocks necessary for PoX to begin. The advantage of using Stacking to provide block availability hints (and the reason Stacks doesn't do this) is that doing so is open-membership. Miners do not need to talk to one another, or even be aware of each other's existence, in order to independently deduce block (un)availability from Stacker data. Miners cannot exclude other miners from reading PoX history, whereas a miner-to-miner protocol for advertising block (un)availability would be.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment