Ethereum Guild 2025-03 (May 13, 2025): ePBS, block building, MEV shenanigans

[philknows]

When: May 13 @ 1400 UTC
Meeting Link: https://meet.google.com/ehf-vjpn-rbf

Topics for Discussion

ePBS and viability

• Complexity. Changes are too large? Protocol risk?
• Changes in commit-reveal timings by ePBS and impact on MEV

Block Building

• State of local block building
• Viability of local block building in the future
• More efficient block building good or bad for overall MEV extraction?
• How to prevent or at least keep timing games in check

Dealing with MEV

• Should MEV solutions be pushed to the application layer?
• Extension to FOCIL with In-protocol transaction ordering: https://ethresear.ch/t/in-protocol-transaction-ordering/21084
• Encrypted mempools:
  • Is programmable encrypted mempools an end goal for fair & effective MEV?
  • Is it technically feasible? Efficient enough crypto yet?
• Lower slot times (eg. 8 seconds) and impact on MEV

[ensi321]

Slightly related but maybe out of scope for this meeting but there are a lot of ideas out there that mitigate or confine and reduce MEV influence to the protocol:

• OG TOB focil (technically limit builders' freedom to pack txs in blocks, so slight MEV mitigation)
• PEPC gives beacon proposers power to instruct how builders pack their txs eg. sort tx by hash in ascending order, sort tx by fee. Depending on how we go about this, slight to strong mitigation of MEV
• APS (Slot auction and other sort) aims to redefine beacon proposer and builder as consensus proposer and execution proposer. This decoupling aims to confine MEV issue to execution proposing such that consensus side of the protocol is not affected by any negative consequences brought by MEV (notably builders' timing game will not impact forming consensus anymore)

[nflaig]

OG focil (technically limit builders' freedom to pack txs in blocks, so slight MEV mitigation)

do you mean the current FOCIL proposal? I don't see how that mitigates any MEV

PEPC gives beacon proposers power to instruct how builders pack their txs eg. sort tx by hash in ascending order, sort tx by fee. Depending on how we go about this, slight to strong mitigation of MEV

Haven't read this is in detail but I don't see why the proposer wouldn't just pick the most profitable strategy. It could be used to improve censorship resistance but FOCIL seems much better for that.

[ensi321]

do you mean the current FOCIL proposal? I don't see how that mitigates any MEV

Yes. Builders no longer have full control of a block's transaction, so they can't harvest the full potential of MEV. Same with PEPC.

And it should also break or make multi-slot MEV less effective but need to investigate more by researchers https://efdn.notion.site/Multi-slot-MEV-Prevention-via-FOCIL-02df82ac72944ec2b4288aa53100c814?pvs=25

Haven't read this is in detail but I don't see why the proposer wouldn't just pick the most profitable strategy. It could be used to improve censorship resistance but FOCIL seems much better for that.

It's more like beacon proposer announces the block transactions ordering requirement to the builders, and then accept the highest bid he receives. So it disrupts the builders and they have to choose less optimal MEV

[nflaig]

It's more like beacon proposer announces the block transactions ordering requirement to the builders

the incentives don't seem aligned here, why would the proposer choose a ordering rule that doesn't provide max profit if he gets payed for it?

Yes. Builders no longer have full control of a block's transaction, so they can't harvest the full potential of MEV.

FOCIL does nothing to reduce MEV, the inclusion list transactions are applied at the end of the tx list and only if there is remaining gas to consume. Also if builder of block N does not harvtest the MEV then builder of N+1 will, the extra delay even increases overall MEV that was extracted.

[ensi321]

FOCIL does nothing to reduce MEV, the inclusion list transactions are applied at the end of the tx list and only if there is remaining gas to consume. Also if builder of block N does not harvtest the MEV then builder of N+1 will, the extra delay even increases overall MEV that was extracted.

Oh yea you are right. I was under the impression that we are using some TOB design to ensure IL transactions are included in the block. My bad.

However if TOB variant of focil would reduce MEV because builders must include those IL txs which are from mempool and only have complete control for the remaining of the block to extract MEV

[nflaig]

However if TOB variant of focil would reduce MEV because builders must include those IL txs which are from mempool and only have complete control for the remaining of the block to extract MEV

I would be careful with making assumptions like "control for the remaining of the block to extract MEV" will reduce MEV that can be extracted in total. Looking at data from mainnet it seems that if previous slot did not extract a lot or no MEV at all, ie. it was a locally build block, then then next slot can extract even more MEV. So all proposals that "reduce MEV extraction" need to be looked at with a grain of salt imo.

[GregTheGreek]

Reached out Flashbots, made an intro @philknows check tg :)

[nflaig]

Same also reached out, but need to clarify what time makes sense and maybe think about if we want someone closer to the protocol or rather the app layer, I think for us it makes sense to talk about it more from a perspective of the protocol and what's the best way forward there.

[nflaig]

few more points we could discuss

• more efficient block building good or bad for overall MEV extraction?
• how to prevent or at least keep timing games in check
• lower slot times (eg. 8 seconds) and impact on MEV
• changes in commit-reveal timings by ePBS and impact on MEV
• future of local block building? APS / rainbow staking?

[philknows]

Adjusted from May 14 to May 12 to de-conflict Ethereum research call.

Adjusted to May 13 now due to change in Ethereum ACD calls.

[philknows]

Note that we may have to change this date again as PeerDAS calls are now being held on ACD(T) on Mondays now that Pectra has forked. We may have to switch this again. Potentially looking at May 13 (where PeerDAS call used to be). TBC.

[philknows]

Ethereum Guild 2025-03: MEV, Block Building, and ePBS - A Detailed Conversation Summary

Recording: https://www.youtube.com/watch?v=jD0W53HuWHY

This summary covers a rich discussion between the Lodestar team and Flashbots representatives (Hasu and Data Always) about Ethereum's block production ecosystem, MEV extraction, and proposed protocol changes.

The conversation involved members of the Lodestar team discussing with Flashbots representatives Hasu (executive team member responsible for strategy) and Data Always (protocol researcher). The discussion highlighted differing views on Ethereum's goals and impact on MEV, with concerns raised about potentially abandoning in-protocol solutions. Hasu introduced Buildernet, a decentralized block building platform utilizing TEEs for privacy and verifiable ordering, aiming to aggregate order flow and return value to users and validators while addressing centralization concerns. The participants also explored alternative MEV solutions like APS and the potential impact of lower block times, expressing a shared interest in future collaboration and a decentralized Ethereum ecosystem.

Enshrined Proposer-Builder Separation (ePBS)

A major focus of the conversation was EPBS, which aims to integrate Proposer-Builder Separation directly into Ethereum's protocol rather than maintaining the current out-of-protocol approach involving trusted relays. Nico highlighted the team's contention with ePBS, as it could mean abandoning in-protocol solutions for MEV, such as deterministic ordering, in favor of relying solely on the builder network.

Data Always explained that the initial reasoning for ePBS was to remove relays due to concerns about censorship and relay timing games. However, Data Always noted that if the primary goal is simply relay removal, other options like flat fee reduction could be considered. Data Always suggested that ePBS becomes more critical if the goal is to redesign the slot or ensure a trustless payment flow.

Hasu stated that the current ePBS proposal has two main purposes:

• Removing the relay (intermediaries in the current system)
• Enabling delayed execution (to increase Ethereum's execution budget)

Hasu considered delayed execution a beneficial change for increasing Ethereum's execution budget and facilitating faster finality and improved block times. However, Hasu expressed concern about enshrining a PBS solution at this stage due to the rapidly evolving market structure and potential incompatibility with developments like pre-confirmations and based rollups. Hasu believes the current out-of-protocol solution works well and that emerging designs could remove relay dependency. Consequently, Hasu does not currently support ePBS

"Many MEV researchers... are quite nervous about enshrining any PBS solution at this point in time because it's still changing very rapidly... you run a very high risk frankly of like enshrining something that's suboptimal." - Hasu

He noted that recent developments in pre-confirmations and base rollups appear incompatible with the current ePBS design, suggesting the out-of-protocol solution (MEV-Boost) continues to work adequately.

Nico from Lodestar expressed concerns that ePBS "basically means we give up on... solutions [like deterministic ordering] and just hand it over to the builder network."

Development of Block Building

Matthew questioned the reliance on out-of-protocol solutions for critical protocol work like transaction selection and ordering. Matthew pondered if the L1 should push the MEV problem to the application layer, similar to how ENS or Cow Swap addressed it.

Hasu's view is that both are necessary and not mutually exclusive. MEV should be minimized at the order flow layer (user, wallet, app) where users have control, and maximized at the protocol layer (validator, builder) to prevent reward disparities. Hasu noted the significant reduction in MEV due to efforts at the app and wallet layers.

Hasu explained that protocol-external block building developed due to the high value-adding nature of block building, which could lead to centralization among validators with varying sophistication. The concern was that MEV existence could cause reward disparities, prompting the development of out-of-protocol PBS like MEV-Boost, allowing all validators to access high-quality blocks. Hasu argued this has kept validator decentralization.

Hasu proposed a dual solution where sophisticated block building is handled by external builders, while validators are more involved through mechanisms like inclusion lists to enhance censorship resistance without imposing heavy requirements on them

Dark Pools and Centralization Concerns

Matthew raised concerns about dark pools where transactions are sent directly to builders, potentially reducing the transactions available in the mempool for validator inclusion lists.

Hasu argued that wallets and apps send transactions to private mempools to improve user outcomes through privacy, protection from sandwich attacks, and potential MEV recapture via order flow auctions. Hasu believes the current system works well for users.

BuilderNet: A Decentralized Approach to Block Building

Matthew Keil highlighted the potential monopoly power of opaque builders and questioned the transparency of sandwiching prevention and order auctions. Matthew Keil asked if bringing such mechanisms in-protocol would be beneficial.

Hasu introduced BuilderNet as Flashbots' solution to the centralization problem in block building:

Key Features and Benefits

A decentralized block building network running on Trusted Execution Environments (TEEs). These TEEs aim to keep user transactions private and verifiably run specific ordering algorithms.

Hasu explained that it's a trusted execution environment, such as Intel SGX or TDX, which uses secure enclaves to run code privately, even from the hardware operator, ensuring data privacy and software integrity.

Hasu noted that current TEE technology requires trust in the hardware manufacturer (e.g., Intel) and has had past break-ins, which Flashbots is addressing by having builders run in data centers where the operator lacks machine custody.

TEE Technology and Alternatives

Peter of ChainSafe asked about the retirement of Intel SGX and alternatives from AMD and RISC-V. Hasu clarified that the consumer version of SGX was retired, but they are using Intel TDX, where the operating system is more integrated into the hardware being proven. Hasu mentioned that AMD has a less performant and mature TEE solution, and Flashbots is proactively working with the supply chain to improve TEEs for Ethereum.

Long-term, Hasu envisions using multiple TEEs from different manufacturers and data centers for redundancy and increased trust. Nico suggested that TEEs are suitable because only short-term integrity is needed, as no long-term secrets are stored.

Nico Flaig mentioned internal discussions about pure software solutions like homomorphic encryption for long-term privacy without hardware reliance, though performance is currently a limitation. Hasu agreed that this is a long-term goal and that the biggest challenge is latency for block building. However, Hasu noted that cryptographic solutions could be used in conjunction with TEEs for defense in depth, potentially reducing communication rounds and latency

BuilderNet Adoption

Matthew questioned the strategy for gaining market share from existing dominant builders once the TEE technology is perfected. Hasu stated that Builderet was released late last year and initial focus was on achieving performance parity with centralized builders.

Recently, it was announced that Beaverbuild (one of the largest block builders) is integrating with BuilderNet by the end of the year and transition existing clients, indicating a potential tipping point where building within BuilderNet becomes more profitable

Hasu emphasized that BuilderNet has reached performance parity with the best centralized block builders, with "less than 5% performance overhead compared to like the best centralized version."

Matthew asked about the economic incentives for participants to use BuilderNet. Hasu explained that the long-term vision is to foster competition on block building within BuilderNet on top of private but universally accessible order flow, creating an encrypted programmable mempool. In the short term, operators joining BuilderNet run the same code, avoiding internal competition.

Nico Flaig questioned how BuilderNet would outbid centralized builders if it provides better UX, leading to more order flow and thus higher bid value. Hasu affirmed this model, highlighting Beaverbuild's decision to join BuilderNet and outsource block building to focus on searching, as an endorsement due to the demanding nature of their high-frequency trading order flow.

MEV Refunds and User Benefits

A significant aspect of BuilderNet is its approach to returning MEV to users. Hasu clarified that Builderet aims to attract more order flow through better UX and features. BuilderNet itself may still compete with external builders and will programmatically bid to validators. Hasu emphasized that BuilderNet is designed to maximally return MEV to users through order flow refunds.

"If your transaction creates any MEV or pays any excess transaction fee then you can be refunded that money because... when BuilderNet generates any surplus against other builders then basically anybody who contributed to that surplus they can get a refund."

This system prevents sandwiching attacks by keeping transactions private and verifiably prevents builders from exploiting user transactions. Hasu affirmed that their builder treats all received transactions as private and does not run internal searches on them, which is verifiable. Hasu explained that refunds could apply to overpaid priority fees or MEV created by backrunning. The system aims to operate like a second-price auction, where users only pay the necessary amount for inclusion.

Single Bid Scenario and Monopoly Concerns

Nico inquired about the auction process if all or most builders join BuilderNet, potentially leading to a single bid. Hasu acknowledged this as a possible outcome, where BuilderNet would have programmatic rules for dividing block value, ensuring validators still receive rewards.

Matthew raised concerns about BuilderNet exerting monopoly power in such a scenario. Hasu responded that validators would choose to connect to BuilderNet if it provides the best blocks and that the system must keep both validators and users satisfied with programmatic bidding rules that could be adjusted.

Financial Viability and Entity Structure

Matthew asked about BuilderNet's financial structure and if there's a service fee. Hasu confirmed plans to charge a service fee on order flow, with the rate yet to be determined due to the system's early stage. The goal is to make it sustainable for operation and future development, including connecting Layer 2s.

Hasu described BuilderNet as an extremely decentralized and private auction system for conflict resolution, starting on Ethereum L1 but potentially expanding to other chains.

Matthew questioned why the BuilderNet concept shouldn't be integrated into L1 as a public good. Hasu argued that Flashbots, as a specialized company focused on decentralized and private block building, can likely develop it more efficiently. Hasu believes that being for-profit and serving as a public good are not mutually exclusive, as a decentralized system can have a programmed take rate. A for-profit model also ensures continuous improvement and long-term sustainability. Additionally, Hasu suggested that a separate entity like BuilderNet could be more neutral and potentially connect more chains beyond the Ethereum ecosystem.

Matthew discussed the scenario of based rollups where sequencing returns to L1. Hasu agreed that in such a case, BuilderNet would play the role of the shared block builder, essential for building cross-chain aware blocks in a decentralized way, preventing a massive centralizing force.

Local Block Building vs. Specialized Builders

The conversation reflected philosophical tensions about decentralization and specialization:

Matthew Keil expressed concern about the centralization of block building: "The builders are antithetical to the ethos of why we all join the blockchain space... to build a better future that is more egalitarian and more meritocratic."

Hasu defended the specialized approach, arguing it provides better user outcomes through:

• BuilderNet being designed to be architecturally decentralized with many permissionless operators, minimizing trust in single entities
• Competitive markets for block space
• Private transactions preventing frontrunning
• Prevention of validator centralization by equalizing rewards
• Inherent benefit of block building in efficiently resolving state conflicts based on diverse user preferences.

The aim is to create the best possible auction with privacy and minimal cost for users.

Data Always also raised practical concerns about scaling local building:

"How far do you think that we can scale local builders and still keep good liveness rates? Right now... reorg rates for local builders are 0.7%. But that's really artificially low from the reduced gas usage.

Nico Flaig suggested this might also be due to local blocks waiting for min-bid, delaying publication. Data Always wondered if this implies a need to shorten the timeout. Nico believes capping blobs and gas limits might be necessary . Matthew cited experience on a devnet with PeerDAS running high blob counts and gas limits with local block building, suggesting it might scale further with a performance-focused mindset. Matthew questioned if running local block production on minimal hardware like a Raspberry Pi is a realistic expectation, suggesting minimum hardware requirements might need to be reconsidered. Nico concluded by stating that the purpose of local blocks matters: whether it's to compete with builder blocks or serve as a liveness/censorship fallback . He expressed philosophical opposition to a future where validators cannot build their own blocks, which was a point of interest in Ethereum's move to proof-of-stake.

Arguments for Attester-Proposer Separation and BuilderNet as an alternative

Matthew noted his own strong dislike for MEV and builders but expressed excitement about BuilderNet as a novel solution using hardware-level expansion. However, Matthew pointed out that BuilderNet's specialized builders and off-protocol work seem to align with the idea of APS, which could undermine independence, censorship resistance, and local overrides.

Nico added the loss of the local block override where the execution client can flag censoring builders to the consensus layer as a concern with APS.

Data Always argued that APS's main strength is the ability to slash sophisticated entities for misbehavior, but TEEs in BuilderNet could offer similar guarantees without the significant protocol changes and uncertainties of APS. Nico asked for the main argument for APS versus the current system or ePBS.

Data Always stated that APS proposals emerged before BuilderNet, and if BuilderNet gains traction, APS might not be necessary due to its large-scale changes.

Nico mentioned that APS might prevent colocation by reducing reliance on latency between validators and builders.

Hasu views APS as a potential end state of the market, acknowledging the builder's power in the MEV chain. Hasu sees benefit in a version of APS that simplifies the protocol and enhances scalability through the unbundling of roles, where different nodes have specific functions and check each other's work. While directionally aligned, Hasu is not strongly committed to APS.

Areas of Agreement and Potential Collaboration

Despite initial philosophical differences, the conversation revealed several areas of agreement:

1. FOCIL (inclusion lists) was recognized by both sides as a valuable addition that could enhance censorship resistance while still leveraging specialized builders

2. Preconfirmations are concerning to Hasu, viewing them as centralizing and potentially hindering decentralization, and suggested lowering block times as a better approach to align with a based rollup future

3. Delayed execution and lower slot times were broadly supported as beneficial regardless of other protocol changes. Hasu explained that lower block times generally correlate with lower MEV, particularly in decentralized exchanges, improving user experience, and benefitting based rollups. While the exact magnitude of the benefit is uncertain, Hasu believes it is unlikely to be detrimental

4. BuilderNet was acknowledged, even by initial skeptics like Matthew Keil, as a promising solution: "This seems like actually a really good solution and it's something that I am excited to hear about."[3]

The conversation concluded with expressions of interest in potential collaboration between the teams, with Hasu noting:

BuilderNet is intended to become "its own decentralized network with... open contribution, several teams, a governance process, BuilderNet improvement proposals."

Conclusion

The discussion highlighted the nuanced perspectives on block building in Ethereum, with tensions between idealized decentralization and practical performance needs. While philosophical differences remain about the proper balance of in-protocol versus out-of-protocol solutions, both teams showed willingness to collaborate on approaches that maintain Ethereum's core values while addressing technical challenges. The emergence of BuilderNet represents a potential middle path that could address centralization concerns without requiring major protocol changes like ePBS.