All Core Devs - Consensus #144

Transcript

[Music] this and we should be live

cool let's see that's the wrong link let me grab the agenda okay yeah

Alex Stokes: everyone so this is consensus layer call 144 and yeah I think people have kind of been pretty heads down with uh the pectra dev Nets that being said uh there's quite a bit on the agenda today so yeah let's go ahead and just Dive Right In uh first we'll start up with Electra and I'm not sure if there's anything to speak to around devet 3 I think we killed it this week but if there are any comments uh to close this out there uh that this would be a good time for

that

Barnabas Busa: I was actually just waiting for ACDC uh just to confirm that I can shut it off by the end of today unless there is any opposition uh I will proceed with it anyone on D 3 we still found a proposal issue with grandine I'm not sure if they want to still debug that or whether they just want to focus on

11 not4

Alex Stokes: that's a good question uh is anyone from grandine on the call okay uh yeah Barnabas I would just say

use your judgment uh if you can't get in touch with them by the end of the day I think it's fine to move ahead and close out devet 3 sounds good cool okay otherwise then Dev nut 4 uh we've all been very busy getting this ready I think I been saw a message on Discord earlier uh a good number of clients I think are ready to go but I don't think we've launched the devet quite yet uh anyone have any more information on the status of devet 4

Barnabas Busa: yeah uh I just thought that syus just joined in uh so maybe we can Circle back for for one second to d uh uh so syus uh would you be okay if I shut off D Tre by

the end of today or are you guys still debugging something uh regarding the non proposals

bug sorry I

Saulius Grigaitis: just uh joined the so uh I think I hope that we will be uh ready I think I mean we we pass all the tests and there could be some integrational stuff that we didn't test in ctoas uh so yeah if we are lucky we will be ready today otherwise tomorrow

Barnabas Busa: no the question is whether we want to keep D Tre around uh are you are you still actively debugging on it

Saulius Grigaitis: oh sorry ER uh I don't know I think I think if you what was the

outcome when you nuked the the server uh was it uh running okay

oh we

Barnabas Busa: we can get back to that uh yeah yeah let's do offline yeah yeah yeah but it's still not proposing that's the conclusion okay

okay we will check then okay

Barnabas Busa: okay so regarding DEET 4 uh I I also have an update for that so we have two execution layer clients working G and interum JS we have a branch for nether mind that but there seems to be some formatting boxs and for the C side we have Lighthouse Teo prism and nimus working

and lotar is able to ATT us but cannot propose and Grand cannot propose

Alex Stokes: okay awesome uh so wait we've launched the devet or this is just

no no

Barnabas Busa: this is just local Crist uh we can so I would like at least one more e uh to come online and then we can probably launch it uh tomorrow possibly

Alex Stokes: okay yeah that works for me um cool any Els on the call who aren't quite ready but maybe you could speak to Readiness by tomorrow

um re is

not quite ready but I'll Sprint

on getting it ready today so we can launch tomorrow

Alex Stokes: cool yeah I think that would be nice um just to have a week or two of DEET 4 uh we did also want to have like a public test net based on devet 4 for Devcon so the uh the deadlines approaching um cool but yeah sounds like there's been a lot of great progress on devet 4 with the various implementations so that's really cool to see and yeah everyone just uh keep at it uh anything else on devet 4 uh yeah just to reiterate it sounds like we'll aim for a launch tomorrow um pending

yeah another one or two El's who can join any other yeah and

Barnabas Busa: and we can always just add them later on as well just make some deposits and in them

Alex Stokes: mhm definitely um cool any other comments on devet 4 okay if not uh then we can move on to a number of other things so at this point um yeah I'd effectively want to think about you know how do we get to a feature complete pectra so you know we

can start thinking about mainnet down the line there are a number of open issues that we still have um you know every call there are fewer and fewer which is also good to see uh one of them here is this PR 3900 and this was a refactor to some of the attestation work uh we had discussed this last call and basically said you know uh there are some like nice security benefit it's here it's also possible that implementation wise because of how core the attestation type is you know this could be a lot of code change for clients so we're going to give it another cycle uh to kind of assess that

a little bit better and then make a call on this uh this change so yeah I mean there's definitely grounds to have this as an update for E7 549 I always get that mixed up with pios um but yeah so I guess any other CL teams here have have you had time to look at this or think about this um I think the pr is pretty much ready to merge we just need to agree that we want to move ahead with it

Yan Rico

Enrico Del Fante: yeah I think like last um last message from d lion in in the attestation PR is kind of a good point

to me and considering that we we had our our Spike implementation it kind of um says to us that is is doable um a quick uh implementation of that that doesn't really impact anything uh it's not very nice currently but we could we could go through in that direction for sure uh but essentially what the plant says is that the uh uh dos attack that is supposed to be blocked is not is a problem that remains there

anyway which is kind of weird and to me is something like this is a is a is an argument that convinced me uh I don't know if anyone has thought about it and if this is true probably makes the entire uh change worthless do you think guys

Alex Stokes: right yeah has anyone had time to take a look uh I would need to go review a little bit more myself but I hear what you're saying um I don't think y's on the call and he was pushing for this um H any other seals have any input

here at the moment

U

Sean Anderson: well basically I would say that um like the general Lighthouse 5 was um yeah we didn't see the benefit of the change so probably not worth doing um for the reasons um D line brought up

Alex Stokes: okay thanks so right okay um I think then I'll try to Circle back with YK offline and get a better sense of yeah what he thinks um in light of this recent comment and yeah otherwise it does not

sound like there's a ton of support to move forward and if anything it's one less thing for us to do so we'll get to pectra sooner rather than later um okay yeah thanks everyone if there's no other comments there we can move to the next agenda item this one was around a number of P2P changes that I think kind of came out some of the discussions from interop earlier this year um I think you know a nice way to think about this is to go ahead and roll out this PR with um with pectra itself and yeah I guess here I'm just

