All Core Devs - Consensus #127

Transcript

[Music] J

[Applause] all

for

Danny Ryan: okay we should be live um YouTube people let us know if you cannot hear us well you know you can't hear me so anyway um allore devs consensus layer call 127 this is issue 951 PM repo there is link we have quite a bit to talk about um I have a feeling

that we're gonna have to again keep continuing this conversation over the next couple of calls but hopefully we can make some good progress today uh generally on the agenda we're going to go over to neb um anything anything we must discuss as well as some discussion around manance scheduling um there was a what I would call um pretty minor incident on mainnet but one that might have you know significant things to talk about uh so I don't know if there's a postmortem out but I do want to just give us room to talk about that in the event that there are critical things to discuss now um I'd like to keep that relatively independent of the discussion of epvs uh which would come a bit later

then we'll talk about electure again um May maybe we're settling on a joint name and have already but let's talk about that briefly uh EIP 7549 which has been agreed to be included has a bit just some I think minor design considerations that we w't escalate then the conversation around various things uh that may or may not go in we continue conversation then open discussion okay let's go ahead and get started um on daab I believe we have forked another public test net uh is there a general status update or any um thing that we want to discuss in related

to test NS and testing

Parithosh Jayanthi: uh yeah so we hit the holky for yesterday and since uh the fork went well uh we did we barely lost any participation rate and it looks like we were getting Globs from quite early on um besides that there's been nothing we not noticed um at least on H ski and we've done uh We've passed a blob expiry window for girly so we ran a bunch of nodes and are doing a mixture of Genesis sync as well as checkpoint sync and all the checkpoint sync nodes El and cl other than the archive ones have already synced ahead and the archive ones we

should have information within another day or so

parents to note is

Terence Tsao: that I'm not sure if anyone is watching but um the slot zero where the four transation Block it's actually missed so someone didn't send that block and then the slot one was arrived but it was arrived at my local note it was 11 second later so so like honestly um this is probably not a big deal but like as a client team it's probably worth checking whether this is um your implementation that's um causing the delay um we are also checking the background make sure PR validator is okay under those scenario because I

suspect maybe the four transition may take like more than a few second here

Danny Ryan: so yeah this is on

heski yeah this is on heski got it

Danny Ryan: any further comment or discussion on that point specifically terces okay um when I'm curious when you're sinking from Genesis past the prune window um is there do you have to bring in a piece of main net information that is within the prune window or can you do so

trustly

Parithosh Jayanthi: right now we're struggling to sync Genesis on gly to begin with because I'm not sure there's that many

gly archive noes yeah so irrespective of expir and the checkpoints sign notes they work fine very cool

Danny Ryan: any other um discussion points for denev dun in relation to testing test Nets

Sean

Sean Anderson: um so we discussed this a few months ago but in a scenario where the chain hasn't finalized for the data availability

period the way to recover would be to checkpoint sync from an unfinalized checkpoint right and also that generally just be useful for like some sort of social recovery in a long period of non-f finalization

um so

Danny Ryan: by recover you mean be able to sync during that environment you could still follow the head in that environment

yeah y

Danny Ryan: exactly

Sean Anderson: so we've been working on like enabling this in Lighthouse and it was actually kind of tricky because um we look at like peers their finalized Epoch and compared to our own and we treat this as sort of like a virtual

finalization so we would just assume we were ahead of all our peers and it would stall our sync on our nodes um so I would just encourage enourage other client teams to also look into this because it the type of thing that we thought should work until we really dug into it

Danny Ryan: right so in the event of issue don't just assume this is easy you know run into something I me that is there any other any further comment or any uh more color on why this was difficult

Sean Anderson: for us specifically it was because um it

was because of peering um like we treat we treat the unfinalized checkpoint as finalized and this is good internally in that like you're sure to never reorg and whatnot right um but your view of the chain I guess your view of like which peers are useful that was the specific issue um yeah

Danny Ryan: I see do you end up reading finalized information from that state and using that for your peering information was there

Sean Anderson: uh no the we're using the essentially like the unfinalized

checkpoint and we assume that our node is actually further ahead in sync because we're comparing that to other chains actual finalized checkpoint which in the scenario would always be lower so we end up sorting through all our peod and saying that they're all useless

Danny Ryan: yeah yeah what I'm saying is is is the workaround to then use the finalized information that's actually written in the checkpoint State not the checkpoint State itself

oh

Sean Anderson: so now what what we're doing is we're making sure that like Lighthouse is aware of if it's in this particular mode so it's aware of whether it was started up with a non-f finalized

checkpoint and when it's comparing itself to peers it'll take this into account instead look at like uh the head the head of the uh Pier chains

okay oh

Danny Ryan: did you have a comment

oh no

Potuz: I'll ask in the chat it's technical yeah

Danny Ryan: all right thanks Sean anything else on this one

Sean Anderson: uh that's about it but if anyone runs into similar issues feel free to reach out

cool other denb tun testing items

Maron

Marcin Sobczak: yeah right now I'm spamming gly network with blob transactions as far no issues but it's like uh one third of experiment so if there will be some issues we'll see it in in few minutes maybe half an hour from now but yeah as far everything uh looks fine

Danny Ryan: great thank you any other Danon testing related okay great work um I believe as has been

broadly discussed over the past handful of calls and much more concretely discussed on the last acde um there's an intention to talk about and pick a mainnet date

Tim

Tim Beiko: yes so um yeah my feeling is on the El side teams are generally pretty ready um to both pick a date and then start putting out releases for it um I think there's not too much uh uh strong opinions about what the date should be and like obviously getting CL folks's perspectives on that uh is valuable um and yeah I mean if I can share my screen

