Two-slot proposer/builder separation

I struggle a bit understanding this discussion, but I think I have the general idea. Vitalik is able to show that a continual censorship scheme will fall apart as valid but delayed txs build up. pmcgoohan points out that only a short term censorship is needed to extract MEV, and that by making short term censorship as a service easier, this will increase the centralization and MEV extraction that the original proposal was thought to reduce.

To this discussion I want to add a minor point to the ice cream example that both ice cream sellers can instead have a bidding war of credible commitments to censor should the competition attempt a transaction to sell their ice cream. Such credible commitments would deter the other party from attempting the tx, and the price for a credible commitment is nearly free, so the ice cream sellers could easily avoid sending all of their profits to the miner. To prevent one ice cream seller from overcharging, the buyer that is aware of fair price can set a maximum price, or the sellers could make a credible price commitment in advance. I think these together solve the ice cream problem, but I did not take the time to consider if solutions down this route are practical to be generalized across all kinds of MEV.

Something I came up with several months ago is a guaranteed time based inclusion market. I mentioned to some coworkers and a tweet, but this seems like a good time to pitch the concept because it may assist in mitigating or solving the problems discussed here.

It could be done with on the smart contract layer though with additional gas costs, but would be better as an offchain service and even better as a protocol level improvement. Where it is appropriate to implement is another question that can come later. For now I just want to pitch the mechanics of such a system.

It started when it occurred to me I often have transactions where I do not care about when they are processed as long as they are processed within the next 24 hours. If the overall cost to me is lower than the slow gas cost, yet I also have a guarantee of inclusion, I would be willing to pay for this guarantee. So would many others. Selecting a time limit for transaction processing is also a better user experience, as this is actually what users care about. Wallets know this and present to user guesses of inclusion time, but predictions fall apart mere minutes into the future. To the point where wallets don’t even bother suggesting a gas price for more than 10 minutes into the future. Even under 10 minutes there exists uncertainty that users would pay to eliminate but have no venue.


Those willing to take on gas price exposure select from analogue spectrum of time frames and for each time they select, they offer a price. For example, for 10 minutes in the future, they may select 80 gwei. For 1 hour they may select 70 gwei, and for 24 hours they may select 60 gwei. They select these prices because in their estimation and possibly by comparing competing bids have predicted on average they will be able to include the transaction within the specified time for less than the offered price. To incentivize the guaranteers to process the transaction even at a possible loss, they are required to place a bond such as 10 times the contracted rate. The user gets the entire bond should the transaction not get processed in the contracted amount of time.

Other inclusion offerers will also select various times and make commitments. To link together multiple arbitrary times with different arbitrary prices, the protocol can assume a linear transition between each offers. For example, if a guaranteer specified 70 gwei for 1 hour and 60 gwei for 24 hours, then the protocol assumes that they are also offering to process a transaction within 12 hours for 65.2 gwei. Essentially each guaranteer that makes 2 or more offers is also making an offer for all time choices between their offers.

The user then can see the best price offered by any guaranteer for any arbitrary time and contract with them. If they want their loan repayment transaction to get processed within the next 22.7 hours, they will have someone to guarantee that for them, and they will be able to get a price better than metamask would have offered for a 10 minute inclusion despite the on average profit the guaranteers are making. I believe adding this optional layer on top of any transaction bidding system would be preferred by all users to the point a large portion would use it.

Such a system would also improve resistance to censorship. A miner would be aware of the guarantee and would know for sure the guaranteer is willing to spend up to the bonded amount bypassing the censorship to get the transaction through.

In the context of censorship though some subgames would probably arise and I have not mentally applied this extensively to the impact on censorship yet. Perhaps the miners try to stop the guaranteer from making the contract, perhaps the guaranteer can tell that an incoming transaction is likely to be censored and doesnt want to make the deal, perhaps the protocol forces the guarenteers to be neutral and accept all offers to prevent this. Lots of depth here, but for now just want to start off with pitching this idea that I think will improve any blockchain especially if it was built into the base protocol as an optional transaction type.

I wrote the ice-cream example in a bit of a hurry. A good real-world example of a high value, p2p target for the censorship market is the Wynvern protocol underlying many of the big NFT trading platforms like OpenSea, Cryptokitties etc.

Hi @imkharn,

