Opening remark

On September 26th, 2023, Blocknative announced its decision to halt its block building and relay operations. When I heard the news ahead of the announcement, I was surprised. Even though I was well aware that companies that were operating the relays for PBS were bleeding cash, I did not expect anyone to actually shut down. When Matt jokingly said, “We may only have a few relays left after next year without a proper incentive scheme” back at ETHCC in Paris, I assumed the community devs and researchers would eventually identify a sustainable solution for relay incentivization before we get to that state.

But now I realize that perhaps such a thought was a bit naive. I had been taking relays for granted and had thrown away all the rational and economic assumptions behind relays in the name of public good. That’s not good enough. So below is my attempt at reevaluating the relay incentive from the first principle with the goal of figuring out a viable pathway forward for relays without sacrificing decentralisation.

Thanks to Tina Zhen, Justin Drake, Uri Klarman, Matt Cutler, Alex Tesfamichael, Mike Neuder, Hasu, Fabrizio, Kydo, Alex Stokes, and Barnabé Monnot for invaluable feedback and discussions.

Original article link: https://mirror.xyz/0xE21b1e6f471EDeF18264e9BBe51b7fA7643EE6B5/0Sh7BDW7qgH_nadfqF8bpmnjxnfoYzPFvRdmoIoi9mg

Relay responsibilities

Let’s take a brief look at the following graph illustrating the relay’s role within PBS.

In a nutshell, the builder submits the bid to relays, relays send that bid over to the proposer, and the proposer commits to the most valuable block. The relay then reveals the block body, enforces the builder’s payment to the proposer, and propagates the block to the rest of the network. For more details, please refer to this post by Stephane. Clearly, relays play a critical role in our transaction supply network today. So why aren’t they getting properly incentivized? Here are a few reasons that I see so far.

1. Relays were a byproduct of solving the proposer monopoly/scalability problems via PBS

PBS was originally proposed to resolve the following risks associated with proposers:

• Pre-PBS Validator monopoly over the block proposal and transaction sequencing resulting in protocol-level censorship risk. To illustrate, a sophisticated validator could earn more fees than solo stakers by extracting MEV. More rewards allow the spin-up of more validators, creating a snowball effect that leads to validator centralization. With PBS, the validator (now proposer) would no longer have visibility in the block sequencing pre-commitment and could focus on increasing the censorship resistance (CR) property of Ethereum via inclusion list (IL), which is ongoing research. It is likely that validator centralization occurs with or without PBS, but I see PBS as a mitigation to an extreme level of centralization that we already observe in the builder landscape.
• An increase in the node requirement for running bundle-merging algorithms and low-latency infra for bundle and orderflow aggregations. The pursuit of a revenue-maximising block may result in the centralization of the validator network via proposers’ increased workload and latency requirements associated with MEV capturing. As such, PBS offloads the sequencing work and latency game to builders to keep validator nodes lightweight.
• Added compute overhead from KZG proof. In the case of Darksharding, proposers will need to compute KZG proofs for up to 64MB of rollup data in less than 1 second. PBS allows specialized provers, possibly builders, to efficiently provide the proofs, thereby facilitating a lightweight implementation of validators.

I believe PBS is a necessary step to pave the way for a more robust, scalable, and CR consensus network, but at the same time, it has successfully “offloaded” an awful lot of problems to builders and relays. For example, the following picture from censorship.pic suggests that while validators are mostly non-censoring, there exist significant censorship problems associated with relays and builders (less decentralised and no IL).

Furthermore, relay and builder problems were not the main focal point of the PBS. And among the two, builders had explicit economic incentives (MEV, CEX-DEX arbs) which has not been the case for relays.

2. “Relay is temporary, enshrining it will resolve the relay problems”

ePBS is still being researched and has many open questions that need to be answered. Different approaches bring different tradeoffs and protocol changes, some are more invasive than others, such as requiring longer slot time. There is a lot more work to be done to reach a conclusion/consensus on whether or not Ethereum should enshrine PBS at all. For the foreseeable future, relays are necessary to sustain the current PBS setup, and I think it’s paramount that we prioritise aligning the incentive of the existing stakeholders in the transaction supply network rather than waiting for a solution that may not ever be realised.

3. ‘Public good’ => Avoidance of incentive alignment issues among builders and validators => Toxic price competition

Given those uncertainties mentioned above, running relay as a public good understandably became a temporary solution to avoid dealing with incentive alignment issues around fee charges within the txs supply network. However, that also led to a toxic price competition among those who are trying to monetize relay.

