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.
“I care about you”
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.
Let’s take a brief look at the following graph illustrating the relay’s role within PBS.
Role of the relay by Kydo
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.
PBS was originally proposed to resolve the following risks associated with proposers:
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).
OFAC censorship by Toni, see https://censorship.pics
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.
Relays Questioning Their Existence by Matt Cutler
ePBS is still being researched and has many @mikeneuder/infinite-buffet">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.
Illustrating the life of a relay
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.
So far, there are two approaches to reaching a more sustainable relay market under different assumptions.
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.
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 @KuDeTa/relay_guild_mvp">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:
So let’s explore those two questions here.
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:
Relay’s leverage over validators:
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.
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
Diagram illustrating the real-time payment by builders
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
Diagram illustrating the deferred payment by builders
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)
If validators pay: Deferred payment
After exploring the incentive dynamics around builders/validators and approaches for sustainable relay incentivization, a few things are clear:
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.
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.
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.
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.
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.
“I care about you”
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.
Let’s take a brief look at the following graph illustrating the relay’s role within PBS.
Role of the relay by Kydo
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.
PBS was originally proposed to resolve the following risks associated with proposers:
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).
OFAC censorship by Toni, see https://censorship.pics
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.
Relays Questioning Their Existence by Matt Cutler
ePBS is still being researched and has many @mikeneuder/infinite-buffet">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.
Illustrating the life of a relay
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.
So far, there are two approaches to reaching a more sustainable relay market under different assumptions.
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.
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 @KuDeTa/relay_guild_mvp">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:
So let’s explore those two questions here.
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:
Relay’s leverage over validators:
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.
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
Diagram illustrating the real-time payment by builders
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
Diagram illustrating the deferred payment by builders
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)
If validators pay: Deferred payment
After exploring the incentive dynamics around builders/validators and approaches for sustainable relay incentivization, a few things are clear:
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.
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.
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.
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.