Whatever maximum fair price they set is what they’ll pay. Price discovery has failed at this point.

The sellers may collude (not that we really want to incentivize cartel behaviour in our sellers) but may just as well defect, especially in p2p markets where sellers have no history and little chance of interacting again. You’ve just added a second game of PD with the same expected outcome.

In addition, even when the sellers are colluding the dominant extractor can stir up trouble by censoring a seller themselves. There will be no way for the censored seller to tell whether this was done by the other seller defecting or the dominant extractor (who is incentivized to break the cartel), but they will likely assume the former and defect.

Thank you for contributing a mitigation idea. If you’ll forgive me, I won’t get into it yet. I am still working to define the problem at this point before moving onto potential mitigations.

Attack 2: Centralized Relayer

I am going to describe how PBS incentivizes centralization around a private relayer. This is a generalized attack on decentralization.

MEV auctions are highly competitive because the mempool is public. There is nothing to differentiate one searcher from another beyond their ability to extract MEV from the same set of transactions. As a result, searchers bid each other up and give the majority of their profits to the miners in order to win blocks.

A far easier way for a searcher to dominate block auctions and profit is to have access to a private pool of transactions which only they can exploit. Quite simply, having more gas available for their block proposals than their competitors means they can afford a higher bid. Here is a simple spreadsheet model demonstrating this.

Crucially, the extra profit from transactions sent through their private relayer is theirs to keep, they don’t need to pay it to the miners because other searchers can’t compete for it.

This creates a very strong economic incentive for searchers to operate private relayers. Something similar is already happening with initiatives like Flashbots Mev Protect, MistX and Eden, for example.

A private relayer would be wise to invest a lot upfront in advertising, PR, token drops, offers of MEV protection and even gas subsidies. As with the censorship market, there are strong network effects and feedback loops around private relayers once a critical mass is achieved. People will use the private relayer that wins blocks most of the time, which in turn means that they can win blocks more of the time, which means more people use them, and so on.

Once dominant, the private relayer has monopolistic gatekeeping powers that will be extremely difficult to challenge.

A private relayer is fully compatible with a secondary censorship market which they must also run to remain competitive.

The mempool is increasingly redundant, along with the decentralization, transparency and accountability it provides, so any additional manipulations the dominant extractor performs are hard to track.

A single, opaque organization with no requirement to have any stake in Ethereum will have ownership of the majority of the order flow in the network, with no protocol enforced limitations on how it is used.

Mempool Griefing

The following is not necessary for private relayer dominance, but we can expect behaviour of this kind.

The mempool is a threat to the private relayer because it is public and the gas it contains raises competitor bids. Therefore they are incentivized to harm the mempool if at all possible.

Once dominant, the relayer may start censoring low value mempool transactions, or at least delaying them. This happens naturally anyway as the relayer has a larger choice of transactions for their block proposals and blockspace is limited. But they may also do it deliberately to punish users for not sending transactions through them. Even a one block delay is -ev for DEX transactions, for example. More cheaply they can put mempool transactions at the end of the block.

If the relayer sees a transaction in the mempool that was also sent to them privately, they treat it as a mempool transaction, and may similarly penalize the user for allowing other searchers to include it in their proposals.

As you suggested, users may try to grief the relayer by raising the tip of their mempool transactions. This backfires as the relayer then includes those that overpay in their blocks, for which they win the gas. They then use this to advertise how much cheaper their services are than the mempool which serves to further reinforce their dominance.

It’s a game of balancing the cost of censoring/delaying low value transactions with the extra profit from users overpaying for mempool inclusion or using their relayer instead. They will only do this if it is cost effective in furthering their dominance or profits, but if it is possible to do, the dominant relayer will do it.

They may be able to use this mechanism to increase their profits by raising gas fees overall.

1 Like

One thing that I don’t understand about these private transaction flow models is: what’s the incentive for any user to agree to that? When I am sending any regular transaction, I would prefer it to be broadcasted as fast as possible, to maximize the chance that it will be included in the next block. If builders become more greedy and stop broadcasting to each other, then my own incentive to broadcast to all the builders increases even further: if there are 4 builders, each with a 25% chance of taking each block, then if I broadcast to one builder I will get included in ~48 seconds, but if I broadcast to all I will get included in ~12 (actually if you analyze it fully, it’s 42 vs 6 seconds).

