I want to start this by saying I get stuff wrong sometimes and absolutely welcome corrections, just don't be rude about it. Reach out on Twitter to @CryptoNymph if you want to discuss this or I get anything wrong. I'll make and announce corrections going forward. Also, I'm really just rambling about this to help me understand because that's how I learn best. A lot of this is just restating (probably less clearly and concisely) what @thegostep said in the original ethresearch post at: https://ethresear.ch/t/mev-boost-merge-ready-flashbots-architecture/11177

Architecture Diagram: The steps start with users sending "private" (with a trusted builder) txs and searchers sending bundles to the block builder which merges bundles and txs to create optimal block constructions and send payloads to a relay. Interesting that this role of bundle merging and execution payload building is separated (I think) from the relay as opposed to how the current FB Relay handles this from submitted bundles. I hope they open source (maybe they already have? idk) the bundle merging logic and we can have an optimization arms race. This separation is a nice step and deals with a centralization point in the relay architecture.

Moving on, these payloads containing the state transitions to be updated based on the block being built get sent to a relay, which verifies the validity of the payload and provides the payload header and value to validators, which select based on the most profitable for them before signing and sending the header back to the relay as well as to the escrow. The escrow is an actor that receives all payloads from the relay and propagates out to the network. They mention the future removal of relays and escrows which I think will be really interesting because there are obviously trust assumptions introduced at these points in the system (relays must be trusted by builders and proposers (validators) and escrows must be trusted by the relay to keep payloads private to avoid validators knowing the content).

This last trust assumption, imo, is worth it in the meantime because of the ability it grants to keep the execution payload content private from validators the are selecting based on their profit and committing to a header, after which only the content of that header can be executed. This is the fabled Proposer Builder Separation that enables trust assumptions to be dispersed around the network rather than funneling into the final miner role as they do now where the separation does not exist. Even if you trust say the Flashbots RPC there is still the chance that a miner can include their own transactions to abuse their information (though not for free since 1559 added a base fee). This separation is also important because it allows a greater level of specialization, though it is still possible for an actor to participate as both (they just can't be both at the same time unless they get really lucky). I think the Single Secret Leader architecture that Vitalik has mentioned (https://www.reddit.com/r/ethereum/comments/m9j5cy/singlesecretleaderelectionprotocols/) will be how this ends up getting dealt with. Only the proposer will know when they are going to propose and if there will be an anonymous bounty (from slashing them) for revealing to another party.

I don't really understand where the incentives to run a relay or escrow come from to be honest. Users want their txs processed, searchers make profit from their bundles being executed, builders take a portion of the fee that gets given to validators for block inclusion. The relay and escrow roles seem to lack any value accrual in the system, as far as I can see, so I don't understand why someone would perform these roles (I say as someone who runs a full node just because). This of course ultimately won't matter because they plan to remove these roles from the architecture.

Moving on again, they go on to detail process flow for block proposal with their new independent middleware MEV-Boost. This sits between the consensus and execution clients and allows communication with the relay to receive payload headers. When relays are unavailable, validators can fall back on the traditional architecture of local payload construction but otherwise can receive from the payload to outsource execution and further create room for specialization as well as introduce PBS. Notably it's possible that a client that exclusive relies on outsourced execution and just can't propose when relays are unavailable could arise. This would enable some low performance hardware to be able to more easily participate in the network. Due to this being implemented as independent middleware, there is minimal modification that needs to be done to client architecture and it is a client agnostic architecture, which from a centralization standpoint is an improvement from mev-geth dominating the network (as much as I love it).

They list a succint and specific set of changes that are required for client integration and mention that they will help teams to make them. These are: - enabling the validator to include and sign execution payload header in beacon blocks instead of full execution payloads - enabling the validator to sign prefixed messages using the staking keys for authentication purposes - enabling the consensus client to route a signed beacon block back to the middleware instead of attempting to send to the network - enabling the consensus clients to fall back to a local or remote execution client if there is a fault in the middleware

Lastly, they mention that most important security point is the trust and the mechanism around identifying situations in which a malicious relay is present is crucial for this system to be byzantine fault tolerant. Either the payload must be pre validated by multiple parties before sending to the validator or all validators need to be able to identify a bad payload and fallback to a safe alternative (local payload construction). This mechanism needs to be robust in the face of adversarial situations where relays attempt to sabotage each other (traditionally through DoS).

I'd like to spend some more time thinking about the security mechanism and attack vectors here but going over this has helped to cement what's going on in my head so I can do that. I'll be keeping my eye on this, I really love the separation of roles being a running theme in execution and consensus.