bloXroute attempted to monetise in the past by offering additional services, such as a low-latency network for block propagation. Their aim was to provide a relay network that is latency optimized, allowing them to charge fees based on the profit that builders gained when using the bloXroute relay. While the added revenue barely covered relay maintenance and operations costs (ranging from $100k-500k), it was a modest success in demonstrating the ability of a relay to charge a fee. However, as more public-good relays (like Agnostic and Ultrasound) capable of providing relatively low latency (optimistic relay) enter the scene, the competition for users willing to pay for these services intensifies, making bloXroute’s fee model less effective over time. Without an immediate solution, the relay market will continue to be a contest to determine who can sustain the public good the longest with the deepest pockets.

Future of the relay market

So far, there are two approaches to reaching a more sustainable relay market under different assumptions.

1. Double down on public good: Relays can collect donations from large DAOs and protocols to fund the operations. This is probably easier to execute but it’s uncertain how much can be gathered and for how long the public good funding will last. Simple but not sure how sustainable it is, unless the fund is in a large size (maybe ETF funds?!?). One great effort on that front is PBS guild led by Tina, raising more awareness around the relay incentivization issue while funding relay research and operations via its grants. It’s certainly possible to have sustainable public good grants via PBS guild if there is an entity, like an ETF fund, that is willing to donate a portion of its profit to the guild like what VanEck did for Protocol guild. However, getting such a donation is extremely difficult and perhaps even unrealistic at this stage. Therefore, public good efforts like PBS guild could be considered as an added incentive for conducting more research and development around the relay incentivization mechanism.

2. Resolve the incentive alignment issues: Form a relay union & reach a social consensus to collectively devise a fee model that attempts to enable relay monetization while aligning the incentive of builders and validators. This requires coordination and collaboration among the stakeholders in our txs supply network, and it is the focus of this article to explore the means through which this can be achieved.

Relay Union: an attempt to move on from public good via social consensus

Some relay operators have attempted to align everyone’s incentives, including validators and builders, to find a sustainable path forward. To start off the discussion, here are important questions we need answered:

1. Who should pay for the relay cost?
2. How should the relay be paid? (e.g. who sets the fee and how?)

So let’s explore those two questions here.

Who should pay for the relay cost?

Intuitively, it seems reasonable that builders and validators, who heavily rely on and benefit from the services provided by relays, should bear the associated costs. In practical terms, both parties could collaborate by allowing relays to deduct a portion of bids, but there’s a need for one of them to facilitate this payment. It’s important to recognize that each party’s participation also introduces varying levels of influence and leverage for the relays. As a result, it becomes essential to determine which party is more inclined, if at all, to accommodate and compensate the relays. Essentially, we must assess the extent to which well-connected relays can persuade builders or validators to take the lead in facilitating these payments.

Note: I refer to “well-connected” to mean relays that have over one-third of the validator registered across the network.

Relay’s leverage over builders:

• Well-connected relays can deliver the bid to more validators, increasing the reach of builders’ bids.
• Large builders, like Titan, Rsync, and Beaver, could be incentivized to create a vertically integrated builder-relay to avoid paying any additional relay fee as long as the cost of operating & developing relay — additional profit from latency advantage in co-locating with relay << cost of paying external relay fee. Large builders who have a significant amount of CEX-DEX activities and/or associated trading partners may profit from improved latency with integrated relay such that the cost of relay operations can be amortized. However, builder-relay in general comes with the following risk factors, hence confining the possible candidates for launching a successful builder-relay to only reputable and trustworthy builders.
• Large conservative validators may not connect to new relays out of security/risk concerns (esp large ones like Coinbase and Lido). BD partnership and nepotism might help, but getting large numbers of validators to connect requires a good reputation for performance and reliability.
• A builder-relay has the potential to manipulate their bids. A builder-relay might claim a bid of 100 ETH when the actual payout, after the proposer commitment, is only 1 ETH. This kind of manipulation becomes more challenging when the relay operates as a separate, trusted entity, unless colluded with builders. It’s worth noting that such manipulation is less likely to occur with the top three builders due to concerns about their reputation. Therefore, it’s primarily the most reputable builders who could establish builder-relays that validators would be more likely to trust.
• A builder-relay could face the risk of being orphaned by validators if the same builder also submits bids through existing relays. Even when the builder runs its own builder-relay, it may still need to submit bids through the incumbent relays for broader reach and efficient broadcasting. This could potentially disincentivize validators from connecting to a new builder-relay, considering they can continue to receive bids from the same builders. Consequently, builders must differentiate their own relays from others to increase their chances of attracting more validators. This differentiation strategy can come at a significant cost; builders may need to consistently send higher bids across their own relay (which may be less-connected) and lower bids across others (which are better-connected), if they choose to do so. Additionally, to initiate validator connections, builders must engage in extensive business development partnerships and marketing efforts resulting in more cost overhead.

Relay’s leverage over validators:

• Reputable relays broaden bid coverage from builders.
• Listening to multiple relays increases the redundancy for payload deliveries and increases the validator’s coverage on non-overlapping bids submitted across relays. This table shows various statistics around relays over the past 7 days (10/20/2023) to illustrate the non-overlapping bids coming from different builders across the relays with validator registration counts. Based on Builder Count (Total) and Builder Count (Top4), we observe that relays that regularly receive bids from top 3 & 4 builders have a high % of successful payload delivery. Note that this is a correlation and does not suggest any causal relationship between the high % of payload delivery and receiving bids from top builders. However, this data does suggest that a relay who has a good reputation and performance tends to receive a broader range of builder bids and achieve a better rate of payload delivery. As such, validators should listen to multiple relays to maximize the bid value.

At this point, I hope it’s clear that both validators and builders need relays, and it is hard to say which party depends more on relays than the other. Builders selectively send their bids to relays of their choice and do not blindly send to every relay as people have suggested previously. Similarly, validators selectively listen to relays of their choice and do not blindly register with every relay, also due to regulatory concerns.

One could argue that relays may hold more leverage over builders for two reasons: first, it’s relatively easier to persuade builders to submit bids when there are enough validator registrations due to the performance advantages; and second, building a builder-relay is a non-trivial task. However, it remains inconclusive as to who should accommodate to facilitate the payment and bear the relay cost. Therefore, our next step is to explore how the fees can be distributed.

How should the relay be paid? (e.g. who sets the fee and how?)

There are two possible modes of payment: real-time vs deferred payment, where the former settles the payment while the payload delivery is performed and the latter settles the payment after. With that in mind, let’s discuss the technical feasibility of possible payment approaches by builders and validators, from which we will also explore who and how the fee is set.

If builders pay: Real-time payment

• Ultrasound has recently proposed a solution that enables real-time builder payment that also attempts to better align builders’ incentives. Here is an overview of how it works:

• When a builder wins the bidding, it typically submits a payload whose last transaction pays the bid to the proposers. During this process, relays perform the role of making sure that the last transaction is actually a bid transfer and that it is the bid amount the proposer agreed to. The Relay has full visibility and control of the payload during this process and has to be trustworthy. Ultrasound attempts to leverage that trust and modify the bid transfer where the relay, instead of the builder, pays the proposer up to the second highest bid seen across other relays such that the delta between the first and second bid can be distributed among builders and the relay. This allows bid rebates to builders, but enable this, builders need to opt-in by providing the following:
• Post some collateral such that the relay would have the liquidity to pay the second-highest bid amount to proposers. Alternatively, the relay could also settle directly with builders after the payload deliveries, which may require the relay to be well-capitalized. The post-settlement of the liquidity is essentially a short-term credit provided by the relay to the builders. Therefore, the relay could explore charging interest on the short-term credit as another avenue of monetization.
• Merkle path to the last transactions such that relay can modify the last transactions and hence the header.
• This approach takes full advantage of the latency competition that is already happening among the builders/relays and tries to benefit from it. There are, however, a few concerns:
• Since the winning builder receives rebates on the delta between their bid and the second-highest bid submitted via other relays. This will incentivize top builders to submit their bids ONLY to the best-performing relays (the lowest latency + broad validator coverage) to maximize their rebates. If most builders opt into Ultrasound’s approach, there will be little to no incentive for builders to submit their bids to multiple relays since that would reduce their rebates to zero, leading to a relay centralization where a single entity handles over a majority of the payload deliveries. This could potentially make relay space even more centralized than the already centralized builder space. Even if all top relays reach a social consensus on applying this fee model, it would result in bid and relay centralizations.
• Relay competitions may lead to an inflation of % rebate, resulting in a race to the bottom on providing the highest rebate (lowest relay revenue). To mitigate this, it may require some social consensus among top competing relays to agree on rebate % and adjustment mechanisms.

This proposed approach is fascinating and worth exploring more ideas on top of it. For example, instead of calculating the delta between the highest bids from other relays, we could explore using the delta of the top and second highest bids received within the same relay. As such, builders could submit bids to multiple relays as usual, and the fastest relay that delivered the top bids and the payload can charge the fee and give rebates. This will still demand latency competitions among relays but can prevent the over-centralization of relays by not disincentivizing builders’ bid submissions to competing relays.

If builders pay: Deferred payment