If I am sending an MEV-vulnerable transaction (eg. a Uniswap buy order, or a liquidation), then of course my incentives are different. But even then, I would want to send that tx to all searchers who support some SGX or other trusted hardware based solutions.

A handful of private relayers cooperating by sharing transactions is indistinguishable from a single private relayer. Their collective incentive to profit from users is the same. In fact, it’s a sound strategy to maintain dominance.

Any individual or collective group of relayers not willing to run a censorship market will fail because they are leaving private MEV on the table for other relayers to extract.

It seems to me that the endgame here is either a single or a group of colluding relayers willing to run maximally exploitative strategies such as a censorship market (I expect there are others I haven’t thought of).

But let’s say that they don’t collude in this way initially. It’s easy to penalize transactions seen in the mempool as I have already described. Penalizing users that submit to multiple private relayers is harder but not impossible.

I could mark any account sending a transaction that appears in the chain that did not pass through my relayer or the mempool. Future transactions sent from this account (and possibly accounts clearly linked to it) will be similarly penalized for a period of say 2 weeks in my blocks (loyal customers get priority).

If we have workable encryption solutions like SGX/VDFs etc then we should be using this to encrypt the mempool and address the problem at root.

I never understood the Flashbots SGX proposal on this. It’s impossible to combine encrypted bundles into a block and guarantee that there won’t be duplicate transactions, but trivial to combine individual encrypted transactions. The latter actually solves most MEV.

That would require trusting SGX at protocol layer, which I think most people consider an unacceptable incursion of a single point of failure. But having SGX in one of many mempools that compete with each other through the builder/proposer mechanism doesn’t have that risk, because if SGX breaks the mempool can switch to something else without touching consensus.

1 Like

So say we have 3 SGX relays (SGX), 3 mostly well behaved lit relays (Lit) and 3 bad censorship market relayers (Censors).

Let’s assume they know they must collude to survive, but that they can only collude where their objectives are similar. The SGX guys are not going to share their private transactions with the Censors, for example. So from now on when I talk about SGX, Lit or Censors, I’m talking about groups of similar relayers.


Straight away we have a dilemma. If there are lots of relayers, users will frequently fail to get their transactions included. If there is only one relayer, we have a centralization risk.

Even if there is a least bad number of relayers, there is no reason to think we’ll converge on it.

MEV is Pervasive

The next problem is that as long as MEV is permitted in the network, you can’t escape it.

If you use the SGX, you still have to pay them enough to let them win the block off the Censor who is profiting from exploiting users for public and private MEV.

It’s a fundamental problem with MEV protection markets. You must still outbid the MEV in the system.

Being Bad Pays

But it’s worse than that because the Censors can outbid their competitors precisely because they extract more from their users (or expect to be able to in the future).

They can offer loss-leaders to gain market share knowing that down the line they’ll make it back and more. The SGX relayers can’t run a censorship market so cannot invest as much in buying market share.

It’s a bit like the ice-cream example above where the seller knows they can only protect their transaction if they make the user overpay.

I suppose what I’m trying to demonstrate is that we can’t expect markets to fix issues caused by centralization.

I’ve stated my position in favor of MEV auctions in my previous article, but I think @pmcgoohan has some very interesting arguments here that we should not dismiss.

First of all, I think we can all agree with @vbuterin that censorship is very expensive and not of much concern regarding transactions that are time-insensitive and can easily wait for several blocks. The users only have to pay once what the censor has to pay again and again every block, so the censor clearly loses.

Second, and that is going to be a lot more controversial, I think badly designed protocols are the ones to blame for most MEV. Just as you should not write an application that expects UDP datagrams to be received in order, a dapp should not rely on transaction ordering within blocks, and should not even rely on transactions never being censored for a few blocks. The only guarantee that blockchains provide in general is that transactions will eventually be included. So in my opinion almost no time-critical economic activity should happen on the blockchain settlement layer itself. Time-critical activities should be executed elsewhere (rollups, off-chain exchange relayers, etc) and then settled later with no time pressure at all. So I don’t see any need to protect badly designed protocols or their users from MEV; protocols should just do better and users should just go elsewhere.

However, if users do care about having their transactions being included very quickly (e.g. in the next block) for any reason, then it is not clear to me that a dominant centralized relayer for fast transactions will not emerge. This relayer will at most be able to delay transactions for a few blocks, but it seems possible to me for such a relayer may be able to obtain a near-monopoly on fast transactions.

I can imagine the following equilibrium.

  1. A single relayer builds a high proportion of blocks
  2. Out of the users who want their transactions to be included very quickly, a high percentage sends them to the private relayer only (and not to the mempool).
  3. If the relayer detects that someone wanted their transaction to be included quickly, but that it sent the transaction to the mempool instead, it loses some money to delay this transaction for a couple blocks.

I think we should not discuss whether such an equilibrium is likely to arise. Rather, we should discuss whether this equilibrium would be stable.

Unfortunately, I think it may be stable indeed. Because of the credible commitment of the relayer to behave as in (3), it is in the rational interest of users to send txs to the private relayer only in (2). Second, because of (2), the relayer has access to more transactions than others and so is able to propose the majority of blocks as in (1). Because it may auction off mempool MEV opportunities to sub-searchers, it may not even be the best searcher itself. Finally extra profits coming from (1) may allow it to maintain the behavior described in (3).

Maybe I am missing something and this is not actually profitable, but I feel I could come up with an explicit economic model in which this equilibrium can be proved to be stable.

To make it clear, I don’t think this scenario would be catastrophic for the network. The monopolist would be able to extract some rents, but no long-term censorship can happen. Moreover, a solution could be proposed in the future and implemented as a hard fork. But it may well be worth thinking about it now.

Thank you for contributing @kelvin.

Thank you for confirming that a direct relayer censorship attack is probably sustainable- I like the way you framed it in terms of being a stable equilibrium.

Have you considered the economics of the censorship market in a similar way?

Let me illustrate how this could work in the OpenSea NFT market:

  • Bob has bid $10k on an NFT on OpenSea.
  • Alice is prepared to pay up to its true value of $50k, but leaves her bid to the last 10 mins (this is rational as the protocol extends the auction by 10 mins for each new bid).
  • Bob can now:
    • (a) outbid Alice for a loss of $40k from his current position (let’s assume he knows the NFTs true value is $50k)
    • (b) aim to block her bid on the censorship market for 10 mins (50 blocks)
  • Bob will breakeven on (b) even if he ends up having to pay $800 per block (and as we all know, NFTs can go for a lot more than $50k and if Alice left it to the last minute Bob could afford even $8000 per block to censor)
  • Let’s say Bob ends up paying $200 per block to censor Alice

The results are:

  • Bob (acting badly) is rewarded with a $30000 saving on the NFT
  • The censorship market (acting badly) is rewarded with $10000
  • Alice (acting well) loses out on ownership of the NFT she should have rightly won
  • The artist (acting well) is punished with a -$40k loss

It’s worse than this though. The censorship market is incentivized to help Bob, because Bob is making money for them and is a proven user of their services. At a certain point, it will become +ev for them to help subsidize Bob’s censorship. As well as being true in any individual case, the more effective they can make their censorship market, the more people will use it long term.

To help them with this, the censorship market allows bids on n block censorship (in this case 50), or even using a specialist OpenSea censorship order. This reveals the censoring users intentions which they can use to calculate at what point it is worth subsidizing them.

One very cheap (for them) thing they could do is simply ban Alice from protecting herself after a few minutes. This would pressure Alice to raise a protecting bid early on. It may make the outcomes more predictable for the customers of the censorship market, while also getting them to pay more upfront and earlier on.

It’s very complex to model, and there are clearly a lot of actions Alice, Bob, the relay and other users can take that I haven’t included.

The crucial observation here is that the incentives of bad acting users are aligned with the then most powerful actor in Ethereum, the dominant private relay and their censorship market. My intuition is that this alignment of bad incentives makes censorship market attacks like this sustainable.

1 Like

I think your argument that short term censorship is possible is reasonable/accurate. I recommend finding a better example than the one you did because Alice should just bid sooner, knowing that short-term censorship is possible.

What it comes down to is that short-term censorship is possible on Ethereum, but you have to continually pay to maintain that censorship. Any situation where you need to censor indefinitely will cost you infinite money. Protocols should strive to be designed such that the cost to censor for long enough to cause damage outweighs the benefit to censorship.