I have a bunch of potential date like the next uh month is um so assuming that teams you know are ready to put out a release in the next week or so um I think these all make sense generally we probably want like two three weeks between the announcement for mainnet and then the actual Fork so uh we should pick a date that like um yeah teams like we should figure out when teams are all comfortable having a release and and then pick a date that's a couple weeks after that um and then yeah all the times on this sheet up put this in the chat but all of these are like the uh

Epoch uh history accumulator boundaries um and they're all sort of midweek so between Tuesday and Thursday um so yeah curious to hear from client teams if they have any preference on or maybe yeah it makes sense to hear from Cent teams like when they could have like mainnet release out and then based on that maybe we can pck itate uh yeah

Danny Ryan: so maybe maybe a bit more concrete Tim when speaking with execution layer teams is everyone we

Tim Beiko: could have releases out next week yeah

Danny Ryan: meaning by Friday of next week by sometime next week

Tim Beiko: so I

think like the earliest that from the El side we could Fork would be uh the 2728 which would feel yeah okay so Maris is saying they can get one out this week so like I think yeah the most aggressive timeline on the El side is really um is really like the last week of February um and teren has a question in the chat so uh hearing about L2 testing so I reached out to all the teams that were in like the top 10ish on L2 beats uh this week I think uh pretty much all of them got back to me but the no one had any major issues all the teams are pretty much in testing phases at various stages um the I think teams are like will be ready on

the L2 side to use 444 on mainnet around early to mid-march um yeah so um that's that's basically where things uh yeah where things are out from L2 so I don't think we should block anything based on on um on where L2 teams are at and I think from the El side we can have people um people start releasing this week and then potentially the relas is coming out next week for the other teams and be ready at the earliest uh end of February

Danny Ryan: real quick your doc does not have open access

shared

Danny Ryan: okay cool

Tim Beiko: yeah I I'll post an actual screenshot in the chat too

I think it's interested um Terrence

Terence Tsao: yeah so from PRM side we survey

the question internally on when just like when when we will be ready to do this major release so we still like two weeks because we still have to do some general clean up and we want to test blood Feld further so I don't think we'll be ready to cut our relase next week

Danny Ryan: but would be by Wednesday Thursday following

Terence Tsao: uh most likely yes two weeks will yes two weeks will be better

Danny Ryan: any other perspective input

on where you stand on where consens lay teams stand on being able to release

Sean Anderson: um I think for Lighthouse probably same sort of timeline like Wednesday Thursday week after next

Danny Ryan: okay on the consensus l is anybody anybody not able to hit that Target um which would put us at you know a main net blog post on that Friday of the following week at the latest um if we agreed on that Target which then we'd have to pick a date that puts us in a good time frame from

there

okay thank you yeah let's start perspective loell star Nimbus

Phil Ngo: yeah we can meet those timelines for load star thanks

Tim Beiko: so I guess then the two dates that are like most reasonable is either Thursday March 6 7th which would be like a straight two weeks after the releases and or Tuesday March 12th which is two I don't know two weeks plus like three

four days two weeks plus a weekend um after the releases um yeah I don't know there's a strong um okay so there's a debate in the chat between 7 and 12

Alex Stokes: is there a good Reon not to do it as quickly as possible

Tim Beiko: I think as long as we have two weeks is from the blog posts that's like reasonable um yeah

Danny Ryan: what's the shortest we've done on Main before Tim do you

know

I think

Tim Beiko: we had one um yeah we had one short shorter than that but that was not great

Danny Ryan: okay what's the shortest we done when we were in emergency

Tim Beiko: probably on the or I I'd have to check um but probably on the order of like yeah two three weeks um so we can do if people feel uncomfortable with that we can do um we can do like the week of March we can do like the 13th or the 14th which is like closer to a full three weeks if from the chat that seems to be uh the main uh yeah the main feedback so the yeah the 12 was the 12th 12th is Tuesday

Tuesday Wednesday Thursday of the week of the 12th each have a a slots that would work so we can if we want to do like closer to like a proper three weeks then some you know doing like the 13th or something is like three weeks

Danny Ryan: okay I think given the given the constraints of conser teams wanting or needing two weeks from now um I think it's reasonable land on y 13 yeah okay you know like if there's if

there's an i I'd prefer 12 13 over 1415 just given the um some room on the post side from the weekend

Tim Beiko: yeah middle yeah middle of the week is nice um and then obviously if client teams have like client teams can start putting out releases as soon as they're ready um today basically uh if we as long as we have the dates so and then we'll have the blog post out uh in about two weeks once we have all the Mind releases okay so I'll post uh the information in the chat

but um and

Danny Ryan: what are we saying the actual like deadline for client releases is okay

absolute L list is this call two weeks from

now so like the

Tim Beiko: yeah so that's two weeks okay

Danny Ryan: um okay any further comment or thoughts on this okay um Tam should we kind of circulate that information allord yes

Tim Beiko: I'll put on Discord and open some PRS on the spec repo and uh tweet about it make it I'll pretty

official

Danny Ryan: great congratulations very exciting okay um like I said I don't believe um there's been a postmortem on the optim relay invalid block incident um but I think we know relatively what happened is there any one do people want to surface details here uh two is there is there anything to do today obviously epvs and other um things that might come in the pipeline are very valid and worth discussion but uh you know are there particular tests that need to be added

or um security things that need to be layered in or it really you know what's the is there anything to patch today

okay is that

Potuz: that what do you mean by tests what do you mean by things that we can do right now yeah yeah

