Proposers being able to build a block locally is not necessarily a property that will always hold true, for example it wouldn’t in ePBS with smoothing or burning or anyway what is sometimes referred to as “consensus bids”. Censorship resistance can also be decoupled from choosing the winning bid, for example by having forward inclusion list proposers that are separate from the actual proposers.
Imho, the main reason why proposers are necessary is simply that our consensus protocol doesn’t work without the coordination provided by proposers. We can have very nice provable security properties for LMD-GHOST-like protocols, but they entirely depend on this coordination. If you were to just have attesters vote without it, the protocol becomes extremely vulnerable to balancing attacks.
Also, choosing the winning bid is not the only responsibility of proposers. They also make the beacon block part (including attestations, deposits, withdrawals etc…), and you don’t really want to auction that off.
However, I’m curious, why do we still need the “relay” at the Optimistic Relaying Endgame stage? If the relays are only used for staking collaterals and slashing dishonest builders, wouldn’t there be a more efficient and decentralized way (perhaps the proposer could verify whether the block is published after signing the block header) to achieve this?
Is it not plausible that over time builder competition will drive out most of the builders that are less effective/efficient?
Imaging a scenario where:
Proposers no longer have the ability to build block locally
All blocks in the network are built by 5 builders (among them 2 builders build 80% of the blocks)
Nation state actors then capture all 5 builders through a combination of bribes and threats
All 5 builders start to censor transactions (by submitting bids that ignore the inclusion list)
What do the validators do in such cases?
do they accept the highest censoring bid that to prevent the chain from halting?
do they reject all censoring bids and vote for empty blocks until another non-captured builder eventually joins back in?
I have to agree with @mikeneuder that proposers should always have the options to build a block locally even if features like inclusion list are already implemented
Great post for comprehensive analysis of PBS and its potential enshrinement within the Ethereum protocol as ePBS!
In particular, the bottom-up approach, which involves leveraging existing PBS infrastructure (relays), to be especially intriguing. This strategy could yield significant benefits in terms of efficiency and scalability.
As we move towards phase 1 (Asynchronous block validation) of the roadmap, what viable options exist or could be developed for existing relays/teams interested in running new relays? Additionally, are there any community tools or resources that could facilitate this transition and ensure a smooth implementation process?
Roadmap prioritization and community involvement: Considering the numerous upgrades planned for the Ethereum ecosystem and various teams working on the PBS front, how can the Ethereum community, including developers, stakeholders, and users, actively participate in these decision-making processes to ensure the most effective and efficient path forward?
ya its a good point! it is for sure not clear that a user would prefer the p2p version over the last iteration that still has relays as a proxy for the bids. one argument to switch to the p2p is if it turns out to be just faster than the relay proxy version. for example, if builders are well connected and validators hear about their bids faster than routing through a relay. i think more likely is the most competitive relays serve as a high-speed bid proxy.
Do you have any in mind? we have thought about trying to make it a smart contract or similar, but the issue we usually run into is that we need some source of truth about the timing of events that happened. e.g., we need to know that the proposer signed the header “on-time” and that the builder produced the full block “on-time”. This is why we call it a “mempool oracle service”, because the relay serves as the source of truth. would love to hear any other ideas you have though!
IMO this is one of the biggest concerns I have with MEV burn. it really removes the ability for a validator to build locally, unless they are willing to burn the amount of ETH required by the floor bid. I really like the idea of the validator being able to build locally, but that is also not compatible with stateless validators, so maybe its just not feasible in the endgame version of the protocol.
we already have phase 1 implemented and running on ultra sound relay! the code is upstreamed into the flashbots repo and open source for anyone to use if they like. there have been some discussions around encouraging funding for non-censoring relays, but besides that there is not much financial support for new entrants. that being said, we are super willing to help any new relay operators get set up with optimistic relaying in terms of running the code and providing infrastructure details. as we move towards the latter phases of the roadmap, we think the barrier of entry will continue to shrink.
this is a great question and also something that the EF is thinking hard about. i think it will grow organically beyond the small group of folks thinking about it currently to eventually having an EIP, community calls, open problems etc. that all feels a bit premature at the moment given we are still fleshing out the designs and thinking about big picture. this post aimed at providing a snapshot into the current discussions and we hope that in the next few months we can coalesce behind a specific design (this is a longer-term project just because of how significantly it may change the “shape” of the consensus layer). i would love to chat if you have any other ideas about how to get more community engagement
Without the ability to propose blocks, what are validators? Mere voters? We all know how well our so-called democratic political systems works. When all the candidates are terrible, what’s the point of having hundreds of millions of voters, if they have almost no power? All we can do is to vote for what perceives to be the “lesser of evils” and suffer the equally bad consequences.
The ability to propose block locally, imho, is the last defense (without resorting to the social layer) against attacks that target the block building infrastructure. I have no doubt that ePBS would centralize the block builders. Therefore it is crucial to preserve validators’ option to build blocks in a decentralized fashion, even if such option is almost never exercised in a normal scenario.
The mere existence of such option should suffice to deter attackers to not even bother trying to capture the builders in the first place
As Mike already mentioned, there’s a future where home-staking gets a lot easier through stateless validation, but where these low-resource validators are not able to build locally. Also there’s a future in which Danksharding makes local block building completely infeasible even for a validator with the equivalent of today’s resource requirements.
Still, it is in theory always possible to let at least well-resourced validators (e.g. staking pools) build their own blocks if they so desire, but it would be incompatible with ePBS designs with consensus bids (e.g. with smoothing or burning). I am not really sure that preserving this property has a lot of advantages, compared to what can be achieved with censorship resistance schemes.
Amazing article, thanks!
This is directly related with @Blanker’s question and @mikeneuder’s answer to that question.
I believe it should be possible to move the relay’s role to blockchains with second or sub-second block intervals and an appropriate smart contract system deployed, along the following guidelines:
There is a public bidpool, proposers may choose a bid and form a tx on the sidechain, signing the block header. This tx also enforces a deposit from the builder. Then the builder publishes the tx payload. There is an oracle committee that decides whether the block was finalized on Ethereum.
Assuming that systems like this are possible, I want to stress the following points:
(a) ePBS is not sufficiently justified. So far, the reason for ePBS is to eliminate the relay, but this scheme also eliminates the relay. It provides transparency, decentralization and incentives (for brevity, I won’t describe possible incentives mechanism here) thus solving every drawback of relays.
(b) This scenario seems to fit well as a step following the “optimistic relaying endgame”, independently of whether we want to continue with ePBS next.
(c) I can think of some reasons favoring this solution instead of ePBS:
(c1) The block building market would be more flexible, by allowing different solutions to live simultaneously and adapt more quickly to varying market conditions.
(c2) Keep L1 protocol as simple and efficient as possible.
hi Sergio! i am trying to make sure i follow your proposal. the flow would be
proposer chooses winning bid and makes a transaction (call it Txn A) on the side chain with the signed header.
the side chain finalizes/includes the block containing Txn A.
the builder sees the side chain including the block containing Txn A, and published Txn B which includes the ExecutionPayload of the Ethereum block.
the proposer constructs the full SignedBeaconBlock and publishes it to the Ethereum p2p.
the oracle committee on the side chain attests to the inclusion of the block in Ethereum.
the biggest issue i see with this is that it depends on the side chain and the oracle network on the side chain. for example, if the side chain stops finalizing (or stops producing blocks) then the whole builder market shuts down. or if the oracle committee can be corrupted, that can impact the consensus layer of the L1. i guess my intuition is that having the L1 consensus depend on a side chain is not that different from having the L1 consensus depend on the relays.
what do you think? am i interpreting your proposal correctly?
Hi @mikeneuder, thank you for your answer!
You are interpreting my proposal correctly. Of course there are details that deserve more careful thoughts. For instance, if the builder fails to publish Txn B, but made public the ExecutionPayload somewhere off-chain, and the block was succesfully included, then the correct behaviour for the oracle would be to declare the block succesful and refund the block builder the deposit. Naturally, I’m still not sure about the precise optimal secure mechanism.
However, I disagree with you appreciation. Namely, that this wouldn’t be that different from using relays.
Without ePBS it is up to the proposers whether to engage in different block building markets. I see this mechanism as a good candidate to provide more reliable and sustainable markets. I imagine a scenario with more than one side chain doing this. They would probably compete for adoption, since from the point of view of the side chains it is an awesome use case. Blockchains are far more reliable than centralized systems (that’s the whole point…), and they typically don’t stop working. In case one of them do, we would still have the other competing systems, including possibly local block production.
If PBS is not a part of Ethereum consensus, then I don’t think Ethereum loses sovereignty due to an evolving free market of block building.
But my main point is simply that in order to decide whether to adopt ePBS, we should compare it with this scenario. Or even better, to provide fundamental reasons for ePBS.
thanks for the response Sergio! i think it is an idea worth considering for sure my gut reaction is that having the L1 depend on side chains for the block production market is an anti-pattern. for example, consider the case where a large Ethereum staker is able to reorg the side chain. then they can get a builder to expose their block in the clear, reorg the side chain, unbundle the block (as was done by the Low Carb Crusador), and propose the block on the L1 without provably doing anything wrong from the Ethereum protocol perspective (it would just look like a locally built block). they actually wouldn’t even need to reorg the side chain if the MEV opportunity is bigger than the side chain slashing penalty for disobeying the rules of the side-PBS market. but i would love chat more about the idea and keep brainstorming!
But the block builder only publishes the block content after seeing the signed header. This seems to be the exact same situation as in your “optimistic relaying endgame”, where the builder publishes to p2p.
ah ok, good point – so the proposer will be slashable on Ethereum, but again this slashing might be much less than the actual MEV opportunity that they steal from the builder. i agree that this is the same issue as is present in the optimistic relaying endgame! we wrote a post on this type of attack after the Low Carb Crusador – Equivocation attacks in mev-boost and ePBS. ePBS addresses this because the attesting committee won’t attest to a block that they see as equivocating. So in this case the unbundling won’t be profitable for that builder because they will not land a block on chain and they will be slashed. maybe that is the key differentiating factor that ePBS offers!
Who picks who is the proposer, attester, and builder? What determines as an ‘observer’ and based on the timestamps slots series of importance? Centralization introduces a single point of failure, and the reliance on a centralized entity for validation raises concerns about trust and censorship resistance.The attesting committee may face challenges in efficiently processing and validating all the events in a timely manner require careful design and implementation to ensure the relay’s fairness and impartiality in handling bids and blocks. What is fairness?
Awesome research piece, thanks! Just wanted to point out that you could have relayer “slash” builder trustlessly as described in the Optimistic relaying endgame. To do so, you could use zero-knowledge encryption and probably build on top of already existing circuits to generate a proof of builder “misbehaviour”. Actually, by the time you’d get to optimistic relaying, extrapolating forward the past two-year of efficiency gain around zk, you could probably decentralise the relay job by having anyone submit a zkp in case of builder misbehaviour!
I’ve gained a clear understanding of the necessity of ePBS and the top-down and bottom-up approaches to ePBS.
I have a question regarding the optimistic relay.
I assume that the optimistic relaying endgame, which involves P2P bidding, wouldn’t allow for millisecond-level competition (cancellation) of bids like MEV-boost.
However, I believe that the ability to cancel bids is crucial for maximizing profit distribution among builders and in DEX-CEX arbitrage scenarios.
Is there a way to implement cancellation of bids in the ePBS framework?
I would appreciate any insights you could provide on this matter.
If you have in-protocol builders instead of off-protocol, then builders don’t need to invest in buying reputation for becoming a relay. They can simply open their own HTTP endpoint and run as a vertically integrated relay. Enshrining them makes this trustless. They can do whatever relays do now, including cancellations