As an example, the protocol designers of the NFT auction should not have a fixed 10 minute extension. They should instead have the extension duration be a function of current gas price and the value of the asset being bought. This can incentivize Alice to buy sooner (though she could simply choose to buy sooner on her own) and if Alice follows the “buy sooner” strategy we can be sure that the cost to censor by Bob is higher than Bob stands to benefit.

It’s more than this though. The point I am making is that PBS/MEVA incentivizes:

  1. the monopolization of all transaction/order flow on Ethereum by a single actor
  2. that actor must (and can) extort maximum value from users by predatory means like censorship markets to maintain their dominance

Tony Soprano runs Ethereum at this point.

It seems to me that this is just the kind of centralized power we want to be mitigating with decentralized technology. In fact, this is one of the objectives of the PBS proposal as I understand it.

I think the example works ok in demonstrating that the auction market is broken. Alice shouldn’t have to reveal her maximum bid early out of fear of being censored later. There will be as many other examples as there are Ethereum use cases because this stuff is baked in. Genuine app level mitigations will always have terrible UX to keep out of range of the censors.

1 Like

I have to agree here. That already happens. I will not name any actors, since in my opinion that is very bad for Ethereum and may only push them further. If transaction order get monopolized, Ethereum will become a rigged system.

1 Like

Why must this be the case? Users should be broadcasting their transactions as widely as possible (UNLESS they’re MEV-vulnerable transactions like Uniswap buys), so their transactions should reach all relayers, no?

Users can send their transactions to as many relayers as they like, but the ones that will actually win blocks and include them will be using the most predatory practices possible (such as censorship-as-a-service) because blocks are worth more to them.

Definitionally, an SGX relayer can’t frontrun, nor can it offer a censorship market, so it will be outbid.
For example:

  • a user sends a tx to both the SGX and the censoring relayer with a 0.01 Eth bribe
  • The censoring relayer accepts a bid to censor the transaction for 0.02 Eth
  • The censoring relayer then wins the block because it is worth 0.01 Eth more to them to make sure the tx is not included
  • Not only that, they also get the gas of another transaction in place of the one they were paid to censor, so their profit margin is greater again. They get paid twice for censoring.

Lit vs Dark Censorship Market

Thinking about it, in a lit censorship market the best way for the user to get their tx included is to pay a total of 0.03 Eth to the censor for protection and to offer the same to the SGX to increase their chances of inclusion and harm the censoring relayer.

For this reason I think the censorship market will end up being dark so that users can’t see how much they are being censored for or even whether they are.

This means no lucrative bidding war for the relayer, but if the censorship information remains private then users don’t know to bribe other relayers to include their censored transactions. It also encourages users to pay for protection they don’t need and it makes censorship more effective which is good for the censoring relay.

By doing this the censoring relay can only ever make the same or more money than a well behaved relay for any given transaction and bribe amount, and so can maintain dominance.

Censorship markets make nearly all transactions MEV-vulnerable.

I guess the thing that I wonder about in response to these arguments is: if your model includes people setting up meta-games where a winning censor blackmails everyone, and almost all individual proposers go along with the censorship market incentives, then why can we expect attesters themselves to be protected from all this?

Any of the “in-protocol enforced mempool” schemes rely on attesters to vote on availability and publishing time of transactions in some way. But that’s a setup that is extremely vulnerable to bribery: each individual attester only makes a tiny impact on whether or not some tx gets included, and so censors can bribe them a really tiny amount to act like that tx had been submitted a few seconds later. Why would such a thing not happen, in your view?


First I’ll briefly introduce the (as yet) undocumented Attack 3: Unstaked Hijack.

Here, the attacker buys blocks continuously and uses them to cause maximum harm and disruption with the intention of crashing the price of Ethereum and it’s tokens having shorted them at margin first.

The crucial point here is that (unlike a 51% attack) an attacker can buy complete and continuous control of block content in Ethereum without having any stake in it. This leaves the door wide open to attacks by external actors hostile to Ethereum.

I feel that the risks of full-block MEV auctions have been greatly understated, and that this in turn has distorted our view of consensus solutions.

In short, if Flashbots are right, MEV isn’t much of a problem and therefore content consensus solutions won’t work. If I’m right, MEV is an existential issue and therefore content consensus solutions can address it.