just should the surface something in immediate one

Potuz: there's an immediate one we can just change our circuit breaker so that if we see invalid blocks we start we fall back to local production we are only doing this on M blocks on enough M blocks in

an EO but perhaps we can be much more aggressive with invalid blocks

Danny Ryan: is no one circuit breaking as invalid as though invalid is missed or or just there weren't enough

Potuz: we are all circuit breaking on missed blocks and we are circuit breaking an invalid block only counts as M what I'm saying is that we can add another test that if it's invalid which is increase the frequency

Dankrad Feist: right but I mean that's also like that potentially allows for dos attacks right if you give a highway to what do you mean dos attack Bic you're going to hold back to local

production

Danny Ryan: right but if you can get all of the quote honest players to fall back to local production with a couple of invalid blocks then you might be able to donate MV Market more easily so there's certainly a tradeoff between those the ability to turn this thing off or how easy it is it turn this thing off

Mike Neuder: yeah you could Sean Sean just said this but yeah if you check the proposer signature and that it was invalid those two things would be pretty strong signal and the only person who could send an invalid block would be like a proposer intentionally

Danny Ryan: oh that's what I mean but if you're 20% of the network and you can turn it off with two blocks for everyone

Dankrad Feist: any Builder any Builder can

do it and any build can intentionally just trly generate and they just have to be the highest bidder so like I just have to take whatever number the minimum number of invalid blocks after which return

office

Potuz: but I still don't see what's really the the attack here into making people fall back to local execution I'd be happy if Builders didn't exist even

Dankrad Feist: well but okay so but I as a poor for example let's say I'm a pooled having 20% of blocks and I can disable uh like math boost for everyone else by sending three invalid blocks

like the cost of those might be low enough that my 20% block that afterwards I get I get so much me out it out of it that worth it for me so it it is an it is an attack on all the other validators who follow this rule

Mike Neuder: yeah and also you don't have to circuit break yourself right like that pool can still keep using me boost

Dankrad Feist: exactly there's no enforcement for the circuit breaking it's a local thing so it's basically a disadvantage for you to have two aggressive circuit breaking so like irrational people just won't do it

Mike Neuder: yep agreed

Sean Anderson: um so usually when we add

something like this though we make it configurable so like it it'd be hard to specifically um like know that you're going to be able to get some proportion of the network offline or even like certain proposers offline and it's also we wouldn't have to agree across clients on like let's do this after one bad block

Danny Ryan: yeah then again you know s defaults are strong and uh the more that you send the more you'd see the network switching their Behavior so um yeah I I agree with you but I also agree that like depending on the level

of the attacker it can still be a profitable Avenue and they can kind of Ratchet it up um I guess one question that's worth escalating is um obviously a lot of the kind of Mev boost me monitoring tools are extremely aware of builders relays you know they see this information surfaced in in U block explorers and and all sorts of analysis you could imagine circuit breaking more specifically on actors but the protocol doesn't know about the actors so is it actually is there actually a reasonable path to Circuit break on a particular Builder or circuit

break on a particular relay um or is that to kind of fistic in in trying to decide who those players are without a native integration L1 integration

Potuz: well you could add some logic to me boost arguably everyone is using essentially the same software and you could add some logic it's up to M boost to to ban particular relays

Danny Ryan: right but do I do I know that the relay was bad if if if you're interacting with the relay you probably know it's bad but if

you're interacting with the relay and it gives you something invalid then do I know like can the entire network know that so I guess

Dankrad Feist: like currently we don't have a proof that a particular relay created a block right because just because it goes to to that relays address someone else could fake that

Danny Ryan: it's presumably authentic you know talking with them is authenticated on some level so you could share that as a gr yeah yes

right

Dankrad Feist: right but we don't currently have that right okay

well so B

Sean Anderson: bids are signed right AR

aren't they signed by Builders or they signed by relays

Mike Neuder: they're signed by the Builder but the relay verifies it and that that doesn't go on chain like the that's just from the relay to verify the identity of the build that sent it

Danny Ryan: right

Sean Anderson: so we would have to like broadcast bids or something

yeah that's what franches been suggest chatter

Danny Ryan: these things yeah like if there were a if there were an optional gossip Channel I could I could drop this information to the network

Mike Neuder: yeah this this kind of sounds like the optimistic V3 version which we talked about a long time ago but the idea was like you have a a gossip channel for the headers and you have more observability there um I think the main issue here is that like in terms of latency the proposers probably won't get their bids from there because it's just a lot slower than directly connecting to the the relay Builder

Danny Ryan: oh right I'm not saying I'm not saying utilize that channel for selecting the B I'm saying I is the person that interact with the Relay can drop information about my interaction into such a channel so that people can act upon that you know if I see that who you interacted with and I seen in val

block my local setup could say oh I don't want to interact with that entity anymore yeah

Mike Neuder: that's fair

Danny Ryan: okay I I don't mean to say this group should decide you what should happen I just wanted to kind of go through the exercise of deciding if something can happen um that does not require protocol changes to at least contextualize what people might be able to do soon or talk about in followup conversations um is there anything else that we want to discuss around this

I

Mike Neuder: I guess it's worth mentioning that this was a bug in like the non- buggy version of optimistic relaying wouldn't would have only resulted in one miss slot so it's not like the optimistic model allows for this it was just like there was a bug in in the relay end so I I don't see it as like fundamentally changing anything

Danny Ryan: and was the relay is the re was the relay bonded and is the relay doing something with back to that Bond

