This proposal for mining in Stacks proposes a change to the current Stacks mining protocol while trying to maintain many of the current system’s properties.
Namely, the goals of this proposal are:
Eliminate coinbase reward based incentives for miners to attempt to crowd each other out of the protocol.
Promote faster block production by eliminating competition for blocks, replacing block competition with miner collaboration.
Retain the existing system’s proof-of-transfer security scheme: miners become candidates for block production by burning or transfering bitcoin.
At a high level, this RFC proposes that Stacks block production occur through the following:
Stacks blocks are produced during 10 bitcoin block terms. During a term, blocks are produced by a producer set. The producer set is a group of weighted public keys. Each block produced in the term must be signed by a quorum of that weight (e.g., 67%).
Throughput limits (i.e., cost limits) are assessed on a term as a whole. The number of stacks “blocks” in a term is not limited to 10, and there is no distinction between a “microblock” and a “block”: there are only blocks.
Producer set selection for term N occurs during term N-2. Would be producers issue a bitcoin transaction containing 2*(term length) Proof-of-Transfer outputs.
Each term, the producer set defines a weighted-by-commitment FROST group. This, in turn, defines a bitcoin output. Before the term begins, but after set selection finishes, this bitcoin output must be created as a UTXO. Anyone can send this transaction as it is “untrusted”— stacks nodes will verify that the UTXO is correctly formatted for the given term.
During a term, the producer set periodically announces their latest block on the bitcoin chain by spending the term’s current UTXO. Each such announcement produces a taproot output as defined by the weighted-by-commitment FROST group. These announcements do not need to land at a specific bitcoin block height, however, the last such accepted announcement must land before the term ends.
Transaction fees are paid according to a 40%-60% split. 40% of the fees go to the participants in the current term, 60% go to the participants in the next term.
The first block of term N must build off of the last announced block of a prior term (not necessarily N-1, but in most cases, N-1).
Thanks for writing this up! I like a lot of the ideas here. Just had a few questions so far; I’m sure I’ll think of more later.
This is a somewhat large transaction. If N = 10, then that’s at least 22 outputs (1 OP_RETURN plus 20 PoX outputs plus 1 change output). This keeps the price of admission about as high as it is today due to the correspondingly high transaction fee. Is there a way we can do better? This is something I had on my mind when I wrote my original proposal.
Executing a weighted-by-commitment signature is somewhat tricky in Bitcoin Script, because Bitcoin Script has no notion of how much a key" weighs." In sBTC, we overcome this by granting each PoX reward slot a distinct signing key. Then, Stackers with more STX control more signing keys, but all signing keys have the same weight. Were you considering something similar for the weighted-by-commitment signature scheme here, or do you have something different in mind?
So, “micro-forks” can still happen here, right? The last few transactions confirmed by the signers in term N-1 might not be seen by > 66% of the signers in term N.
Yes, I think there may be room for improvement here, but this would still be a real reduction in bitcoin transaction fee costs. First, a 22 output transaction is smaller than 10 x 4 output transactions, not just because it has 28 fewer total outputs, but because it’s also amortizing the size of the inputs and signatures. Secondly, because the scheme allows the transaction to be included any time within a window of 10 blocks, meaningfully lower transaction fee rates can be tolerated. Ultimately, though, I suspect this is less important for improving miner profitability than the other changes here (namely, making smaller miners difficult to crowd out).
Yep, something similar. I think using the same scheme as sBTC could work, with something like a well-known variable lower bound on inclusion (i.e., you must commit at least 1% of the total commitment during the tenure).
Yes, though there’s two reasons that this should work much better than the micro-forks seen in the current system. First, these micro-forks would be limited to the boundaries of the term, so would only occur every 10 blocks (already an improvement over the current system). Second, because there’s not a competition for production of the first block in term N, “racing” to get a commit produced is no longer necessary. However, I do think there’s a lot of space for design improvements in this aspect of the proposal. For example, the protocol could mandate that the last “bitcoin announced block” of a term is the last block of the term. This means that the design would have an element where inclusion in a specific bitcoin block is important (a bitcoin announcement failing to land in block 10 of the term would mean orphaning the blocks since the prior announcement) but it would eliminate any choice about block inclusion at the start of the next term (other than specific fork selection, i.e., term N choosing to build off of term N-2 instead of term N-1).
Hi Aaron, I’m trying digest the concepts, particularly the claim
Because generally economics and financial incentives are always at play especially when something useful is requested be done.
If I may summarize the proposal in 3 points:
stacks miners register to commit to mine Stx blocks over a period of 10 btc blocks. This period is called a Term. Some time before the Term begins the miner make block commitments in order to participate in block production during the upcoming Term.
during the Term, Stx blocks are not tied to btc block production in lockstep. Miners have the latitude to produce as many Stx blocks as they wish as long as…
… as long as 67% of miners approve of the block to be created. This 67% threshold is define by the weight of the miners’ block commitments for that Term.
My questions are:
does the summary above accurately describe the mechanics of block production process?
do miners receive 1000stx block reward for every block they publish?
The block production during a term would be limited by a cost and byte length limit. If the change were to match the throughput of the current system, then the term limit would be:
term limit = (term length) * (the current cost and byte length limits)
Basically, yes, with the note I made above.
No, I think that similar to the cost and byte length limits, the reward would need to be scaled from the current system to the term length. So a term of length 10 would get 10 block rewards.
So the crowding out can still happen, but at the Term level instead of the block level. The bid would be at a value of 10 block rewards or greater to crowd out other participants to control a Term.
An opinion: If Stacker-Signing upgrade is adopted, then block producer (aka miner) centralization shouldn’t matter as they can’t execute a chain re-organization. They could perform Tx censorship but they could be evicted for doing so. So as long as block production as-a-service is being performed well, it wouldn’t matter if it is one entity doing it or multiple. Treating miners as result-oriented contractors may be an appropriate view because miners of STX do not necessarily aligned with the network long-term because they do not have consolidated capital in the network - unlike bitcoin miners with their ASIC investments.
The most sure-fire way to have multiple competing miners is a high STX token price. If at $50 per token, each block would require $50k of block commitments to crowd out competitors which would be difficult to keep up over time. But at $500-$800 per block? Someone with a cursory interest to acquire some tokens could pay up.
@aaron thanks for putting this up, I love the proposal in general!
Some comments and questions:
Can we make throughput limits a function of VDF cycles? Right now we’re sort of working with term limit 1 and the throughput limit is fixed i.e., fixed in-between two Bitcoin blocks. The VDF can enable dynamic throughput between blocks (or terms). So maybe we can extend the same concept to the 10 block term limit.
I like the idea of no distinction between “block” and “microblocks”.
Can we talk through the effect that this proposal has on the two problems that have been identified? I see how the Bitcoin MEV problems are solved, but I’m not clear if this solves the orphan blocks problem.
Bitcoin MEV
Problem: A Bitcoin miner could censor the transactions that give entry to the producer set
These transactions can happen over 10 blocks, so the nefarious Bitcoin miner would have to win all 10 blocks to censor other producers.
Solved
Problem: A Bitcoin miner could censor the block announcements
These announcements do not need to land at a specific block height, so if a Bitcoin miner censors the transaction, it can be picked up in the next block. This could delay the on-chain confirmation, but not prevent it from happening. In the worst case, the nefarious Bitcoin miner is creating the last block of the cycle and censors the final commitment. These microblocks could be orphaned by the next set of Stacks miners.
Solved
Orphan blocks
Problem: One Stacks miner (or group of Stacks miners) can ignore blocks from others, orphaning them
I think this would now only make sense on the order of sets
If a nefarious miner has 67% of the producer set weight in set N, they could build off of the last announced block from set N-2, orphaning set N-1.
Honest miners might have to do this if the last block from N-1 is announced on the Bitcoin chain, but has not been received on the peer network.
Do we still have the same problem as before, except that it’s now 10x more expensive to do it, and it causes 10x longer forks?
I don’t think so, but I definitely think that this requires some analysis.
The way that this proposal addresses the “orphan blocks MEV” is through altered incentives. It’s true that this proposal still allows for forks, but the cost of forking away a prior term is much higher: that prior term likely contained rewards for members of that 67% coalition. So, by “forking it away”, they’re losing those rewards. Furthermore, one of the supposed outcomes of the orphan blocks MEV is dissuading participation of other miners by “crowding them out”. Crowding out miners is much more costly in this proposal: term membership is determined solely through the block commits. This means that even if a coalition of 67% of producer weight wants to crowd out other miners by forking or otherwise, they are still sharing their current block reward with the other members. This makes “crowding out” other miners very costly: if someone crowds out other miners, they are paying more and more bitcoin to do so, with less and less “lost reward” for the ones being crowded out.
For example, suppose there are three miners: A commits 1 BTC, B commits 1 BTC, and C commits 1 BTC, and suppose for simplicity the term reward is 300 STX. In this situation, each miner expects to receive 100 STX reward. Suppose further that this is a “break even” level for the miners (so 1 BTC = 100 STX). Now, if A wants to crowd out the others, they increase their commitment to make it less profitable for B and C. If A commits 4 BTC, and B and C both still commit 1 BTC, then the expected rewards would be: 200 STX, 50 STX and 50 STX. Miner B and C are now experiencing an economic loss: each are “losing” 50 STX, so they may at this point be disincentivized from participating in mining. However, A is experiencing a loss of 200 STX.
But seriously, thanks for that explanation. That sharing of the reward definitely does change the economics of it. So then to completely own the reward, they would need to put the other miners below the 1% threshold you mentioned, which would raise their price even more. I’d be interested to see someone put together some deeper analysis on the expected value of these orphan attacks in this model.
I’ve been thinking about the producer set selection, and how to ensure that small miners don’t get too disadvantaged against large miners.
In the simple case let’s say one large miner commits 50% of the BTC for set N. Next we have 3 medium miners that each commit 10%. Finally, we have 10 small miners that each commit 2%. With this proposal, everyone gets a fraction of the rewards proportional to the amount they paid. The advantage of the larger miners over the smaller ones is that the overhead of the Bitcoin fees is smaller relative to the reward received for the large miners. This disadvantage is probably acceptable, but could be improved upon with miner pools.
The more complicated scenario arises from the lower bound threshold, which could exclude the smaller miners from the producer set if their portion of committed BTC is too low. This lower bound is needed because the collection of signatures for block announcements is an overhead to the block production, requiring that the total number of miners for one set should be capped. If a small miner ends up below this threshold, they will have paid BTC, but not receive any rewards. This is where the disadvantage to small miners could be a problem. To address that, I’m proposing that the miners below the threshold maintain a credit for the amount committed that could be carried forward to later set selections. If a small miner committed 0.1 BTC for set N and ended up below the threshold, then in set N+1, if this miner again commits 0.1 BTC, they would be considered to have a commitment of 0.2 BTC for this set. If this miner does not participate in set N+1, then the credit is saved until the next set where they do commit.
This proposal eliminates the risk that a small miner would have of committing BTC and receiving 0 rewards and should maintain a fair competition for small miners against large miners, while still allowing for a cap on the number of miners per set.
A group of us have been reviewing the proposal in the Better Blocks Engineering meetings and had some open questions. I think these are mostly details left out of this brief proposal, but I wanted to add them here in case they are not covered in your full proposal.
Where does the BTC to cover the fees of the block announcements come from?
How do the miners in the producer set decide how much to pay for these fees?
What is the incentive to broadcast the announcement transactions?
I think the answer is that the transaction fees. If 40% of the transaction fees is greater than the BTC fee, then they are incentivized to announce, else their microblocks can be orphaned by the next set.
How does the microblock creation work?
Can any producer in the set propose a block and then collect signatures?
Do we need competition amongst the producer set to build these microblocks or is there some consensus mechanism to decide? (there is not one “correct” next microblock, since valid blocks could differ in how many transactions are included, which transactions are included, and the ordering of those transactions)
TSS got hacked today. So made me think of…
FROST is cool, but apparently also not had the “test of time” if I’m correct? (research phrase-ish?)
So my natural question is, what is the risk there if FROST is compromised? What is the worst can happen, and what’s the backup plan if it does have loophole?
Would love to hear thoughts for myself and the rest of community’s awareness.