calling it out uh for everyone to take a look I don't know where we are here there's a lot of convers ation um but yeah do have any CL teams had a chance to look at this PR uh feel strongly one way or another about merging it from what I recall there was pretty strong support for this direction uh at interop this PR would be I think a pretty like maybe not invasive but somewhat substantial change to the networking layer which I think with then would imply you know a good bit of

testing which again I my understanding is that the V justifies the cost but it's just something to think about

Pras

Enrico Del Fante: we discussed that L internally and seems like this is yeah there will be several several changes uh to to go for and seems like um a little bit um late to Target backra for for for that uh could be better to to Target the next one but this was to make to make things Mo mostly stable and uh and don't

don't add additional things to do for the next Fork it's been there for for a while and we were trying to keep Electra stable enough and having that merged now seems like big change

Alex Stokes: right okay uh this one was also coming from yasik so yeah unfortunately he's not here but yeah we got a thumbs up from Terren as well okay uh I'll try to reach out to him as well about this and uh get a better

sense of how much he wants to push for this and on what timeline cool um then next up we have uh a bug fix to some of the max EB things this is pr3 3979 uh and I think here the ask is just to take a look um it does looked like there was another issue with uh withdrawals handling and um yeah uh as far as I know this is a straightforward bug fix and it should uh should be merged so yeah client teams just take a look if you have a moment uh oh Mel's here I don't know if you want to add anything

else

Mikhail Kalinin: um yeah thanks Alex but yeah I don't think it's Quest report as mentioned so just take a look please at for the proposed

Fe

Alex Stokes: cool thanks and nice find uh I I think we definitely need a round of testing and review uh around the specs and one way to help that is to get to a stable Petr speec so again I think we're migrating to that regime and hopefully there are Cycles over the next month or two to really flush out any bugs okay next up uh we have an issue or at

least a proposal to think about as a z support for the Builder apis so here let me grab a link to at least this here here so this kind of came out some of of uh came out of some of the request handling that we were talking about with these execution layer requests going from the El to the CL and there was a lot of discussion around how do you structure these like is there a Json encoding is there an ssz encoding and in any case um the same question also comes up with the builder apis uh because then if you're a proposer going to talk to say some Builder it's they have to communicate

these to you as well and the Builder apis right now go with uh essentially this like Json encoding uh that deviates a bit from the engine API and this point was raised as a way to kind of at least have the option for both uh kind of get the best of both worlds via direct SSD support uh the question here for the CL teams at least is that you would need to support this uh in your client uh to talk to me boost and from there there's other like infrastructural things that we need to change um but I guess the first point there is like these other players like relays and Builders uh generally also support this it's in lower lency for them which they like and

yeah so it would make a lot of sense uh the question then is though you know the question then is that you need SE Buy in as well so the proposal concretely would be to go ahead and say this is like a you know sort of official part of pectra you would uh expect to have your client have support for this uh with the pectra hard fork and yeah I think that's the context there anyone disagree or feel like that's unreasonable to aim for uh Dustin asked oh someone was going to talk

Sean Anderson: that was me I was just gonna ask I just gonna ask uh it looks like the pr is meant to be backwards compatible so

are we expecting like relays to support um like this in a backwards compatible way which would mean like this would actually be I guess not mandatory for clients not not that I don't think we can or will implement it but

Alex Stokes: right so my understanding is that you set essentially like a header in the request uh that just signals you can work with this transport uh and then you go from there and yeah the idea is to have sort of the existing again this like Json encoding uh then also just the option for

SSC

Sean Anderson: okay gotcha

yeah also I think uh Petra would

be a good timing to address this or to test this as well and because I think this was proposed two years ago already and even though it's backwards compatible I think uh having a stricter timeline maybe pushes it a bit and yeah CLS don't even need to implement this but of course if you need want to profit from the latency against then because we only need to implement the client s side so it's mostly important that relays and sitec car software implements

Alex Stokes: right so it sounds like there's General

agreement that this is interesting um one thing we'll definitely want is support of this uh and my Boost um so yeah that's something I can work on with the relevant parties and then separately yeah CL teams just keep this on your radar I don't think it's a huge lift implementation wise um and yeah we can go ahead and also get the pr merged that's a good first step uh so have that into the Builder specs and then yeah from there uh let's aim to have support for this uh along with Petra and that can be part of the pectra testing as we move along to mainnet does that sound good to everyone

there was one more question uh

also we discussed on on uh Discord which was basically who will profit from this latency gain because I mean buildo could just eat it up with playing timing games for example and then in the end there's no real latency gain uh but I think since this is also it's in the response of the get header request and also in the when you submit the blinded block and the main latency benefit would be in the second part when you submit the block so and since we have a R Timeout on the header implemented in clients I think timing games would not be a profit from this extra

Laten again

Alex Stokes: right I mean also with ssz

encoding you use less bandwidth which will be nice uh in any case and it also does harmonize with where we might ultimately want the engine API to go which would also have an SS transport so I think it makes sense uh even putting aside that question okay uh I can move ahead the spec things there and uh yeah let's just keep this on our Radars for pectra okay next up uh I think we just generally have like a sort of um notice especially for application developers

who happen to be listening so we have this concept of generalized indic which basically correlates to uh with the ssz again serialization scheme that we use on the CL there's a corresponding merization scheme there's a way to identify nodes in this Merkel tree for each type uh that we have on the CL and a facilitates like clients and you know anything that looks like a like client for current purposes uh it looks like the beacon State then will cross uh this like key number of like a power of two in this case 32 which basically means that the current Lea structure gets pushed down a layer and so these these like fixed numbers all change the

concern here is that if you're writing an application against these things there's no way at the moment to be attract to them and so you need to also update say your smart contract so yeah I think the ask here is just to flag this uh again if you're using things like say 4788 which is the parent beacon block rout uh EIP that we've had or uh yeah different things like this if you get if you reason about these generalized indices in some other way in your smart contract uh right now with Petra there will be a breaking change so um presumably this makes sense to you uh if it doesn't you probably don't need to worry about it but please be aware and

uh yeah Mel you had the comments I don't know if there's anything else you wanted to add to that