Mike Neuder: right yeah so the builders the builders are bonded with the relay um in this case since it was the relay's fault they refunded the proposers directly um Ben from blocks route was on this Twitter space is yesterday talking about it so yeah there

that's already taken care of in terms of like the the restitution I guess

Danny Ryan: which is kind of one of the one of the attempted things to happen with optimistic relay is to ser quote at least via uh trust model unconditional payment yeah

Mike Neuder: yeah exactly I mean it's not really unconditional because you have to trust that the relay will refund you and I think that's that's the issue that

um it's

Danny Ryan: it's trust that they'll refund you and otherwise the network probably the assumption is people would then not use that relay anymore because

the trust yeah exactly

Mike Neuder: like if blockx route chose not to refund the like one eth worth of missed slots then like I think they lose a lot of credibility in terms of the validators connecting to them

Danny Ryan: okay anything else here we will have some discussion around Uh current APS designs coming up in the Electra discussion okay um is anyone that works kind of in the me boost specs me boost landscape interested in specking what a gossip

Channel around proofs of this kind of stuff would would work on or is how that would work or is that not something that people want to dig into right now

Potuz: I'd be strongly against it because if we are going to go with a protocol change that does something like this this is already covered in epbs this is literally covered in epbs

Danny Ryan: right I guess my argument would be even if we're going to ship epbs as the next big as the next thing the next Fork we're still talking about 12 months

Dankrad Feist: I don't think we've made a decision onbs though right like I mean corre we're not

that a very conditional

this

Dankrad Feist: this depends on actually having a viable Construction so I think like I don't think we should presume anything at this point I agree

Potuz: it's just that my point would be that having something that colludes with epvs I would much rather discuss

epvs

Danny Ryan: all right and let's discuss it in a couple points

Dankrad Feist: why does it pollute it

Danny Ryan: this it it it uh continues to the Band-Aids would would uh I think the argument is the Band-Aids would make it such that EP MF boost can continue to live another day instead of

actually working on kind of the Native solution

Dankrad Feist: no but that's a terrible argument

Danny Ryan: uh I think the argument is not terrible if you consider complexity analysis like if it's 50% as complex just to patch meev boost right then do EPA epbs right then maybe then we're talking about it if it's 1% of the complexity then that's a different world I do want to table this I do want to talk about a couple things around Electra and then get into the EPS discussion um in a couple of points okay there is a desire to figure out

what the joint name of Electra is uh Electra and Prague um it seems like some believe it's already been discussed and named as pectra uh I believe I've seen this in testing and a couple of other places uh is there I don't this is the last thing in the world that I want to be trying to use our decision-making power but does anybody want to make a case that's not Petra with the c um okay I'm I'm gonna take that as some

sort of decision or desire not to talk about this um and we will continue forward great okay um based on some discussions with Don Rod that then surfaced into and others that then surfaced into a comment on 7549 there was a desire to kind of like do 7549 all the way and be able to uh more unify attestations on chain than uh keeping the kind of theual committee index but in a different place of the adest station uh it seems like

that is generally what some of the designers want to do but Mel can you give us some more context and some of the trade-offs here

yeah

Mikhail Kalinin: thanks Danny so basically this is the um one more step on top of uh what was originally proposed by 7549 um and yeah as as Denny said uh it allows to pack uh attestations more tightly on chain in on chain structures and uh what's nice about it is that uh considering the uh current while set size we can uh increase the block space in terms of pations up to four times so instead of

uh currently we uh can keep um arations for two slots um if they're kind of ideally aggregated uh this change would allow to do this for eight uh slots instead of uh two uh without increasing the block size in bytes um this is great um at uh and yeah if AR stations were kind of like aggregated um PR well um this change will all just to reduce the size of a block uh yeah keeping the same information the same number of vots in it uh so basically what's uh how to achieve this um uh is uh turn the um

aggregation bits uh into a list of bit lists uh so basically uh every item of this list will represent the bit list of uh um of uh each com Committee of of a yeah of the committee and uh also the other change we would need here is to turn committee index into committee bits uh of the same size which is 64 bits uh and uh yeah this is going to be a bit Vector which will have uh bits of uh yeah of the Committees that are included into the aggregation bits list so basically it's a quite straightforward change and we can use the reuse the same structure for um onchain Aggregates um

where many committees uh will be in one station obviously signature will be aggregated uh yeah uh for all of those committees um and uh also it can be used on the network where uh just one committee will be um in the attestation uh in this attestation structure uh which yeah is kind of required by the network uh by the aggregation algorithm that we currently have um relatively small changes to the spec uh we'll have to do some you know um uh we'll have to go over all comites uh when processing the AR station um and

uh uh uh the uh dep line made a great point about like U complexity of tester slashing messages and this is really uh one of the um kind of uh complexities here so it basically um This Ti aggregation would mean that uh if we want to create a tester slash and message uh out of uh um onchain data which are tightly packed it will mean that we'll have to say if there is just a slot uh uh yeah a committee which is which will have a size of a slot of uh you know while there is that assigned to

a slot so we'll have to keep um all those in one uh in indexes of all those while there is in one tester slash and message um there is a bit of analysis uh linked into into the um comment um um yeah so we have an increase there uh but uh if we have like this yeah this more uh kind of more of a problem for uh the aest sessions where SL just one or couple of wers they will be uh they can be much bigger than what we have now because we have currently we have a um quite good gr granularity uh

test stations but for kind of like Mass slashings events uh this will not be um too bad um yeah and um we'll probably have to do something at least to reduce the max tester slashings to one so you can read about uh in the comments about this analysis and about the proposed change let's I have gone over quickly really quickly and yeah

