Thread
Everyone is talking about the merge, but what does it actually look like?
And how will Flashbots' MEV-Boost soon play a huge role in Ethereum? Quick thread
And how will Flashbots' MEV-Boost soon play a huge role in Ethereum? Quick thread
Today you run one monolithic client (e.g., Go Ethereum, Nethermind, etc.) that handles everything. Full nodes do both:
1) Execution - Execute every tx in a block to ensure validity. Take the pre-state root, execute everything, and check that the post-state root is correct
1) Execution - Execute every tx in a block to ensure validity. Take the pre-state root, execute everything, and check that the post-state root is correct
2) Consensus - Verify you’re on the heaviest (highest PoW) chain with the most work done (i.e., Nakamoto consensus)
They’re inseparable because full nodes not only follow the heaviest chain, they follow the heaviest valid chain. That’s why they’re full nodes and not light nodes
They’re inseparable because full nodes not only follow the heaviest chain, they follow the heaviest valid chain. That’s why they’re full nodes and not light nodes
The Beacon Chain currently only runs consensus to give PoS a test run.
No execution. Eventually a terminal total difficulty will be decided upon, at which point the current Ethereum execution blocks will merge into the Beacon Chain blocks forming one chain:
No execution. Eventually a terminal total difficulty will be decided upon, at which point the current Ethereum execution blocks will merge into the Beacon Chain blocks forming one chain:
However, full nodes will run two separate clients under the hood that interoperate:
1) Execution client (f.k.a. “Eth1 client”) - Current Eth 1.0 clients continue to handle execution. They process blocks, maintain mempools, and manage and sync state. The PoW stuff gets ripped out
1) Execution client (f.k.a. “Eth1 client”) - Current Eth 1.0 clients continue to handle execution. They process blocks, maintain mempools, and manage and sync state. The PoW stuff gets ripped out
2) Consensus client (f.k.a. “Eth2 client”) - Current Beacon Chain clients continue to handle PoS consensus. They track the chain’s head, gossip and attest to blocks, and receive validator rewards.
Clients receive Beacon Chain blocks, execution clients run the transactions, then consensus clients will follow that chain if everything checks out.
You’ll be able to mix and match the execution and consensus clients of your choice, all will be interoperable.
You’ll be able to mix and match the execution and consensus clients of your choice, all will be interoperable.
A new Engine API will be introduced for the clients to communicate with each other: 
Alternatively: 
Ok now onto MEV-Boost
Unfortunately in-protocol PBS simply won’t be ready at the merge.
Flashbots comes to the rescue again with a stepping stone solution - MEV-Boost.
Unfortunately in-protocol PBS simply won’t be ready at the merge.
Flashbots comes to the rescue again with a stepping stone solution - MEV-Boost.
Validators post-merge will default to receiving public mempool transactions directly into their execution clients.
They can package these up, hand them to the consensus client, and broadcast them to the network.
They can package these up, hand them to the consensus client, and broadcast them to the network.
But your mom and pop validator has no idea how to extract MEV, so Flashbots is offering an alternative.
MEV-Boost plugs into your consensus client, outsourcing specialized block building.
Importantly, you still retain the option to use your own execution client as a fallback.
MEV-Boost plugs into your consensus client, outsourcing specialized block building.
Importantly, you still retain the option to use your own execution client as a fallback.
MEV searchers will continue to play the role they do today.
They’ll run specific strategies (stat arb, atomic arb, sandwiches, etc.) and bid for their bundles to be included.
They’ll run specific strategies (stat arb, atomic arb, sandwiches, etc.) and bid for their bundles to be included.
Builders then aggregate all the bundles they see as well as any private orderflow (e.g., from Flashbots Protect) into the optimal full block.
The builder passes only the header to the validator via a relay running to MEV-Boost.
The builder passes only the header to the validator via a relay running to MEV-Boost.
Flashbots intends to run the relayer and builder with plans to decentralize over time, but whitelisting additional builders will likely be very slow. 
MEV-Boost requires validators to trust relayers - the consensus client receives the header, signs it, and only then is the block body revealed.
The relayer’s purpose is to attest to the proposer that the body is valid and exists
The relayer’s purpose is to attest to the proposer that the body is valid and exists
When in-protocol PBS is ready, it then codifies what MEV-Boost offers in the interim.
PBS provides the same separation of powers, allows for easier builder decentralization, and removes the need for proposers to trust anyone.
PBS provides the same separation of powers, allows for easier builder decentralization, and removes the need for proposers to trust anyone.
For even more go check out the latest UCC podcast just dropped today with a 🐐 lineup of @hasufl @thegostep @TimBeiko and @dannyryan
Mentions
See All
Hasu @hasufl
·
May 25, 2022
Great summary!