A significant threat to decentralized consensus networks in operation today concerns the economics of miner extractable value, the complex art of extracting profit from the ability to choose the content of the next block. A simple MEV example is arbitrage across all on-chain decentralized exchanges based on the previous block's price movement. While normally PoS rewards are reasonable and even, i.e. the rate of return for a single validator is the same as for a strong staking pool, finding complex MEV extraction opportunities has resulted in quite significant economies of scale. A 10x larger pool has 10x the chance to extract MEV, but the pool also needs to be able to invest more in proprietary optimizations to extract more value per opportunity.
In addition to this problem, MEV also complicates decentralized staking pools, because in decentralized staking pools, packaging transactions and proposing blocks still needs to be done by an entity, and they can easily withdraw MEV secretly. Instead of distributing these revenues in the pool.
The best known solution is the proposer/block builder separation. Instead of block proposers themselves generating a revenue-maximizing block, they rely on a market composed of external block builders who generate transaction bundles containing the complete block content and fees to the block proposer, The proposer then selects the transaction bundle containing the highest fee. In this way, the selection of the block proposer is reduced to selecting the transaction bundle with the highest fee, which can be implemented by a simple algorithm - in a decentralized pool, it can even be done in MPC (Multi-Party Computation) to prevent Cheating.
This article proposes some designs on how to achieve this.
first level title
Optimised proposal commitment scheme 20
Desired properties of a proposer/builder split block proposal design
The top five desired features we will focus on:
No need to trust proposer friendliness: the risk of a proposer bullying a block builder is virtually zero, so block builders have no incentive to favor off-chain proposers with pledge pool).
No need to trust builder friendliness: the risk of builders bullying proposers is virtually zero, so proposers have no incentive to favor off-chain builders with reputations or personal relationships with builders (since this could lead to new builder entrants to the market is not selected).
Weak proposer friendliness: This mechanism should not require proposers to have (i) high bandwidth or other computing resources, or (ii) high skill
Unstealable transaction bundles: Proposers should not be able to accept transaction bundles proposed by block builders and extract transactions from them to form their own transaction bundles, thus preventing block proposers from earning profits (and possibly further harming them)
first level title
idea 1
Block builders build transaction bundles and publish bundle headers for these transaction bundles. A bundle header contains a commitment to the bundle body (the expected block content), payment information to the proposer, and the builder's signature.
The proposer chooses the bundle head that offers the highest fee (only needing to consider whether the builder of the bundle actually has enough balance to pay). They sign the transaction header and issue a proposal containing the transaction header.
When seeing a signed proposal, the block builder who provided the packaged transaction bundle header publishes the complete transaction bundle.
At this time, the fork selection rule can make one of the following three judgments (instead of the usual two, there is a block vs. there is no block):
No block proposal exists
There is a block proposal but no transaction bundle body
Both block proposals and transaction bundle bodies exist
analyze
analyze
Three of the five properties are fairly easy to present:
Block proposers accept promised payments unconditionally, so transaction bundles cannot bully proposers
All three steps are very automated and low bandwidth, so this satisfies weak proposer friendliness
Proposers cannot see information about the bundles they want to sign, so this satisfies bundle unstealability.
Consensus layer properties and trustless proposer friendliness are trickier. This design will indeed change the fork selection mechanism from two options to three, which means that the proposer will no longer be the last actor in this mechanism. In theory, one could reason that if the fork choice is decision-making then this should be fine, but this is still a breaking change with potential unknowns.
Block proposers cannot see the contents of transaction bundles and cannot bully block builders by stealing transaction bundles, but they can launch a more subtle attack on block builders. They could publish the proposal at the end of the slot, ensuring that the prover (presumably) sees the proposal in time, but the block builder doesn't have enough time to publish the transaction bundle body, so it is very likely that the prover will not see the transaction bundle body in time. This creates risk for block builders and encourages them to favor trustworthy proposers. Plus, it gives the majority of the chance for malicious actors to heavily penalize block builders they don’t like.
I think there are two sets of ways to alleviate this problem.
Provers have a 2-second delay between the maximum time they accept a proposal and the maximum time they accept the body of a transaction bundle. If you trust the prover, this basically solves the problem, although the risk of the block builder losing their funds still exists. Also, it's unclear if there is an incentive for provers to vote in this way (although one could conceivably force them to wait by asking them to prove a proposal for a 2-second deferrable verification function)
If the body of the transaction bundle is not included, the proposer only gets half of the payment (and the block builder only pays half). This makes the proposer's sabotage costly, but it still ensures that the block builder's sabotage is also expensive (when the cost is high enough in both cases, in general you can trust even anonymous actors would not want to do acts of vandalism). For example, if the proposer fee for a transaction bundle is 1, the block builder earns 1.05:
○ The builder and proposer payoffs for honest behavior are 0.05 and 1, respectively.
first level title
idea 2
Block builders build and publish transaction bundles. Transaction headers contain a commitment to the content, a payment to the proposer, and the builder's signature.
Proposers make a selection of the transaction bundles they see, form a list, and sign the statement that the list consists of.
Upon seeing this statement, the elected block builder publishes the corresponding transaction bundle body.
A proposer selects one of a list of transaction headers they have previously committed to and uses it to issue a proposal.
A new slashing condition is also required, where any proposer in the same slot that proposes a transaction bundle that is not in its commitment list will be evicted and penalized.
analyze
analyze
Likewise, the trinomial of the five properties is fairly easy to show:
Proposers cannot steal transaction bundles because they can only see the body of a transaction bundle when they have restricted themselves to a limited set of existing transaction bundle headers.
It is impossible for the builder to pay the proposer until the complete transaction bundle has been packaged, so the proposer cannot economically cheat the builder.
The consensus feature remains unchanged, because the system setting is still the proposer as the last actor of the mechanism, and the content determined by the consensus rules has not changed.
In this case, the two more tricky properties are weak proposer friendliness and trustless block builder friendliness. The concern with this scheme is that malicious block builders could attack proposers by making lots of proposals with high transaction fees, but never publishing the body of these transaction bundles. If the proposer has an upper limit on the number of transaction bundles accepted, this attack can exclude all legal transaction bundles, so that the proposer has no legal transaction bundles to propose to be included in the block. If the proposer had no cap on the number of transaction bundles it could accept, then there could be an infinite number of full transaction bundle bodies (think: 500 kB each) sent to the proposer, which would require a very large amount of bandwidth.
One solution to this dilemma is to somehow rate limit the submission of transaction headers, which is not a hard limit.
There is a fee to submit transaction bundles, adjusted to a certain rate through a mechanism similar to EIP-1559 (for example, 8 transaction bundles per slot)
Becoming a block proposer requires a deposit (necessary anyway to ensure the proposer gets paid) and a rule that if you publish a bundle of transactions that is not included, but a cheaper bundle is included , then you cannot submit transaction bundles in the next N slots.
Fees will be deducted only in this case: your transaction bundle is not packaged, but the lower-priced transaction bundle is packaged, because in this specific case it may be that you are evil (or the proposer is evil, or the network state not good).
There is precedent for this; previous ENS auctions had a 0.5% loser's fee to discourage someone from bidding when it was clear they would not win, forcing the winner to pay more.
However, these techniques may introduce trust requirements on the proposer, so they need to be handled carefully, and the penalty for failure to package transaction bundles should not be too high.
An alternative is to allow free and unrestricted publication of transaction bundle bodies, but restrict bodies to broadcast at the network layer. A simple algorithm is:
Adds a slightly delayed minimum time limit for bundles to propagate: 0 seconds for the bundle with the highest transaction price, 0.2 seconds for the second highest transaction, 0.38 seconds for the third highest transaction, generally speaking for the kth highest transaction The price transaction time is 2∗[1−0.9^(k−1)] seconds.
Added a rule: If a node has already broadcasted a transaction bundle body with a higher transaction fee, it cannot broadcast it again.
in conclusion
in conclusion
So far, I don't know whether only the above two methods can solve this problem, there may be others. Of the two approaches, idea (1) is conceptually simpler, but it creates risks for block builders and introduces more complex fork selection rule requirements. Idea (2) is simpler in fork selection and consensus, but has difficulty dealing with DoS attacks by malicious block builders, and any solution to this problem is resistant to other problems, although it is conceivable to way to minimize. So far, I'm still not sure which one is better.