Danny Ryan: yeah in the propos changes you're suggesting reducing the number of ating stations to eight given that you can handle a lot in these bit lists does that but that that reduces the diversity of attestations that can make it on

chain do you see an issue in the event there's high asynchrony or forking uh such that you can only capture kind of eight different views or is that do you think sufficient

Mikhail Kalinin: um yeah I think I think yeah it's a good good point I think it's pretty much sufficient uh I don't think it changes the status quo in that regard um I don't see how how differ to what we have today um it yeah it might be even better because we increase the capacity of one block so it can accommodate more votes in it

Danny Ryan: well it's a trade-off because you increase

the capacity but you decrease the diversity of that capacity the potential diversity of that capacity which I it seems like is the proper tradeoff is a reasonable tradeoff for one to consider at least because you you could do another thing right you could have like a more sophisticated counter here that you could have two counters where you have you can have many anti stations that have a small number of bit lists or you could have fewer adorations that have a large number of bit lists but then you're adding you're adding certainly more complexity to get that tradeoff space between the two

Mikhail Kalinin: right but if you uh have many add stations from different slots uh uh yeah

that that can be right right so it can be

yeah

Danny Ryan: right so kind of how I thought

reduce yeah yeah

Danny Ryan: yeah I thought of it before I read it was like you could have essentially two counters um but then certainly more complexity

Mikhail Kalinin: yeah I think over overall I think this uh anyway this change requires more deep analysis and this is basically a temperature check and uh yeah if there is a desire willingness of Cl deps to extend this EIP uh then we can you know um invest more time and analyzing

tradeoffs of this solution but I think yeah this this Chang is what basically um what actually the original proposal uh was supposed to enable um yeah and not doing it not exploring the space um yeah I think it's

Danny Ryan: yeah I think something in this direction uh makes a lot of sense if we're going to be planning up the committee index um and at least the temperature check on everyone in the pr is good so far does anybody have any additional comments okay um I would say we should

go for the the more cleaned up version

Mikhail Kalinin: cool so I'll I'll do some analysis and try to come up to spe changes and yeah one other question I had is probably that we can have it as a separate e but uh we have it in in the next hard for I don't see it makes sense to have it as a separate TP so it can be as um go in the C AP um but yeah if we consider it for lat inclusion it could be separate

AP

Danny Ryan: yeah it seems like the relative

complexity is marginal on top of what was already there so I'd hope not to do it in a two-step fashion but open discussion okay great uh we're going to continue the conversation around what to include or not include an Electra um I believe two weeks ago we did not have our full conversation on to see or at least um give enough time for discussion iton is there anything additional you want to bring to this group um or do people have questions for T again noting that a lot of this complexity is on the execution layer um and so I I do think that a decision

Point certainly the conser can say we don't want to prioritize this but I think a lot of the decision point on on the complexity ends up on the other side of this equation uh but nonetheless

s see

Etan Kissling: uh from my side I don't think I need to add some um more explanations from last week I went through all of them um I think on the consensus side the stable container one EIP 7495 um may also be useful to um have forward compatible generalized index for execution payload Beacon State and beacon block just because those struct keep changing and I

think if we can make them forward compatible it would help decentralized taking pool such as Rocket pool to um require fewer engineering to keep up to dat with the the various Forks

Danny Ryan: right and to remove a piece that NE that might need to be governed um engineering is one thing and then also figuring out if and when and how

and stuff for sure

Danny Ryan: yeah what is the temperature check on doing kind of a one-time change on these data structures to make them forward compatible forwardly

stable

Etan Kissling: for SSC Library it's quite easy by the way it's not a big deal

Danny Ryan: all right does adding that kind of onetime break in the structure of the tree is that a huge engineering complexity does anybody want to weigh in that

Etan Kissling: it's only for new blocks though like from the fork you just have a new block type and the difference is that those blocks you can like you can then use the same parser also for future

blocks and I'm not sure if everyone reviewed this already

Danny Ryan: right anybody want to give any signal in one way or the other uh I have pretty much zero temperature check on

Sean Anderson: it seems like a good thing to have um I don't I haven't personally looked into this so I don't really know how complicated it is I know people are generally wary of like new SS types because like the ones we have are super well tested but it seems like a good thing to have

in terms of engineering work um

changing fast library is always a pain but you know um if it's not too large of a change then I guess we can handle it

Danny Ryan: yeah Casey's servicing that he'd rather wait until this was bundled with more SSC changes um okay is this something that teams want to do a little bit of diligence on and we can talk about again in two

weeks okay I will pop that on the next agenda and um pop a message into Discord saying if you want to take a look at this to have a more depth conversation now time okay um any other SSC discussions great

thank you poas epvs

Potuz: all right so I don't know how to start this discussion actually so so I think the

problem that we've seen on mainnet is not like a light problem or a minor problem it's not the issue that nine blocks were missing or that validators like got refunded or Not by a relay the problem is that we need to trust the relay for this um we don't even know what the check was we don't even know what the fix was this closed Source software and it's happening this development is happening on a black bxs and and these are five players that are relaying all of our blocks or 90% of our blocks and 10 players maximum that are building these blocks uh I think what we need to do is to decide that this is a priority that we should not have in ethereum at

trusted player making these decisions with a close Source software uh being the one that is responsible for paying or not for refunding validators for even deciding which transactions are censored or not uh once we make this a priority then we can discuss whether or not there are viable Des signs for epbs certainly we're not going to be discussing this in a meeting like today I maintain that we have a viable solution for bpbs that could be implemented in less than a year's time and I am willing to defend this in an actual meeting with the community uh and this things should not be discussed in small meetings where

