Long post ahead, 1 hr+
Background:
The current Stacks miner centralization problem is a manifestation of the “51% attack”. The symptoms are orphan blocks and long-chain reorganization which compromises transaction finality. During a chain reorg, honest miners are revoked of their block rewards for which they have paid commitments for. Becoming unprofitable, they drop out leading to further mining centralization. We are already past this point.
The 51% attack is an attack vector that presents itself in Nakamoto-Consensus blockchains for which Stacks and Bitcoin are a part. The way the attack works is if a selfish miner can accrue at least 51% of the mining power, they can build a fork hidden from the rest of the network. This fork is composed exclusively from the attacker’s own blocks through refusing to integrate the blocks of others (orphaning) and keeping their own blocks to themselves (withholding). Then at a later point when their hidden fork exceeds the length of that of the competing “canonical fork” - an inevitability because the selfish miner produces blocks faster than the rest of the network combined - the selfish miner then publishes his fork for the rest of the network to reckon with. The honest miners receiving this longer fork have to accept this fork as part of the new canonical chain per Nakamoto Consensus, evicting the honest blocks from their place. Even as this is not the desired outcome at-large, it is the rule: The longest fork is proof of the most work done and reorganizing the chain around the longest fork is a core consensus rule of Nakamoto Consensus which allows contentious forks to resolve to one canonical chain without appealing to a central authority. Thus is a brief overview of the mechanics of the 51% attack.
We are not advocating to remove/replace Nakamoto Consensus in Stacks. It has a proven track record to converge without trust and under adversarial conditions. It is also attack-resistant, but only if certain supporting conditions are met.
Nakamoto Consensus enforces how to resolve a conflict i.e. fork length, however it takes no stance or enforcement on whether the techniques or strategies used to create said forks are fair. During bitcoin’s GPU mining days, the introduction of ASICs caused an uproar as just a few dozen of these machines could completely dominate the hashing power of the entire network. If ASICs were forever restricted to the hands of a few, the Bitcoin network would not be secure despite operating under Nakamoto Consensus. However, today Bitcoin is considered very secure. The point is this: deploying the Nakamoto Consensus on its own does not confer automatic security. There are other supporting conditions required for this consensus method to provide meaningful security.
What are these supporting conditions that make an attack on Bitcoin difficult? We can identify 2 conditions:
A1. Insurmountable upfront financial and logistical costs to anyone wishing to accrue 51% of hashing power. With bitcoin, the combination of ASIC machines, technology, logistics, and operational expertise adds up to be a massive economic barrier up-front for a malicious entrant. The costs are in the billions of dollars if indeed even feasible at all.
Q: Why then, don’t the current pre-existing bitcoin miners collude their hash power to 51% attack the network for their own benefit?
A2. Miners have substantial consolidated capital investment. Given bitcoin mining operations have substantial illiquid capital in the form of ASIC machines and its associated enterprise, degrading the network would be akin to slashing the valuation of this capital. Bitcoin could be considered proof-of-stake of ASICs. In short, it is economically harmful to them to degrade the network. It is common belief, at a glance, that bitcoin is secured by hashpower alone, but this view is incomplete. A bitcoin miner’s desire to preserve consolidated capital motivates the miners to conduct themselves for the benefit of the network, rejecting cursory bribes to undermine it. The particulars of the social and economic cast that lies beyond the code often gets overlooked when reasoning about bitcoin security.
As for the Stacks network, those 2 supporting conditions are not satisfied. Let’s review:
B1. It’s cheap and easy to accrue 51% of Stacks mining power. To accrue 51% of the mining power, the malicious miner just needs to submit 51% of the total block commitments for the sortition step. Rational miners are looking to make a profit, so the total value of block commitments generally does not exceed the value of the stacks block reward. At the current price of $0.5 (as of this writing) the block reward is $500. Practically speaking, commitments totaling above the $500 threshold will result in a negative expected value (-EV) for all mining participants. A malicious miner will over-commit precisely to economically evict honest miners and wrest control of the mining pool. The cost to 51% attack the network is thus measured in only hundreds of dollars. Proposals to fix 51% attacks that focus on tuning rules around threshold commitments and the block reward distribution are still limiting the security budget to some fraction or low multiples of the value of the block reward, at best.
B2. Stacks miners have zero consolidated capital requirement. Without consolidated investment, the miners’ actions are no longer tied to the long-term health of the network. Mercenary mining behavior will dominate where the miners are only interested in very short-term results such as profiting from the spread between their block commitments and the block reward. They are susceptible to bribes and other corrupt behavior as they have no locked-in or vested interest. It is almost certain that the current batch of miners are not advocates for the network for which they are a participant, have no interest in accumulating stacks tokens and liquidate their rewards to realize their profit immediately.
Is there a solution?
Yes, perhaps. The claim is that it is possible to upgrade the Stacks network protocol to gain the security virtues as described in A1 and A2 while preserving Nakamoto Consensus. Restated, the Stacks network can gain security so that a would-be 51% attacker will confront these 3 Security Postulates:
C1. Insurmountable upfront financial costs to accrue 51% mining power.
C2. They themselves have pre-existing consolidated capital invested in the network.
C3. Nakamoto Consensus is the tie-breaker; conflict-resolution is trustless. When conflicting forks present themselves, the longest fork wins.
In my opinion whichever solution that ultimately gets adopted should have to satisfy these 3 postulates in order to demonstrate sufficient tamper-resistance.
The Proposed Solution:
We begin by detaching Nakamoto Consensus from the economics of block commitments. The reason being it’s too cheap (see point B1). Instead we organize Nakamoto Consensus around stackers where there is a large amount of capital in play. Nakamoto Consensus is now the conflict-resolution strategy between stackers. Conflict resolution for what issue? Conflict resolution for the stacker’s new responsibility of advancing the chain tip. Let’s dive into the details.
The actors:
-
Stackers: The same as the stackers as we know them today with one more thing: they have a new responsibility of advancing the chain tip. There will be Stacker nodes that Stackers must run to perform this task.
-
Block Committers: Block committers make block commitments. The closest analogue is current stacks miners, but we shall deprecate that term because it’s overloaded for tasks they are no longer responsible for under this design.
-
Stacks full nodes: Same as what they are right now. Not super relevant to this discussion.
Let’s walk through the steps of a single block round in a basic ideal path. We begin with all actors agreeing on same chain-state:
-
At the start of the block round, each Block Committer constructs a valid block that he would like to see the chain-tip advance to should he win the sortition. These are their candidate blocks.
-
Each Block Committer sends his candidate block to the Stackers for archival.
-
Stackers receive candidate blocks from Block Commiters. They validate and store each block in their cache, retrievable via its hash.
-
Each Block Committer makes their block commitments along with their candidate block’s hash for sortition.
-
After sortition is complete, the Stackers of the 2 slots randomly selected to receive the PoX yield are the Chosen Stackers. With the hash of the winning candidate block at hand, each Chosen Stacker retrieves the block from its cache, validates it and appends it to its view of the canonical chain, advancing it.
-
Each Chosen Stacker then signs that candidate block which is now canonical, and publishes the canonical block to the rest of the network.
-
The network nodes receive the canonical block, validates its signature confirming it originates from one of the Chosen Stackers, validates the block for itself and appends it to the tip of their chain. The Block Committer receives his block reward.
-
A new round begins.
First point to note: There are no changes in either the reward or payout structure for either the Block Committers (formerly miners) or Stackers. I repeat: there are no new financial incentives introduced in either magnitude nor distribution for anybody; no one is earning more or earning less than what the current network rules have in place. On net, this design is asking Stackers to take an active part to earn their PoX yield in exchange to heighten network security, rather than sitting by idly as they do now.
Second point: The tasks that were previously held by the miners are now split between two acting groups. The Block Committers exclusively construct blocks but cannot control the chain-tip; The Stackers decides on the chain-tip but cannot control the choice of block that appends to it.
How much more security can be gained by this arrangement? Let’s walk through an attacker scenario. Recall that for this design to be worthwhile, we must demonstrate that a would-be 51% attacker encounters the 3 Security Postulates (C1, C2, C3) that impede their attempts.
51% Attack Scenario:
The attacker Alice is looking to produce a fork consisting of her own blocks. This fork is to be mined in secret and then published at a later time when she needs to reorg and overwrite the canonical chain. Her motivation is perhaps she is about to place a on-chain bet with a casino application: if she wins the bet, she does not need to reorg the chain and can abandon the hidden fork; if she loses, she will publish her hidden fork to the rest of network in an attempt to unwind the transaction history to a state before the bet took place so as if the bet never occurred.
Her strategy: She has Block Committer nodes to create candidate blocks to her specification. She also runs Stacker nodes that control 10 PoX slots (out of hundreds) so she has a chance to become the Chosen Stacker which earns her the right to append her block to the chain. Let’s illustrate the sequence of events step-by-step:
Attempt 1:
-
Alice constructs a candidate block and enters into the sortition with her block.
-
She wins the sortition so her candidate block is selected to be incorporated into the chain.
-
Her Stacker node also immediately wins 1 of 2 PoX slots, making her one of the Chosen Stackers, giving her the right to append her block to the chain.
-
Her Stacker node appends her block to the chain, but she withholds from broadcasting the signed block in order to initiate her secret fork.
-
However, the winner of the second PoX slot is an honest stacker and acts honestly. He broadcasts his block to the rest of the network. Therefore everyone is on the same chain-tip as Alice and no secret fork is created. This attack attempt is thwarted.
Alice, realizing she needs to win the pair of PoX slots, tries again.
Attempt 2:
-
Alice enters into the sortition with her candidate block.
-
She wins the sortition so her candidate block is selected to be incorporated into the chain.
-
Her Stacker nodes also immediately wins both PoX slots, giving her exclusive control to append to the chain.
-
Her Stacker node appends her block to the chain, but she withholds from broadcasting the signed block in order to initiate her secret fork. Only her nodes see the chain tip advance to block height 101 (stx101) while the rest of the network still sees the tip at height 100 (stx100).
-
For the network at-large, failure to receive a block is a “block-miss” and a non-event. No special action is needed. A new block round begins.
-
Alice creates her candidate block. This candidate block is now archived by only her own Stacker nodes as other honest nodes cannot validate her block due to being on a different chain-tip than her.
-
Alice enters into sortition with her candidate block.
-
Alice wins the sortition again and her candidate block is selected to be incorporated into the chain.
-
Her Stacker nodes also immediately wins both PoX slots, giving her exclusive control to append to the chain again.
-
Her Stacker node appends her block to the chain. Again, she withholds broadcasting the signed block in order to build her secret fork to length 2. Her block height is now at (stx102) while the rest of the network still sees the tip at (stx100).
-
A new block cycle begins and she repeats the steps above in an attempt to add to her fork …
It should be apparent to the astute reader that for Alice to even reach this far with the 10 slots she controls is a highly improbable statistical outcome although possible. At this point she would be wise to abandon her secret fork attempt and publish her blocks to collect her block rewards. To push on, she would have to continue her streak of winning the sortition and winning her pair of PoX slots in order to maintain her lead. It is exceedingly unlikely given her current control of the network. Furthermore her theoretical maximum fork length she can conceal is of length 5.
She has 10 PoX slots and each round consumes 2 slots. Now assuming the most likely event does take place over the next 3 blocks and she loses both the sortition and slot drawings, the honest network will add blocks (‘stx101), (‘stx102), and (‘stx103) to their chain-tip. Per Nakamoto consensus, if she publishes her fork (stx102) it will not displace (‘stx103), instead her chain will reorg to (‘stx103). Nakamoto Consensus selecting the longest fork is now precisely the outcome the network desires; thus Postulate C3 is demonstrated.
Alice however, is unfazed and she correctly surmises she will need to control a substantial portion of the PoX slots - over 51% of the PoX slots, in fact - to be able to consistently win both slot selections during each round. At current market value, there are over $300MM of stacks tokens stacked. So Alice raises at least $300MM and hits every bid on the stacks token market to acquire the correct nominal amount of tokens needed to control over half the slots; thus Postulate C1 is demonstrated.
Alice then takes her tokens and stack them in the network. However, having done this, Alice now has substantial consolidated capital locked in the network and she is no longer interested in performing actions that could undermine that capital. The incentives simply do not align that way. In fact, she is likely to become an advocate of the network. Alice is now an ally; thus Postulate C2 is demonstrated.
Now that the 3 Security Postulates have been demonstrated, we can answer the question of how much security is gained quantitatively by comparing the estimated financial cost of conducting a hidden fork between the current protocol and the proposed upgrade. The cost for the current is measured in the hundreds of dollars (point B1), whereas post upgrade it would be in the hundreds of millions, or by a factor of about 1 million fold (1,000,000x).
Other considerations: What if Stackers refuse to run the Stacker node, or refuse to sign blocks?
If every single Stacker node is offline or decides not to sign off the canonical block, then block production will grind to a halt. If only half of the Stacker nodes are online, then the block progression will move at half the speed. Stackers are economically incentivized to be online and sign, not only because they have consolidated capital they wish to preserve, but also because their PoX yield depends on it. Block Committers put up block commitments expecting the block reward but need a signature to receive it. Stackers want the bitcoin yield and can sign off a valid block. This is a perfect coincidence of wants and both participants are peers in this exchange. Neither party has lordship over the other. If Stackers do not sign valid blocks presented to them, Block Committers will refuse to make block commitments and over time the PoX yield will decrease proportionally to the Stackers’ absenteeism. If Stackers are economically rational actors who voluntarily give up short-term liquidity in exchange for stacking yield, they will be online ready to sign.
What about on a block-to-block basis? Is there a way to deny a Stacker of PoX yield if they are offline or don’t do their job?
Not really for now. Controlling bitcoin transfers is a bitcoin-write-problem. We could however adopt a different block reward distribution schedule where the block reward is paid out pro-rata to block commitments made over a certain span of sortition blocks. This would virtually guarantee the Block Committer with the missed block will get rewarded when the next block is signed. This also solves the Bitcoin MEV problem and is one of the solutions under consideration.
Censorship Resistance
There is an attack called the “empty block attack”. An empty block is a block without any transactions; they are valid, however. The way this works is if a malicious block producer has 51% of the mining power, this attacker can choose to append empty block after empty block and essentially halt the blockchain’s transaction activity. Honest block producers who present useful blocks are simply orphaned and never become part of the canonical chain. What is the motive for this attack? It’s malicious intent. It is not an economically rational behavior within the incentives of the network; it is clearly more profitable to collect transaction fees by processing transactions. This is the reason it’s not an attack typically performed. Nonetheless it does occur for ideological reasons and it amounts to censorship.
Besides demonstrating reorg resistance, we must also demonstrate how this proposed design is censorship resistant.
The current Stacks network is vulnerable to this vector of attack because it currently has centralized mining control. The Stacks network is not experiencing empty block attacks at the moment because although the miner is malicious they are still economically rational and prefer to maximize profit processing transactions. However if their intent changes they can halt the network while still operating at a profit - just less profit. If this happens, the current network protocol doesn’t have a way to recover other than directed intervention by the community.
Let’s consider how the upgraded protocol could handle this attack.
Empty Block Attack Scenario:
The attacker Alice has been commissioned to attack the Stacks network in order to undermine confidence in the project. Since she cannot reorg the chain, she will attempt the empty-block attack instead.
Her strategy: She has a Block Commiter node to create empty blocks to archive with Stackers. In order to position herself to win every sortition, she must push out any other honest Block Committer… By overbidding on the block reward, she will make it -EV for Block Committers. Economically rational Block Committers will drop out and She will be the only Block Committer remaining. This is the sequence of events:
Attempt 1:
-
Alice constructs an empty block and submits it to the Stackers
-
Alice enters sortition by making a block commit worth $500 which is $500 on top of pre-existing honest block commitments worth also $500. The block reward itself is worth $500. So now we have $1000 worth of block commitments (the honest Block Committer’s $500 + Alice’s $500) chasing after $500 worth of block rewards. This is a negative expected return (-EV) for all Block Committers who will on average for every $1 spent will see $0.5 returned.
-
The sortition completes and regardless of the outcome, some honest Block Committers begin to leave because they recognize a bad deal when they see one.
-
A new block round begins and Alice repeats her actions. The block commitments total $700 for this round with (Alice’s $500) + (honest Block Committers’ $200). $700 dollars now chases $500.
-
The sortition completes and Alice’s empty block is the winner.
-
The chain appends an empty block.
-
A new block round begins and all honest Block Committers have dropped out. Alice submits the sole block commitment of $500 and is the sole sortition participant and winner. The blocks appended to the chain are now empty.
Alice can sustain this course of action indefinitely because her $500 block commitment is rewarded with a $500 block reward so she is at net zero on executing this attack. It could be suggested that this attack be made more costly for Alice if the protocol mandates consolidated capital in the network as a security requirement for block production. However this requirement would void the open-membership quality that Block Committers currently enjoy. I believe this is a non-negotiable for this community.
As It turns out the proposal as-is already has natural affordances to defeat this. The concept is PoX-Recycling: Stacker can take the PoX that Alice pays to them and recycle this yield as block commitments to be used back against Alice. Since this is pure yield, Stackers incur no net losses for doing this. With the network in jeopardy, Stackers will undoubtedly mobilize together, either informally or in code, to protect their consolidated capital. Let’s play out this action resuming where Alice left off:
-
Stackers, realizing the network is being attacked, cooperatively agree to recycle PoX rewards for 10 rounds.
-
At the start of the new block round, each of the pair of Chosen Stackers that received their PoX rewards from the previous round (X-Chosen Stackers), will submit a useful block thus acting as Block Committers.
-
The X-Chosen Stackers recycle their entire PoX yield ($500) into their block commitments. Alice also makes her block commitment of $500. Now there is $1000 in total block commitments (Stacker’s $500) + (Alice’s $500) contending for a $500 block reward. Alice now incurs a -EV for her attack.
-
The sortition completes. Alice’s empty block wins and is attached to the chain. The Chosen Stackers’ PoX yield now totals $1000.
-
A new round begins. The X-Chosen Stackers recycle their entire PoX yield (now $1000) into their block commitments. Alice also makes her block commitment of $500. Now there is $1500 in total block commitments (Stacker’s $1000) + (Alice’s $500) contending for a $500 block reward. The Stackers’ block commitments now dominate Alice’s and she incurs an even higher -EV.
-
The sortition completes. The Stacker’s useful block wins and transaction flow continues.
It is apparent that if this continues for 10 rounds, Alice’s $500 block commitment will be up against Stacker’s $5000 block commitments. Not only is Alice losing her entire $500 due to extreme -EV, her attack exerts negligible pressure on transaction flow. Furthermore, ramping up her spending cannot help her; Alice’s -EV is the Stackers’ +EV so she will always be outspent. Alice’s other option is acquire enough PoX slots, over 51%, in order to break the Stackers resolve, and so we have the same resistance against this attack as it is with the 51% attack.
In Summary:
I want to thank you for your attention. It’s an exceptionally long post and we had to develop our reasoning from ground truths and praxeology. I think this proposal presents zero compromises for Stack’s values: Nakamoto Consensus, open membership for block production, and preserves existing reward payout structures.
Comments?