Notes on Flashbots PBS architecture

As the first steps of my EPF project, I want to understand how the current implementation of PBS works. And see if I can use it to propose blocks from a validator that uses a Portal Client instead of an EL client.

Flashbots architecture for MEV is the most widely used PBS implementation at the moment (September 2023). So that's what this article will be about.

I made this diagram to visualize the architecture:

You can find this diagram in higher quality here.

This infrastructure provides a way for validators to trustlessly outsource the work of building blocks optimally. The process goes as follows:

1. Searchers send their transactions to builders. The searcher can choose which builders they send their transaction to.
2. Builders arrange the most profitable possible block from the transactions they receive.
3. Relays:
   • Accept new blocks from builders.
   • Send the header of the most profitable block to the validator.
     • The validator locks their commitment to propose that block.
   • Send the full block to the validator.
4. The validator receives the full block from the relay using MEV-Boost and proposes it to the Ethereum Network.

As I want to focus on how to propose blocks, I need to go deeper into steps three and four, and properly understand how MEV-Boost interacts with relays and the CL client.

Fortunately, there's an article dedicated exclusively to this on the Flashbots docs.

"MEV-Boost Block Proposal" by Flashbots, used under CC BY 4.0 / Source

Now is a good moment to mention the Builder API. "The Builder API is an interface for consensus layer clients to source blocks built by external entities." This is the spec that MEV-Boost and MEV-rs have to follow to enable validators to propose blocks built by someone else.

Going back to the diagram, I did some research on the functions that are called when proposing a block:

• registerValidator
  • Builder API endpoint.
  • MEV-Boost implementation.
• getHeader
  • Builder API endpoint.
  • MEV-Boost implementation.
• getPayload
  • Builder API endpoint.
  • MEV-Boost implementation.
  • There's also a function called processCapellaPayload.

Taking a step back

While learning about this, I realized that I needed to take a step back. The endpoints described in the Builder API are exactly what I was looking for. They describe how to propose a block built externally. But there's something I wasn't paying enough attention to:

You need to be running a full EL + CL combo to run MEV-Boost.

This means that even if I manage to implement the Builder API on a Portal Client, I'll need to run a full EL client besides it, beating the whole purpose of my project.

So, I'll have to just go ahead and start researching how to implement the Engine API on the Portal Clients.

Some final thoughts

I'm not sure about this, but I'll mention it for future reference:

I think the reason you need an EL+CL combo running for MEV boost is that the CL client won't start unless it has an EL client to connect to.

This means that there might be a minimal set of Engine API endpoints I can implement just to start the CL client, and then run MEV-Boost (or maybe, import mev-rs to Trin) to fill the missing endpoints.

There is a minimal set of Engine API endpoints I can implement just to start the CL client, and then run MEV-Boost (or maybe, import mev-rs to Trin) to fill the missing endpoints.

This would have the nice side effect of solving the problem I mentioned in my project proposal: not being able to test Lighthouse without running my own EL node.