research has some point of view some biased point of view for EF research some other client deps like we are on prism have another biases um and we're focusing on different kinds of design we should have something like the interrupt that is going to happen soon in May and we can uh come up with a design there decide whether or not the current design works or not uh but this what I'm asking is for this to be prioritized and if it's the scope of this work is kept for 2024 then this cannot be included but uh if the scope of this fork or the next one is maintain for 2025 then I would ask that we use the time to discuss these things seriously and to allot the

time for the interrupt in May and uh come up with a com uh with a compromise to ship this by 2025

Danny Ryan: thank you I have a a quick question uh can explain in a theoretically good epvs sound epvs design what would have gone differently in this incident

yes visible many

Potuz: there there minor things that are actually different but uh some of them are the following so the blocks would not have been missed the blocks would have been empty the consensus part of the block would have

been included inclusion list in those consensus part would have been included and enforced in the next blocks no matter how many payloads were missing in the middle uh payment would have been immediate and conditional and for any amount and not trusted by the relay and and finally the block the payloads themselves would have been signed so I would have gotten my value got an ass signed pay yeah exactly the payload itself would have been signed by an entity that is in protol and validators can actually now they themselves decide whether or not they have a way to B them or I mean each client could then de decide if I'm gonna B ban those Builders

or not instead of

Danny Ryan: interact with them on an economic level right

I me as long as someone

Potuz: that is building the block signs set then that entity is responsible for the block currently the validator itself is responsible for something that is not producing so even if a builder decides to go with a relay instead of opening itself a an antp point so that validators ask for the Builder directly for the header even if postive PBS the Builder decides to use a relay the relay whomever is building the block will be signing them and we can ban them we can react to them which is not something that the validators were allowed to do in this event

Danny Ryan: just real

uh Stokes does note that as we previously discussed you could potentially map some of this transparency into a gossip Channel because of the way signatures work today

just corre

Potuz: and we can we can continue patches we can continue adding small patches and small patches and small patches instead of actually dealing with the issue which is relays are trusted Players let's make them trustless

Danny Ryan: thank you uh so we got a few hands up Terrence

yeah sure

Terence Tsao: I just wanted to add on top to that right so today epbs is one solution to the problem but the fundamental problem is that like today the Builder API is not like it's it's

basically not like incentive align with the rest of the protocol right because you have literally 90% of the block that's relaying outside of the protocol but the protocol does not have enforcement on that right and there are two factors right the first factor is basically cost right because Rel are spending tons of money a year they're doing this work but they have no way to monetize it and the second factor is also the schedule right for example when the when today when how so how often um when the client release already and then we look at each other and then we're like well we still have to wait for M boost we still have to wait for M boot Rel so he definitely adds a lot more complexity to to basically um the add

more complexity to the process of the protocol and then yeah so basically I think we need to do something here

got it John

Sean Anderson: um yeah so the I think the idea of separating the consensus information from like the me incentives is it generally makes sense um specific though like I feel like a lot of a lot of the problems could be solved without as extreme a solution as bringing builders in protocol like maybe that is good maybe that is the end state

but like for example guaranteed validator payments like could you do that via using inclusion lists like in the current inclusion list designs you just like require the Builder to also include with their bid an inclusion list transaction um that has the payment then the other thing people have been mentioning is like just gossiping bids I think would be valuable and we could pretty easily Implement some sort of tracking with like Builder signatures Builder public but that's it that's it for me

okay good

Dankrad Feist: sorry did you say

me oh sorry I didn't hear um yeah so I think um so I'm I'm not against epbs but overall I think like realistically all P epbs constructions are going to be quite major protocol changes so the potential Tech Deb that we're getting from these if we don't Implement a good solution if we find out later that it has major flaws or we come up with a much better one is actually way way bigger than fing fixing a few things around uh meus which doesn't actually involve like core protocol changes at all so I think I would be very careful like I think like my feeling is that we are not there at

the moment um specifically with the constructions that I know of that have major flaws in terms of not properly protecting Builders from being exploited in like balancing attacks and things like that this is actually a huge concern I have about them and I think like before those are fixed I feel like it's not really worth implementing them um because to me is a trust like relays have two kinds of trust they have the trust by the validator so you have to trust the relays um and I think that is minor because again like we can easily like Blacklist them if like a relay misbehaves um and like for for example

if said relay I don't know well whoever it was like didn't pay out those valid datas then I think lots of valadas would now say well I mean that sounds terrible I'm not going to use them anymore so um this is a minor part of the trust the big much bigger trust problem is that Rel can um exploit Builders by like analyzing their strategies stealing the m and so on um and uh like if we allow um validators to explo exploit Builders then that part is actually not solved at all and we will actually continue having Rel because Builders will still want that because they can otherwise be exploited and are not willing to include their High transactions and so then in the end we

haven't fixed anything at all we will still have the relays and we will still have that problem

H

Potuz: yeah so I think I know which attack D is referring to on which is something that is not guaranteed on by the this BTC of like designs yeah I'm not I'm not willing to enter into like a technical discussion of what what is a good design of epvs or what's not but I do want to say that I would argue against this being a large protocol change if you look at every design that we have uh they all will have the same set of ingredients so this is not going to

change whether or not you go with BTC or another aration all of them more or less rely on the same sort of like two slots approach two reveals two rounds of votings and one two rounds of attestation one way or another so they're all more or less the same and we are already discussing that there were serious proposals of having inclusion lists and Max CB for the current Fork even scoped for 2024 and those are the largest changes from the point of view of the CL side uh the

the the M

