# Building Blocks - Closed Software, Competitions

This post focuses less on the technical aspects of block building and more on the high-level reasons why depending so much on closed-source and out-of-protocol block production software in L1 consensus is negative for the protocol. While some points may seem trivial, they are worth discussing in written form with key points.

First, let's define what an out-of-protocol software is and then extend the terminology further.

- **Core-protocol software**: Software that one **MUST** run to follow or extend the chain. Extending the chain requires staking or some sort of economic bond to account for malicious behavior. We call this software core-protocol because you must run it to follow the chain correctly and extend the chain honestly. Actions from running the software and protocol are auditable on-chain. For example, "Did Alice's validator correctly vote on slot 100?" This is further provable with EIP-4788, which can be verified on the EVM.

- **Out-of-protocol open-source software**: Software that one may run to extend the chain. An example of this is mev-boost. Some portions of relayer components are also open-sourced. Given the out-of-protocol nature, it's not auditable and enforceable. For example, "Alice chose a bid to include, but the relayer did not reveal the block on time, so Alice did not get paid." Who is at fault here?

- **Out-of-protocol closed-source software**: Software that is proprietary and cannot be run by everyone. Most builders and searchers use proprietary software. Some relayers have proprietary software components, like delaying bids or taking a fee/rebating bids to builders. For example, "The relayer offered Alice the best bid of 0.03 ETH, but is that really the best bid from the builder? How can this be trusted?"

**Key Point #1**: The protocol is healthier the less it has to interact with closed software.

I think this point is easy to understand. Ethereum is meant to be an open-source, transparent system, and we should strive to maximize the surface of transparency, although understandably not everything can be open. Closed software is difficult to audit, debug, and hurts neutrality. ePBS improves upon key point #1 by enabling validators to exchange directly with the builder. Instead of requiring two pieces of closed-source software to propose a block, the protocol only needs a single piece of closed-source software. We should aim to minimize closed software leaking into the Ethereum protocol layer.


**Key Point #2**: The protocol is healthier the less it has to interact with out-of-protocol competitions.

Competition happens across all layers of the protocol because there's an incentive to do so, and that is fundamental. Competitions should be promoted openly to improve the health of the protocol. Competitions in the dark are negative for the protocol. Let's look at how competitions could happen across all stacks. Validators could compete with each other by DOSing each other if proposing blocks next to each other to propose a more profitable block. Empirically, this has not happened, at least as far as we know. Unlike proposers whose assignments are predetermined, relayers compete to win relaying the winning bid of the slot, and builders compete to win building the winning block of the slot. The outcome of these competitions leaks into the protocol (e.g., relayer timing games)[1]. Today, there are two competitions happening in place across two sets of actors: relayer and builder. In ePBS, there's only one competition in place: builder. The fewer competitions across different types of actors the protocol has to manage, the better. We should aim to minimize the surface of out-of-protocol competition leaking into the Ethereum protocol layer.

[1] ePBS does not solve timing game, builder could also delay the bid.


**On bypassability**, some may argue that relayers can still be used in ePBS. You can imagine maintaining the status quo by having the builder sign the header as in ePBS and proposing it through the relayer. The core-protocol consensus bid is 0, and the bid is sent as an ETH transfer as it is today. I'm not convinced this will happen. For this to occur, someone would have to go out of their way to fork the client code, which is not easy. This behavior is also highly attributable on-chain, and builder capital efficiency hasn't been raised as a concern yet.