Mikhail Kalinin: yeah I just want to add that Ean proposed um potential solution uh to not cross this uh mark this time we could group um some some new Fields into yeah into some logical groups um based on uh more on request stuff like uh like withdrawals uh consolidations and deposits so there going to be three groups and we just put uh every new introduced field in one of those buckets but yeah from my perspective is kind of like uh artificial more artificial and yeah but that's one of the potential

Solutions uh so not to not not breaking not introducing this breaking change right now and maybe uh and in in the future once we have a stable container uh we will break this thing just once and we will not have to deal with it uh after those containers are introduced so yeah that's one of the one of the work around for this problem just to use kind of logical grouping of of the new Fields but I'm kind of like personally inclined not do anything unless the re um strong reason for that like something is completely broken so that's just a comment I wanted

to share

Alex Stokes: yeah no that makes sense and yeah that's a good option uh if it was like a huge issue I guess it's worth reaching out to some of the like for example users of 4788 uh and R that by them but otherwise yeah um it's probably good just to have this be known and move ahead as is cu yeah we could think about restructuring the beacon state but then there'll just be some more code thrash which is not ideal yeah

Mikhail Kalinin: and basically yeah even even though we are relying on stable containers introduced in the future uh this is going to be a break and change as far as

I understand so uh these 4 788 uh you can block routs um yeah like the applications using them will have to be updated anyway at some point in time whether we have stable containers or whether we just in increasing the um number of fields in the Bon state in the future so in any possible way it will we will happen

right okay

Alex Stokes: uh so next up uh I suppose I just wanted to give a brief update on uh this breakout on EIP

2537 this is entirely an El concern uh but there was a breakout call that we had and we kind of came back to this core question of uh how to structure the the apis to the promiles and there's a bit of a trade-off here between like user safety uh and essentially cost or performance with uh how we think about some of these features like if you want to get into the details there's a notion of a subp subgroup check that is very important for the cryptography um but yeah then the question is just like the right way to structure these uh essentially the the inputs to to each Pi compile so I think I'll just flag that for now uh again if you're listening uh and

especially if you expect to be a user of of these features uh on mainnet say for example you want to use you want to verify Zer knowledge proofs that uses curve on the Chain um also the use case of like validators and signatures so this EIP does let you reason about validator signatures trustless Le in the evm which is really cool and that all being said um yeah please reach out uh if you think this concerns you we would love input uh to help answer the question around the right way to structure the the some of these details of the EIP

cool okay that was everything on the agenda for Electra any other comments about that for the moment otherwise we have pios next up okay then yeah the blobs our favorite ethereum future so I think to get started well okay even before that I'm assuming there aren't any substantial updates with the p Nets from what I've seen um so I believe there was a

breakout this week and yeah I think clients have been working through maybe some sinking issues there but otherwise I'm not I don't think there are any um significant updates on the on the devet status

Barnabas Busa: nothing cool thank you

Alex Stokes: so that being said there are things we can think about in parallel uh one of them is uh this PR which pairs actually with uh this engine GI blobs V1 method that has recently merged and there's a question around clarifying sort of the P2P spec here for an honest node last call we discussed this and essentially we got to the point that yeah this PR makes sense uh I think the

key question here being like if you get a blob in this way say from your local men poool should you then treat it like you've received it from Gossip from a pier meaning that you then gossip to other nodes so yeah I think at this point uh everyone's in agreement on this being the right call and so we'll go ahead and merge this I'll bring it up now just to serve as a final call um any comments or questions on this okay then I think we'll look to merge this even later today cool and then I guess you know related to this I was curious if there

implementation updates around this feature uh you know we can think about ways to structure this where it does provide significant B savings to nodes I know last time clients had been looking at uh this engine GI blobs V1 and there is a variety of different states of progress any clients care to give an update on this now yeah

Terrence

Terence Tsao: yeah so we had our implementation since last week and then we have been testing it on the Wild and um I wrote a report yesterday let me see if can drop into the D but the t drr is that like um the heat rate surprisingly to me is really well so I was able to

recover like one blob side car per 12 seconds over like four days and that's pretty good if you really think about it because like say today the target is three that that's trying to assume that you can get like 33% of The Blob side cards just over the man pool and then because of that the import time of the block turns out to be much faster because typically my node weights about like 100 to 500 millisecond waiting for the block and now that time is just basically gum because I can import the block faster without waiting for the block cycle over the W while and then so that's one benefit I did see that I have received less blobs P2P message over um

over the gossip St and I think that's pretty good as well but I cannot I couldn't quantify how much like um bits per second or mega bits per second that saving is right and then the last thing I observe is that because of that I am the fastest note on the network in a way that I receive the blob the fastest it turns out to be sending more blobs out right because now it's kind of the trade out because I am on the other end of the spectrum that I am in a way receiving blob the fastest therefore I reduce my dunal bandwidth but in parallel since that I want to serve notes because of that I tends out to be using more upd I I think that will

change when more um notes have this feuture and then yeah that's basically my update

Alex Stokes: cool thanks uh is there some way to think about throttling your use of the Uplink you know assuming you get AOL from the M pole in this way

Terence Tsao: yeah Lighthouse has a write up which I haven't reviewed so they're think about assuming concept from the p d perspective right so it does make sense to kind of play the tradeoff F to kind of play the tradeoff in a way that if today you're the fastest note you kind of want to throttle your upload so you can wait maybe wait a little bit before you broadcast the blobs

uh

enria

Enrico Del Fante: yeah we implemented uh it and we also released it and is currently working on mainnet um with bzu correctly we got problems with nether mind and uh yeah waiting for other El clients to to release and and test um currently the te implementation due to what what Teran said uh is not um using it immediately when you see the blocks so we wait at least half a second before doing this just to avoid um yeah to be the

Super fastest node fer not that then has to be um has to publish because actually we we yeah essentially this this this this waiting delay is happening on the attempt to try to recover instead of recovering and then wait before publishing so yeah this was the first uh since we were pretty one of the first client implementing it so we decided to go first in this direction and by the way we saw a lot of nice uh recovering we so we are systematically grabbing blobs from the and this reduced all the attempts that

te um te try tried in the previous implementation uh through through recovering via RPC so we were particularly pretty aggressive in trying to recover late blobs and now though this thing is went down a lot because be because we try e first so so far so good

for for for ohol

Alex Stokes: yeah that's really exciting to hear okay uh anything else on that um sounds like yeah progress is underway

I guess again I don't know if there are any yells on the call uh but yeah the more it yells to have this implemented the better

Sean Anderson: I was curious Terence if you know how many of the blobs during that period were expected to be seen over the public men pool because 30% seems lower than I would have guessed because I had the impression that 80 or 90% of blobs were coming over the public V pool

oh

Terence Tsao: oh yeah but then the problem here is that uh the relayer and the Builder they purposely broadcast the blob side card uh before they broadcast the block right so because of that I'm sure the number would have been higher

if today they do the reverse but since that I am receiving blob py first before I receive the block Mo most of the time it kind of yeah it it kind of mess up with the number here

Enrico Del Fante: yeah essentially he's not even trying to get it from DL because you got the blobs first right

Sean Anderson: okay I see

Terence Tsao: yeah yeah

Alex Stokes: doesn't that kind of defeat the point of this being a balance saving thing though

Ansgar Dietrichs: well it does not if the stat is meaningfully different between relay blocks and home builder blocks right because home builders do not do this and we primarily want to help with um the peak bandwidth for their blocks right so

it would actually be really interesting to see that stat broken out between the two types of and

Enrico Del Fante: and what is important is the local building here uh so when when the relayer is involved doesn't really matter because anyway they will they will gossip everything by themselves but when the Lo when the proposal builds locally this is where things get interesting and um the local recover really matters

all

Alex Stokes: right Terrence uh did you have a chance to look at this in the write up you had the the breakdown between relay blocks versus local blocks

I do not

Terence Tsao: so I will follow up on

that

this

Sean Anderson: feels a little weird because you know the nodes have already done this work to get the blobs over the transaction pool and just because the relays are sending out first we're not able to take advantage of that work

Terence Tsao: I also suspect that will mostly likely be the case because of the timing game so the relayer their incentive is basically to gossip the block as late as possible to the into the 4 second Mark right so if today if we ask them to uh maybe send a blob after then they would just presumably just sensor The Blob I presume so I don't yeah I think that's kind of yeah I I think that's kind of

I I think I think that's a hard one

Enrico Del Fante: to be fair what what I think it will happen is that the reler even start um not BL not sending anything over the b2p in terms of blobs just sending the block when when the majority of the network just is able to recover from the logal Y why sending the blobs and the the Y the Cs will anyway um uh send will anyway recover and send over the b2p the blobs so they they will do their work

Sean Anderson: is there a way to receive a like blobs side car header and then before

requesting the full blobs from the cptp ask the

E

Alex Stokes: there isn't today I mean we could think about that but it also then is going to complicate things because you like the delivery becomes like partial right like you could have this header state or you could have the header plus payload State meaning the blobs side car right well in any case uh uh I think

this was really helpful um and yeah if we could keep drilling into these different metrics of how this actually works live on mainnet that would be super helpful um to get a better understanding and yeah maybe there's something Downstream like like client was suggesting uh to deliver these B savings with this feature

Dustin Brody: so uh one one point regarding that I I guess I'll I don't have a strong view on it yet I guess but right now it's explicitly marked as as optional and and I understand this and I'm I think it makes sense as as introduced in this PR to be optional um because it was not had not been explored the way people are exploring it now but

if if we continue to pursue a certain direction that that uh is being looked at regarding um increasing blob space with and here's the crucial part with the Reliance the the key Assumption of it is okay precisely because of get blobs and it would not be okay without get blobs then I would suggest that the optionality of that be

assessed makes sense s yes yes so

Saulius Grigaitis: so I'm interested in um in kind of implementation detail here where uh when we when we receive blops from uh

from P2P this is like driven um so so whenever we we receive we we just get it and for for E we just uh mostly pull it uh so uh so is it so let's think that uh that this um uh optimization will be implemented so is it uh so the current thinking is that we just uh pull um eel in order to to get um uh the blobs that eel has whenever we see the block for example or there are discussions that U uh there may be some

some other way to fetch the blobs from

e no

Alex Stokes: I believe it's just the first path so I mean one way to think about this is it's like another availability uh sort of Avenue for the node so you know you get a block and there's some blobs attached you need to know that the Bobs exist they're available and gossip is one way but the mol is another the idea being that at least currently most blobs are in the public men pool at least that's sort of our working assumption um the data might suggest otherwise uh but in any case the idea then is that you don't really need to wait for gossip from a pier you can just go to your local men pole because you

know in some sense you just already gossiped this at the El layer so the CL doesn't need to like wait

yeah

Saulius Grigaitis: yeah but so according to the data it looks like uh uh if if a CL block arrived then uh I just uh ask eel once uh and I should get the blobs uh so there is no some no need for some extra more complicated more even based approach uh here is is it correct

Alex Stokes: well the issue that just came up was an AirPlay between this feature and the relays and like the external pipeline cuz um basically I mean it sounds like what was

happening is that the relays send out the blobs before you even really think about this uh just do the way like the blocks and blobs are disseminated from relay so yeah to the extent that we also want this like to the extent we think this will be savings for bandwidth uh for all nodes even if you're talking to relays then we'd need to think about some refinement of the mechanism to actually let us get that uh because we can't get it right now

okay

Saulius Grigaitis: okay thanks

Alex Stokes: and yeah maybe just to close out the point like we were probably mostly concerned about uh nodes not using the relays so you know I don't think it's

necessarily A blocker but it is an interesting interaction between uh these two different parts of of main net cool yeah thanks everyone that was I thought really helpful discussion next up uh yeah this one might be a pretty straightforward yes no the question is just rather to rebase uh puros onto Electra this is certainly the intent and then it's just now a question of timing um I don't know if this came up on the breakout this week but I believe this PR's ready to go so it's just kind of coordinating with client teams and um

yeah making sure that everyone's okay with uh moving ahead with this in the specs uh Dustin I'll assume you're answering yes to this question uh any other client teams want to hold off okay we got to do it that's good doing it okay cool anyone not ready

Barnabas Busa: anyone working on peer death ready I think this is going to delay the next

devet uh by potentially a couple of weeks to three weeks even

the next periodos devet yeah if if we

Barnabas Busa: going to be requiring this

Alex Stokes: was anyone at the breakout call the perios breakout call this week

Barnabas Busa: yeah the general consensus was that it's better to do it sooner than later so everybody seem to agree with that uh so that just the two branches don't get too far apart from each other uh but yeah the the major issue is I think that we don't have a stable p network right now

so just going to complicate things a bit more for beer death going forward

Alex Stokes: right I mean we will have to do this at some point and so the question is just like yeah do we take the pain now or later uh I would lean towards merging um okay how about this uh I can try to reach out uh to differen SEAL Teams and in particular the people working on pios on those teams just to do like a final check uh the next couple days um but yeah otherwise if not then I would expect to see this merged definitely before the next

ACDC cool let's see what was next okay so yeah to round out the blob segment of today's call uh I believe uh Francis was here and even wanted to give a presentation on some of his analysis are you here Francis

yes uh let me share my screen

Alex Stokes: okay

and

all right um okay so more blobs um I believe everybody like or like most of us uh on this call have already like uh viewed this do so I'll try to be quick and like um just reiterate down some of

the important like uh points I guess um so uh the an analysis is broken into like I guess three parts first is like why we want to like increase the blobs and second is like what in the what's the kind problems and then thirdly like what's the kind of like solutions to relevate the concerns for those problems um so the first section is like why the urgency so I this two pictures I just took them from last night and you can see that the blobs are trending towards the target the three BL Target already um so that comes to the first point like the existing consumers are like continues to scale and base on open

Manet have plans to increase their sale and increase in like significant increases in Block usage for example uh base has increased started to increase like the gas per second from like late September and it has increased from 10 megga per second to 40 megga per second as of yesterday so uh a lot of those changes are kind of like eaten up by the base gating as well the second point is that there are new chains trying to join and use blobs space for example uni chain like recently just announced and they are aiming to launch with blobs atda later this year uh for their main net so that's kind of another um uh new blob like requirement the

third part will be the loss opportunities for other l2s if they see that okay it's already a Target and the deal is going to be super expensive then they are probably gonna like reevaluate and maybe go with like odda Solutions or some other things so um I guess two quod balic we cannot afford to let the momentum slip on moving more layer TOS over to using blobs um so what are the concerns today uh there are like very legit concerns about like different aspects of the network and I think the from what I gathered there are two like main concerns the first one that solo stakers uh their proposed blogs uh can be like reor due to their low upload bandwidth

because they cannot gossip out their blobs and blocks like in time for them to be attested so that's like the first concern the second part the second concern is that if we increase the target number that could potentially impact the network like thinking performance especially uh for the unhappy case where the network like does not finalize and uh everybody needs to catch up with like thinking the historical blocks but also have to keep up to tip of the chain so there might be some added B there that might push things over the F so um what we are trying to do is to like take a look at this like situation in terms of like block bands in terms of bandwidths from a first principle like a

perspective and try to really see okay in the worst case scenario what are the upload bands needed uh to be able to F like fulfill the network requirement so uh before that I'd like to re uh reiterate this things uh the some of the things that we are not talking about to just focus us on the like same SC the same problems um so first we are not going to focus about like block based fees uh we believe that it's important here but they are kind of like athal to the analysis and with the current flow up Market close to being saturated we believe that the uh entire kind of like feed Discovery will happen very very

soon the second part is that uh we will not talk about like solo sers who have me in mayot so this is specifically for the S stakers who are trying to propose in that situation so there I think for this situation there is Broad Community consensus that with me in V the bur of Distributing blocks and blobs is offloaded to the like Rel layers so not the solo stakers and we're not going to talk about any way timeout and fall back to local building situation because it should happen very very rarely and the assumption is that download bandwidth here is not the B neck and this we didn't hear anybody complain about they cannot download things like in time Etc and in most places download Bandu is much higher than upload

Bandu um okay so that this is like the things that we are not going to talk about and the things we are going to focus on is like a solo Staker that does local building and tries to propose their blocks uh to the entire network the true bottleneck here is basically I think the number five step where the after is kind of like the the proposer the solo Staker like build its own block it needs to like gossip out both the block and blobs over the P2P layer on the on the consensus layer side and it has to happen within four four seconds of the slot to get majority attestation and um if theorically like

this should be like a little bit faster so that like it can propagate or all disseminate properties throughout the network so with that we have done some like um first principal analysis like we using very conservative and numbers and uh some of them we use the like empirical data that we observed from the network and also using the worst case scenario data first slow to illustrate the need so for example for stations like the worst case upload bandwidth we've observed uh is like 300 kilobytes per second uh as shown like sorry uh yes I okay never mind I think it's here like 300 like uh kiloby per second for the

upload band it um and there are like other points that I'm not going to go through like uh Point by point just in case of time but one thing I want to call out is that for the calculation we are using like 2 seconds of the windows transmission for the C layers to broadcast all the things out block and blobs so some some people have like mentioned that maybe two seconds is not enough but the the general s the general sense of this calculation is that to Showcase okay what are the kind of like proximate like network band we need with different blob numbers and the and then we can lead to the like optimizations we have and see what are the benefits of those like optimizations

so uh we don't need to like actually like look at the numbers here we just need to know that okay for different blobs like the more blobs you have the more like upload bandwidth that is required so um what can we do here to basically make it safe to increase the blob Target and blob number and I believe we've discussed extensively about the engine like get what blobs V want that is already showing like very promising results from both the lighthouse design on thep that's uh devet and also from like uh Terrence who just did the like analysis from his like on Z the network which showcase that the Block in part time is like much faster and there are benefits of the reductions

on like download bandwidths and for the upload bandwidths like we are I think we will like continue to like monitor the network and once more and more um notes with this new kind of like changes like being like online then we should hopefully see that the upload B will like decrease as well the point here with the engine get blobs we want is that with that the C layers doesn't have to broadcast the blobs out during that stringent time window that's relieving the like Peak bandwidth or Peak upload bandwidth they need so if we might use that and deduct all the like CL need to goip out the like um BLS we can see that

with five BLS Target and eight BLS Maps Max the actual like Peak B PE upload band need is low even lower than three blocks although like you still need to like gossip out those blocks but it doesn't have to be like that quickly and there are optimizations that has already been talked about like a little bit prior basically mean that okay we can potentially like delay goip out blobs a little bit later uh so that it doesn't mess up with the block gossip and also maybe intentionally save some like Block band it if you can if all the other people can get their like blobs like from their local em

pools so the client Readiness part I've done some like search by myself this probably is not like entirely accurate but so for the Y side I believe never mind never mind B has already done the implementation for the engine is get on gu has a PR already and Aragon hasn't implemented yet for the CL s what what I know is that PR and Lighthouse are are about to release a new version that supports utilizing the this new API so the point here is that seems like most of the clients are ready or almost ready and if we make it kind of like the into the hard work then everybody like after far hard should have this change and should have uh or like potentially

will have like a lot of like savings for the network band we the second point is to disabl publishing uh I think this is more about like te and they are already releasing that already so I'm not going to talk about this like extensively and the third part is like Implement I don't want P2P protocol messages and from the like multiple researches that uh we've seen it seems like with that uh we could result to like 3 30 to 50% like traic reduction and some of the like latency reduction as well but uh understand that the these are kind of prelimary numbers and will the results will like we will see it on the main to be sure but these are definitely like promising like um advancements I guess so there are like

another one which is proposed by B atoms I believe and we to suggest that we adopt like P2P like quick so that we will have like a better rgt latency and um I think this could be a good add as well so with all the like improvements uh I'd like to go through the like proposed options here um so uh we believe that with the suggested like modifications um if we take it at the face value right now uh it will be safe to increase the target to five and Max to eight without uh basically increasing the load on the various like solo stakers and also because the blobs are almost close to be saturated it would be

great to have a little bit more like 60 six% more like block capacity just for the like interior to space all the 43 to scale as a whole until P that's coming into play like after Petra and regarding the work uh I believe that with the required work is like implement this one engine get be one Implement I don't one message which are already being done U mostly by all like majority of the clients so you shouldn't add a lot of like extra um work or workload on the uh client teams and hopefully they should they could be done within like one or two weeks of time window and

uh with that uh there are other options like we don't increase or will we just increase this like Target two four to give a little bit more Lev BL capacity to the network um so the the actual like path forward that we want to recommend is that uh there are I think the the right approach with this is like let the client teams to implement this and roll it out to the network and then we use the real network data from Main net to see okay how much band do did we actually save let's say is if we see that with this we saved like 30% of the network B for upload link then with the extra like blobs it should be like on

par with pre prior requirements or even lower then you should be safe to like increase the blob number um at that time so the proposal is that PL teams like implement the mention features and changes and make them make the releases releases as soon as possible we let it run on theet and observe for some period of time and answer the questions like okay um can we get more blocks directly from E without like having to download them from uh the CL layer like all sorts of like orations that we can we can do and have all the like data ready and then if and when we observe the real benefits to the metrics we care about which hopefully we will uh then we

officially commit to the change and on the off chances that we don't see enough improvements we fall back to just increase the target to four um I believe that's it any questions comments or like suggestions

Alex Stokes: thank you uh that was really great to see there was also a lot to adjust um but yeah I mean I think the different options you L out end uh could be really promising fast forward anyone else have any uh feedback at the moment there are a number of you

that left comments on the dock I saw okay well so I do think this doc helps ground the conversation uh around like potential options for changing the blob parameters uh imp Petra and otherwise yeah it's like you're saying Francis if we have a little more time to gather some data that will help inform the decision

onar

Ansgar Dietrichs: yeah I was just wondering so it seems General consensus that we um want

to kind of make a call on this a bit later into the F process but I was wondering at what point would it make sense to if we at least think there's a reasonable chance we want to increase include a b Bob increase that we um add that to the to a devet um ideally I would I would argue for like the most ambitious version of it say I don't know 69 add it to the devnet just so we already have kind of make sure double check that that the actual kind of making the change on the technical side does not run into any issues obviously that itself wouldn't give us like much data on like you know the the the real world kind of constraints but but but but still um would that make sense or would we want to wait with that until we

made the final decision

um I

I think how can we do this like can we maybe like soft commit to this change like to this increase on the call so that we can both do it on the D net uh like in pcture a bit later and also like try the changes on the main net to gather like information from both sides and with that we could like have more data and more basically informs like information to make the decision like finally

Alex Stokes: yeah I mean I I don't know what exactly we mean around soft committing

uh to have this in Petra formally but definitely I think everyone has self-committed to you know answering the question uh so you know from there there's a question of yeah do we want to touch uh The Blob Accounts at all and then if we do there's a question of how um Barnabas brought up this comment and 7742 I think is generally our answer to this uh anyone feel well I guess one thing is you know maybe just to confirm has anyone started thinking about 7742 implementation uh or is that not really where we're at at the moment the strategy here would be to like have 7742 because it becomes far simpler to actually change these numbers

uh and then from there we can think about actually changing them especially I think this is more attractive if we want to think about experimenting with different numbers say on a devnet um my understanding is that it's really hairy to actually go and make changes to these just given implementations today

Barnabas Busa: I think this can potentially push the hard for back a month or even two months that there's not a single client that has any implementation with 7742 so if you do want to increase the blop count in pcture then we really need to lay on 7742 um I'm curious

is it possible to

just like do a hard increase like like hard Cod increase for now and not adding like 742 because seems like it's not like entirely ready and it does require extra band WDS for like both to implement that

Barnabas Busa: as far as I know there's not like a single constant that needs to be bumped up but it's like multiple different things and multiple different libraries that have to be recompiled and stuff so it's not a very straightforward change

Alex Stokes: yeah so I don't want to distract people from dead. 4 but we could

consider uh on the next ACDC revisiting this question around 7742 with the idea being that we are going to make some blob Target or Max increase in pectra does that sound reasonable to everyone

Ansgar Dietrichs: but just one one last question on this if we say that even now already basically if we were to start prioritizing it um it would it would possibly create a one month delay or more to the hard for it wouldn't that mean that like if we only think about this in two weeks now we are basically adding two extra weeks of basically time on the critical path um of shipping this

if we um decide to to still include it into the Hat fog like if if this is the case we should probably just make the decision as early as possible

Alex Stokes: right and so I mean that's the thing like if a client team has time to go ahead and start with 774 before the next call that's great um but again like we should focus on Dead 4 and this is what we had said with like this original split decision was like we focus on the corector stuff uh there is in you know for very good reasons uh the point made that we should really think about the blobs uh and Petra as well so we're just here at this moment in time and yeah I mean that seems reasonable to me I don't think you know

just adding 7742 is going to add like a two-month delay you know don't hold me to that but that sounds uh like a lot of time especially if it's like the exclusive focus of all the different SE teams so that being said it seems reasonable um because you know we'll launch that for tomorrow there might be bugs and then it's it's a whole thing so I mean yeah that being said do your point ongar um yeah various Sal teams any El teams if you're listening if you bandwidth like the sooner you can start thinking about 7742 the better uh if you could even have it implemented in the next couple weeks that would be amazing

was

Sean Anderson: there any was there sinking

concerns with 7742 because if we don't have the if we're being driven by the CL we need to validate The Blob limit The Blob Target are we can have the same types of issues that we're having with requests when we're optimistic syncing

Alex Stokes: yeah I believe we work through these questions with the EIP already and so I think uh let's see I think we setled on having the Target and the header for this reason

got it I both actually in the header

Sean Anderson: yeah we need the Max

Barnabas Busa: need the Target and the max

too yeah yeah especially if you want to especially if you want to have different values not just always half of it yeah

Sean Anderson: yeah yeah it's a good St have it implementing it like a month ago and it seems okay it's not a oneline change by any means but I would much rather do it than art coding new values in but I am curious like from a CL perspective how difficult it will be to drive this new API

it seems like from the like uh chat

people have not like really looking to like implement it but they are down to start implementing today so maybe we can do the same thing and um understand a little bit more while like people are trying to implement it

Sean Anderson: sure I'm just curious like what when do we cut a Petra spec release for main net and we started forking test Nets because we're talking about making this decision later but I feel like we're right now already rushing towards

one into four test

Nets

I guess do we have any like operations or like um objections to doing it this way just try to implement 7742 and prepare DEET for Target and Max increase

Alex Stokes: yeah I mean if if the client team wants to correct me please do but my sense is that uh yeah I just wouldn't want this to become a distraction uh with the other Petra stuff so like my sense would be kind of what I said I mean look the other way to think of about this is we can half a latency and make a decision

on uh ACD next week um that actually might be the way to do this and yeah if we can get implementations the sooner the better uh I just wouldn't want this to become a distraction for the other p uh yeah the other Petra stuff

Terence Tsao: may I ask what other Petra stuff are there because my understanding is that death net for consists of all the eips right for Petra a so if you're if today you're net 4 already you are mostly maintaining the future set right funding bus and stuff so now the question is that whether do we include this uh EIP and have a death net five or do we just cut death net four short

basically

Alex Stokes: I expect we'll have DEET 5 you know we'll launch DEET 4 even say tomorrow there'll be bugs that will take up some like attention to fix um but yeah I mean okay like do we want to commit to moving ahead with this today it does feel like process-wise I mean yes like I think we all agree but like yeah like I think

doesn't

Barnabas Busa: agree to include this by the way what is what is

Alex Stokes: what is what is this it's 7742 and then a commitment to change the Bob count somehow right

Barnabas Busa: well I would I would commit to 7742 and then we can discuss all the

changes later on but 7742 will be a requirement for pier anyway so might as well discuss about including that and then uh pring The Blob limit once every client has actually implemented it

Alex Stokes: okay uh I do think we'd want to have all the Els also buy into this but we could go ahead and say today are there any CLS who are oppos to 7742 and moving that to uh I think we call it scheduled for inclusion now okay anyone

disagree

okay

Alex Stokes: I will assume that's unanimous consensus then um so right if you have time uh please move ahead and start looking at 7742 implementation and I'll be sure this is on the agenda for next week and again I don't really expect any surprises um but then yeah we can move ahead and yeah just keep moving towards a blob increase for Petra okay uh we have a little time left and there were uh some ask for another set of eips are there any other final blob

points to make uh before we move to those anything with pios or blobs or scaling okay uh cool so there were two that were kind of related um I'll just go in the order they on the agenda so the first one was 7783 uh right yeah let me double check actually right so yeah 7783 so uh this was on last week's ACD call and essentially it's just uh having some more structure around uh how the

gas limit would change assuming there was a targeting within the protocol that would raise it or lower it um let's see is Julio on the call

Giulio Rebuffo: yes

oh

Alex Stokes: cool yeah do you want to say more

Giulio Rebuffo: um yeah actually I wanted to say more in context of 7782 um because this is not a CL specific IP I just wanted to give a more introduction um so yeah so basically instead of increasing gas limit uh in a cliff like manner you increase it gradually and you can kind of pick away some of the UN some unknowns uh one of

which could be for example if you guys don't remember if you guys remember the 413 status code error um and also yeah thisp is not part of the protocol so it's also easy to implement it's not an art Fork uh um yeah so it's basically it's basically um it's basically a counter IP to e 7782 and yeah that's pretty much it next week ATD will give an update on it um here I just wanted to to present it I don't want to waste people's time on on on any Le too much here

Alex Stokes: cool thanks and yeah I mean this

was the next one uh paired with this one was 7782 uh let's see I think yeah is from Ben uh and looks like you're here on the call would you like to give us an overview

Ben Adams: sure so the the idea of rather than raising blobs or gas um directly at least initially would be to decrease the slot time from 12 to 8 seconds um which would also um in effect increase the blob count and um gas limit in aggregate um however rather than loading any increases on a single valid dator by

speeding up the slot time um any increases are shared between one and a bit validators um and rather than so again this was brought up in ACD um but it's more of a consensus change than execution change and um I suppose one of the most important Pro uh questions would be how difficult um technically a change changing the slot time would be um some oh one of the other benefits is for for instance based rollups where their

latency is directly dependent on um uh layer one latency um outside of things like doing pre-confirmation and other more complex changes so yeah any any feedback on what changing the slot time would

be

Giulio Rebuffo: so yeah yeah so I so just to repeat what I said in in the last ecd about this is that probably this is a good change to eventually because it makes the chain more lively but by talking around to

with some people especially from the distributed validator camps uh they told me that this EAP is punitive because because it it actually it actually still increases bandwith quite significantly and another concern I personally have is that it may slow down development of single finality because one of the approaches being researched is um is basically trying to just brute force uh just brute force with some smart strategy of aggregating the signature so I think lowers lot times will not help there that much um and yeah so these are just my concerns from last time at ACD I just

restated

them here

yeah uh yeah

Guillaume Ballet: I just dispute a bit the fact that this is mostly an a CL change like yes the change happens in CL but the history is going to grow 30% faster um and while the performance itself is not really uh linked to the size of the history because at least in guess we move those uh those old blocks outside of the DB um if the it's going to take more space on the disc and you know a typical gas plus Lighthouse install is like one 3 terabyte at this

point uh if we start making like the chain grow faster and faster which by the way the chain is the biggest uh the biggest uh size hog um I think we're going to have a lot of uh validators out there that going to have to upgrade much sooner than anticipated um is it 50% faster like once once you get there it's 50% but until now it's 30% okay my Mass is probably terrible

30

Ben Adams: 33 um on the history growth that's significantly decreased since blobs um because a lot of a lot of that Co data that has moved off to blobs and then not 444s also

Guillaume Ballet: yeah okay that's that's possible um

but just um I I I don't think we should um you know jump into this without making some concrete measurements

Giulio Rebuffo: um I have the measurements I mean I basically asked for the guys from um I mean I talk with the guys from a Staker and they basically told me that whether you increase throughput of gas or not in around six months validator in order to comfortably round we need to switch anyway to four terabytes so I mean since you're you're basically since the hardware Works in power of two if that going to happen anyway might as well just you know increase throughput right like if if you don't do anything it you still increase the the requirements if

you do nothing increase the requirements so just make some people happy I guess that's but yeah um so that's the answer to your question but I think this should be discussed in ACD probably if anything

there any feedback from consensus

Alex Stokes: one thing I would say is you know the slot time is very critical to many many things uh in the protocol and also with implementations one concern I would have with this is that you know it might sound pretty straightforward but then ultimately has like all huge

implementation load um sort of like with the attestation EIP we have in Petra where you know it only sounds like it sounds pretty self-contained but then again just given how critical this concept is uh to like the protocol and it's it does you know it implies like a lot of uh a lot of work so yeah I mean I I agree with others that we should you know sit more with like the actual performance benefits and you know weigh that against what we're actually aiming for um One path forward to Der risk the like implementation question uh would be to yeah work on a debet or something off in parallel uh just to get a sense of like how much work this would actually

be

Franchesco

Terence Tsao: uh yeah

Francesco D'Amato: just wanted to say that one thing that uh might not be obvious is just how much it kind of has a potential get in the way of future changes to the which you might think be things that we haven't agreed upon might be even things that we haven't even talked about uh on ACD because they're just research at this point but there's just like a whole bunch of things that uh we might potentially want to do in the future from epvs to ILS to all kinds of stuff that do uh interact with the structure of the slot a lot and yeah just compressing the slot might might really not be good for that I'm I'm not saying that you know we can never do it but just I think it's something that we should only do if we in like an

extremely deliberate way like really being sure what we're doing so if if this is really about just increase in the uh gas limit or uh blob through and so on then uh I think in the short term it would be much safer to just do that as opposed to do it in in this way

Alex Stokes: was that helpful been in terms of feedback

Ben Adams: yeah

Alex Stokes: or yeah I guess from here

like would there be a place to continue conversation

Ben Adams: I mean uh yeah there's a on eth magicians of um uh a thread and I I do think it's so I I originally raised the p uh EIP because there's been a lot of talk about changing slot times but nobody's actually put anything down to to focus and center the discussion um so sort of putting out there as something to consider and think about because it does um impact quite a

lot of things um base rollups for instance is is one one thing that seems to be seen as a more aligned rollup but then that has the disadvantage of being quite dependent on um L1 speed compared to other types of

roll Cor

Alex Stokes: okay uh any other comments on this for now like Clan has a question how hard is it for CLS to change SL times in general

uh which I think is a good question and that's kind of what I was getting at is uh it could be the case that yeah it sounds simple but is actually more complex than it sounds do any sales today have a sense of this like is it as easy as just changing a constant or some uh configuration or would it be you know more invasive than that enrio says it's not simple yeah Julio says it's not which I think just lends Credence to the other arguments made that you know we should be very sure about this and do it very intentionally if we do do it cool well thank you um we are almost

at time there was one final thing just more administrative so uh ACDC on November 14th this is right in the middle of Devcon I would propose we go ahead and that call uh because I think most of us will be there uh I'm happy to have it if we want it um but yeah would anyone be opposed to canceling that call given that uh yeah most of us will be at Devcon and if anything can just uh yeah chat in person or various times through the week anyone opposed to that otherwise I'll

move ahead with canceling that one okay great then yeah I think that was it for the day unless there are any other final comments we'll go ahead and wrap enrio you're unmuted I don't know if you had something to say

just byebye

Alex Stokes: okay then that's that thanks everyone

and I'll see you around

thanks bye bye

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