Danny Ryan: component you you don't think is is like a huge engineering change no

Potuz: so no actually not I'm not from the SE side payload validation changes a lot uh because of inclusion list but this is already part of inclusion list the part

that uh the the changes that are actually on for Choice uh for the C on the implementation side they're the minor Parts I am actually already implementing for prism the one design of apbs and epbs alone is much simpler than the rest so adding maxb is the most costly one which is the one that I'm delaying for the end of the implementation

Danny Ryan: okay so my intuition here like getting into timing and fundamental data structures of having kind of this two-part data structure would be a massive engineering uh change but but you you say otherwise that is no

adding extra

Potuz: so adding CH changes that are that are on for Choice are typically not that complicated not

to implement changes on processing are the things that are most complicated to implement uh it's true that it's it's not a light change and it's not something that is going to happen this year certainly but I claim that the biggest part of the complexity of implementing epvs comes from Max CV changes and inclusion lists I mean if we go with a with a bonded uh impr protocol Builder which is uh State

Danny Ryan: okay so there there has been a lot of design and and research and discussion over the past more than two years on this um and you have something of a a spec that

you're working off of and a prototype to demonstrates a level complexity uh there are the last whenever I see this open up there's a lot of questions as to like what are we even optimizing what is the right end goal of this um and it seems like there's a lot of varying opinions on that um and so the decision to include this first becomes the decision to figure out you know what is the design um and I guess are you making the case that over the next few months figuring out if and what a consensus

design is on here should be prioritized or are you making the case that

Potuz: yeah so my my case has been always the same on these meetings in the last few weeks that I think we should prioritize in deciding what's the scope for the current for case if the scope for the current for case is 2024 then I don't argue anything and I I'll argue against any big change and I'll hope that we plan something on the interrupt in May for 2025 if the scope is 2025 then I would argue that we need to consider epbs for the next form uh and either way I would want to have by the time of the interrupt some designs so that we go there and we pick fix one particular

design

Danny Ryan: during and and and that's what that's what I'm going to argue is um if there is a sense of either urgency or a sense of the ability to actually hone in on design at this point um you know regardless of the electure conversations that happen over the next however many weeks there can be kind of a parallel thread uh that attempt to hone in on this design with maybe some breakout calls and Home Design as we meet in person to May um you know I don't think that we can and and so that's my that's my big question is like do are we at that point I believe you

you believe we're at that point that we can we can have like a very productive um three months to kind of hone in on on this uh is that the general feeling or is that is is the feeling that there are when you people from or at least a couple people from various teams are willing to be a part of that conversation to home own design you is the next logical step to have a breakout call about this uh to at least begin to answer the question of whether people are willing to be putting a lot of effort into this or or even moderate and consistent effort over the

next many months okay I see some thumbs UPS I see some comments it seems like at least we'll have five people on the breakout call um okay we'll Tim do we usually schedule breakout call times on the call or do we circulate something async

Tim Beiko: let's try to do it let's try to do it in the chat

Danny Ryan: okay

Tim Beiko: 14 UTC is usually a good time but yeah

indeed e o CL

Danny Ryan: um okay cool let's let's uh bounce some times around in the chat see if that we can get on a call um you know again R&D call that's trying to

bring together the threads or at least um bring together the attempt to bring together the threads all um thank you poas thank you everyone for discussion let's move on to the next thing uh so I I'll just to be frank my read after the call two weeks ago was uh inclusion list we're going to the general consensus was was to table um my read on that was challenged by a number of folks uh and said no there's still discussion to be had um and not just from the authors of inclusion lists but

from a number of of folks so it is back on the agenda and Mike has had some I think very very Illuminating especially the spec change overview to help us understand the complexity Mike do you want to reintroduce this topic

Mike Neuder: yeah sure thanks Danny um I guess I'll post two links in the chat uh the first is this unconditional e research unconditional inclusionist post on E research and then the second is the one Danny mentioned which is this uh overview and yeah I guess the the second dock the first DOC is kind of going through this new design and um kind of discussing the relationship with

the 3da post and kind of like bringing back some of these these design that we've been hashing um I think actually we're kind of converging on something that that we're all happy with and so I started kind of just taking a look at the spec which is that second doc um in general it seems to me like the goal of that dock was rather than trying to like iron out each of the kind of individual points fully more to kind of scope what the changes in the spec would look like which parts of the spec it would touch so both on the consensus layer side and the state transition function for the execution layer and in the engine API um just kind of defining the interface

between the two so yeah I guess thanks to all the the members most most of them in this call who helped kind of scope that up and and review those PRS but um yeah I think in general trying to convey the message that it's it doesn't have to be a massive change and that it could be really beneficial to include it in Electra just from from both the timing perspective of like that censorship could could change dramatically over the next months and weeks um there's one kind of one Builder one neutral Builder that we depend on to include you know a certain subset of transactions and that

could could change very quickly and also just getting some version of censorship resistance in prod and like starting to collect data on its usage and you know I think of I think of um censorship resistance as like this defense in depth thing where there might be this might not be the end game but like some of these farther out research ideas like multiplicity and you know they could all kind of synergize well with inclusion lists and yeah I guess in general it feels worth worth trying something rather than letting it go go longer with the current censorship um that we're seeing on mainnet now so yeah I guess that's the pitch that's the the reason I wanted to get the spec do out there um I I think have talked to a number of

