Post-Merge MEV (Breakout #16)

Transcript

okay uh we are recording uh welcome to the post merge mev uh breakout room uh stefan's gonna walk us through the proposal architecture uh some demos and then we have plenty of time also for questions comments conversations uh from the different client teams uh yeah again this being recorded if you're not interested in that please jump off now uh we'll have full notes and record it available for people who want to watch later um yeah over to use the phone awesome um yeah thanks everyone for for showing up um so brief agenda i'll just cover some of the basics of

uh what we're trying to achieve with mev boost how it fits within sort of the transition from the current med geth how it works on the network today and and where we want pbs to go um and then i'll try to get into some of the the technical overview of how it works i'll cover some of the the milestones and and how we plan to implement them um then probably do a quick demo of what we have with merge mock running right now jason if if he sure would be the right person to jump on and buy that demo um and then yeah we can go into discussion and i've listed in here sort of the the open remaining questions to uh to um they need to be figured out over the

next couple months [Applause] okay without further ado let's jump into it so i'll just assume a good amount of background knowledge on of geth if you don't uh quite understand how the system works definitely go check out docs.flashbots.net it has uh sort of a good description and highlight of how it works but basically right it's a block space auction it allows for outsourcing parts of the job of block construction to uh basically anyone in in the network and uh and the way that it works today is uh with sort of this intermediary uh that's a relay that aggregates um uh transactions as well as bundles which

are like fractions of blocks um filters all the like spam all the invalid stuff and then forwards them over to um to the minor um you know it's working right it achieves sort of the goals that us set out to achieve which is uh providing a block space auction mechanism uh but it's by no way perfect um so i've just listed here some of the properties that um that we're looking to improve upon for with my boost and with with pbs so the first one is um full block bids so right now right it only accepts bundles but that doesn't allow for expressing sort of the full range of

um of types of med that can be extracted or really preferences on the the order of transactions um and so switching over to a system that is able to send full payloads right in the in the proof of stake context sort of addresses this this issue another component is solo sticker participation um so right now the way that medgath works we're sending all the transactions over to the miner in cleartext so the miner has a view of all the transactions that are coming in and really we're relying on a trusted relationship between the relay operators and the miners um to prevent the miners from sort of uh

stealing those transactions or you know dropping censoring those transactions inserting their own uh et cetera and the goal is to move away from uh from this because it restricts the ability of solo miners to participate in this so i've got today right there's really only mining pools that are participating and and only mining pools with a with a significant history of participation in the network um but uh we want to move towards a model where anyone can sort of just connect their their proof-of-stake validator node as long as they have you know the 32-each stake they're able to connect to the system and start receiving payloads so to do that we want to withhold sort of the content of the

transactions not reveal them and instead only forward over to the validator the header so we have it sort of noted here as the validator gets the payload header from the relay and then it's able to return this this signed header so yeah this allows for the soil sticker participation uh but it also sort of adds an additional um sort of trust assumption on on the way that the relay operates um third component or third design criteria that we had was client diversity um it's kind of in the name right like medgath was built um

baked in directly into into the geth client um whereas for uh proof of stake we want to really um help contribute to the to the the drive for for client diversity and so uh met boost moves a lot of the um of the logic to an independent uh middleware um so this diagram sort of shows right the components that we're already familiar with the boundary client the beacon node and the execution client uh meth boosts sort of slots itself in between here as as a middleware and interfaces with both the execution clients and and the relays for performing uh block construction

duties um and then yeah we can talk a bit about the the trade-offs are involved in here so um complete privacy and trustlessness um ideally we want to move towards a world where um the the builders or the the transaction initiators don't need to trust anyone when they submit the transactions and they're guaranteed to be sort of private or at least unknown until they're included into a block and propagated to the network here there's sort of a an asterix because it does improve the condition over the way that mev guest works because the validators don't see the content of the

transactions but it still relies on relays as uh sort of being um uh uh actors that that aren't as you know uh profiting from the uh from the content of the transactions that it receives uh so um that's a property that only really gets removed in the full pbs at the protocol level where um we're able to remove the the relay component completely and the builder can communicate a payload without revealing its content to to any third parties and then yeah trustlessness sort of works in the same way but this is really from the validators perspective which is under the boost

formulation of um of the separation um the validator uh sort of receives a relay from receives a payload from the relay and uh signs it without really making sure that it's a valid payload and instead it trusts the reputation of the relay not to produce an invalid payload and it's up to further validators in the network so you know validator is our future slot tenants to evaluate to see if the relay was acting malicious or properly and make sure that the the payload that was proposed by the relay wasn't a bad one and if it was make sure not to to accept payloads from that relay anymore

so again in other asterix there's some improvements to the way that the trustlessness work but it's not as good as it could be under a full uh pbs format um yeah i'm tempted to pause here see if there's any thoughts questions comments before i dig into the rest of the presentation okay cool um yeah maybe i'll try to keep an eye on the chat as well if uh if anyone wants to just drop questions there while i'm going through i'll just try to answer them um

so this i just want to talk a bit about how i see network topology so i think one of the scary things about looking at this is like wow okay so there's one builder one relay and then you know they're sending payloads over to the validator um that's not really the goal the goal is to make sure that there are as many redundant parties that are operating in each of these roles and what this essentially enables is that if like one builder serves to do censorship or something like this it's easy and trivial to switch a different builder um and like the other builders will still be able to submit their transactions um similarly with the relay if like one relay starts to propose invalid payload for whatever reason let's say they go offline they

have some infrastructure issue the validators can sort of trivially fall back to to a different relay you know this is just network redundancies to make sure that the system continues to operating as normal but in any case the validator sort of locally has still the ability to fall back to a local execution client if all this fails and all this becomes invalid um so yeah we've done a few rounds of iteration on how the system works um so this is kind of like the latest uh sequence diagram of how the messages are being passed i'm just going to go over

it quickly i think it's useful to highlight some of the calls that are sort of standard in the engine api today and then some of the calls that are that are modified to make the system work so yeah this is a full life cycle of a block proposal of the block construction um it starts by uh the engine fork choice updated call um which gets proxy to the relay uh or i should say to my boost that also sends that to execution clients and and the relays um so right now this fork choice updated is used uh for both like notifying what's the latest head of the chain but also for communicating the the fee recipient

address that's going to be used by by the by the slot tenant on their block proposal um once uh it's time to actually produce the block here what we've done is we've replaced the familiar get payload api call with a builder get payload header call and basically you know the the parameters of the call are the same but the return values are different so um instead of uh of returning a payload that includes the full transaction list uh the relays are only returning uh payloads that have the the root of the

transaction tree so um they withhold sort of the content of the transaction list so that um the validator is not aware of them until until later um the other thing that met boost does here is it's uh it needs to be able to compare the proposals from all the relays it talks to and the local execution client and select uh whichever payload is the most valuable um and instead it's that payload that it returns to the to the consensus clients great the consensus client receives this payload it puts it into a beacon block it signs the block um we've introduced this new call which is proposed blinded block

so this is blinded block is basically what we call a um a beacon block which does not uh contain the uh transaction list of the payload and said that is just null um and then uh but you know the the signature and the header of the block and the header of the payload are all still valid um so it proposes this blinded block back to the uh booth um uh middleware uh which is then able to route that that uh that block to the right place um in this case it routes it back to the relay uh who has the uh the transaction list um and then uh

it returns the uh the the transaction list back to uh to the the middleware and the consensus client so that the consensus clank can then propose it to the network at the same time the relay is going to propose that that full beacon block to to the network and you you move into the next step of the block proposal with the attestation and everything else so yeah i guess there's quite a bit of cover here but the highlight is these two new modified calls right get payload header and uh proposed blinded block which which are sort of um inserted as um complements to the the current engine api so

great where do we go from here um we've been working on this um on the implementation of medboost um here under flashbot slash navboost um and we sort of detail what are the different uh implementation milestones and and what's involved with them we split up the development into uh into four milestones right now um the first one is really just about the basic logic that's required for met boost to be able to communicate with various relays and be able to propose payloads to um to the consensus clients

and it also involves sort of the support by consensus client for for these blinded blocks um so i highlight uh sort of the the behavior and the client modifications here um but yeah the the consensus client basically the only change that's required to be compliant with this this milestone is uh the ability for them to accept um the get payload header calls and then return a blinded block from them so uh shout out to the lighthouse team they've been super proactive uh paul and sean um at uh helping implement uh and provide feedback on on this initial

setup um our goal right now is to have that ready for whenever consumi goes live which to understand where we're nearing um in a few days uh so it'll be super exciting to have live and and get some of the uh the members of the of the flashbots um youtube working group uh also set up uh to run this um maybe maybe for contacts if you weren't aware um flashbus has set up this this working group with various different validator teams and solo validators etc and in the community to to provide a a

forum for discussion on both the design of of boost uh uh collaboration on testing um of the system ahead of the merge so we'll we'll try to produce some um [Music] some some package for them to get set up with uh with that boost and i guess whatever clients uh support it uh for for consugi um yeah the other thing that we have ready is a merge mock implementation that supports um this milestone one um so that's uh the demo that we'll jump into just just in a few minutes um

so great we have the basic logic but uh by no means are all the questions i answered yet so the milestone two that we've laid out here um is meant to implement all the remaining critical components of uh of the system and those involve security so having a a fallback in in the case that meth boost uh like crashes and fails over um to be able to fall back to a local execution client um authentication so so that all the communication between that boost and um the relays are using signed messages and and everyone knows who they're talking to um to basically prevent uh dos and and

[Music] and spam um and then uh the third one is reputation so even if you're authenticated with a relay um you need to be able to tell if the relay uh turns malicious or starts sending invalid blocks etc so there's some baked in logic into uh meth boost that needs to be able to identify if um if a relay starts misbehaving and react accordingly so the goal for these is to have them expect over the course of the next month and implement it by the end of january so that we can do um further testing uh with those now there's another two milestones here

that are worth discussing um i think we can probably skip over milestone four which is just about um about uh configurations optional configurations and optimization that various validators might want to run if they have different preferences on for example privacy or or or you know where they want to uh optimize for latency etc so that can be sort of discussed separately but one of the main topics i think that remains to be figured out is privacy and and by privacy i really mean validator ip obfuscation um there is a design of the system that

um that avoids revealing the mp addresses of the validators to the relays but it requires um a lot of work with implementing custom channels or topics i'm not sure what they're called with with lib pdp um and just from initial feedback from both validators and client implementation teams it seems it's not really um such a concern for them um so this is um this is marked as as optional and i think we'll be pending more discussion with uh with the client teams and the ef to see if it's worthwhile to um to put in the the engineering cycles to implement this or not um so with that

said i think it's worthwhile to jump into a uh a quick demo of uh of merge mock connecting to met boost and then um i could start highlighting some of the other open questions that we have here and and move into more discussion so um yeah let's see jason do you want to try sharing your screen yeah let me go to world uh oh no you have to stop sharing first looks like should we get all right can you see my screen yes sir all right

uh okay yes we can now all good awesome all right so uh this is the med boost repository i'm just gonna start up my boost real fast uh it's written in go it's very straightforward it's relatively simple as far as implementation goes uh let's let's move over so i'm gonna run in three separate terminals so in the first term i'm gonna run my boost second term i'm gonna run merge mock the execution engine uh for those unfamiliar with merge mock it's just a very simple stripped-down uh client for both engine and consensus it's meant for doing mock testing mock integration testing um so i'm gonna start that up and i'm gonna start the consensus client as well thing worth noting here is i'm doing one extra

flag here which is i'm pointing the engine at port 1850 uh one eight five five zero um that's where med boost is running so instead of how this normally runs is this communicates directly with uh the merge mock execution client or with you know a geth or what have you whatever execute clients in our case we're instead uh communicating with my boost directly let's go back to my boost logs and we can see it's successfully getting the payload header uh and it's revealing the payload in the proposed blinded block call so uh if you refer back to the charts or the the documentation that uh stavan showed earlier we're no longer calling git payload we're calling get payload header and then in a second step

the consensus client will fetch well we'll send a blinded block and then fetch a full payload back from web boost um there's some areas here you're seeing it's it's not actually communicating with the relay at all this is only communicating with the execution clients so for the purpose of testing mergemon this is great right it's it's we can see it working we see it working exactly as it used to with uh the merge box execution client um and i think we have plans to uh provide more extensive testing on the relay side as well we'll provi probably provide a mock relay to run locally as well but for this for consensus client implementation purposes this should be more than enough you should be able to test the get payload

and propose blinded block uh endpoints that's pretty much it so it's not much for demo honestly it's just showing that's working and showing that we're testing it with uh with some clients all right awesome um okay cool yeah i can go back to share my screen and um yeah we can sort of open the floor up the discussion i think yeah we can either talk about um [Music] some of the remaining design decisions for this um this milestone

um and have a discussion about that or yeah maybe let's let's do that i'll just list these um i'll list these open questions um and these are all things that we are looking for additional feedback from uh feedback on they are currently sort of underspecified right they're mostly um ideas but um and proposals uh but hopefully they'll they'll move to being much more concrete over the course of the next few weeks so yeah the first one is this validator ip obfuscation there's a proposal for how to go about changing the way that messages are

passed around and make sure that basically it's one-way communication between the validators um that uh send basically messages to the relays and and the rest of the network and those can be done over over peer-to-peer but it doesn't really address the relays when they communicate messages to the validators right in particular the most important one is um is getting the payload header from from the relay here so it's kind of a silly question mark on on how to address this and and the feedback that i've gotten is that it might not even be worth too much hedge scratching here because um ipdn randomization still is um

is an issue regardless um so the option two is just let the validator deal with it right um if a validator is um [Music] quite sophisticated it should be somewhat trivial for them to insert a reverse proxy around uh their met boost client or like run met boost behind behind some kind of protection that even if it falls over it doesn't affect the rest of their infrastructure um that's how miners are operating today so um i'm just assuming that would be reasonable for for uh for validators to operate this way as well um and the other option is if they're

they they disagree with this approach then they don't necessarily need to run um web booth at all and they can just fall back to running their clients the normal way uh without without all this meb stuff um so that's one discussion topic another one is fee recipient authentication um so there needs to be a way for the validator to communicate to uh both relays and block builders right so looking at this the father needs to be able to communicate the relays and block builders what fee recipient it's going to use

and in the first milestone what we're doing is we're using the fork choice updated call and sending that over to the relays to communicate that but uh ideally we wouldn't rely on this and it would be possible to just have some um some authenticated message that um uh met boost is able to get from the beacon clients that lists all the fee recipients that are associated with the validators that that leaking client is representing so you know if the beacon client has like a thousand validators running behind it on startup or on connection boost would be able to request hey give me all the

fee recipients for all your validators the beacon client would then request from each validator node to sign a message and then submit that back to my booth would then submit it to the uh to the relay and the relay would make it available to the rest of the network um that's kind of the way that this this proposal works right now just on that does it make sense for for battle that is using eth1 credentials but it makes sense to just use that address so you're talking about yeah you're talking about like withdrawal credentials yeah maybe um the problem is i would require that withdrawal

um address to collect all the fees for like transactions and and mev um and like even the block rewards uh uh i guess not in e3 and in proof of stake there's no there's no no such thing but certainly the the transaction fees and the mev that's would be where like all the fees would go um so perhaps if they're comfortable with that then yes i think right now the fee recipient isn't like limited to being um to being the withdrawal key um yeah so and there's no way to upgrade currently so it's not the full solution but potentially becomes one yeah

that's cool thanks it is true that i think even if the view recipient is a withdrawal key um you can then like you're not limited to to withdrawing and so withdraw that value before um uh stake withdrawals are implemented because correct yeah i guess yeah this the idea here is that it would be possible but not like required right for for the withdrawal key to be the few recipients so the valder can pick whatever address they want um okay so why do builders or searchers need to know

the specific fee recipient can't they just use the coinbase opcode so the fee recipient is what goes into the coinbase lab code but actually this is a really good question um so the builders uh so because the the the coinbase opcode is a part of uh the header and can be accessed through edm execution it also creates um like you can have a code path that switches based on the coinbase address right so when the builder or the relay are processing their blocks in order for that block execution to be deterministic they need to know ahead of time what is the

uh the address that's going to be used um in in in the coinbase um so there's two ways to go about that one of them is like the validators communicates the the fee recipient and then the builder like includes that as the coinbase address of that block and then like submits that through or the alternative is for the builder to set their own address as a coinbase address and then at the end of the block that they produce they just have a simple transfer from the coinbase address to the validator address for the value of uh of their block that they want to pay um so either of those uh sort of approaches uh

should be possible um and they remain the property that like throughout each step the block is fully deterministic okay cool um next point is around execution client block value so one of the key objectives really of this system is to enable profit switching between the payloads are produced by multiple different relays as well as from local execution client

so this step here right this this logic where my boost compares the payloads it receives and selects the most valuable one really requires uh some indication of the value of the payloads um so the get payload header call and the like get payload call need to be able to return an extra field that says this block contains like x eth of delta in value for the fee recipient that is that is defined um so uh sort of talk about it here but um that message needs to be returned um in a way that that boost is able to compare these different payloads just like the most valuable one and submit it

um and like a further enhancement would be for this call to include um some um some kind of miracle proof on the on the balance change um which would um which would provide potentially further guarantees um the tricky thing here is obviously it requires some changes to the engine api and particular changes to the data that the execution clients expose alrighty next item here is

uh frog proofs so because the relays are not including the list of transactions and the header that they provide to the validators the validators are are signing blindly right and they just presume that the relay is proposing a valid block um that's okay from like the network perspective because once the full block is revealed it's still up to the attestation committee to actually validate if the block is valid and so the network will never finalize an invalid block but it does cause the validator to um to lose the value that it could have

received from both the mev and the reward for the for the block proposal um and it basically just got a miss slot in in the chain um so you want to have a system where um other validators can um can notice so let's say you know this is the path that's taken you get a bunch of transactions all the relays propose a block to the validator here and this is the boundary of slot one this is the value of slot two the value of slot three slot four you know if the validator receives an invalid um payload from the relay and submits it to to the network you want the validator number two to be able to notice oh wow like this really

proposed invalid payload even if he sends me a payload for my slot i'm going to ignore them and just switch to using the the other relays um and the way to do this is using sort of this fraud proof message so because all of the relays and all the validators are listening to leia's state of the beacon chain um what you need is the validators to be able to communicate back to all the relays hey here is the payload that i received from relay one this is the one i decided to include in my block i can prove it because they signed it and then all the other relies are like okay now we can validate to see if this payload was correct or not um if it's incorrect what they want to do

is send this fraud proof message to validator number two that says hey look um we really number one proposed this payload uh for this block height you can see that it was invalid because you can like see the state of um of the beacon chain uh for that for that for that block height uh therefore you should no longer accept uh payloads from this relay um so this fraud proof system is sort of what keeps the um [Music] me boost protected uh sort of automatically from um from relays that turn malicious but it requires to be further spec because

there's likely to be some uh some modifications to the way that uh it validates those payloads um both with the local consensus client and with the local execution clients uh to run smoothly um and there's a few approaches to doing this so it's worth sort of calling out as one of the the remaining discussion points okay if you're still there if you're still bearing with me the final one is splitting away the execution payload call um so one of the components i mentioned in uh milestone two here is a security um so

under this description right the beacon client is only communicating with the local execution client through meb boost but really what you want is a situation where if md boost goes offline for whatever reason has some software fault the beacon client is still able to operate all those duties by falling back to communicating directly with with the execution clients so this is just about making sure that this exists in um in all the beacon nodes um so you have that that level of redundancy if there's a complete system failure and uh yeah that's it that's all the

discussion topics that i have i've listed some resources down here and um and some some notes that uh that paul has put together um uh on uh while we were iterating on on the work that we have so far um so definitely great german to check those out cool thanks um yeah so i'm paul from lighthouse um i've mentioned a couple times i've been working with flashbots on it i thought maybe i would just talk for a little a little bit about what i've been working on with it so i've been i'm online as a developer of one of the consensus

clients so i've been trying to get involved with flashbots to just make sure that um this can be as safe as possible and that we can also maintain the concept of client diversity so we're kind of when we bring in something like media boost flashbots we kind of become at risk of centralizing upon this thing not from not necessarily from like a i don't like a governance perspective but more from like a piece of software that can fail and take everything down sort of perspective um so the designs reflect that now um something i've been trying to make sure is that we have the ability to um fall back to the uh local execution node like you know nevermind geth whatever um if things stop working um and also what i think is very important as well is to

not rely upon any of the boost for verification validation of payloads so they'll give us a payload and we always uh verify it with our own node so that we can um that basically stops immediate boost from being in the position where we can finalize completely invalid transactions and things like that um so that's kind of what i've been working on um as well is trying to make sure that it's multi-client um compatible from a consensus client perspective so try to make it so that it's easy to implement to consensus clients and make it so that there's a clear path to doing that so that it means that we can get all of the consensus clients that are interested in implementing it i can get them on board with a pretty low barrier to entry so that we don't end up with a

scenario where um you know if you want to run any of the boost you need to run some client and therefore we'll skew the network so yeah it's been great working with the flashbots team um looking forward to being involved more yeah and if anyone especially from the client teams have any questions or want to talk about it i'm my door's always open thanks cool any other thoughts questions what's the best way for folks to reach

out to the flashbots team as they're starting to look into this and like have questions and whatnot yeah good question so there's um there's a channel on the eth r d discord called block construction under execution r d um and i'm almost keeping i'm always keeping an eye on on this thing uh for any messages so if you need to reach out to to flashbots you can just add the ghost up there and i'll see it thanks uh lucas has his hand up yeah i i have a question so

as muv boost is kind of this middle layer that between something that produces a block like an execution engine but we still have a execution angle to fall back to right um would it make sense to like bundle it with an execution engine process like for example never mind has this plug-in ability would it be good to have a plug-in for mev boost that would think so the next thing with the execution engine can have a look at the current state of the network uh for from the execution engine

perspective as well as communicating to the river yeah i i think this is kind of like an open question of like how deeply can mav boost be integrated with um both the beacon nodes and the execution clients um [Music] we've tried really hard to comply as closely as possible with the way that the engine apis work today so that it's like cross-client compatible by default that being said i do expect that there's some advantages to having um deeper integrations

um i we haven't spent that much time looking into it to be honest we've just been focused on how to make this thing as as stable as possible and and like broadly compatible as possible but um yeah i do expect there there could be some some advantages to to integrate further yeah the beauty of it it's abstract so it can be integrated in the exchange right so uh that's that's the idea but but the integration part is still part of the question maybe there are benefits to them too right like you could definitely i think implement all of them met boost logic

as part like as a module on nethermind right probably and then you wouldn't have this like other piece of software that's running in between you would just have the execution client that's also talking to our relay and it's it ends up looking much closer to the way that mavgeth is sort of architected right um but you do like remove the need to have this um this other piece of software so if if like client teams want to explore that and just replicate all the logic i think that that's something interesting to look at any other questions comments

um i i have some how how can we make sure that the builders and the relays are not the same person um i think if you like if you run a successful relay um or like if there's a cost for validators to to to like be at multiple relays in terms of whatever setting it up uh uh bandwidth whatever then they would probably only go to a couple and like how can we make sure that those relays are not

uh i don't know getting getting bribed out of banned by the builders yeah that's a really good question um [Music] so i can say how i sort of expect the uh industry to like work around this and like respond to this um yeah let me let me talk a bit about this so i think as everyone here is aware right like not all validators are sold validators right they're running both their validator client they're making clients and their execution clients but in practice while there are some individual stakers who do this you know a big chunk of the um of the

the proof-of-stake network right now works by um either people running their own validator client but then outsourcing the beacon client and the execution client to some infrastructure provider or you know pooling together and and staking pools where they don't control the value of their client either um and so there's sort of an industry that's propping up around various different actors running different segments of the system right like even solo stakers who are running about a client and beacon client are still outsourcing their execution clients and fira right so each component is sort of set up to be bundled together with each other in a way that provides a service that might be interesting to some uh to some users i do expect somewhat similar thing to

occur um in this level of abstraction so while there will be builders who just focus exclusively on building because you know that's where they have their core competency of being able to merge transactions together being able to find some meth and and produce blocks with it um there will be others who say like oh yeah we don't want to trust a a third-party relay uh who you know will see the content of the blocks that we produce and so we'd rather be able to just communicate directly with validators and so they they will try to run their own relay as well and and get as much as many validators as possible to to sign up for for their relay um similarly i do expect

um that some of the large uh validators will say well you know we think it's a big risk for us to um to sort of trust all these third-party relays um so we'd want to also run our own relay such that we can like see the content of the of the payloads before we sign off on them and we're able to validate them and so we don't need to worry about this you know this fraud proof mechanism but instead we can just sort of operates very similarly to the way that uh mev gas operates today where you have full information and you can just sign off on blocks but it's really probably only going to be the large validators who do this and you know an

example of this is ether mine who has been running um you know in the proof of workland both the relay and and their miners so the i expect they'll probably continue to do this um but there will also be these sort of individual entities that are incentivized to uh to run relays so uh within the uh flashbacks working group right now there's three entities that i've indicated so i'm interested at doing this so so one of them is blocks routes who they are currently running a relay for the proof-of-work version um they'll continue to do this um here um there's a consensus that's indicated they perhaps want to

see if this is a product that would make sense within pure and then alchemy as well have have indicated some interest in exploring this so i do think there are some entities like those whose you know business model is very much so on being an infrastructure provider whose role is quite fitting to run this really infrastructure um you know when you you think about what running a relay really is it's opening up uh some endpoint right to like as many people as possible as many users as possible to receive a bunch of different block proposals uh doing some highly scalable stimulation of these block and verification of these blocks filtering out all the garbage and then

only submitting you know the best ones over to the validators so that's pretty similar to a role that um that infurer does right now by you know receiving a bunch of transactions from users and then only submitting the ones that make sense to to the transaction pool and uh an another thing um uh so regarding the the issue that we need to know the value of the payload produced by the local execution

client if we have a standardized format for paying the block producer okay now that doesn't do well like the the the mev boost knows the transactions right so if we had a standardized format to to create a transaction that pays the fee recipient and put it in then we would know how much someone would be willing to spend

and uh so we could uh gauge uh meb based on that right yes that's right um actually i'll shift over to here i mean i have one line on here that describes it but it's something that's worth talking about um there's a slide on on milestone four that says consider adding merkle proof of payment you know to shift verification requirements to the relay so basically what this means is instead of leaving the option for the builders to set their own coinbase address uh or you know use the fee recipient of the coinbase address it would say okay no builders always set their own coinbase address um and

they include a transaction at the end of the payload that pays the fee recipient and then what they can also do then the relay can produce this proof that that transaction was included and has you know the the right uh precondition on the balance of the builder to be able to uh to complete the payment to the um to the fee recipient um so this would involve you know standardizing the way that the payments are made and then you can create this proof that the payment was included and then attach that to the header to the payload header when it's communicated to mefboost and then in theory the execution client can can do the same

you know i think if there's a way to avoid this like level of deep constraints and like remain maintain the ability for the builder to like set whatever they want as a coinbase address and uh simply say you know this is the change in the fee recipient uh balance um and have that be sort of self-standing without restricting how the payments is made then that seems ideal uh in my mind because it's less restrictive yeah but it adds like some complexity to to block building

and uh two like two it also adds complexity to people that are not using maybe maybe boost right because they have to to uh to opt into this to the same api like i would i would be okay with having this as an optional field in the in the uh payload in the in the get payload object but not having this required yeah i think that's fine yeah it seems fine for it to be optional any other questions comments

uh i have minor question about uh last chapter uh like proliferate proof message uh what would happen if uh elijah is not revealing uh the block in the end of all this interaction uh validate risks to just um just just miss this miss the slot right correct yeah so um in this initial post right that describe this architecture um we list three ways that like a relay can misbehave first one is just producing a valid payload second one is misrepresenting the value that the payload has and then

the third one is missing data so just never revealing the transaction list um [Music] so there isn't really a good way to do um like a frog proof for that right because it's just based on timing you know i really can claim that the um message came but just too late and i can just stall it out or or whatever um so i think this can be much more subjective um maybe it has to be like a statistical approach where you know if a relay misses more than x number of slots within you know y amount of uh block proposals then it becomes uh like disabled

that's that's my idea um i'm wondering if yeah what do you think of that yeah thank you yeah i think it's going to be solvable without like like completely of chain maybe like some complicated mechanics but it's it would complicate things uh but yeah it's like still like a possibility of of attack uh this kind of not revealing the payload in the end of uh all interactions but yeah i think that good relies it's not interesting in twinsies i had a question kind of based on what you guys just discussed so you mentioned like disabling malicious relays so who

controls like what's a valid relay or not like is there a master list of active relay that's controlled by whom so there isn't um the way that it will work is basically the validator uh when they start up mv boost they can define a list of relays that it wants to connect to and so the validator is always in control of um is always in control of which which relays it it wants to communicate with something that we've discussed in the past is does it make sense for like there's always a question of like what

are the defaults right like there's a defaulted like no relay does it default to a single relay or does it like default to outsourcing to um to like a list that exists somewhere um we haven't really decided on this i guess that's like open for discussion um something that like might be useful for like solo validators is i don't know if if you all are aware of uh like tokenless like if you use uniswap right like instead of uniswap coming up with a list of valid uh tokens you know the ones that aren't malicious tokens and making a decision themselves they allow for like any third parties to submit a list and like maintain their

list of tokens um it could be a similar system here where um the validators can delegate to a third party list that's curated by you know some some entity that carries some reputation and who focuses on exclusively um uh verifying the uh the activity of of of the relays but really the goal the goal is for um always maintaining the ability for the validator to to define which release they trust okay i guess that makes sense it just also causes like a potential problem like if you're trying to punish like malicious

relays but really it's a permissionless system then they could just probably find another way to get back on a-list or or whatever obviously it's more difficult but yeah it's it relies on this reputation right so if the relay does something malicious super malicious and then they go offline and like spring back up with a different identity um it's it's kind of up to all the users in the network to try to identify that if if the user using like a third party to do this like reputation check um then you'd hope that that third party would be able to identify that too so it's certainly it's certainly a risk like um uh i really could could attempt uh to go uh this direction um

but i expect over time as they build reputation that's sort of a sub cost and they they aren't necessarily incentive bias to evaluate that and uh like the remedy or or fallback mechanism for like a potential i don't know mass denial of service attack against relays like like obviously at some point that's just disabling nvd boost but um [Music] is there any other way to do that or like the ip's not even exposed um definitely the like fallback mechanism if all the relays go down is like mev boost still talks to local execution client and is able to produce blocks that way um yeah if like if every single really goes

down yeah yeah but like if if some go down and then the ones that are around just get bad blocks that's kind of like i'm imagining it yeah so you could have like an extended period like let's say all the relays at the same time start producing bad blocks um then you would have like a cycle where uh validators like one by one disable the relays right and so maybe like just thinking about it the longest amount of time that the chain would go is like the number of like relays are enabled by all the validators so ideally right you have um you have uh validators that all have like a

different list of which relays they trust and then you have a bit more like diversity there you don't want like maybe an overlap between all of the shared relays correct yeah yeah yeah but yeah worst case scenario i think that's like the block the the chain misses the number of blocks equivalent to the number of relays after militias and are relays able to um provide like like malicious blocks as opposed to just invalid blocks so when they get something from the builder is that like a fully i don't know how to say it a fully what sorry um

so like obviously they can either like not respond with a block which is the same thing as responding with an invalid block um but is there a possibility that they basically respond with a block that's like not been built by a builder and they just come up with their own thing and it's like a bad block in some way yeah so i can dig into like the three ways that i really can sort of do something bad so the first one is just like it tries to like send whatever a transaction from somewhere that doesn't make sense or like just contains some you know some logic that that doesn't work like the the header is formatted or something like that right so the payload can just be invalid um another one is like inaccurate value so

something that a really could do um is you know the block that it's actually producing has one each worth of value that's being paid to the validator but they claim that there's 10 eth worth of value and so you know they can basically guarantee that they win the profit switching here um even though the block that they produce wasn't that valuable so i say that's probably like a clearly malicious thing that like wouldn't happen by accident is over reporting the the value of a block um so i'm wondering if that's that's what your question is yeah no that makes sense

anything you have to say a couple people are still unmuted if you have a question comment just jump in uh i had to step away for a minute to get a computer that arrived at the door um but i posted a question in the chat did you guys answer it already um a couple of us were wondering we were chatting on the side are relayers incentivized separately from the builders so it's not defined within the system um you know actually neither is the builder uh uh compensation right i sort of propose like the way that i think builders will likely want to monetize which is they set their own coinbase address and then they like have some payment and they can keep some delta between the two and

still their incentive is to pay the most that they can because they're competing against all the other builders and producing this i expect relay's business model to be more fees oriented so if we just think about how um like block blocks route operates today right they they have like a fee per number of messages that that it uh inputs um and uh you know obviously infuria and alchemy have a similar system where they just charge by like api calls so i expect those to be the like likeliest monetization routes for the relay is it possible for the relayers to take some cut of the deals that they pass them through so that they're

competing in price discovery like the builders maybe though i don't see that being uh super stable like basically would require adding additional transactions somewhere where they really would say you know we only accept blocks from builders who like pay us within the block that they produce and then they would like then for the payment on by adding their own transaction at the end of the block to the to the validate year so it could be doable it could be doable um feels somewhat less likely to me but it's a possibility okay all right thank you um

i was wondering so what is it that's missing right now that makes us need the relays in mav boost but we won't need them later when we have the full uh pbs yeah good question um so we had a um a discussion uh last friday where um where vitalik presented uh pbs and like the properties that that it has so um it's called mev roast um maybe there's a way to surface a link to that but i definitely recommend checking out that talk basically

what you need to remove the relay completely from the system is the ability for the value to accept messages from any builder and to do that you need to have unconditional payments attached to to a payload so right now right the way that it works is the builder creates a payload and submits it through but if the payload is invalid right if the payload reverts for whatever reason the validator doesn't get paid but under um to have all the properties that you want to be able to remove the relay you need to have this be completely independent where even if the block that the builder proposed is is

completely invalid and reverts or like just never gets accepted the payment from the builder to the validator still uh still settles um and that creates sort of the counter incentive for builders to produce valid blocks it like prevents the dos and spam issues and then you can handle basically making sure that you continue mining on the ballot chain by updating uh the fork choice rule of uh of the chain um so that's that's how pbs sort of handles this issue awesome thanks anyone else

okay well yeah if there are other questions comments as people look into it like we mentioned earlier the blog construction channel is the right place to discuss this uh thanks a ton to the flash boss folks for coming on presenting this um yeah agreed with the comments this was really helpful and yeah thanks to everybody else who attended ask questions and yeah i guess we can wrap it up uh we'll have a recording for this and i'll share it on the discord as soon as it's ready awesome thanks everyone thanks for the really great questions um yeah looking forward to chatting some more on all of this