Week 1 Notes - HackMD

# Week 1 Notes ## Understanding liveness risks from mev-boost https://writings.flashbots.net/writings/understanding-mev-boost-liveness-risks/ Mev-boost middleware that validators run to outsource block construction to a market of block builders Between builders and validators sit "relays" In charge of facilitating smooth commerce between the two parties Relay protects the builder from leaking any info about the block to the validators Ensures that even small validators can participate in the builder market Relay protects the validator from receiving blocks that are Invalid Overstate bid to validator missing entirely Relays can connect to one or more builders Relay connected to many builders will aggregate bids Relay can see all the blocks submitted by the builders to confirm their validity and how much they pay to the validator Relay then only submits the highest valid bid to the validator to sign mev-boost just a relay aggregator or a local relay or relays Will serve validator winning bid from all relays If mev-boost has no relays or all relays are offline then beacon node will always fall back to constructing a block from the public mempool Risks -> Withholding Attack * Entire network connects to the same relay And * That relay is the highest bidding relay, so its block is selected by validators And * The relay sends the block header for signing (not offline) but after receiving the validators signature does not publish the final block to the network Same relay would keep suggesting blocks to validators, and these validators would keep signing them and no block is published Results in series of empty slots Liveness Issue Network not making blocks Different from DDOS attack Affected nodes still fulfill all of their other network duties Withholding attack can cascade into a liveness issue for the entire network Malicious relay can lie about its bid to guarantee it is always selected by all validators that register with it Malicious relay bidding an artificially high number that is higher than that of honest relays Attack is free for the relay because it never publishes the block and pays the validator Yet all affected validators miss their slot for proposing Only concerned about relay that creates systemic network risks If 10% of validators miss their slot, their problem If 100% of validators miss their slot, it is Ethereum's problem. Solution System Recovery 1.) Validators remove the faulty relay from their mev-boost config Or 2.) Other relays start outbidding the faulty relay Or 3.) The faulty relay goes offline entirely Or 4.) The faulty relay starts publishing blocks again 3 & 4 are within the control of the faulty relay 2 is in the control of the other relays Validators are only interested in solutions that let us remove relays once we realize they are faults Local Solutions: Most simple Validator can track the performance of the relay If relay misrepresented payments or didn't publish blocks Validator can remove it Has local information Solution protects a single validator from a bad relay, but the next validator doesn't know about the bad relay For large relayers that have good snapshot of network not to bad, for small relayers with 1-2 builders bad Validators need to know how the relays performed *on the slots of previous other validators* Global Solutions: Validators look at global history of the network not just their own The community is building two global solutions ahead of the merge Relay Monitor Watches the global performance of relays and can send a message to validators to remove relay If relayers misbehave all validators who connect to the relay monitor will have their configs updated Risks Since mev-boost default (w/o listed relays) is beacon chain Relay monitor can only temporarily remove relays from a validator's config. not add new ones cause validators to miss any slots Circuit Breaker Similar to relay monitor but does not rely on 3rd party service Part of beacon node Looks at the local view of the network and if node sees x out of y missed slots in a row Will disconnect from the builder network and fall back to producing blocks locally Nuance about picking a good number for x because a small number would allow a large validator to miss slots on purpose to trigger the circuit breaker for the rest of the network and turn off their mev-boost Large number could lead to many missed slots in a row Why Commit-Reveal Design In previous (Stage 1 PBS) version block builders send full blocks to validators in cleartext, and validators have to open a DOS-sensitive RPC to block builders Validators can always look @ block to verify that the block is valid and how much it pays the validator. If no builder sends a block in time, the validator can fall back to local block construction and there is no risk of ever missing a slot Disadvantage: Block builders need to trust validators not to steal MEV from them, and validators need to trust block builders not to DoS them. Consequence: Only trusted validators and builders can participate in the PBS market Would completely cut off solo stakers from MEV extraction Community decided against Current commit-reveal scheme has issue Relays can fail to release blocks after making the winning bid. ## Proposer & Block builder separation-friendly fee market designs https://ethresear.ch/t/proposer-block-builder-separation-friendly-fee-market-designs/9725 Normal PoS regards egalitarian, single validators earn same rate of return as powerful pools Significan economies of scale in finding sophisticated MEV extraction oppurtunities Pool that is 10x bigger will have 10x more opportunities to extract MEV but will also spend more effort on making proprietary optimizations to extract more out of each opportunity. Best Solution PBS Instead of the block proposer trying to produce a revenue-maximizing block by themselves, they rely on a market where outside actors (block-buiilders) produce bundles consisting of complete block contents and a fee for the proposer Proposer choice is reduced to picking the highest-fee bundle, and algorithm so simple that in a decentralized pool it can even be done inside an MOPC to prevent cheating Desired Properties Untrusted proposer friendliness: Minimal or no risk that a proposer will screw over a block builder so block builders have no incentive to prefer proposers that have some off-chain reputation or personal connection to the builder (would favor large pools) Untrusted builder Friendliness: minimal or no risk that a block builder will screw over a proposer, so proposers have no incentive to favor builders that have some off-chain reputation or personal connection to the proposer Would make it harder for new builders to enter market Weak Proposer friendliness: Mechanism should not require proposers to have either high bandwidth or other computational resources high technical sophistication Bundle Un-Stealability: Proposers should not be able to take bundles proposed by block builders and extract Tx from them to make their own bundles Prevents the block-builder from earning a profit Consensus-layer simplicity and safety: Mechanism should continue to be safe and ideally be covered by the same analysis as the existing block proposal mechanism from a consensus-layer perspective Idea 1: * Block builders make bundles and publish the headers of the bundles that they create A bundle contains a commitment to the bundle body (intended block contents), the payment to the proposer, and a signature from the builder * The proposer chooses the bundle header offering the highest payment (considering only bundles where the builder has enough balance to actually make that payment) They sign and publish a proposal containing that bundle header * Upon seeing the signed proposal, the block builder that offered the included bundle header published the full bundle The fork choice rule has the ability to make one of three judgements Different from normal two ( block present/block absent) Block Proposal Absent Block Proposal present and bundle body absent Proposal still becomes part of the chain Crucially, the block builder's payment to the proposer still processes ( but the block builder does not get any fees or MEV themselves) Block proposal present and bundle body present Analysis 3/5 properties assembled * The proposer receives the promised payment unconditionally, so bundles can't screw over proposers * All three steps are very automated and low-bandwidth, satisfies weak-proposer-friendliness * The proposer cannot see the contents of the bundles that they are signing, so this satisfies bundle un-stealability Design changes how fork choice works, (3 options instead of 2) Proposer is also no longer the last actor in the game If fork choices are capable of making decision, the this should be fine Still significant change with potential unknown-unknowns Proposer does not see bundle contents and cannot screw over the block-builders by bundle-stealing Can use more subtle attack Proposer can publish their proposal near the end of a slot, ensuring that attesters (probably) see the proposal on time, but not giving the block-builder enough time to publish the body, so there would be a significant chance that the attesters do not see the body on time. Imposes risk on block-builders & gives them an incentive to favor trusted proposers Creates an oppurtunity by which a malicious majority can heavily penalize block-builders that it dislikes Two mitigation approaches: * Attesters have 2s delay between the max time at whic they accept a proposal and the maximum time at which they accept a body. Solves issue if you trust the attesters Fundamental issue that block builders have a risk of losing funds still remains. Not clear that voting in this way is incentive compatible for attesters. Coule force them to wait by requiring them to attest to a 2-second-long VDF solution to proposal * If a body does not get included, the proposer only gets half the payment (block builder only pays half) Makes griefing proposer costly but ensures griefing by the block builder continues to be costly Honest behavior (builder: 0.05, proposer: 1) Proposer/attester publishing late leading to header-only block being accepted: (-0.5, 0.5) Idea 2: * Block builders make bundles and publish the headers of the bundles that they create. Bundle contains a commitment to the contents, the payment to the proposer, and a signature from the builder * The proposer chooses and signs a statement consisting of the list of bundle headers that they've seen * Upon seeing that statement, the selected block builders publish their corresponding bodies. * The proposer chooses one of the bundle headers from the list they've pre-committed to, and published a proposal with it. Analysis: 3/5 properties Proposers cannot steal bundles because they only see any bundle bodies when they've already restricted themselves to a finite set of existing bundle headers No possibility of the builder-to-proposer payment happening without the full body being included, so proposers cannot cheat builders economically either Consensus properties are the same as before, because the system is still a proposer-moves-last game and there's no change in what the consensus rules are deciding on Harder to ensure Weak-proposer-friendliness Untristed-block-builder-friendliness Concern is that malicious block builder can attack proposers by making a large number of proposals that all offer a very high fee, but never publish the body of any of them If proposer has a cap on how many bundles they accept, then this attack can price out all of the legitimate bundles Leave proposer with no bundles that they can legally include in their block If no cap on # bundles a proposer can accept risks an unbounded number of full bundle bodies being sent to the proposer Overwhelming amount of bandwidth Solution: Rate-limit bundle header submission in some way that is not a hard limit Fee for submitting bundles which is adjusted through some EIP-1559 mechanism to target rate Deposit requirement for being a block builder with rule that if you publish a bundle that does not get included when a lower-priced bundle did get included, you cannot submit bundles for the next N-slots Fee itself could be changed in the case where your bundle does not get included but a lower-priced bundle does Evidence you or proposer may have acted maliciously Similar to ENS auctions %0.5 loser fee to discourage people from making bids when they are clearly not going to win just to force up the amount that the winner has to pay These fees introduce trust requirement for proposer so they need to be done carefully and the penalty for failing to get a bundle included cannot be too high Alternate Solution: Allow free and unlimited bundle body publication, but limit body propagation at network layer Add slight delay for the minimum time at which bundle can be propagated 0s for highest-paying bundle 0.2s for the second-highest-paying bundle 0.38s for the third-highest-paying bundle $2 * (1-0.9^{k-1})$ s for the k'th highest paying bundle Add rule that a node does not propagate a bundle body if it has already propagated a higher-paying bundle body Can use together slight fee to reduce the expected # of bundles, then use network-layer mechanisms like this to reduce bandwidth requirements further Conclusions Idea 1 conceptually simpler but introduces risk to the block builder as well as more complex fork choice rule requirements. Idea 2 simpler from fork choice & consensus perspective, but has challenges dealing with malicious block builder DoS. Comments ## Beginner's Guide to mev-boost https://writings.flashbots.net/writings/beginners-guide-mevboost/ mev-boost = iteration on Flashbots auction Compatible for PoS Eth Flashbots Auction [](https://i.imgur.com/Tr7pnKD.png) Private Tx Pool -> mev-relay Sealed Bid Blockspace Auction Mechanism -> mev-geth mev-geth introduces new RPC endpooint `eth_sendBundle` the message sent to this endpoint Allows miners to outsource the work of finding the optimal block construction Bundles consist of one or many Tx to be executed in atomic batch sent by searcher -> relay -> miner Searchers Eth users who prefer to use FB private Tx pool over regular p2p pool Monitor state of the chain and send bundles to the relayers Searchers can express their bids for inclusion via the ether gas price, or by direct eth transfer to the miner's coinbase address So not have to pay for failed bids Can make payment conditional on bundle success Relay bundle propogation service that receives bundles from searchers and forwards them to miners In charge of validating and routing bundles serves as a mitigation to this DOS threat Since searchers do not have to pay for failed bids Potential they could spam the network with invalid bundles Serves as a mitigation to DOS threat Will simulate each Tx and only forward valid bundles to the miner Miner/Block Producer Party who ultimately collects all the bundles and produces a block Geth: Miners greedily order Tx by gas price Miners participating in Flashbots run mev-geth Miners evaluate incoming bundles using the first-price sealed-bid auction and pick the most profitable bundles to place at the top of the block Node compares the Flashbots block to a normal block and begins mining on the most profitable Flashbots bundle information allows the searcher to express blockspace preferences relative to the state of the chain state of the Tx pool Before Flashbots the only way for searchers to express their preference for transaction placement was via the gas price This led to competition in gas price for Tx that needed to be first in the block For Tx that could be anywhere in the block, bidding on gas price might be ineffective Miner can evaluate all bundles received and combine those which do not conflict in order to produce the most profitable block Miners have full access to bundle content and could arbitrarily reorder/steal/censor bundles sent to them by searchers and relayers Incentivised to comply Flashbots monitors misbehavior and removes miners who Flashbots Auction decoupled placement from gas price Enabling price discovery for discrete MEV oppurtunities instead of competition for priority PBS Uncontrolled MEV extraction promotes economies of scale that have a centralising effect Also causes complications to decentralized pooling Instead of the block proposer (validator) also trying to produce a maximally profitable block by itself, it can outsource this process to a block building market Block builders would produce bundles consisting of a complete block and a fee for the proposer Proposer just has to pick the block with the highest fee Desired properties Untrusted proposers and builders should be able to participate successfully little to no risk that a proposer would steal blocks from a builder Proposers are not advantaged by having high resources or technical competence Proposers cannot extract Tx from bundles without paying the fee New design works with the existing consensus layer MEV-Boost [](https://i.imgur.com/IHBYVhq.png) Searchers take Tx from the public mempool/add own and arrange them into bundles Private/Exclusive orderflow Tx included in blocks but not visible to public mempool Tx are sent to certain entity and may route these Tx to their own nodes or keep secret in order to build more profitable blocks for themselves Block Builders Services/providers that will aggregate various bundles and Tx into block templates Builder orders Tx in a block according to what is most profitable for them Block Templates then forwarded to relay Relay receives block templates (execution payloads) and will verify their validity MEV-Boost component is a middleware which handles communication with the relays, the profit-switching logic, and a fallback mechanism in the case of some system failure Splitting block proposal and block building has desired effects for protocols goals removes the requirement for validators to hold the full state (stateless Eth initiative) PBS necessary for DankSharding