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?
Hey Mike and Justin,
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!
Happy to jam on this if needed.
Thank you for the insightful article!
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