I wanted to keep the OP heavy on facts and light on opinion. So, here are my opinions on this issue:
- I believe that the coalition is likely controlled by a single entity. At best it’s a few coordinated entities who are carrying out a deliberate value extraction scheme. It is certainly not the product of an innocent bug or any of the other more benign explanations that were offered in the other thread. When you really look at the data, the behavior is simply way too coordinated and aggressive for those explanations to make sense.
- I believe that 1-3 entities controlling a $1B blockchain and censoring others from joining the mining pool is an unmitigated emergency. To the extent that there’s competition for engineering resources, I’d argue that Orphan MEV should clearly be prioritized ahead of Bitcoin MEV. I’d also argue that it should be prioritized ahead of sBTC and any other top priorities.
- I believe that the issue is totally fixable.
Suggested Solutions
A few quick takes on the suggested solutions that I linked above:
- I do not believe that pre-commit voting will succeed in solving or even mitigating Orphan MEV, for reasons I outlined in that thread. I’m open to being wrong and am curious to here feedback from @jude and others.
- I’m intrigued by the idea of fork temperature, though I’m still kinda chewing on it. There are some legitimate objections in the github discussion, and it sounds like it could degenerate into an undesirable “fork wars” scenario.
- I think the “Lift mining off of Bitcoin” proposal would clearly solve the issue (as well as Bitcoin MEV), and in general I like that proposal. However, it sounds like a big change, and @jude acknowledged in the post that it would take some time and effort to implement. So while I’d be very open to this as the ultimate solution, I still think an interim solution is badly needed.
A Few Assertions
Before I get into my own proposed solution, I want to lay out a few assertions. If you don’t agree w/ these assertions (which is cool), you probably will not agree w/ my proposed solution. So I want to lay them out systematically and make a case for them:
Assertion #1: Forking is an anti-pattern
As I see it, there are only 2 reasons for a miner to fork the chain:
- It was an accident
- Manipulation
(1) is a catchall for any benign technical reason that a miner may fork the chain (e.g. flash blocks, network too slow, bug in mining code, etc.). (2) is what the coalition does. I am truly curious to see if others can put forth reasons outside of these 2 buckets, b/c in my (admittedly non-expert) mind this is the complete list.
In other words, forking is an anti-pattern. I truly can not think of a scenario where it’s better for the network for a miner to create a fork vs. simply mining from the longest chaintip. Forks create confusion about the canonical state of the chain, reduce throughput, and serve as a vector for manipulation and value extraction. They are an undesirable event, and it is completely legitimate to disincentivize them at the protocol level.
Assertion #2: Stacks current protocol design encourages forks
I think all of us understand the macro benefit that the coalition gets from incessant forking of other miners: they eliminate potential competion.
What I haven’t seen discussed is the micro benefit. And I’ll preface this by saying that I am not 100% sure on this point, so it’s really more of a question than an assertion, which is: How are mining rewards handled in the case of a (successful) fork?
stacks-dump
seems to suggest that the miner gets their normal 1k STX reward for the block, but logically that doesn’t seem right to me. It seems more likely that they would get a larger reward similar to what happens with missed blocks. IF that is the case – and it would be great if someone who really knows can confirm/refute – then the coalition’s incentives to fork are about more than squashing competition. The forking operation would be not just a mechanism to deny a potential competitor a block reward, but instead a mechanism to effectively steal the other miner’s block reward.
So micro benefit is a question to me, and if it’s real I think it’s very much worth calling out. That said, I’d stand behind this assertion based on macro benefit alone. Admittedly it does need a qualifier though, so perhaps I should amend to “Stacks current protocol design encourages forks if you control >51% of the mining power”, which unfortunately someone does.
Assertion #3: Designs that explicitly penalize excessive forking are the most direct way to combat Orphan MEV
There have been some interesting proposals on how to combat Orphan MEV, but I’ve not yet seen one that seeks to explicitly measure and penalize excessive forking. To me this is the most direct and likely the most effective way to make the behavior stop. It can and should be combined with other approaches like compensating orphaned miners, but penalizing excessive forking is a natural tool to address Orphan MEV.
Proposed Solution: Slash and Redirect Mining Rewards When Orphan Frequency Is Too High
Here’s the idea:
Every X Bitcoin blocks, calculate an Orphan Frequency O, defined as the number of orphans divided by the total number of Stacks blocks mined. Feed O into a slashing function F(O) and slash mining rewards on any “forking blocks” within the X block interval, where a forking block is defined as any block that creates one or more orphans. If slashing occurs, redirect a percentage P of the slashed funds to orphaned miners, pro rata based on the number of orphaned blocks they mined in the interval.
Attempting to set parameters, I would suggest X=100 and P=0.5. Designing a good F is probably the trickiest part, and I think that would be worthy of discussion if the group wanted to get serious about this proposal. But as a jumping off point I’ll throw out a uniform distribution between O=5 and O=15. In other words, if fewer than 5% of blocks are orphans then there is no slashing, and if >=15% are orphans then forking blocks are fully slashed (i.e. miners of forking blocks receive nothing). For values between O=5 and O=15 the slashing percentage grows linearly from 0 to 100.
Let’s walk through an example with hard numbers. Imagine that the coalition controls 100% of the mining power. A new miner attempts to enter the pool at the beginning of a 100 block interval, and they put up enough capital to claim 15% mining power. In the subsequent 100 blocks, then new miner wins 15 sortitions while the coalition wins 85 and orphans all 15 of the new miner’s blocks. In other words, O=15 and the coalition’s forking blocks are fully slashed. Under the assumption in Assertion #2 that forkers effectively steal the reward of orphan miners, the total slashed rewards are 30k STX, and P=.5 implies that the new miner is made made fully whole on his/her orphan blocks with a reward of 15k STX (if the “stolen reward” assumption is not correct, then I’d advocate for P to be higher). The coalition receives 70k STX for their 85 blocks, and 15k STX is burned.
There are a couple things I’d point to here to suggest that this design would quickly break the coalition’s monopoly. First, the new miner has earned fair value on his/her contributions to the pool and should be able to mine profitably and thus remain in the pool. Even if the coalition pursues a different and arguably better strategy and forks the new miner exactly 5 times, the new miner still earns 10k STX, which is still somewhere near breakeven. The new miner also has countermoves (increase capital commitment, fork back) to improve profitability. In the end, the coalition simply does not have a viable strategy to lock even a small-ish competitor out of the pool.
The second point is that not only did the coalition fail to lock the new miner out of the pool, they did worse for themselves by trying. They could’ve had a total reward of 85k if they’d mined honestly, but instead they ended up with 70k. This is stark contrast to the situation today, where they earn money by manipulating the chain rather than lose money.
Put these things together, and I think this change would quickly break the monopoly.
Curious to hear thoughts and additional ideas from others.