To show you what I mean, let’s use your figure of 0.1 Eth as the avg MEV per block, and assume the proposer gives away half of this to the set of 200,000 attesters as a bribe, giving a bribe per validator of 0.00000025 Eth per block.

Let’s say we have consensus rules similar to the one you proposed where attesters refuse to vote for a block that fails to include a transaction after a certain period of time. A ‘Bad’ actor breaks these rules, a ‘Good’ actor follows them.

Now let’s run the game, first with Flashbots MEV risk assumptions and then again with my MEV risk assumptions.

#1 Flashbots Risk Assumptions: MEV is mostly harmless, a superior way of doing arbs and liquidations, and improves network security by increasing miner rewards.

Payoffs for a bad proposal:
Proposer’s bribe 0.00000025
Attestation reward 0.00002 (given the low-risk assumptions above, it’s safe to assume the bad proposal gets voted for).
Attestation Payoff 0.00002025

The attesters back the bad proposal so:
Proposer Payoff 0.05 in MEV +gas +proposal rewards

(Outcome: consensus content failure)

#2 Pmcgoohan’s Risk Assumptions: MEV makes Ethereum too expensive for widespread adoption and will centralize the network around a monopolistic gatekeeper running an extortion economy punctuated by severe attacks from hostile, unstaked parties.

Let’s put a per-block figure on the risks I have so far identified:

Attacks 1 & 2: Centralized Gatekeeper Running CaaS. For passive holders, the risk here is a drag on the adoption of Ethereum and therefore Eth value. Let’s call it 25% over 2 years (personally I think it’s much higher). 6500 blocks per day x 365 days per year x 2 years = 4,745,000 blocks. A 25% loss in the value of 32 staked Eth is equivalent to 8 / 4,745,000 = -0.0000016 Eth per block.

Attack 3: Unstaked Hijack. Let’s say it takes 2 years before this attack takes place. An 80% loss in the value of staked Eth is equivalent to 25.6 / 4,745,000 = -0.0000053 Eth per block.

Payoffs for a bad proposal:
Proposer’s bribe 0.00000025
CaaS EV -0.0000016
Hijack attack EV -0.0000053
Attestation reward 0.0 (because of the above, it is now unlikely a bad proposal will be successful)
Attestation Payoff -0.0000117

The attesters no longer back the bad proposal so:
Proposer Payoff: 0 Eth (no gas, no MEV)

(Outcome: consensus content success)

Now things look a bit different. Assuming Eth at $4750, over 2 years CaaS costs attesters -$38,000 and the Hijack -$121,600 making a total loss of -$159,600 whereas the bribes make them only $5634.

The attesters have a negative long term expectation if they vote for bad proposals, and no juicy bribe that they can go out and spend today (a mere ~$0.0001 per block in fact).

So to answer your original question re: incentives for proposers to behave vs incentives for attesters to behave; it’s clear that attesters are playing a repeated game, but you could argue that proposers are playing a one round game. That chunk of MEV looks pretty tempting at around $237.50 a pop for the proposer compared to ~$0.0001 per block for the attester, and it only comes around once every few months.

But if you have enforced consensus, they still won’t do it, because proposers know that the attesters have a negative payoff in their repeated game and will vote against it.

Crucially, the risks of full-block MEV must be fully understood and (just as importantly) honestly communicated to validators and users for this to work.

In any case, it is surely vital that we understand the risks of full-block MEV auctions before doubling-down on them. The EF is usually meticulous about such risk assessments.

As far as this goes, I’m happy to be of service, but I’m not enough.


#1 Flashbots Risk Assumptions: MEV is mostly harmless, a superior way of doing arbs and liquidations, and improves network security by increasing miner rewards.

I don’t think Flashbots assumes that “MEV is mostly harmless”. Rather, it very much assumes that uncontrolled MEV is a huge centralization risk, but focuses on containment rather than elimination as a strategy. I also don’t see why “MEV is an existential issue” should imply that “therefore content consensus solutions can address it”. I think that any model of game theory that allows a majority of proposers to get bribed to censor will also allow a majority of attesters to get bribed to censor at an even lower cost.

Making the object that we are focusing on blocks rather than transactions, and relying on PBS and backup games to ensure that blocks actually include transactions, ensures that there’s fewer objects to focus on, which makes it easier to come to extra-protocol consensus about whether or not 51% censorship attacks are happening so that they can be remedied if needed.

