Given the importance of the off-chain mev-boost stack to the Ethereum protocol today, we can always spend more resources allocated to testing, security, and performance of critical software.
An idea for a proposal involves an open call to facilitate greater testing of critical mev-boost software. A full vision here is something like hive specialized for testing mev-boost, relay implementations and any common builder software deemed relevant. Such a project, say mev-hive, could run nightly builds of all software and host a suite of tests determined to validate conformance to the builder-specs and relay-specs. This software could also be extended to measure nightly performance of critical code paths to flag any regressions (cf. hive and sync tests). If this type of project is interesting to you, please reach out to us to figure out the right scope.
Along similar lines to supply chain testing, automated harness software to measure block building performance for mev-boost builder software and also consensus-execution client pairs for local building would be a very interesting proposal. A project here could take a known set of transactions (and/or bundles) as inputs and start by measuring latency to build a block and value given default settings. Block value and timings could be compared across all implementations and could highlight places that need further R&D. An example extension would look at continuous building over a set of time as transactions are injected to each builder module and a distribution of time vs. value could be generated for each implementation.
One problem surrounding testing relay software on testnets like Goerli, Sepolia, or Holesky is the fact that any new relay operator who wants to come online must also do the integration work to get sufficient validator subscription to improve the feedback cycle. A potential solution here is to write a piece of software like mev-boost that aggregates relays in some fashion where this “meta-relay” would do the work once to get many validators subscribed on a given testnet, and then any relay could slot in to this meta-relay for testing. Even a simple round-robin from proposer to each relay, routed through the meta-relay, would go quite far and obviate the need for a lot of legwork from each relay operator.
Ethereum has been quite successful following a multi-client development philosophy. However, all of this success is side-stepped in the current mev-boost ecosystem as all production relays use geth to validate incoming blocks. And the high adoption of mev-boost on mainnet today means the gains we have from a multi-client architecture at the execution layer are nullified. To help improve upon this situation, an proposal could refine and champion for the inclusion of a common endpoint all execution clients support to offer block verification. Relays can then easily swap out geth for another execution client.
This idea is further explained here: https://notes.ethereum.org/@ralexstokes/cross-el-client-builder-validation