Overview

Presently, we have support for multiple EEs in the execution_layer crate. Users specify these EEs via the --execution-engines flag.

I propose that we remove support for multiple EEs and only support a single EE.

Why

I added support for multiple EEs in the early days of merge specification in the interests of providing redundancy like we do with --eth1-endpoints on the BN or --beacon-nodes on the VC. As the spec has evolved, it's that redundancy for EEs isn't going to be the same as it is for BNs or "eth1" nodes.

With redundant BN endpoints or Eth1 endpoints, users can have another endpoint "standing by" that's ready to serve requests should the primary endpoints failed. These "backup" endpoints, in my practical experience, are some third-party service (Infura, Alchemy, etc) or another self-hosted node that's shared between many nodes. Since an EE can only be driven by a single CE, this shared-backup is not feasible. Therefore, if a user has 5x BNs and wants redundancy with EEs, they need to run 5x EEs (rather than just 1x EE with a shared backup). For small-scale setups, there's no option to use centralized services (Infura, at the very least) as backups. For large-scale setups, having redundancy for many EEs is much more expensive that for BNs or Eth1 nodes. It's clear that redundancy for EEs is less appealing economically than for the existing places that we provide redundancy.

So, the benefits of redundancy with EEs is dubious.

Another reason we might use multiple EEs is because we want to compare the results of multiple EE implementations to detect consensus faults. I'd argue this is a taks for developers, not for users.

Proxies

Interestingly, we could support multiple EEs for whatever purposes (redundancy, consensus fault detection, etc) via an external prupose-built proxy. Point Lighthouse at the proxy and the proxy at multiple EEs. This would be suitable for all client implementations and remove the complexity from Lighthouse.

Summary

Since the benefits for multiple EEs isn't as clear as the other reasons we've added multiple endpoints for other services, and we can do the same thing with an external proxy, I propose we just go with the proxy approach. Whether or not we actually implement the proxy (or leave it up to someone else) is another question.

Another point to consider is that we need to add support for MEV solutions (see #3062). This means supporting another type of EE; one that should produce but not verify payloads. Add this complexity to supporting multiple EEs and we've got ourselves quite a lot of complexity.