So to answer your original question re: incentives for proposers to behave vs incentives for attesters to behave; it’s clear that attesters are playing a repeated game, but you could argue that proposers are playing a one round game. That chunk of MEV looks pretty tempting at around $237.50 a pop for the proposer compared to ~$0.0001 per block for the attester, and it only comes around once every few months.

Not convinced by this. The total bribe required to shift the behavior of attesters should be less than the total bribe required to shift the behavior of proposers, because attesters suffer from the tragedy of the commons: each attester only has a small impact on the outcome, and that small impact is multiplied by their small share in the outcome, so the bribe required to shift their incentive is quadratically small.

The fact that the attesters are playing a repeated game is not really important, because no one is going to be tracking the behavior of individual attesters and somehow treating those individual attesters differently as a result of their actions in prior rounds. And proposers have a repeated game often enough (the large staking pools) that if repeated-game logic worked we could just rely on one of those large stakers to include a transaction, and transactions would still get in after ~5-10 slots.

Surely this undermines the basis of eth2 PoS consensus. How then does Ethereum secure itself against validators colluding to raise proposal rewards or even perform double spend attacks?

Correct me if I’m wrong, but I imagine your answer will be that it is not in validator self-interest because of the threat to their stake from a loss of confidence in the network.

What I want to show you is that the risks of full-block MEVA are comparable in severity, both in terms of gatekeeping centralization and damage to staked value, therefore (once these risks are understood and communicated) validators will similarly reject MEV collusion networks in favour of consensus content.

Perhaps I’ve got the game wrong, but eth2 PoS seems to make similar assumptions. It is arguably in the interests of the proposer to pay themselves a massive proposal fee (one-off game) but it is not in the interests of attesters to allow them to (repeated game).

Again, I think the same applies to a content consensus solution and that this will hugely benefit the security of Ethereum.

(Also, even if the content mechanism is perfectly colluded against, it degrades to having the same outcome as PBS, assuming Flashbots then run an informal market over it. It’s a bet to nothing with the advantage of reducing regulatory risk rather than increasing it. I suspect it is far easier to implement as well).

Validators cannot collude to raise proposal rewards, because validators do not have the ability to make invalid blocks. Users would automatically reject the invalid blocks, so from the protocol’s point of view it would be equivalent to them publishing nothing at all.

perform double spend attacks?

Today, not much. But this is exactly why I have proposed A model for cumulative committee-based finality

The only thing that 50%+ of validators could do without being penalized automatically is censor. And for that, community-coordinated soft forks may indeed be the only option.

Again, I think the same applies to a content consensus solution and that this will hugely benefit the security of Ethereum.

The difference between validity and transaction inclusion is that we don’t have consensus on when transactions were published in the mempool, and therefore can’t have consensus on whether or not the transactions were published “on time”. There’s an inherently large gray area. One of the big benefits of blocks instead of transactions as the main unit of analysis is that there is normally only one block per slot, and so the gray area becomes much smaller, and attempting to figure out to what degree a chain is censoring becomes much more computationally tractable.

Thank you for the explanation above. I’m so impressed that you would consider a change on the scale of introducing fast-finality. That kind of dynamism really is Ethereum’s super-power.

I’m interested in your ideas for Parallel PBS.

I think it could be made more effective if we were able to remove txs in higher order blocks that were already included in lower order blocks.

I was wondering if whoever publishes the intermediate block (winning primary builder?) could remove these duplicate txs from the aux blocks.

One problem I see here is that to allow verification of the exec headers, the original unduped blocks would have to be recreatable.

I thought the intermediate block could include some very compact data (calldata?) containing a series of insert instructions allowing reconstruction of the original blocks. Something like {copyBlockIndex,copyTxIndex,toBlockIndex,toTxIndex}


The original exec blocks (dupes shown in [])

Primary Aux0
Tx1 [Tx5]
Tx5 [Tx3]
Tx3 Tx2

Would be written to the intermediate block as:

Primary Aux0
Tx1 Tx2

And then reverted using the insert data:


It’s kind of a compression technique, so it would also mean using less blockspace. This is a little nitty-gritty for my knowledge of PoS. Is this workable or am I way off? If not, is there some other way of deduping successive blocks?