Over 100 subscribers
bt3gl
today i go over ethereum post-merge architectural changes, how to integrate mev-boost, and the PBS && relays discussion.
*the concept of maximal extractable value (mev) was coined by the 2019 research paper flashboys 2.0, and encompasses the profits generated by participant parties when producing new blocks on a blockchain.*
since the ethereum blockchain doesn't enforce rules on the contents or ordering of a block, block producers can arbitrarily include, exclude, or re-order transactions (txs) however they want.
re-ordering txs based on the fees that senders are keen to pay (and the consequent profit generated from it) is now a multi-million dollar industry.
you can learn more about the mev supply chain dys/u-topia here.
💡 THE MEMPOOL
“every second, hundreds of new transactions appear in the public mempool”
the mempool is the ethereum memory pool, where pending new txs wait to be confirmed, i.e., validated and included into new blocks.
ethereum has a public mempool and many private mempool spaces (such as the ones provided by flashbot’s protect or rook’s coordinator).
this means that nodes and associated entities are entitled to configure their own rules for their mempool by allowing private (exclusive) order flow to txs to be included in blocks, while not visible in the public mempool.
mev-boost is paradigm’s flahsbots' open-source middleware for post-merge ethereum validators, allowing them access to a block-building free market, as an interim solution to implement the proposer builder separation (pbs) paradigm while it's not in-protocol.
remember from my previous posts that in our current proof-of-work ethereum, nodes must run three pieces of software: an execution client (e.g., geth) and a consensus client that is divided into a beacon client and a validator client (e.g., prysm).
mev-boost implements the pbs new type of auction (the slot auction) by introducing an interim new route and communication channel in the block production pipeline: the relay.
relays facilitate an honest double-sided connection between builders and proposers.
when you add mev-boost to your node, it entitles your validator (the block proposer) to sell their blockspace to a new primitive, the block builders.
builders create blocks containing transactions (txs) order flows and optimizing for mev extraction (consequently increasing your validator revenue for producing new blocks).
it’s cool that flashbots created mev-boost, and it’s compatible with all the consensus clients. validators can now earn more from the blocks they propose. solo stakes are now on equal footing through relays.
at this point, without mev-boost, validators only have two alternatives:
to get blocks from their execution client, restricted by only tx coming from the ethereum public mempool.
implement their own builder, but also restricted to the public mempool.
if we care about the self-sovereignty ideals brought by ethereum, we probably want to diversify all the things and move away from any herd mentality.
proposer builder separation (pbs) is a proposal to the ethereum core protocol to mitigate centralization risks by mev extraction from vertically integrated block producers in a proof-of-stake world (i.e., parting from miners to validators), by introducing a free market for two entities: block builders and block proposers.
in the pbs paradigm, block builders would produce complete blocks with a fee for the validator (the block proposer), which simply picks the ones with the highest fee. in the middle, a trusting relay guarantees integrity from both parties.
for instance, node operator groups connected to large staking pools (such as lido, rocket, etc.) could be incentivized to hide the value of a block and keep the fees. however, with the competition brought by this new open market, this problem dissolves as block builders maximize their block bids and validators maximize their blockspace bids.
lastly, pbs is also a needed step for the ethereum sharding proposal.
in the post-merge block open market, validators can outsource block building to specialized parties, fetching the most profitable blocks from in-between relays, and proposing their inclusion to the ethereum network.
remember the drill for validators: for each of the 32 slots in an epoch, validators are pseudo-randomly assigned to either propose blocks or attest those proposed by other validators.
with mev-boost, validators can opt between receiving and proposing a block from its execution client, OR receiving an execution payload header from relays and blindly signing these escrowed txs.
block builders are providers that aggregate bundles and txs order flow (execution payloads) into block that are forwarded by relays to validators.
ethereum.org has provided the API specifications for external builder nodes, so validators can delegate block-building duties.
thus, block builders can now specialize: as they prepare full blocks they can optimize bundles for mev extraction and distribution (profitability is measured by: fee per gas used, priority fee, and validator payments).
💡 BUNDLES:
bundles are one or more txs that are grouped together (batched) and executed atomically in the order they are provided.
they were introduced by flahsbots’ auctions as a message to a new RPC endpoint,
eth_sendBundle, that includes a signed array tx and metadata.can you speak code?
sure, here is an example in python for two txs, from a previous post:
tx1: TxParams = { "to": receiverAddress, "value": Web3.toWei(0.005, "ether"), "gas": 21000, "maxFeePerGas": Web3.toWei(300, "gwei"), "maxPriorityFeePerGas": Web3.toWei(50, "gwei"), "nonce": nonce, "chainId": CHAIN_ID, "type": 2, } tx2: TxParams = { "to": receiverAddress, "value": Web3.toWei(0.005, "ether"), "gas": 21000, "maxFeePerGas": Web3.toWei(300, "gwei"), "maxPriorityFeePerGas": Web3.toWei(50, "gwei"), "nonce": nonce + 1, "chainId": CHAIN_ID, "type": 2, } tx1_signed = sender.sign_transaction(tx1) bundle = [ {"signed_transaction": tx1_signed.rawTransaction}, {"signer": sender, "transaction": tx2}, ]and here is a cute dashboard explorer for bundles.
searchers (or keepers or solvers) are bots managed by trading parties running sophisticated strategies to capture mev (such as front-running, tailgating, liquidation, or arbitrage).
with mev-boost, mev bots need to optimize their strategies for two auctions:
blockspace auction: the competition for bundle inclusion within blocks that builders are proposing.
slot auction: the competition for their block produced by their builders to be included on-chain.
thus, mev bots need to make several choices when sending their bundles through mev-boost:
choose block builders that are performant and trustworthy.
choose block builders with less searcher competition to reduce the chance of being outbid in the blockspace auction?
choose block builders that accept txs from profitable searchers, improving the chances of block inclusion to the chain (as the block might be more worthy from transaction fees and mev)?
bid for the blockspace auction AND the slot auction (via validator’s coinbase) to increase the chance that the block is included?
work with multiple builders as opposed to one?
💡 THE VALIDATOR’S COINBASE:
mev bots can pay validators for txs by triggering the coinbase evm opcode
block.coinbase.transfer(amount).to process their payment, builders either set their address as the payload's coinbase and append a tx to the validators’s
feeRecipient, or set this field as the coinbase address of the payload.
relays provide block escrow as the interim trusted router between proposers and builders, aggregating and verifying blocks (execution payloads) from multiple builders to select the block with the highest fees for the proposer.
relays are in charge of validating and forwarding blocks, checking whether the block txs and attributes exist, the gas is within the validator’s gasLimit, and the fees are correct on feeRecipient. flashbots have provided two endpoints for relay block submission, getValidators (GET) and submitBlock (POST).
💡 SLOT COLLISIONS:
collisions might occur when more than one relay pushes the payload for a slot.
for instance, if a block is the most profitable block for multiple relays, these relays would return that block during a
getHeaderrequest for a slot.
since searchers do not have to pay for failed bids (again, they can use the coinbase address directly), they could spam the network with invalid bundles.
relays could help mitigate denial-of-service (dos) threats by implementing priority queues, reputation scoring (e.g., flashbots’ or rook’s), or small stakes from builders before allowing them to submit blocks.
however, would this open the gates for censorship?
in our post-merge ethereum, until pbs is incorporated into the network protocol, relays should intercept a significant part of the blocks that are produced.
the trusting value that relays carry is pretty obvious. apart from infrastructure challenges (e.g., hasu talks about liveness risk here), censorship is kind of a big thing.
as part of the pbs proposal, censorship resistance lists (crlists) are designed to prevent builders from censoring users. in response, flashbots has introduced a crlists discussion for mev-boost.
flahsbots provided a relay api spec, and has open-sourced its relay golang code after some centralization polemic. Blocknative also open-sourced theirs.
however, at this point, probably because incentives to run an honest relay are unclear, there are only five relay groups available (flashbots, blocknative, manifold, bloXroute, and eden), and a promising one coming soon?
some data on relays and builders regarding number of blocks, total value, and network participation can be found in the mevbost.org dashboard.
on top of the relay scarcity, the current relays still show some weird hiccups:
and the OFAC polemic (the “office of foreign assets control”, a financial enforcement agency of the U.S., which was responsible for sanctioning tornado cash; more info at mevwatch.info):
other somehow related initiatives:
flashbots released a mev-boost transparency dashboard of metrics related to their relay and builder since the merge.
here is a discussion by ethereum.org to complete privacy for mev-boost and another on privacy concerts with flashbots data api.
flashbots says they are working on a relay monitor to track performance.
there is really a lot to build…
okay, we are now ready for some terminal action.
from the discussion above, you know we have only five options to choose from.
how to pick? 🤷🏻♀️
here is a tool that can help with some relay info and stats:
let’s go back to our local setup from 🥓✨ run your own goerli validatooor and add a fourth terminal window for mev-boost.
💡 RUNNING YOUR NODE IN PRODUCTION:
our local setup was proposed as an introduction to running your own ethereum nodes. as you advance, you might want to change your deployment design for each layer by: creating config files, configuring systemd/launchd, containerizing with docker, moving everything to a cloud service, getting specialized hardware, etc.
if you need help in this step, keep an eye on my github resources (as i am planning to open-source at some point my docker + terraform + kubernetes game, and other scripts and configs).
let’s go ahead and install mev-boost. make sure you have golang installed, and then follow mev-boost’s README.md:
go install github.com/flashbots/mev-boost@latestnow, let’s connect our goerli node to our favorite relays(s) through the default port 18550. note that multiple beacon clients can use a single mev-boost instance.
./mev-boost -goerli -relay-check -relays relay1,relay2the --relay-check flag checks the status of relays (returning error for any problem). if you are using flashbots relay on goerli, here is their dashboard.
success:
now let’s start routing our beacon node through mev-boost by connecting it to localhost:18550.
for prysm, this can be done with the flag --http-mev-relay=localhost:18550. for other consensus clients, check this list.
our prior setup would now be:
./prysm.sh beacon-chain --prater \
--execution-endpoint=http://localhost:8551 \
--jwt-secret=/Volumes/<ssd name>/keys/jwt.hex \
--suggested-fee-recipient=<your wallet address> \
--db-backup-output-dir=/<ssd name>/ethereum/consensus \
--datadir=/<ssd name>/ethereum/consensus \
--http-mev-relay=localhost:18550
in the case of prysm, all you need to do is add the —enable-builder flag to the original command:
./prysm.sh validator --goerli \
--wallet-dir=/Volumes/<ssd name>/keys/wallet \
--suggested-fee-recipient=<your wallet address> \
--graffiti="<some cool message that does not identify ya>" \
--enable-builderif you see "Retrieved header from builder Retrieved full payload from builder", celebrate victory 🏆.
mev-boost is independent of any execution layer client, so nothing to do here, anon.
this is how it looks like after the setup above:
