All Core Devs - Consensus #130

Transcript

[Music] e J

[Applause] all

for h

Danny Ryan: okay great we should be live uh this is aeps consensus layer call 130 this is issue 987 in the PM repo just Shar the link um anything related to den then we'll move on to a quick discussion around local block boost defaults and we have a lot of things to talk about in Electra and then some networking stuff to discuss so quite a pack schedule um before we jump into it Trent you had something more to

sh

yeah so for the past um couple weeks like starting in beginning of February

actually that's like a month and a half I've been collecting submissions for this thing called Denon Diaries I just dropped it into chat and it's a just a compilation of um ctive perspectives looking back on the last two years and looking forward to pectra and just future ways that we can um better improve the processes so check out the link uh I think it's a really useful resource if you people have been around they'll know that I've done this for uh the merge and also the beacon chain launch so just adding to that collection of um historic record uh hopefully we're starting to build a institutional memory of how core Dev and how the community around it works so um thanks to everybody who submitted I

think it's a really nice snapshot of sentiment and hopefully we're we're learning as we go um but I'd love for uh anybody to check it out um if you weren't included for some reason or you missed the deadline please just DM me and uh we can we can get you added to it thanks

Danny Ryan: great thank you okay we still have the nub on here um one one it item from Tim

Tim Beiko: yes if you wrote an EIP for the fork that went live we should move those to final um I've opened PRS for every single one of them that were not uh final I think Alex Stokes was the only

one who did it so shout out to Alex um they're all Linked In This PR so um again if you're an author on one of those Eeps please just take a look um I think pretty much all of them only require an approval um yeah and then hopefully we can get all of those finalized in the next couple days

Danny Ryan: yeah cool it also needs an approval from editors um from an author and editor

Tim Beiko: yeah once once we have all the authors approved I'll I'll bug the EIP editors to get them to approve the batch

Danny Ryan: Terence

Terence Tsao: yeah I guess this is somewhat

the related it's probably easier to use this forum so we have been seeing um blocks that has kvg commitment but the blobs never arrive so means these are unavailable blobs block so by definition these blocks never gets imported so they are reor but consider these are actually somewhat valed blocks it's pretty interesting so if you're running a validator I so I kind of presume this is a builder issue already because like standard clients has been tested fawh so if you so say if you use a Bel so say today um if you're validator you are missing blocks and um yeah but then for some reason um your blogs are not

getting included then please take a look so here are some numbers so on um March 18 we have three March 19 we have 10 March 20 we have six and March um and 21 we have four of those incidents and I finally capture those blocks it turns out that no one's capturing those blocks by default so I have four of those blocks and I will um look into them and find out what's going on yes I also have the slots as well I can share those

Danny Ryan: yeah interesting um it might be worth doing a Sandy check through block print if they are all the same client Well yeah if they are all the same client that might be might be telling

them maybe it's on a builder isue um maybe you can also tell if they're bu any questions for Terrence that's interesting okay um something we don't have to get into today but something that uh I think as if and as we do have any sort of meaningful data analysis on um performance BL distribution times things like that please add them to the call I think people are eager to to get an insight into how things are performing um are there any interesting

metrics or things worth sharing right now other than looks okay primarily to 4844

and

Parithosh Jayanthi: short um blog post on some of the metrics we're seeing I've just linked it uh just have a look at yes I think one of the thing that we wanted to keep a close eye on is that the P95 value for uh blog blob arrivals with respect to a slot are getting relatively close to 4 seconds this was based on the first day of data so we still haven't done a follow-up analysis after the week but that's something we want to keep an eye

on

got it poas

Potuz: yeah just looking at this blog post U about resources usage uh it might be slightly misleading there's uh we changed the timeline for attestations to be included on the net so we're allowed to include attestations from more than 32 slots ago and both at least prison an Tech will have this problem that they they would just remove this attestation from the pool and reg goip them if they see them again so someone is sending these attestations very late we do not know who but certainly prison and te will just keep

resending them and this blows up CPU and bandwidth so so I mean certainly bandwidth has increased because of the pl pork but uh but the numbers we're getting are just exacerbated by this box uh just this is already fixed on prism I suppose on te as well

Enrico Del Fante: yeah I can confirm and we have merged a couple of fix to to actually accommodate the the change uh reflecting all the configuration around different pools and ghes that we have so the next release should have that fixed

Danny Ryan: got it

any questions on either Perry's metrics or the agation kind of amplification relaying book sorry I'm I can't mute him surprisingly um all right cool um anything else on

Dan

Gajinder Singh: I have a small cleanup PR that I think is also linked to the agenda regarding just renaming of uh blob base Fe to blob base Fe per gas basically to make sure that the unit is more aligned with what it conveys

where

Danny Ryan: where is this PR okay this is to 8316 this is a clarification or this is a bug bug fix or this is just a naming

change

Parithosh Jayanthi: yeah I mean it doesn't uh affect any of the headers so basically just yeah sort of renaming of some helper functions and references

Danny Ryan: I see okay so maybe the for po auth take a look and if anyone else has wants to CH in anything else on Danon okay I did notice on some of the

charts that the base fee has gone above one a couple times but I think last time I checked is still sitting there okay

well just on that note I did a very cruded uh look at the blocks and it seemed like we're um posting about 30% of the of the target uh number of blobs per block uh on average it was just over a thousand blocks but makes sense why the base fee is glued to one right now

Danny Ryan: yeah and that's that's what I've been seeing we're kind of still on the average of

oneish over time one all right cool let's keep our eyes peeled on interesting developments here and surface anything here that's that's relevant to either client stability or potential future improvements um next up Frederick has to leave at halfway through the call so um he's has some comments around local block boost defaults

R

yeah um I'm in the SAA but I hope the microphone is working fine otherwise I'll go outside sounds good um so uh yeah this is basically about um doing a client change uh which should

hopefully improve the sensorship censorship resistance um if you look at the one of the pages that Tony created censorship. p uh we can see that I think it's around 64% of all the external block Builders are censoring blocks um basically by not adding certain transactions and about 51% of the relays um also block um these kind of U blocks and since basically today I think it's around 95% of all the blocks being built are done using um relays and external

Builders this PO is a bit of an issue um because uh some of the blocks will be uh censored so basically what we could do uh to kind of help mitigate this a bit is to adjust the default local value boost to 10% current currently in all clients this is set to 0% but by changing it to 10% it means that the local blocks will receive a a 10% boost so instead of like if if there is a block that's built uh that can be built locally for

0 4 uh e and an external block coming can be built by 041 e than the external would be design uh be used uh in in these cases but by setting the default to 10% the local block would be uh prioritized in that case um the way that clients have implemented this differs a bit uh some of them have a boost on the external blocks and some other boost on the local blocks but this can always be changed by a flag so even if the default is set to 10% uh a user who don't want to do that

could always change it to 0% or they could set it to 100% if they want that um and the current status here there are some PRS that's been made um they're linked on the issues for this call um Nimbus and teu have already merged these changes uh the other clients have PRS for it and are thinking about um approving them I think um and the EF testing team are also implementing some additional tests for this um which was based on some feedback from the prison team so yeah that's it in Nut

Show

Danny Ryan: Terence

Terence Tsao: yeah I'm supportive of this change I guess one question I have was that like um this will also I break some testing per se right if before we're just adding a little bit of Builder bit that's that that's higher than local bit now we have to make sure we add this at 10% more so that's one thing the second thing is that um can we get some um testing on hive for this um test case just because for the prism side I don't think we have end to end test that cover this scenario yet so I hope H can do it

yeah I think Mario is here can probably mention something about that he created a think it's for it

Mario Vega: yeah I created a ticket um I'm going to work on making Hive aware of this

flag so we can um reliably configure it depending on the test test case um it's going to be very simple uh basically just if you are setting it to a high number a higher than normal number we should expect that the the blocks are locally built and the other way around or the other case yeah super simple but yeah

Enrico Del Fante: and not not all client have the same parameter working the same way I guess so that this is the only thing

of course

Mario Vega: of course so probably what we'll have to do is that we have a like a um high value that's going to be transformed into a client specific value

Enrico Del Fante: oh yeah makes sense and set the

FL P

Potuz: I want to be the voice of descent uh we should stop specifying these kind of things we should stop doing this in a coordinated fashion uh the reason this wasn't merged in prison to start with even before the merge when we started designing this was that it would be controversial if we had a value that was bigger than zero and now we're coordinating to have something and even thinking about txting this I think clients should be free of setting these kind of things however they want they're configurable by the user and we should be less afraid of actually acting on this in our beliefs

Danny Ryan: right I guess the testing infrastructure

can should probably be neutral to defaults it should just in the event that this flag exists be able to still test building right can we trck that balance

sorry uh please

Mario Vega: yeah in my opinion yes it's going to be like um just when in the case the flag exists and it's set it functions properly that's the idea behind test

Danny Ryan: but agreed I mean there's some of these things that um there's a reason other than just kind of network resilience that many clients many different clients

exist different design different philosophy different failure

SE

Sean Anderson: um yeah I generally agree with B is that it should be sort of a reclin thing um and a reason like not to set it to 10% for example would be that it would be kind of an unexpected default and it's kind of like taking advantage of the fact that a user might not be aware of this fature whereas like a better approach something maybe in Lighthouse we could do this um would be to like require a user to set that value if they're using a builder so it like raises awareness of the flag without like um I guess giving opinion towards what it should be and that might have

like a similar effect

I

Danny Ryan: I am curious um maybe some of those that do some uh analysis on this like obviously we know that me is quite chunky so a lot of the margin you get on most blocks is is pretty small um do we actually know as a function of call it 5 10 20% whatever whatever that margin is like uh how many blocks additionally would be locally built

Potuz: well but we are seeing relays playing some games that actually are making this margin as small as possible right so over time we're seeing this margin being getting

lower

Danny Ryan: okay um are there any other comments on this other than just kind of surfacing awareness um and knowing that there is a design space for clients in their default and ux are on this perimeter Yeah Tim that but that that that's kind of this absolute value on

Tim Beiko: right you need to map that to a percentage but yeah

I

I think it's you know it probably

depends a lot on the on the current market conditions as well like if it's uh if it's a scenario where a lot of transactions are being done um we can probably make a bit more juicy me U blocks and then the margin for might be higher compared to to um a bar market for example but uh yeah I don't I don't have any stats right

show

Danny Ryan: that's why that absolute number is kind of tough to deal with because the the market can change quite a bit whereas like the the percentage that a builder usually gets on top of um a local build might actually not have the same type of like

Market function Market Dynamic function but

it yeah um yeah we have a

Danny Ryan: we have a pack schedule is there anything else people want to talk about I know there's still some active stuff going on the chat which continue

no nothing

Danny Ryan: great thank you Frederick okay um Electra before we get into it I do I Max CV I mean there's there's a number of like small proposals that might filter in for example blob gasing increase think committee slashing maybe is maybe is a small proposal um but these two big ones um we've gone back

and forth we've thought one or the other was buried and the roof surfaced um at various times but we're definitely at the point where uh if we're not making a decision today we really need to be making decision soon um there is the intention to have functional prototypes and Deets of Electra some point in May um and we're closing at the end of March so I just want to contextualize these are medium if not large items that we continue to discuss uh we can't continue to kick the hand on the curb for too much longer um otherwise I think the default just

becomes no I guess indecision is a decision um I have I'm lots of opinions on the but I will leave it at that I think it's time to it's time to make a call I'm also not going to be here for three months starting at the end of this call so um you might have to make the decision on me anyway there have been a number of breakout calls uh there was an inclusion list breakout call I there is certainly some uh conformance on design and some of the subtle decisions around the design uh Mike can you give us an update on where we stand

here

Mike Neuder: yeah for sure thanks Danny hey everyone hopefully you can hear me um yeah so just linking the the comment in the issue um which links to many more links so kind of links all the way down yeah as Danny mentioned there was a there was a breakout room the recording is is there um it was pretty well attended and I thought quite useful parents took some notes um that are linked in that hecd and I guess the main takeaway was just everyone coming to consensus on the set of features that we want for the POC um yeah that was kind of the last big thing was discussing the whether or not to

bundle the inclusion list with the block on gossip and we all agreed to do the unbundling version and yeah that's kind of where we're at um uh a few more docs that I linked in that comment um Poes has has the dock on bundling that I just mentioned um Terren had a a short dock on the relationship to blobs to inclusion lists um this isn't part of the proof of concept but it's kind of an interesting thought experiment as we as we kind of move down the path um I wrote a small doc called the case for Electra um that's more of like the meta argument for why this feels important and then the PC spec is still being developed um in this link here

I'll but the I'll link this one actually in the zoom chat because it's kind of the the source of Truth Trent put his camera on too that's funny um so yeah I guess it feels like a lot of the um a lot of progress has been made I guess in the last week would yeah love to continue jamming on it in the in the room and I guess a lot of the client teams have started implementing and would definitely be happy to hear from any of them if they would like to to chime in here um seems like generally the implementations are are going well and uncovering lots of like nuances about um the spec that

that we're kind of ironing through the only thing I'll bring up today as far as technical issues is there was this one question about the relationship between um enshrined 4337 and inclusion lists um had we've kind of talked about this once before but this um was kind of rebr up in today's context and I think I don't think it's a blocker from what I can tell there's nothing that um oh yeah I has unknown with AA yeah so I don't know if you saw my latest message Terence in the chat but I don't think this actually is a blocker um I think we can deal with it I don't know if it's worth going through the exact mechanics here but yeah

yeah P

Potuz: yeah can we I mean if we have

execution ler clients uh that are not that are actively working on account abstraction let's just trace the problem abstractly here what it is it imposes a condition on account of fraction that forbids an account from being spped by from being swept by a different account uh if there are the signs that are the have chances that are people like looking at that will allow an account to be swept out by a different account by a transaction coming originating from from a different account that would break our current design of inclusion lists this seems like

yeah did

did you see the message so I asked valal about

this and he said basically one way around this would be to just check a few things you add another condition which is not only if the nons is being reused but also if the balance of the account decreases then you can ignore that transaction for the inclusion list like like even if there is a AA world where you can sweep an account without sending a transaction from that account um we could just have this other check on the inclusion list transaction uh condition does that make sense right that's what I was thinking too um yeah I sent the screenshot of the chat to the I don't think it gives free free da because you can just drop the

transaction in the inclusion list because the summary entry is Satisfied by the transaction or by the balance of the account going down

Lightclient: it does I think it gives you free ability to fill the iil with useless transactions that you sweep

Mike Neuder: well you can leave the I empty already I is yeah

Lightclient: um but if you can convince nodes that are trying to construct ILS that some transactions might be good to put in the I and then once they make it in the I taking space for maybe other transactions which might have been

better then you can just sweep them and remove them

Mike Neuder: yeah I see what you're saying yeah oh yeah I think Fran I agree with franchesco's point in the chat that like you could already try and stuff really high paying trade transactions into the summary and then use a different transaction with the same kns to to replace those transactions I think you still have to pay the gas so like it still feels fine maybe there's a slight subtle difference here but yeah um maybe we can handle it

offline

Danny Ryan: yeah so one of the one of the attempted things to assess over the past month on This was um engineering complex does anybody want to chime in on engineering complexity maybe noting any sort of concerning points of design or unknowns or maybe comparing it to some type of work we've done before so that others on this call can better understand the relative complexity

Gajinder Singh: I'm working on the ILP so I can basically add few points over here uh so basically uh it is it is a little

bit different uh than blob availability uh because the next block if you get the next block then which is valid uh then basically the previous block I get satisfied uh so when you are trying to do range sync uh basically you don't really need an i and when basically you are saying to head and are doing gossip and at that point the IL availability really matters uh so that is the only you know gocha that uh that was around this and uh apart from that I think I found that uh keeping keeping uh status sort of flag in folk Choice was actually

more convenient uh because then it would help me sync forward sync uh uh blocks easily through blocks by range and basically I could just track the status that okay this is I need to basically check that where whether they will have the valid child in the end or not the tip will have a valid child in the end or not or I will basically then have to uh uh start start looking for and importing the IL corresponding to the tip uh but apart from that uh I think these These are the moving parts and then the engine API integration that uh I'm going to start with G but it doesn't seem that

challenging and uh uh basically I think uh I once once we wrap around the head wrap around our head uh for uh over the concept that is is uh I basically is forward and uh the availability is a bit different uh and basically just handle it that way I think uh uh it could easily be uh developed it could easily be targeted in

electr

Danny Ryan: thank you any other perspectives

on relative complexity um or any questions for

Kender

Enrico Del Fante: um I can jump in saying that that I start I started working on the PC implementation and I got um so I I I I become more and more um confident on the on the implementation complexity generally and um the only thing is still in in the back of my mind is the IL signing compared to the block production

so if so if we need to sign if we could if we want to sign the El is is convenient to sign and send over the network Nel before the actual block production it it will then also require some additional API calls and different and other timing between vcn BN so I'm I'm I'm currently thinking about in in for the PC just having the same um at the same moment just sign the block and sign the together uh but this might be

another um complexity in the in the API and the integration between VC and BN if I'm getting if I'm not mistaken

P

Danny Ryan: asked why is that but I'm not sure what point of the conversation you ask question

Potuz: I'm not sure how technical we want to be here uh but I didn't understand Enrico's point that we need extra extra extra API methods to send the inclusion list before the slot

Enrico Del Fante: is is there a conf can can you repeat here I I haven't check

Potuz: I didn't

understand why sending the inclusion list before the start of the slot would require extra API methods it seems to me that it's the same you're just going to request it from your execution layer before right after you send the FCU of the previous

you

Enrico Del Fante: you need to sign that so when currently the block production is is started uh this slot before right so at the moment of the of the block block uh proposal you the VC just request the block and you the block okay but you're also mentioning that you it's also possible that you could um sign you can send it

Potuz: yeah you

could sign the inclusion list and send it before the slot the thing is that you're gonna sign that thing anyways you're gonna sign it at your slot or before the slot so that that Ai call is going to be there either way

Enrico Del Fante: right but you need to request it through the BM right

Potuz: yes and you will do that you will do that anyways during your slot

Enrico Del Fante: well no it's because now we have this concept of block content in going going through the API and if like we have for for blobs you got block plus plus blobs and plus other things so we could put the El inside of it and then the VC on the same API call you got you sign the block

Potuz: so

you're saying that instead of like having two different calls you you're going to have to overload the call for the blog to return an different envelope with two different messages that you sign

Enrico Del Fante: yeah I mean yeah okay so that's if we want if we can if if we want to make the flow is the same we can at the moment if we want to release everything at the same moment but we if we want to have the freedom of of signing and sending over the network in different timing we need to design a new API this is my I think we we can we can't avoid that

Pawan Dhananjay: yeah I've been I've been implementing uh uh ILS on Lighthouse and I agree with P I think it is uh quite uh useful

complexity wise if you uh are able to send the IL before the start of your slot because you don't have to touch any of the existing uh block production block production logic at all so it would be a significantly smaller refactor and it would be an addition and I would complexity wise I would prefer that compared to overloading the current block and blob proposal methods

Gajinder Singh: unless uh just at the beginning of the slot your head changes right so uh that basically can cause you to basically request IL and sign it and

send it but I guess that can be taken care of and I also agree that independent design is better because uh what generally happens in Block production is that it's not just the execution layer that we and wait for they also wait for Builder which basically sends uh the block a little bit later into the slot which I think they they're always trying to Target 1.5 second or more uh so it it would be faster definitely just to you know at the start of the slot just to request and I and send it over

independent all

Danny Ryan: right let's table this um it's interesting that we're at the point of debating some of these nuances

which is certainly if this is to go in um we'll have plenty of time and fun to do that um there I I don't I don't want to attempt to make the I occlusion call without El maxb discussion I will say before we move on to the maxb discussion that um at least a couple of individuals and load start seems as an aggreg signal that they would like to see this um in the for but let's I think that we generally have a feel on the status update it seems like a lot of people have opened this up and taken a look let's take a look at um max

CB where that stands there was a breakout call yesterday and there is to be another one on Friday I there were two because of time zone considerations uh Phil you wrote up some notes can you give us a high level to start

Phil Ngo: yeah so yesterday we had a breakout room in which uh we had participation from loadstar from lighthouses there and uh also prism uh overall it seems like at least between the three of us there seems to be uh some general consensus on inclusion for this and mostly because um you know we we have a a lot of validators um on here and it's going to get to be pretty

concerning if we don't deal with this so it it seems like we have consensus on that but we do have some remaining decisions to make in the spec which is what these follow-up calls are for um there is a issue open by by Mark for these two um and there is an agenda for the next one which uh I'll post in here as well um and then if you can come to these meetings with some your thoughts I believe uh Mel had also updated um D Lin's PR in regards to Max EB uh with some additional points in regards to

slashing um but yes that's basically the tldr um not sure Mark if you wanted to add anything to that

um well I yeah so I think from Lighthouse perspective uh what I've seen is that we've prioritized Max EV in then inclusion list but are totally open to doing both in the fork I believe that's basically the same idea from load star and Preston um on prism expressed a similar sentiment um and then I talked to um Phil yesterday and te and and or Paul sorry and

um he had similar sentiments

I would say um yeah um I think that's go ahead yeah can I

Danny Ryan: can I jump in I I'm um curious prism's current perspective on the complexity of Max evb engineering complexity um that has been something that's been brought up a number of times but I know that the team is going to come reevaluate can somebody speak to that

Potuz: is Preston here so if Preston is not I can just say that he's very op he's in charge of

doing this and he's been he has a an implementation that is it's almost complete and he's very confident that uh that it can be included and and that that it's he's confident that we can Target maxtv for end of this year which was one of the hard requirements that we had on any

ID

Danny Ryan: right okay

one of the takeaways from the meeting seemed to be that Maxi be required a little bit more of like making decisions around our cleaning up the spec I guess where um but it seems like less engineering work to actually Implement than inclusion lists whereas inclusion list is a little bit of the opposite the

Spec's a little more stable um uh but it's a little more engineering work but yeah it I mean the things that remain on the on the spec to decide are it's like we have several good options it's it's almost reaching the point of bike shedding to where you know we just kind of got to pick one nothing that we can't fix

Danny Ryan: okay um Mark you were echoing that a number of teams were signaling both but did you

also say that those teams were signaling both with a preference for Max CB in the event that it was one or the other and that consistent across

so I Preston did I I believe he said um that they that he would at least him personally would have preferred maxb over Electro uh that's my opinion um and Sean's opinion in Lighthouse I don't know about Pan um and then I think load star Phil you might have uh expressed a similar opinion in terms of priority but um oh did I say Max over

yeah I think

you meant you meant is

I meant inclusion list yeah um but yeah I I think everybody expressed that sentiment um and I think that's in the notes um maybe Phil you can correct me if I'm wrong but um yeah I think that's what I remember I I certainly remember Lighthouse prism um saying that and I know that um I know that Paul said it I don't know about Paul's priority but he did say that Max CB seem fine to him

Danny Ryan: um yeah so great so there's a couple things I want

to bring to the table um obviously being able to handle the engineering complexity of one of these and isolation is something um at a certain point just when we're smashing many things together um spec-wise one the spec builds more complex to the testing um of that on every single path is more complex uh the the getting to the point where you're even at testing for clients takes more time so certainly um these things can sometimes compound an unexpected ways and I I want to keep that in context yes they're moderately isolated

in terms of the components they're touching um but you know I I wouldn't naively just say like the the complexity is additive um in terms of shipping in a tire Fork um so want I just want to keep keep that in mind if if and as people are pushing for two I also do want to bring up and reiterate there is a third moderate to Major R&D uh thing going on which is pure dos pure data sampling um my intuition is that one of Maxi be or I's going into a lecture probably does not greatly uh detract from the paralyzation of being able to do p do R&D um but that

in the event they're both that we're now you know beginning to trade off and probably not really being able to tackle all those three things um in parallel once that's that's not to say that some of that will happen right that the networking experts are different than than people that are touching database this or that so I I do there is paration that can happen but intuitively it feels like we probably going over a Tipping Point on a lecture where um that's going to take out most of the oxygen in the room and so I just want us to be very conscious about these Dynamics when attempting to make this

decision

I think um we we did a little bit and there was I mean just the because P Das can be parallelized provided that team that was kind of why the other two proposals were being pushed more that's all I'll say about that that was just kind of a sentiment

Danny Ryan: yeah I agreed agreed I I do think that they're imp parallelizable um I just I worry that the kind of mounting complexity of Electra will almost certainly L across some teams if not all begin to be a kind of a balance between resources and siphon resources at at times if not the entire

time

Sean Anderson: um yeah I guess I'll just say something um I do agree that like at the end of the day there's only so many engineering hours so like including both is sort of a tcid acceptance to De prioritize P death to some degree um I do think though that we have the capacity on Lighthouse at least um so yeah those my two cents

Danny Ryan: are we so I I at the outset I

said from a timing perspective um in relation to what we're tting to do in and by May we're already behind into attempting to make this make these decisions um that and so kicking the can down the curb for another two weeks um puts us certainly in in a tough position to try to hit some of those for May targets um so implicit there is today's the day are is there additional information that we are going to gather the next two weeks it's going to help us make this decision or are we in the place to make this decision today that's a go or no go on both of these moderately large if not

large Sean

Sean Anderson: um yeah so I would just say like it seems like the further we've been getting into the poc's the more confidence there's been from like a development perspective that just implementing these two are doable um I definitely get your point about um like especially in the spec and the spec tests like flushing all those out at the same time covering all the Ed Edge cases that might take more time but I think from a development perspective like definitely achievable like in the clients

Danny Ryan: and on the inclusion list side

um one thing that I didn't bring up earlier I would like to get the perspective on is the amount of complexity in the execution layer versus the consensus layer is this something where by making this decision here you know it's really 90 95% of the complexity is over here and it's really kind of a a small ass on that side or is this something where it's more like 5050 40 60 in terms of complexity split

Potuz: I think it's not even clear right now today we started discussing that now the Y is going to have to go back and check if the certain balance decreased in the previous block uh to validate the inclusion list we are

just learning about this issues now right and this is in part because at least I can speak for myself my naive naive not knowing about execution I really thought that this transaction would revert instead of being just not includable

Sean Anderson: yeah I I think we we need to I I think we can analyze the damage I guess kind of risk of this new account abstraction thing in the next day or two like I don't think it should fundamentally change anything honestly and as onar mentioned earlier like in Shrine 437 is a like this only matters in in Shrine

437

Potuz: so no no but the thing is the thing

is that even if we do include this and we not consider at all what will happen in the future with account abstraction this increases complexity on the El side for implementation of this

Sean Anderson: do we um Matt or Marius could you talk a little bit about e complexity or if any of the breath guys

Lightclient: I think for is it's not too bad on the E side I worry slightly about having to keep track of balance changes from

the previous block but none of this stuff is intractable it's just a bit more work bit more things to Think Through

Sean Anderson: yeah super happy to work through the implications of that that specific AA thing I guess apart from that though it seems like everything's well understood um I'm I'm definitely not an elev so trying to guard my language as much as possible

Lightclient: I think it's I think the work on the El side is maybe like 20% of the

Sean Anderson: yeah that's that's the number I was going to give to

8020

Gajinder Singh: yeah from my the GS perspective I think IL yeah should be easy to implement on E side because you have so es have all the capability they have D mol they have they can gather transaction and just Bunch them up and easy to verify again like executing a payload

Danny Ryan: so um are we at the point where these specs could be built into Electra with 70002 and the other things that are already or or you know is it a couple more weeks of of R&D of PC of of design decisions

it sounds a bit like the

letter

Sean Anderson: I mean I I don't know I I just get the impression that everyone more or less agrees that these things can be done I don't that there there's probably not major uh unexpected implement problems that are going to come up and at this point it might be a question of what do you prioritize more

Danny Ryan: between the two or between

Sean Anderson: yeah I guess complexity complexity complexity I

guess makes the decision on whether or not we go we go for both and if we have to go for one then it does kind of depend on what do you what do you prioritize that's at least my read

Danny Ryan: how much of I mean one one interesting thing is that uh the anti- censorship parameter changes from prick earli in's call you know if that really moved the needle on quality assurance of transaction economically viable transactions making into the the block then can is wait you know is there any Intuition or data on that

um on how much we can move the needle with with smaller things because if that if that was if that could be moderate even moderate not even massively substantially moderate I I would make the case for being afraid of the complexity of of both of these things together and knowing how timelines go and kn how tough it is to test these systems and and tbling that if if there aren't some moderate winds to be had there or in other other places then maybe it's worth taking the now

yeah poto just to contextualize we're talking about what to include in the electri fork um obviously there is major R&D stream um which is p do so it that will occur in some amount in parallel uh so it's but it is there's it is there in the trade-off space the more that goes to elure the more that that parallel work stream um will not get us as much fire what's o op oh out of protocol Mike says my two sents don't depend on oop for CR

uh I I do agree uh but on what time frame right like if we can help reaffirm the norm of CR and uh be in a reasonable spot for a stretch of time with smaller changes than it advises time for the protocol to then take on that complexity that's at least the argument I would make

yeah so I the I Deion can't be made without the execution there we have EXs here but um if there was an attempt to go on on this side this I think have to surface in a week on the execution a call to do an affirmation on that side um certainly the decision on on Max CB I believe is almost entirely in isolation Tim says uh we can see if I I start with my and everything else and see how feel that get the first that's

time you want to speak to them one right

Tim Beiko: yeah so um I think yeah for for two reasons I guess I'm proposing that like one um obviously there's High uncertainty about whether we can fit ILS and Max CB in the same Fork um so we should probably just start um I should probably just start working on it um two like yeah Max CB is is clearly just a you know CL thing whereas IL does does have implication on the on the El side as well um so it'd be good to sanity check with the other El stuff that we are considering um you know the the team sh likeor bandwidth so if we include Max evb uh we have this CFI thing that we've used for

uh the e in the past that basically signals things we are strongly considering for the fork but not fully committed to yet um we can put aises there work on a first devet with um maxb all the other stuff we've already included if next week we make some decisions on acde about like small eips um you know new OP codes or whatever we can have that part the first death Nets and also I think this gives us a couple more weeks to figure out some of these spec level issues for ILS where um yeah like two you know if if like two to four weeks after that we have a first devet or two with everything else a better understanding of the I complexity

then we can decide to merge it all together or you know potentially to push is out to the next fork or something like that

yeah

Danny Ryan: so it's the proposal to finalize Max evv spec to build into the electri speec while over the next two weeks to continue the ilp's and go no go in two weeks based off of that and at which point we either building into the spec or setting aside

Tim Beiko: yeah and I don't know if I'd want to put two weeks but maybe you know two

to four or something like like I think the data point that we should be looking for is is like uh implementation Readiness on everything else alongside like the IL spec Readiness so like if in like four weeks we have a working dep net with Max CB and like people people are feeling very confident about the whole thing then great maybe we can add iil and that's additional complexity but if in four weeks we're in a spot where like it feels really hard to even get what's already done implemented um then yeah that's a signal that like is is probably like additional complexity that we can't take on

Sean Anderson: my only concern there is like would

there ever be a case where we then decide I are more important and switch it out with

Max

Tim Beiko: you know like if probably not

Danny Ryan: because of this my attempted aggregation of signal that Max EV is the preference um I know that you feel otherwise but I think that's what most people have echoed so far in the chat

Tim Beiko: but yeah but it is I think it is worth emphasizing though like yeah if we go that route it gets hard to pull out Max CB because we've like merged it with every everything else

Danny Ryan: yeah and again my my read has

been for the majority of people in this call if it were one of the other Max and B so begin the spec build with Max and B I also just from a from a spec build standpoint you know that that's going to take the next 10 days next at least week um so and I don't I don't really want to build those two things into electric at the same time uh so there's kind of a a sequential thing that has to happen anyway

I'm going to say again I personally believe that these two things together we've entered into a much more complex space than we have been discussing and intended to over the past couple months so just do so knowingly oh say at this point in the process we're also always very confident and excited to take on complexity and there's a lot of work to do

okay we do have a current plan I'll just say it uh Maxi spe to be worked on gotten into a very stable place and uh integrated into the electr spec build as soon as possible IL PLC PC's uh final design decisions and things to be done over the course of the next one to four weeks um and be make kind of informed decision on iO inclusion in the two to four week time Horizon probably more like four based off of continued understanding of complexity pcc's

electric poc's Etc okay thanks everyone tough conversations

poto

Potuz: yeah I just wanted to confirm that uh it seems that it's not really certain but it seems that we're aligned with prism that maxb is a yes and if we do commit to mab then IL will be a no

Danny Ryan: okay good to know um I think that we can still have the conversation in two to four weeks um and y'all can if you stand

firm in that Echo that in in that at that juncture but good to know going into it any other comments on these two proposals before we move on and the implicit proposal of pios that is in competition with them just a quick update on that um very active work on specs and subal prototyping um and eager to have other teams really at this juncture jumping into certainly the the spec and Design discussion and pro as

well okay we have we're not going to make it through this whole uh schedule today um onar timebase blob gas increase proposal can you give us just a quick perspective on that

M

Ansgar Dietrichs: yeah sure so so right so basically that initially we had like a a big big debate about the right super level 4 44 ended up going with three Target six Max so maximum of 750 kiloby per bu trade off of course P2P load and the validated dis space and yeah the intention of course is that we want to scale up da from here to full D Shing over the next I know three to five years or something and

most of that we will have to do via actual um sampling methods so so P do and then potentially steps afterwards and but for P for foras we will need to have an e anyway that increases the throughput because that's the only kind of in protocal change that that needs also separately um we could even before pias already try to just basically make the most of the current Headroom that we have B6 was of course cautious um by by by Electra um I was thinking we'll have like six to 12 months of of experience um with with kind of 36 and how how stable the network will be with that um we have this this e by Tony 7623

to increase the call lettera cost so that will decrease the the worst case um normal block size from from roughly 2 megabytes almost 2 megabytes today to to roughly half a megabyte um at at count gas limits um so and the idea of course for that is to to both just basically protect against C Worst case attacks but also just give us a bit more head room both to increase the the L one G limit but also hopefully some some some extra blood throughput of course for blood throughput it's not just about worst case it's also about average case considerations but but still so so with kind of both from both these perspectives both called potential pias but also like already using the head room that we have today and there was the idea of

basically having having an EIP um for potential kind of increase in the the B throughput so so we created one just mostly as a basic Shing point for compensation run this um it's currently in draft there's a link in the in the in the agendas the idea would be although of course we could change that to maybe pays in the the BL throughput increase gradually the count AP proposes to go from count 36 to a total of 816 so one megabyte Target Two megabytes Max over the over a span of four months basically every month ship one extra Target blob basically um right and uh so in in base case we could use that for we still with

full for for download logic and then gradually scale that and and make sure we have this emergency escape hch that if we if we see any problems with the network we could qu and basically um cancel that that that those further future increases um but also if we are shipping if we are successful shipping pasas on a similar timeline to elra then we could of course just seamlessly use that as the kind of throughput increase um that that that that would be powered by instead um yeah so the IDE is of course kind of like it's a little early to make the decision now it was more to now have ANP that we can specifically reference when whenever we talk about this um and in my personal belief at least is that like basically sticking to this rough

meme of trying to 3x the ethereum da every year from now on over the next three to four years until we are dun sharing levels would be like a very very nice thing that we could provide for L to that would be roughly reliable in terms of the time timeline for increases and this would just be a first step on path

Danny Ryan: thanks onar uh just quick context I am a co-author on this I do um I would support something in this direction uh one assuming we get solid data on 4 four in production uh two in the event that the Tony's called price repricing scheme does go in um and three I I I'm

certainly a proponent of this timebase increase of timing and maximums to be debated in this case and also in the case that we're doing P dos type or datability sampling type things um really going from test net simulations testing analysis to to main net is I think always going to be come with with quite a bit of uncertainty um and so this like time based approach where we do have the Escape PCH of kind of um an upgrade to to to cancel um is I think a tool that's going to be quite useful as we're changing things around data uh we have a lot on this agenda

this is certainly just to kind of open up the dialogue uh does anybody have additional comments or questions at this

I can't figure out how to raise my hand uh how does the kill switch on this work if we decide that we want to stop the progression of increasing the limits

Danny Ryan: that would be just a quick Fork uh it would be an additional EIP and a fast upgrade so in the that that should be considered when thinking about automated time based increases um essentially at these various junctures you get you get new main main net data

um there would not you can certainly designed some sort of like kill switch where it's like a like how the the gas increase is done you know essentially consensus voting or something like that um I would try to avoid that complexity and governance point all right um anything else on this one thank you

onar next up um a couple of uh eips were dropped in byon Sy committee sh this is in draft status Tom do you have any you want to comment on here other than it's distance

Etan Kissling: yeah um it's like uh essentially the current state of the research of what was previously in consensus specs there was an issue where I already made this proposal last year and for the light client data backfill there is an open PR but um because they affect consensus um I think it's

appropriate that they are also tracked in theps um the light client uh s committee slashings they are especially interesting together with maxb because maxb allows the SN committee to have a larger total balance so larger total balance there means that more eth can be slashed in case of an attack right now many use cases even if the slashing is perfect are limited in how much they can secure because there is only 512

validators um even if they are slash down to zero it's not that much if it's like a bridge that secures a lot but with maxb this could become interesting to follow and the like cine data back fill what this one enables is um eventually decentralized chain synchronization for the beacon noes similar to what we have on the El with SNAP sync we can build it for the CL as well once we have that because it allows to um sync The Trusted block route decentralized and then also enable snaps

in from there own getting rid of the servers like checkpoints and those are no longer necessary

Danny Ryan: one thing that's worth contextualizing at least in my mind on the community slashings is that there have been at least a number of R&D efforts to attempt to uh ZK the FFG portions of the beacon chain um in the to get these bridges that end up having full CTO Economic Security with kind of a default slashing default uh consensus and just bypassing the te um do you have any perspective on whether these are likely to come into

production fruition um in in reasonable time frames or are they still

P Skyes

Etan Kissling: from what I was told and what I heard like no no I didn't check personally but it's still quite far definitely post veral as as I understand but I'm not an expert in this area so if if such transition Could Happen earlier of course it would be much greater than the stent committee which yeah it's still theistic are to say with the CK proof you know that it's correct right

Danny Ryan: yeah I'm Gonna Knock on a couple

doors I heard you a year ago uh moderately promising result but I haven't heard of any of these projects actually finishing um any questions foron or um intuitions or opinions on where this these two might fit in relation to Electric okay any further comment on

this okay um we do have a number of uh P2P discussion points um there is a new proposal up by agent Anton on network shards which would be in relation to kind of how nodes are selected for at net and future Das distribution um a or Anon can you give us a brief on that

yeah I can

Adrian Manning: yeah I can just give it yeah I'll just give a quick overview of maybe just all the things that I raised uh just to save save time um essentially I just wanted to make some of the teams aware

of these things so there's this PR which we've called Network shard uh something that Anton suggested um but it currently isn't super important for what we have right now but when we start having extra gossip subtopics that we need to form like stable backbones for uh this introduces A New Concept that essentially allows us to tag a a node ID or a pier ID to which topics they should subscribe to and allows us to have essentially an easier way of keeping track of those peers to make the the topics stable um so essentially I'm just trying to get some attention from client teams to have a look at that PR and just signal whether they think it's a good idea bad idea so that uh we can kind of progress and move forward with it um the

second thing that I suggested uh is uh the I don't want message which is in Gossip sub uh it's in the gosip sub specs at the moment uh it's the implementation at least for us anyway is quite small but it it promises to significantly reduce some of the bandwidth on Gossip sub where we we're planning on starting to test this uh practically now in Lighthouse um but it's one of those things where we need uh the entire network to upgrade before we start seeing some of the effects so if you have some spare bandwidth it's probably worth the effort to try and implement this into your client and you'll share the benefits of it um it should be fairly easy to understand if you just have a look at these two PRS

Danny Ryan: um

the backwards compatible but the more people that do it the more aggregate uh effect it's going to have on the network meaning you could roll on Lighthouse independently but you're just going to be a bit in isolation in usage of it

Adrian Manning: exactly yeah so so it's entirely backers compatible we'll we'll probably try and release it into Lighthouse and see if it is useful but we only have you know X percentage of the network the more clients that do it the the the better the effects yeah

Danny Ryan: and isation Final in the is it in state that you would release it yet or do we need to go through some P top um hurdles to kind of get it into the spec I see it's not merged

yeah

Adrian Manning: yeah so it's not merged um in my opinion

so the general premise is pretty much outlined in the specification that you can go and implement it and you won't have any issues there's some parts that aren't specified and there's some discussion around like some dos vectors that can come up um because scoring hasn't been introduced into the spec but I think that's not a huge hurdle for not implementing like at least the base version of it

Danny Ryan: um but like the message format and things like that

Adrian Manning: yeah that's all speced out yeah okay yeah so that should all be fairly good um yeah I'll take questions on all three if uh after this if anyone has any uh but the last thing is implex I think there was a discussion about this earlier on where some of the client teams only had implex

and were going to upgrade to YX implex I think in liip is now being deprecated uh J is uh on our networking team may have some extra things to say um but just curious about any client teams whether they still require implex because uh our plan is to kind of deprecated at some point yeah that's it for me

Danny Ryan: let's take the last question first um does anybody still relying on solely on Imports uh for Techo our implementation of yo is not really production ready yet so yeah we still r on

NX

Danny Ryan: and it looks like Roar does as

well

Phil Ngo: yes we still working on our yamuk uh implementation right now just dealing with some performance issues with it

Danny Ryan: given the deprecation of imple in Spec um can we start talking about a timeline to to deprecate in rpec you know is for four six months um end of year is there any intuition on on when we can do this

Phil Ngo: I wouldn't be able to give you a confident answer today without talking to Cayman

um I'll have to get back to you on this

dline

Danny Ryan: I'm the only reason would be if there are security concerns wi rush it um which I do not have good visibility

on

Adrian Manning: oh yeah J has been looking at it I think a little bit in more daytown okay yeah maybe

yeah

Danny Ryan: yeah um Xiao and and AG if there are particular security or optimization

or other reasons to do this on you know fast timeline can we surface that outside of the call um and if not uh you know obviously we have a lot of different engineering items going on maybe both teu and lar can can if there's not a reason to rush uh they can take a a look at the potential timelines um does something

yeah we've had a few question sorry but

I would just ask for for us to move on with the spec because on the spec and Plex is still required um if you could move into optional would be a great update already

Danny Ryan: yeah we certainly could but we

would just know that that would fragment communication the network as of now given them Tech stairs impation um maybe it's worth opening up a PR that makes it optional to Galvanize the conversation in one place I have a do question on network shards is the obviously we use uh Discovery to find uh bage particular apption subnets

already live is this compatible with that or if you implemented Network shards you now would have an issue finding peers that haven't implemented meaning is it is it backwards

Adrian Manning: yeah it's Backward Compatible um essentially I don't plan on changing any of the discovery things at least until all the clients have kind of upgraded uh you wouldn't get any benefit if you tried to do the discovery kind of optimization um at the moment yeah we're still using the same Discovery we've always used for forever um even though we have we currently have the current iteration of the node ID to add a station subnet that's in the spec at the moment but it

is back is compatible yeah

Danny Ryan: but once everyone does upgrade you would make some changes

Adrian Manning: yeah once every once everybody's upgraded we'd probably have two one I Pro initially I would try and use the fast optimization where you search for the prefix and then uh fall back to just the standard one where we just search everything but it yeah

Danny Ryan: that's not a spec change that's an engineering change once you have confidence that the network is upgraded

Adrian Manning: yeah exactly

Danny Ryan: yeah I mean given that we want to use something similar with data availability uh this layer of Attraction

does make a lot of sense to me yeah essentially making it a tool we can reuse analyze and understand any other questions on on any of these um the I don't want has been close for a long time I think that at least a couple of teams implementing this could get this over the get this over the edge um and especially when thinking about Network load and relation blobs and other things like that I don't want to make you know at Le a moderate impact

seems very very with well especially for the the relative Simplicity that it is all right any other questions comments on on any of these networking proposals I was not confident we're going to make a through um any other discussion points closing remarks and with a couple minutes to spare thank

you everyone um Alex Stokes will be running this call for the next few months um please don't give him too much trouble take care

thanks guys thanks thanks Dan thank you guys thanks bye

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