different client teams uh both on the execution and consensus side um just to kind of get their take and and generally people seem Keen to learn more and and happy to engage so not sure exactly I think maybe like a breakout call for inclusion list specifically could also make sense um Shia recommended that so if that feels like a reasonable next step we could bundle it with the epbs talk I mean I definitely think there's a lot of overlap in terms of the themes that'll be discussed there but um I also think having its own talk could be useful potentially so yeah thanks for thanks for the time I think I'll I'll leave it there unless there's any urgent questions I guess

Danny Ryan: yeah has um has anyone been able to look at Mike's spec change overview and want to weigh in on complexity perceived complexity okay okay um is there an appetite to get a call with Mike and others that have been doing R&D on inclusion list to dig a bit deeper

um sometime in the next 10 days poas

Potuz: so I this the sign is essentially exactly the same as what's already

included in our epvs proposal uh and I definitely want this in but as I said before if we're going to scope this for for this year I think it's impossible I think a big chunk of the complexity of epbs is included in this and in

Max EB you keep saying Max EB in relation to EPS is Max EB a dependency for EPS

Potuz: well not not for epbs the same thing for inclusion list inclusion list shouldn't be a dependency of epbs but both of them are right pretty much a requirement for for my kind of

epvs

Danny Ryan: um right I I did I did take a look at the spec change overview um and was moderately convinced that it's actually not a super complex change um but you you believe that it it is a large portion of the epbs complexity already like you would say it's 50% of the epbs complexity or 35%

Potuz: no I'm not not y I think the for epbs Max CB is the thing that scares me most

Sean Anderson: um I also checked out Mike spec and I did think it looks simpler than I was

expecting so I definitely think it's feasible to include an Electra um I think I still think Max ebast seems like a more important change to me just because like at some point the size of the validator said like is going to be an issue and the migration itself could take a while um but yeah I I think right now I would lean towards trying to include both Max CB and inclusion lists and not do full P epbs um but yes just personal Vibe right now know if that's too much

but

Danny Ryan: and what's your perspective on since we're here uh P do and where that may or may not fit into what we want to do here

Sean Anderson: well so like I think the pios changes are like since they aren't hard Fork dependent like I'm not thinking about them as much like uh like to me it seems like they can be worked on in parallel to like a a greater degree than some of these other things um but it's I mean for us it's like I would say that's the been the highest

priority change and it's got the most progress on it already so yeah

Danny Ryan: okay back to the question um is there desire to have an inclusionist breakout is there desire to have it as 15 minutes of the breakout that's scheduled for EPS um how do people want to approach discussing this further or at least wrapping their heads around a complexity and and making informed decisions from here

if there was a separate one would people attend seems like Franchesco Terrence Mike others would attend on okay well a few people will be there um let us discuss in the chat uh are we agreeing on other eips for inclusion pcture in this call we're continuing to talk about some of these big ticket items um that have a difficult tradeoff space in terms of

when to add them if to add them uh when to prioritize them and competing complexity and priorities so yes I don't know if we're going to agree but we're going to continue to talk um so the next thing is on the list is Jos uh this H like I I'll echo my opinion on one one of the authors here um I think it's at least from my interpretation a number of teams intend to put networking resources on this it is has a good degree of high paraly ability and doesn't necessarily have to

shipped you know with the same type of work um the shipping pios without a hard Fork means that there's no gas change but that's also that is a potential strategy to do here um also shipping pust with a tiny Fork to change the gas the data gas limit is also kind of a feasible path um and so I do personally think that like it can continue to be on kind of an independent R&D rail that is highly paralyzed um and I guess that's at least for at least for a few teams seemingly the intention because

that's just what's happening um is there does anyone want to make the case for not only having it on Independent R&D rail uh to be shipped when it's ready but to also make the case for having it stated and intended to actually go out with the lecture at this point or is that just not where people stand on this again does anyone want to make the case to say pios should be stated and and intended and put into the list for Electra or should it just remain as a

high priority paralyzed rail um the the default is the latter speak now if you believe the former

Sean Anderson: uh so I just sort of think the if we pursue some of the bigger ticket items in Electra and it's I think it's possible that since pias is just CL and would require like smaller uh changes for a hard Fork then maybe it might even come sooner so I think at least select sh is kind of my my point of view

Danny Ryan: my other strategy here is that you know

you could say tensi of inclusion per Electra but it's because it's super seal dependent and because it's uh not doesn't touch the state transition it's also something that can be ripped out meaning if it were to be the blocker it's easy to for it to not be the blocker on getting a main any other opinions people want to surface on how to handle okay my I would

say very much agreement on high high priority parallel item um but that we can have these breakout calls and continue to discuss a couple of these other things that may or may not go in before uh pios surfaces anywhere in relation to Electra but that we can regardless it's something that people are and will and be working on but that we can pop this up in in a couple weeks and and contextualize it after the breakout calls reasonable okay and then another fun one

Maxi B uh where do people stand in relation to that is there further discussion um that can be had today or does it need to also be contextualized by uh what comes out of some of the discussions that are going to happen outside of this call in the next couple weeks any status update here any any further thoughts okay so this is going to this will come

up in a conversation again in two weeks um and potentially there will be the ability to contextualize or foil against some of the other things that have been thought about in that in room okay are things people want to talk about in relation to Electra today other discussion points for today

anything related to research specification or just general open discussion am I live

can anyone hear me you're live

Danny Ryan: thank you um okay I I appreciate it this is these are these are tough conversations to have uh there's a lot of really important work to do um a lot of great research and specifications uh to dig through so thank you for bearing with me and and working through it all and we'll

pick it up again in two weeks take care everyone thank you

Terence Tsao: see you guys thank you thanks

thanks Danny thanks bye bye thanks bye I

e time

Speaker names adapted from ethereum/pm, CC BY-SA 3.0.