The Impact of Optimistic Relaying on Builders
By: Eyal Markovich, Co-founder & COO
Optimistic relays are the latest trend in the MEV-Boost ecosystem. Frontier Research published a good article to cover the optimistic relay landscape. In this post, I want to explore a small observation that is affecting builders who are using a mix of optimistic and non-optimistic relays.
Optimistic relays increase builder inclusion rates by skippings the block simulation, which is a major bottleneck. This allows the relay to return the highest block value received, even if the get_header request from the proposer comes in immediately following the block submission time.
For example, suppose a relay receives a block (b1) worth 1eth from a builder at time t0. If the proposer requests the bid at time t1 (where t1 > t0), without optimistic relaying and assuming 200ms for block simulation, the relay will only return b1 if t1 is greater than t0+200ms. However, if optimistic relaying is used, the relay will almost always return b1, even if the request is made immediately after t0.
Optimistic relays are beneficial to builders as it improves their chances of success. However, we must also consider block replacements. While not part of the protocol, most (if not all) relays will use the latest block from a builder. If a builder sends block (b1) and later block (b2), and if both b1 and b2 are the best two value blocks at the time of get_header, the relay will return b2, even if its block value is lower than b1. Builders expect this behavior from the relay, and there is a potential risk if the relay does not follow it.
Working with mixed-type relays comes with some potential risks too. For instance, if a builder sends block b1 to two relays, one with optimistic relaying and one without, and later sends block b2, the second relay may return different blocks depending on their validation process. If the relay has not completed validation by the time the get_header request is made, it will return b1, even if the builder is expecting it to return b2. This could result in the builder losing money.
Let’s consider an example. Assume a builder sends b1 (1eth) to two relays at time t0, one with optimistic relaying and one without. At t1, the builder is sending b2 (0.5eth) and expects the relays to return b2. If the get_header request arrives at t2+100ms and relay2 hasn’t completed validation, the second relay will return b1 and win the auction. In this case, the non-optimistic relay benefited from the optimistic relay’s immediate deletion of b1, allowing the non-optimistic relay to win in the 200ms simulation period.
In conclusion, builders must carefully consider the risks and benefits of using mixed relays and choose to use mixed relays if the value added from non-optimistic relays is higher than the added risk.