• Relays will prepare a smart contract where builders could post a few ETH of fee collateral as a form of prepayment for relay usage. Every month (or some specific time interval), relays can check the total number of bids and winning bids submitted by a specific builder. Relays can then decide to charge builders according to their fee specifications, such as % charge on winning bids or fixed fee cost per winning bids etc.. The trust assumption here is that relays do not withhold the builders’ collaterals and do not charge additional fees beyond the fee specification that was agreed upon originally. The assumption here is fair for builders given that they are already trusting relays for many important tasks, such as relaying the bids/payloads and not unbundling and stealing MEV. This approach enables a flexible expression of relay fee preference that could better align builders’ and relays’ incentives while preventing over-centralization among relays. However, there are some concerns:
• Deferred builder payment does not provide a rebate, hence not competitive against relays that adopt Ultrasound’s real-time payment approach (Latter provides the rebate while the former doesn’t)
• Builders could try to bypass this deferred payment by running their own relay, but for the factors I mentioned previously, it may not be worthwhile for builders to spend the cost and effort to run their own relays if the fee charge is reasonable (based on winning bid etc.) and sufficiently low (5% per winning bids).
• Deferred payment is simple and flexible, requiring only relatively small builder collateral as opt-in prepayment. However, attracting builders could be more challenging if the alternative relays offer rebates. Due to the smaller collateral requirement, it may better cater for builders with fewer resources who aren’t willing to post large collaterals.

If validators pay: Real-time payment

• MEV-Boost currently maps the received bids with the corresponding relays via

relays[BlockHashHex(bidInfo.blockHash.String())] = append(relays[BlockHashHex(bidInfo.blockHash.String())], relay)

such that proposers can keep track of all the received bid-relay pairs. This enables proposers to have visibility into the incoming bids with associated relays and the number of overlapping bids coming from different relays. However, the fee-recipient field in MEV-Boost is for distributing validator rewards to a designated address, usually the validator themselves. Hence the current MEV-Boost construct keeps track of the relay’s bids but does not allow payment to additional entities like relays. To enable that, there are two possible solutions:

• Modify MEV-Boost to enable adding an additional fee-recipient for relays. Also need to add necessary logic to determining the fee distribution mechanism, such as First-Come-First-Serve or equal splits among relays who handled the winning bid. However, going down this route would require Herculean effort in updating the MEV-Boost across the existing validators in PBS and is not realistic from the incentive alignment point; it makes little sense for validators to update their client so that they can get charged a relay fee.
• Validators opt into PEPC/Eigenlayer where they commit to relay fee payment, e.g. % of the highest bid. This approach does not require much coordination but might be ineffective in delivering meaningful relay revenue. Validators may opt-in due to public good but have to bear the slashing risk, which clearly doesn’t align with the validator incentive. Regardless of whether having MEV-Boost modification or not, real-time payment by validators requires opt-in from thousands of node operators, and many may not choose to do so due to the reduced fee (bids) that they will receive in both scenarios.

If validators pay: Deferred payment

• Similar to builder’s deferred payment, relays can set up contracts for validators to post ETH collateral and charge the fee according to fee preferences. This will likely be an opt-in model due to the difficulty in convincing and aligning thousands of node operators (much easier done with builders with collective effort). However, this could be an extension of the builder’s deferred fee mechanism where benevolent validators could contribute to the collateral pool in addition to the builders’.

Concluding thoughts

After exploring the incentive dynamics around builders/validators and approaches for sustainable relay incentivization, a few things are clear:

1. Public good (not charging a fee) will always lead to a race to the bottom: Even if Ultrasound and bloXroute try to capture value on the latency advantages, the value capture will be forced to zero if there are equally competitive and neutral public good relays providing similar latency-optimization.

2. A social consensus among major neutral relays to pull out of public good is necessary: At least all the major relays of today (most of which are neutral) should collectively put an end to free relays and start experimenting with opting-in on proposed incentivization schemes.

3. Easier to charge builders: Enforcing validator payments requires a tremendous amount of coordination and incentive alignment across thousands of node operators. This is made even harder given that the relay revenue always comes out of a proposer’s bid revenue. Additionally, validators hold leverage over relays in that more validator registrations enables more competitive relay, thus attracting more bids from builders. Hence, I believe it’s more practical to convince 20–30 builders and try to align their incentives.

4. The tug-of-war between relay incentivization and centralization: In devising our relay incentivization scheme, we have to consider the centralization risk of the relays that emerge from latency competition. Ideally, we would want a coopetitive relay market that ensures collaborative payload deliveries for maximum liveness while still allowing monetization, which could be derived from latency advantages. It is also worth noting that the emergence of distributed block builders like SUAVE helps alleviate the need for relays as it offloads the trust overhead on txs validation to hardened TEE.

While there is much more work to be done in the quest to find the right approach for sustainably incentivizing relays, I hope that this writing can help clarify some of the under-explored incentive dynamics and technical challenges associated with the various approaches to resolving this relay incentive problem. I am also looking forward to seeing more future discussions around relay incentivization to push this initiative forward.