ePBS | Potuz | EPF Office Hours

figure out how it works and you came along and and started contributing it's really great but also uh po has been part of the cab of the um EPF before we took over with joshh uh under Piper so the OG EPF uh fellow as well uh so so it's honor to have you here because with your uh with your uh current work on the epbs on prism client I'm sure fellows can learn a lot from you and your journey uh I I believe you have some sort of presentation for us uh some uh some you talk about at first oh so actually I don't really know how you guys want to run this uh I have slides for a talk that I thought might be interesting here which is exact same talk that I gave at flashboards uh to pitch epbs uh I mean there's enough slides to cover like a three-hour talk it doesn't really matter how I this is also supposed to be an Ma so I'm not really sure I mean if people are really uh Shameless and they they actually want to interrupt me like every 30 seconds then I can go with the slides and that's something I would love if I get interrupted every 30 seconds then I can just start and try to aim for to give this the full talk if people are just quiet then probably it's better if I only speak for like 10 to 15 minutes and go over just a few first few slides I would much rather be interrupted all the time and then we can have a conversation and then we can just decide over as things go by how how this meeting is going to evolve guys are you Shameless uh yeah yeah uh people already love you that's great uh yeah we love you PS I mean it's that's but is a very candid person that's what that's say why I love to have you here and just to deal with the openness uh I think you can just start the the slides the presentation and people will either interrupt or you can just let's give it like 15 minutes or something at least uh for you to give them the context have the presentation and then uh then we will have more room for the and I I would say like yeah if people have if people have some questions along the way like feel free to feel free to raise your hand and um and you can speak uh but yeah uh feel free to share the slides go ahead and so let me see if I can do a window instead of yeah so I can do a window yeah let me know if you can guys see this perfect perfect yep we see because I don't have the mirror in here all right so uh uh I timed it correctly or Mario timed this correctly the EIP is out or at least the pr is open I'm linking it on the chat and there's a link there for the actual changes that are in the consensus pack uh that's a different uh e PR which I will link now in the contest spec all right so I'll go over like in the first few minutes if if I get a lot of interruptions then we can just go over most of the slides uh but if no one speaks at all I'm just going to stop in an awkward position and force you guys to ask questions and since this is supposed to be an AMA the questions that if you interrupt me you can interrupt me and ask me about something completely different I don't know vertx address if you want anyways uh so I want to tell you about uh epbs uh which is the project that I've been working on for over a year now uh I haven't really done any prison work in a long time now and I've been focusing on epbs and I don't want to get into the philosophy of epbs if you want to ask me about that I'm happy to answer I'm just going to go over the mechanics of epbs which is something that I want to sell uh so instead of telling you about PBS let me tell you how the ethereum slot Works to get today I'm not really sure how familiar everyone here is so I'm going to try to go slowly here uh the consensus algorithm we have today in ethereum works as follows uh slot is an unit of time which is 12 seconds and at the beginning of the slot this is how things should work at the beginning of the slot the proposer propos builds a block and broadcast it but proposers mostly do not build their own block they Outsource the construction of the payload of the block the actual transactions of the block uh in exchange for money in exchange for eat as a form of payment they gather the bids at the beginning of the slot and they delay this as much as possible because the longest you delay the broadcasting of your block the more money that you can get from the Builder that is extracting mvv during that time so typically a block would arrive to your node two seconds into the slot and it needs to be validated and attested before 4 seconds into the slot so that means that your node is doing most of the work in those two seconds between the block is arriving and the attester is well has validated it and the attestation goes out at four segments the rest of the slot is s sort of like Irrelevant for the rest of the conversation uh the next proposer has uh about uh 8 seconds or about 10 seconds to Val validate the payload uh before proposing a block on top of this or not but the ATT testers are the hot path the vast majority of validators only have two seconds to validate a block okay so this is just a text over the next the last slide we have two seconds for payload validation we have four seconds for attestation propagation after those 4 seconds those attestations are aggregated this is a feature of our consensus algorithm of the moving to proof of of stake uh and then we have the last four seconds into the slot where those aggregated attestations are propagated everyone gathers them and you compute your new head and the question is can we make the hot path better can we make it so that you have more time to validate in principle we could we could for example ask the validators not to submit their attestations for seconds into the slot and you can say let's why why don't we adjust at 6 seconds into the slot because the remainder of the slot is wasted time on the CPU anyways but if we did that what would happen is that the proposer would send their block not at two seconds they will send it at four at five seconds because the longer they wait to submit their block the more me they extract so that's an inherent problem of the current mechanism for PBS that we do not have a solution for so this is how enshrine in PBS would work uh you would gather the same way bits at the beginning of the slot you would still delay as much as possible to submit your your your your block so the proposer would still submit their block as late as possible in this example is two seconds it could be more it could be less and the validators would have to attest to that block at three seconds so it looks worse actually than before before they needed to attest at four halfway through the slot the actual payload would be revealed so the consensus block that is being broadcast at two seconds will not have transactions will only have a commitment to a builder to submit later those transactions and then N9 seconds into the slot and new committee would vote for whether or not they had seen the payload and what we want to do is to implement a notion mechanism so that the proposer can sell the rights to a builder to submit their block without trusting it and the Builder can actually buy those rights without trusting the proposer and knowing that they don't need to reveal their payload unless they know that that payload would be canonic so here's how the slot hot path is now going to work you still have a very hot path for consensus layer validation since the block arrives until the block is actually attested the validators which is the the attestors which is the vast majority of validators will need to do a hard and fast computation but that computation is very fast because there's no execution now it's only validating the state transition on the consensus layer that typically takes 80 milliseconds on a normal computer today as opposed to the one to two seconds that takes to actually execute the the blog Kira you can speak up I'm not even reading the the chat uh actually ask the question can you hear me yeah I was asking why did we reduce the CL validation time oh so because the CL validation time is actually very fast so we can sync a block if we don't care about execution we can sync a block very very fast this is pre-merge time we were talking about 70 M milliseconds per block after merge now it's a little bit uh a little bit more but still it's under 100 milliseconds to syn a block uh okay don't to raise your hand guys just speak up we're a civilized group uh someone said I got a notification that someone wanted to speak up who's this Risha audible am I audible yeah yeah so my question is you mention in one of your blogs and said here also that commitment to a particular Builder is needed not to a particular payload so would you like to clarify on this why only a builder is need to Beed yes so that's that's a very good question and I have that at about like slide like 20 something and we're in the second slide but yes so here I haven't been specific enough in the way that I'm talking today is actually the way that the EIP is phrased which is what is called as block auction and not a slot auction so here this consensus block actually does commit to a particular block hash to a particular payload and that payload is checked that the Builder is submitting later but that's not really necessary uh you could have a different it's going to have a different market dynamics but uh the Builder could say I am willing to pay this much send a sign message like that and not specify what is the payload that they need to reveal only specify that they will be the ones that are allowed to reveal a payload during that slot so that's what is known as a slot option and the difference there's many difference and there's subtleties too um one advantage for example would be that between the time that the bid is accepted and the time that the payload is sent this is that time if you committ it to a particular block hatch because during that time no Builder can actually be building anything because the Builder that that bought the right already has committed to a particular payload he cannot be updating it we already know that that payload exists somewhere and it's waiting to be released uh if you only sold the slot then between these two seconds and the six seconds that Builder would still be able to construct uh on his payload on the other hand that also lends itself to a timing game in which that Builder is now enticed to send the payload as late as possible because he already knows that he's the only one building it and the longer he builds the more IM he can extract that's one of the things another thing that can happen is that the Builder can attack the network since he hasn't committed to a particular block has he may send two separate block hash both of them valid both payloads valid in order to split the view of the chain and we need to deal with those four Choice uh situations uh when we analyze the security of the system uh did this answer your question uh somewhat I yeah I partially understood maybe when it is completed I'll get it more clearly okay uh but but essentially the big difference here is when the consensus proposer submits a block he's submitting a commitment and this commitment can have different flavors one of them is uh I sold my rights to Builder number three to submit a payload with this particular payload hash and then later in the six seconds the remainder validators would actually check that that the Builder number three submitted a payload with that particular block hatch commit to the block hatch we could have a separate auction in a different mechanism where the proposer submits a payload say a block saying I am committed to uh receiving this much E from Builder number three as long as one valid payload from Builder number three shows up that payload is good and there are different Dynamics for this uh and it's a trade of of design uh I suspect that EF research likes better slot auctions than block auctions I personally I haven't thought much about slot auctions I also believe that they're better but I'm not really sure at any time at any uh at any ways the big difference on this mechanism is that the hot path no longer involves validating the payload which is the hard thing on ethereum validating the payload can be of the order of seconds a typical Rasberry buy could take 4 seconds to validate a long payload today question yeah yeah someone so we reducing uh can you hear me yeah we are reducing validate uh uh validation time uh or a tester uh time from 4 to to 3 seconds and granted the the payload is much more uh less is less sophisticated so it uh it consumes less calculation is is anything changing in the payment of the a tester because they are currently being paid at 4 seconds not at all I no a testers are not being being paid at 4 seconds a testers are being paid when you perform the uh Epoch transition action attestations are not being paid immediately they are paid on the next Epoch when you count whether they attested or not and no nothing connected to a testing yeah isn't it connected to testing before four seconds okay uh well actually it's not connected to a testing before 4 seconds either it's not that today uh a testers are required to attest before 4 seconds but this is not enforced by the protocol you can send your attestations 3 minutes late and it will still get in a block today and you will still be paid you will be paid less because you will most probably lose the head vote but you will still be paid there's no place in this protocol where we enforce those four seconds and in fact if you send your maximum payment yeah you still get maximum payment probably if you send that 6 seconds uh so today if you hack your node and you send your attestations to six seconds instead of four you will probably perform better than uh than the vanilla validator there's no enforcement of these four seconds okay thank you all right the big win here and the huge win here is that well we attested to the block at 3 seconds for choice and the head of the of the Mario has a question uh it depends on inclusion distance yes so okay so let me explain how payments to attest to ATT testers work today um you attest and when a validator sends an attestation is attesting to three different things it's attesting to what was the last Justified block that they have in their view of the chain that's what is called The Source they are testing to what is the current uh Target Epoch so that that is what is what they see as the first block in the current Epoch or if there wasn't any Block in that one the previous to that so that's called as the Target and then there's the last one which is what is the current head of the of the chain which in the CA in this case of this slide that would be the block rot of the block that was just revealed and a testers get different amounts on whether they get either of these votes correct and also whether they get them timely and timeliness is measured from the time that they were supposed to be attesting but only the slot not the actual wall clock the slot that they were supposed to be attesting and the slot in which their attestation got included in a block so it's irrelevant this 4 seconds 6 seconds or 12 seconds or whatever it is the only thing that matters is which proposer after they sent the attestations included that attestation so if the next proposer includes your attestation it doesn't matter if you attested like at 11.5 seconds it only matters that the next proposal included Your attestation got it thank you for elaborating yeah um the docks that I shared have a good visualization of how do how do reward curve goes down with the the delay so uh yeah so inclusion delay uh attestation delay is something that existed in Phase zero and now we measure it in a different way we have Flags to te to check uh to check timeliness on these three different things but the original algorithm from phase zero to the alter Fork only counted this inclusion distance all right uh so going back to to epbs and how what is the scaling of epbs that brings to ethereum is that now uh when the payload is revealed at 6 seconds no one needs to validate it immediately no single validator needs to validate in less than two seconds so the next proposer of course needs to validate it and he will have six seconds to validated before he proposes his block because it's going to be based on this payload but the next testers which is the vast majority of validators they have nine full seconds to validate it now instead of just two all right so there's no validation done on the payload until the next block is revealed and by then you need to know that the previous payload was valid so this is the big win if we could solve uh state blo for example database growth or if we have stateless not stateless noes uh then we could send huge blocks because this gives us nine seconds to validate them instead of just two so if we solve the problem of the state growth on desk then epbs already gives us a solution for execution validation uh well this was a talk for flashboard so I guess you guys don't care much about like how the building mechanism change and the searching mechanism change for for me but those two things also are going to change under epbs all right so this is summary of those slides we have uh 9 seconds for payload validation 2 seconds for the consensus layer validation but the cons validation is very trivial you wouldn't need to validate much also there's much it's much faster to send the blob because the block is very tiny now it doesn't have all the transactions uh the CPU usage is distributed throughout the slot instead of like having the node work in just two seconds and then doing nothing the remainder of a slot now you're working two seconds hard to validate the consensus block and then you're working after the payload as long or as fast as you want uh but it's throughout the rest remainder of the of the slot to validate the payload Builders actually yeah so so if Builder is not having any commitment and like it he does not uh send the block at all does the slot go empty or like is the proposal slashed uh so uh in order for a proposer to propose a valid block they need to include one commitment a valid block includes a commitment the way a vanilla validator would work is exactly as today at the beginning of the slot you request your execution layer to give you a block and you request from the Builder to gives you to give you bid okay if no Builder pays as much as you want then you will take your own block and include a bid to yourself okay so the vanilla validator would still be able to produce a block itself and it would it would produce a bit to itself and immediately broadcast the block because they already know that they won the option okay and in fact trusted Builders so builders that already trust the validator or that immediately see the block and count at the St for it because for example you're Lio validator and you know that you're Lio Builder as well you know that Li validators are attesting to your block then you can just immediately broadcast your block your your block you don't need to wait for six seconds in fact fast Builders will do this immediately fast Builders will count attestations reach a threshold you can reach a threshold today inless than one second you can count all possible attestations on the network so in less than one second you counted that you've seen every attestations for the block you know that that block is strong you can just submit your broadcast your payload because you know that you're safe okay so what are the guarantees that inbs wants to have so this is an option this is the proposer is trying to sell the rights to build on this block and the Builder is trying to buy those so what are the guarantees that you want to ensure so that this is a trustless interaction one of them is that no matter what the Builder does the Builder already gave you a bid to assigned bid saying I want to pay this much to build a block if the proposer includes this block in an honest fashion and sends this block then the propos should be paid no matter what the Builder does if the Builder doesn't reveal the blog if the Builder reveals a different blog if the Builder reveals an invalid payload whatever the Builder does the this proposer should get its payment and this is enforced in a very simple way the Builder is a validator we request that Builders are validators and whatever bid is included on the consensus block part of the state state transition on the consensus layer is take this money from the Builder transfer it to the proposer that's it you do it immediately so the proposer gets his payment up front even before the Builder has even revealed the payment all right so this is a contentious point for many people will Builders want to be state will Builders want to avoid using epbs because they don't want to be state or not uh there are many answers to that question one of them is I talk to the main Builders and they told me that personally they don't care they will be State that's one possible answer another answer is the following uh we do not know how to provide Builders with a trustless way of paying uh that is not that does not require them to have the money up front if we didn't transfer the money on the consensus layer like the mechanism I just described and we wanted to do this on the execution layer let's try to imagine how that would work in a trustless manner right so this would work as follows you send the money as it is today in a transaction to the proposer and that transaction is executed on the on the execution lay now how does the proposer know that he has a transaction that is going to pay him and he needs to know this in advance to be in a trustless manner the only way that we know how to implement this is that the Builder gives the proposer together with the bid that transaction and it gives it the transaction saying here's a transaction that pays you you can execute it now it's a signed transaction if you execute it now you're going to check that this transaction is valid and you can get be paid but that means that that transaction has to be the very first transaction of the block it cannot be the last transaction of the block it means that we do not know how to make the Builder to get money out of the block that he's proposing for example by extracting MV getting enough money and then from that money take money to pay the proposal this is impossible to do today it requires some ZK magic that we do not know how to do so that's another argument for staing the solution we have on the L is not better it's just exactly the same for them they need to have the money up front and the actual the actual answer is that me uh is very highly concentrated in a few blocks most blocks come without any M uh just in a few blocks is where the actual money is made uh there's an nft drop there's an air drop there's some run to buy or sell something and in those very spiked uh gas uh auctions on on chain the builders or the Searchers are making the big the biggest money by front running so when this happens if you have a particular percentage of validators that are not willing to run a modifi node today we have at least 10% of validators that don't I don't aren really willing to buy to to run with Builders uh there's much larger set of validators are not willing to change their software so then the builders by not staking are going to be risking not producing those blocks whenever they fall on such a validator all right so this is a good point because it's already half a talk and I can stop there the remainder of the slides are going to talk about like the safety concerns like what are the guarantees for the builders what are the guarantees for the proposers what are the market mechanisms and then later for those nerds like me we can talk about for choice and what are the attacks what are sandwich attacks what are exanti attacks what are post anti- attacks and what are the safety mechanisms for those uh but this is a good spot to stop and see if there's questions I see that there's one question on this chat which is the cpvs have constraint on the bits like Builders can only bid up to a certain point Etc yes if the in the proposed VIP where the build are State and um and you you need to enforce that the Builder can pay so if the Builder is State 10,000 if the Builder can beid up to 10,000 if because the payment is extracted from the consensus layer if we go with a mechanism that allows the Builder to pay in a transaction up front then there's no bound as long as the Builder has that balance in the execution layer to pay for it I hope that answers that question are there any more questions do you guys want to talk about something else yeah or should I continue with this I have a question yes can can the proposer and Builder still uh bypass bypass epbs like do it off chain or yeah this is uh the the problem that epbs solves is the following very basic problem if I am a proposer today and I want to sell my my rights to block to build a block in a completely trustless manner I do not know how to do this I I don't have an option to do it so the problem that epvs solves is it gives the proposer a way of doing that it doesn't Force the proposer away we don't I we don't need to force proposers to behave in a way if proposers are not rational or they want to uh bypass the protocol because they feel like they trust uh whatever Builder or relay is out there that's absolutely fine um in fact I think you can prove it as a theorem that there's no mechanism that would force proposer not to trust a player uh another comment to that to that is that it's it's actually kind of irrelevant if proposers bypass uh the mechanism on the one hand it's irrelevant because most of the gains come from the pipelining on execution so even if the propos actually do bypass this mechanism we get we get a lot from just the fact that we're delaying the validation of execution another comment to that is that um it's very hard to believe this the way the auction is tailored is such that it's beneficial for proposers not to bypass it and for Builders is not so clear so this change makes the auction much more proposal friendly than the current option currently the builders are calized in three in three relays there are uh the relay doesn't really pay the best bid to the proposer the relay gathers bids and they take the difference between the first bid and the second bid and they pay the proposer the second bid and from the difference between the first bid and the second bid they they spread this between the Builder and the relay uh so that's already one thing the other thing is that the proposer can hide the bid under epvs the proposer can request bids from the Builder and may hide them or may advertise them to every other Builder however they want it's their choice for Builders the situation is actually more complicated because Builders currently can see the bids uh from other builders by pulling the relay uh in this mechanism Builders are not g by your relay so if you're a builder you don't need to have an authorization from the relay to submit payloads you can just open your endpoint and proposer would request request it from you and you lose this extra timing between you sending the bid to the relay and the proposer requesting that bid from the relay the proposer would request it directly from the builder at the exact time that they are about to propose so all this extra delay makes it much more expensive for a propos for a builder to be working with an intermediate so even for Builders it's cheaper for them and it's better for them to just open an endpoint and work themselves as a relay I'm not sure if this answers your question but like you know there was someone there yeah can you can you hear me yeah okay I have uh I don't know much about epbs but I have a um a fundamental question and a little bit of confusion in how the reward system work uh so you're saying that the Builder is sted and uh the reward that comes out of uh the actual uh build block would be a transaction right in the in the block itself and okay no so so you mean the reward for the proposer no so in the in the situation where the Builder is State uhuh so what I was discussing is two different ways of implementing the payment one way is the simplest way which is the Builder estate and then the payment is carried in the consensus layer so you take money out of the validator which is the Builder and you give it to a different validator which is the proposal okay no no transaction is involved here okay then another another way of implementing this would be by a transaction but then you don't even need the Builder to be sted at all so in that word the Builder is not even State the Builder just is someone that has a public key and a private key that we identify and that's it and then the Builder sends a bid with a transaction and that transaction pays the proposer on the executions on the execution layer so that would be an alternative uh an alternative mechanism that has some advantages for example for the Builder it doesn't need to be state it doesn't need to be run in a validator but most importantly it doesn't need to be uh draining money on the consensus side the current mechanism imagine if you're a builder and you're winning a lot of blocks like say you're Beaver Builder or Titan Builder any of the major Builders your validator would constantly be losing money because the money goes as payments to other proposers for the bids and then you are getting money on the execution layer by m extraction so you're making money on the El and spending money on the C so from time to time your Builder will need to make deposits to top up their Builder their validator on the C so that's a disadvantage of the system uh that I'm proposing today it's an obvious disadvantage but it makes the system much easier it's a it's a fork that is only a fork on the CL side and it doesn't need changes on the consensus lay on the execution lay the other mechanism would allow Builders to not need to make uh deposits because they will be paying on the execution layer and getting their me extraction on the execution layer and the the cost of doing that is that well it will require changes in the consensus uh lay in the execution layer it will be a Joint Hard Fork which is much harder uh to actually Implement to test and to roll out uh and also it also it requires the validators to execute something when they when they uh import the consensus block they need to execute at least the payment transaction makes sense and poto using the alternative with the transaction would wouldn't it be more uh I mean less safe I in the context of uh contraction couldn't those transactions be used as an attack no so so that's that's why we do not know how to do this unless the transaction is just the very first uh in the transaction in the first BL you you send a transaction and then the proposer sends their consensus block together with this transaction so nodes immediately executed and this is the new execution state so the actual payload needs to buildt on top of that state so it is absolutely safe it's just more complicated to implement uh I see some questions in the chat I suppose that this was already answered but just mentioning yes uh the easiest we can do is not change any of the consensus side on that regard so if the Builder drops from below 16 e it goes out this also precludes Builders from being stayed less than 16 in so it makes it harder for a builder because they need to have at least 16 eth uh we do not have a mechanism to have a Builders being stayed with less than 16 eth because they that would open for spamming the consensus uh layer poas I have a question for poas because I think this is a really good one and really fun one and something I like about PBS is that currently the blob Market is really weird right because say if you have a very valuable block right as a builder I may not want to add any blob side card to it because it's gonna prolong the delay of the block and then the block could get reorder right so how does they change uh for EPB such that for the incentive to um releas a blobs side card uh in that sense uh I I don't so I know what the answer that you're expecting for me to get and I'll give the answer that you're expecting me to to mention on the other hand from the market mechanism I'm not really sure that this is a deep change uh so today we're aware of only one thing that uh is affecting builders on the blob Market market and this thing is that if you include more blobs in a transaction in in in a block then that block becomes heavier it becomes heavier to validate and it becomes heavier to propagate and it makes your blog more likely to be reor so then there's two things that you there's two things that are in contentious here you are on the one hand a rational actor wants to delay the revealing of their block the most and they want to delay it because they can still extract M up to the very last millisecond and they also want to delay it for example they may want to delay it to obscure information that allows them to be constructing the next block while other builders do not so there's many different reasons why you might want to delay your block as much as possible and those reasons might still be there on epbs uh so but the situation today is that because you want to delay your block the maximum possible you cannot include many blobs because you cannot delay much and include blobs at the same time because you're going to be reared what epbs allows you is that if you see a commitment to your block even though if you haven't seen any attestations for that block you know that the commitment is already there then you know that you can broadcast the blocks very early even before your payload you can can broadcast the blobs immediately and that gives the blobs three more seconds to propagate and to be validated than your own payload so in principle that takes away this disadvantage of including blobs but on the other hand you still want to delay your block as much as possible uh because of what I said even if you are not going to be reor because of the guarantees of epbs uh and you're not going to be extracting more Meb because you're already committed to a payload for example you know that you're not going to be extracting more MV you have the information that this Blog has this state transition function so you can already be constructing the next block and beat the other builders by not revealing your block on time so these timing games are always going to be there and it's going to take some time for us to actually understand them all I'm sure Builders are going to know these games before we do uh but it does seem like the blob Market will get better on EBS oh Kira that's a great question uh sensor resistance what I've described today does not have any implications at all for sensor resistance ship except the following so I'm not talking about any inclusion list nor anything now which is perhaps what you wanted to hear but already PBS without anything I does help in sensor resistance in sensor resistance in the following way uh if I am a proposer today and I want to connect to a non sensoring Builder what can I do well there isn't a relay that only includes blocks from non- sensoring Builders the major relays they include blocks from both sensoring and non- sensoring builders that means that if you request uh a block from a relay even if you're only one to take blocks from non sensoring Builders you don't get that guarantee because if the sensoring Builder has won the action the auction in the relay you're going to get it from that sensoring Builder so a proposer today cannot choose the Builder a proposer today can only choose the relay of course we can socially enforce this by having a relay that only includes non- censoring Builders but this doesn't exist today uh and if it did it would be a trust in a trusted way uh even in a trusted way at least epbs makes it easier it makes it so that the proposer can get a list of builders that they themselves advertise as non- sensoring and you only contact those Builders and that's it uh now which is your actual question like can we do something about sensor resistance yes we we can uh the current version of epbs is compatible with EIP 7547 which was uh proposal for inclusion list that did not make it into this for but might make it into the next one there are alternatives that are being researched today uh inclusion list is one way of dealing with the with um with sensor resistance ship in particular forced inclusion list those are inclusion list that will not allow any payload unless uh the payload includes those transactions and yes those there are mechanisms to to to deal with those uh the reason 7547 did not get included was account attractions and some edge cases that we found shortly uh before they this EIP was scheduled to be included in the fork and epbs makes those issues slightly better but it doesn't solve them completely but at least it solves the four choice part of them uh but today we're researching into different Alternatives there's uh four Choice uh enforced inclusion lists that seem to be they they are based in a committee instead of the proposer deciding the the sensoring transactions and those approaches seem to be better uh research is new so it's not really clear there's a question by Jorge I assume or Georgie could you speak it up sure uh in slot auction since a builder has Monopoly after they win the slot the Meb found after the auction can't be burned or paid to validators why is this preferred to block options where they have to specify the block oh okay yeah so so there are uh there are a several iterations on top of uh block Au on top of EBS with block auctions we can go to slot auctions and then we can go to execution tickets or we can actually do the full separation between the attester and the proposer which is the one of the latest goals of of the research on that on that field I I would encourage you to have a conversation with Ray about this instead of me I have strong opinions on the matters but but they they it's their field of research which is the I think they're most more qualified to answer those kind of questions but there's a tradeoff uh there there's a trade-off you can burn that me if uh if you make the auction very far in advance then in theory what's going to happen that's what the theory said that if you make the auction very far in advance like 302 slots in advance as execution tickets wanted to do then the buyers would be buying on the average price of Meb it's going to be smoo out and then what you burn is that the fee of the buying of those tickets uh on the other hand there's this argument that the risk price that you need to Discount the risk because of this time in advance that you are paying for the ticket then that is not being captured by the protocol uh yes so the I think these kind of questions that are Market related I'm not the right person to be uh to be asked those questions and I would asked these questions to uh to the Rick crowd uh I'm more interested in the safety concerns of the of the and The Trusted assumptions of the current protocol than the market assumptions of thanks uh there's one thing that is worse I think than than the Mev that the Builder would be extracting out of the slot auction uh one problem on block auction is that is the ux of this if I send a transaction after the auction has happened then my transaction cannot make it into the current block because the payload was already committed so this transaction can only be checked even to be checked that is going to be valid you can only check it in the next block so from the point of view of the El there's some changes that are not hard for that are going to be have to be taken into account because now the El is going to be propagating a transactions that might actually be invalid once the already committed payload makes it on chain uh so so epbs in this sense might lend itself to some spamming in the network U we need to analyze that so these are the kind of questions that I'm more interested in about like safety concerns of the protocol we have like five more minutes I think uh I think this was scheduled for 1 hour I don't know so we can uh all are there any like good projects if any of the EPA Fellers want to contribute to epbs in general like besides prison code like what are some other like useful thing you think people can help on I've heard from one fellow here I think Dan who's working on delegation that has some tangential con uh connection with epbs uh I I think fellows would be welcome to work on the Builder API yeah so delegation seems like a cool project more connected directly to epbs I think working on the Builder connect the new Builder API would be good understanding what is what what will be the Dynamics on an epvs World on how Builders connect to to open sourcing for example the relay code would be great uh so that's that that is that is a neat a neat project flashboards has a relay today uh open sourcing it and making it fast so that any Builder can actually open an HTP Point um having the design for a contract so that on chain proposers can find which Builders are and what are their addresses that the builders are advertising their payloads that's a really cool project so that you don't need to gate uh Builders by say e research or if uh e Staker posting lists of Builders you can just have a contract and anyone can submit to that contract their address I am sending bids in this address uh so that's cool project there you can contact me and I have a bunch of projects that I think are cool to to code and we're none of us is working on any of those those are like future iterations of over epvs one good one on top of my mindent chice sorry go ahead oh yeah so I was to say one my mind is is that current like four choice is very complicated it's probably the hardest part epbs I think writing like iteration of like four choice SP tests will be very valuable that cannot force you to understand how for Choice works but then also I right python to generate SP test which I'm really happy to help someone with it but yeah I really want to get that done that will be helpful for APS also no U there's a yeah uh I wouldn't I wouldn't want to get that's is true uh I wouldn't want to get too far ahead but but yeah we we need we need uh spec tests uh we do need spec test and we haven't generated them um it would be cool to happen there's no time probably to talk more on Builder safety concern so if I have if I may have one question on it the final sure um I'm here until Mario kicks me out so it's fine okay so Builder is it connect builder needs to see I'm paraphrasing you builder needs to see the payload uh be in order to be able to say okay I'm going to beat this round or I'm not going to beat this round is this is this related to Builder safety or related to you know censoring or being you know allowed to S to to to not beid if they want to censor no no it's not about bidding or so if if I mentioned during the talk that uh the builder needs to see the previous payload it's just to Simply know what is the state right so how does a builder work you have was in context I'm sorry this was in the context of inclusion lists on on on R&D Discord so that's a different thing okay so so this is a very different thing uh for every one that is not following that discussion there's one of the one of the approaches to inclusion list there is a new proposal is to have a committee that sends transactions or send addresses uh and and and nonsense um as a form of like a an attestation um these are the transactions that I would want to have included in the next block and then the someone in the this case would be the Builder would aggregate those uh inclus list and send an Aggregate and then the next builder needs to include these transactions needs to satisfy this aggregate okay so the problem is that uh the problem is that in order to build the inclusion list to say which transaction should be in the inclusion list you definitely need to have seen the previous payload because whatever transaction you want to have it included in an inclusion list needs to be valid after the last payload that you buy validated right so these are transactions that need to be executed therefore they have to be executable so whomever builds the inclusion list needs to have seen the last payload and needs to have validated the last payload too because they need to know that these transactions go after that payment so that's a hot path that I don't want to AG to to add after epvs because epbs gave me this great thing that instead of having two seconds to validate the payload now I have nine and I don't want to lose that so that's one contentious the other one is well if you made this as long as possible the maximum would be six seconds because that's as much as the next proposer has anyways and then the problem is okay now you send the inclusion list six seconds at the same time that the proposer is supposed to send the block so therefore the Builder that is beating does the Builder know what is beating him or not so if the Builder hasn't seen the inclusion list you might be a sensoring builder that now you're forced to either sensor or pay the bid without revealing your payload so if you're a sensoring builder you will not even bid in these conditions not at all which is somehow might be good you you might think that it's good but on the other hand it lends itself to this attack in which I am one malicious person in the committee and I send you a transaction to the Builder that will look like as though you can actually get a lot of reward by front running me so you beat a lot but then at the same time I sent this transaction on the inclusion list that invalids that uh that Arbitrage opportunity so the Builder is in a in a conundrum he either satisfies the inclusion list and has a valid payload but he lost a lot of money because he had already bid on this Arbitrage that doesn't exist anymore or he satisfies the Arbitrage but not the inclusion list and therefore his payload is invalid so these are the sort of like uh the tricky situations that appearing in that design right so you'll say let Builders let the Builder always see the the content I think the builder needs to know before bidding they need to know what they're bidding on what are the constraints of the block that they're going to be building got it hi go ahead I can hear okay um so I was going to ask about execution ticket and creating an new protocol market for for buying and selling of bids and I have little concerns I'm thinking the protocol is um tending towards a system where is becoming very fragmented don't you think on the long run it like opens up a lot of security concerns I'm sorry I I'm I'm I don't understand so I can barely hear you what what are the security concerns on what on the payment for execution tickets no and what concerns on the system becoming very very fragmented sort of what system um by time you separating um when I was checking the road map for epbs and it looks like further down the line they are going to be things like um execution markets for buying and selling of ticket propos can go and put their rights to create blocks up for sale and stuff like that so I don't I think for further down the road ethereum is looking much more it's looking like it's going to get much more segmented and fragmented like being brok down into like different places so I don't know so yeah I'm not really sure I follow uh on how this fragmentation is happening like uh today the system is really much involved today and it involves like several moving parts that are off protocol getting together to build a block there's the validator that is part of a large pool that is sending requests to different relays that are gathering blocks from builders that that are themselves Gathering bundles of transactions for from Searchers and are themselves solving a hard problem which is knap problem of how to build these bundles them how to collect these bundles and order them in the correct manner which and each bundle within themsel is an ordering of transactions by themselves so so there's a lot of like different parts different moving parts that are getting together today in a very short amount of time which is the critical time of proposing a block if anything the designs that we are seeing in the future make this fragmentation better distributed throughout the slot and better pipelined in a way that not only they can still happen they can happen more efficiently and they can happen in a trustless inal manner uh so I don't yeah I don't see how this actually decreases the security of the system rather it allows player to play Within the system and it doesn't disallow the players that want to continue playing the previous manner so whatever worked before will continue working if validators want to continue using the previous software so our task is to provide a way that we think is safer we think it's more open um we think the validator might want to use it just because of that but I canot force validator to continue using whatever was working for them before any more questions question regarding the project idea so it seems people haven't reached to consensus regarding implementation details yet and so I wonder what do you expect from making prototype of DBS and if we are going to make a prototype what do you think it should implement oh so I I I don't know if you were here at the beginning of the of today I posted links to the EIP that is open and and this I'm going to post them again and uh and the pull request to the consensus repo uh there is not there's no consensus on the community about what version of epbs or if epbs or lots of questions about around epbs mostly about me there's I I I admit that there's no consensus no broad consensus among the community there is consensus about client Debs though uh CL devs which are the only ones that are involved in this Fork will be implementing this finding bugs on this and each rating over this spe I think this is safe to say that at least three of the major major CL clients are already having look having people looking into if not the five of them actually have already people looking into this uh python spec they've already read it they're readying it we have a bi-weekly meeting every Friday and everyone is uh free to come uh Terence if you have the link to the PM repo uh you can probably post it um so we are already iterating over this spec so the implementation details I I think there's no contention here these are the implementation DS what what there's no no no consensus on the broad Community is not about the implementation details but rather about the protocol itself so I'm less concerned with that I've already did my best to try to do the politics and explaining why I think this is good and I'm hoping that I convince enough people that they themselves can actually now do that work uh I will from now on focusing on just implementing this particular form of the consensus mechanism and talking to other client devs because we're iterating and finding M finding small bugs like withdrawals should withdrawals be processed on the payload or should be processed on the consensus block these kind of things these are really minor things right so if I'm correct if I'm hearing you correctly uh there is no consens of across all Community but as long as client devs are agreeing on some certain set of implementation details we are going to have that update be applied to the oh no not at all that's that's not what I said in any form uh for an EIP the the governance of ethereum is a very complicated subject that I am not uh very well vered therefore I try to not participate more than just giving my opinion on what I think is correct and what I think it's not uh the fact that every client would Implement something that does not granted to be included at all take eof on how many years has taken for it to be scheduled on a fork eof has been implemented by every single client but death by but G for many years um so there are many many aspects in which client deaths might be uh in agreement and how to imp Implement them might be in agreement of having a proof of concept we might even have a death net for it like verle has have a de net for the last two years and hasn't been scheduled in a for yet uh and the community is what ultimately decide what gets including to a fork or not all I'm saying is that if client deps will now start iterating on a particular design it would be this design there's no other and this is a very simple answer because there's no other Des sign out there it's not that I've seen that anyone has seen any python specification for any other proposal but this proposal so clients if clients want to start implementing something this is the only thing that they can actually Implement because it's the only one that has been specified gotcha that clears my mind a lot uh actually I'm interested in participating the prototyping epds so I wonder if I want to proceed with that how can I what what be the best way for me to oh yeah so so this will depend a lot on what language you feel more comfortable with and which client uh code you feel more comfortable with we at prison we already have a branch and we our client is written in go and we already have a branch and we're already advanced in uh implementing this protocol but other clients are already starting uh either they have a design doc or they have a plan on how to implement this it's just that everyone is rushing through Electra but as Electra time is being freed people are looking more uh in depth into how to uh implement this so my advice would be choose your language choose your client that you feel more familiar with and contact those CL devs and ask them I know for a fact that uh Dustin from Nimbus is looking into this en rco from Teo is looking into this pan from Lighthouse is looking into this uh and um uh haaj Jinder from loar uh is looking into this so I suspect that every client if they don't have a branch yet will soon start working on a proof of concept I'm hoping more than suspecting but I think this will happen so if you just contact any of them might actually just be very very happy or if you contact us in our Discord we already have are running a branch so I can point you to the branch where prison is having this implemented great thank amazing thank you so much Poes for for your time today and answering all sorts of questions here um we'll create a thread in the uh protocol Fellowship channel in uh the R&D Discord server if any of you guys have follow-up questions for Poes or or anything else around epbs uh we can post them in there um yeah yeah thanks again pus for for your time today and for giving us this watch VVS yes thank so much uh yeah we went bit over time but I think it was a bit lat it was really great we learned a lot uh thank you so much pus for like you know uh no uh uh just just just the real uh real important stuff technical topic uh really enjoyed it learned a lot man thanks a lot um and for everyone else I wanted to say um uh that I'll see you guys in Brussels and otherwise next week we'll have the stand up probably not the office hours uh as normal and a week after after uh the ETC we will have office hours back uh for the pro project presentations um uh not the these sort of amas but we'll have uh we'll have you guys to present the project um yeah uh po I'm not sure if you guys are coming to it probably not teren is teren is awesome yeah so I hope to meet you there I'll send you some details about our event there so maybe you can meet some follows if you if you have space um yeah awesome yeah thank you so much guys I really appre