All Core Devs - Consensus #143

Transcript

[Music]

Alex Stokes: okay we should be live cool everyone uh this is consensus layer call 143 there's the agenda here in the chat it is issue 1158 on the PM repo and yeah we have a number of things to talk about today um both with Electra and then also uh scaling the blobs so so let's go ahead and get started so first up I think it'd be helpful just to touch on devnet 3 I think the last time we checked in it was going pretty well but in the meantime I think there have been a few bugs pop up

and uh last time I looked for participation wasn't uh super good are there any updates on De n 3 anyone would like to give

Parithosh Jayanthi: yeah so I think the bezo teams identified what the issue is and they're currently working on a fixed image uh Daniel mentioned that it should be ready by tomorrow so we can deploy the fix tomorrow uh he's on the call um I guess he'll expand on that

Daniel Lehrner: yeah in in the end just what what par said so um we had a bug where we did not warm up the to address at the

beginning of a transaction for um 7702 accounts so accounts with delegated code um this led to a wrong gas calculation on our side um so this this issue I've created a PR I need to add um a bit more of tests but yeah as per said by tomorrow we should be ready

Alex Stokes: okay cool and that was the only assing thing I three that we were tracking

Parithosh Jayanthi: yeah there was one Lighthouse nethermind note that uh had an issue I think right now we've basically choed it

down to Hardware issue on the VM we got on the cloud provider um so we've started resync and I have to look at uh I have to check up if it's fine now but besides that I don't think we found anything specific

Alex Stokes: okay cool okay uh that sounds like we're good on Deet 3 then we'll wrap up those items and hopefully things restore to normal then we can move on to devet 4 so yeah there's a number of things here I think the first thing to kick us off I'll just call out uh this document from

e panda Ops the devet for

specs there's a section here on open PRS I think this is the best spot just to see what remains uh before we can gets to w94 um on the seal side I think the main thing is that it says here listed Alpha 6 for the specs release I think it will end up being Alpha 7 but if someone feels differently let's discuss um there are a number of PRS since Alpha 6 that again I think we'll go into Alpha 7 and yeah from here it'd be nice to sync on some of them so I think the biggest thing at this point is this execution request structure and how we're handling them so

it would be good to resolve that um I think there was some work uh on Discord around how to handle this what I saw there were like a number of issues around um yeah a number of different things would anyone here be able to give us an update on that um I do think there was a resolution uh to get to at least a design that we like so it' be good to agree on that particular sign

Felix Lange: I mean I can't give the update so basically the the open issues that popped up were that um well we uh the main thing is that some of the CLS decided that it's a

bad idea to like having to compute the request hash on the CL side and they want to leave this to to the El um in a response to that we are changing the engine API um to pass the request instead of the request hash calculated by the CL so the El will calculate it we have also changed your commitment to resolve like the request commitment in El we have changed it to resolve a potential hash collision and um the commitment is very simple so even if the CLS don't have to comput it it is absolutely possible for them to compute it because they just sh to 56 of some bytes uh which they have

so it's not like anything complicated there's no rlp there is no MPT in that commitment so that should be okay if they want to compute it but they don't have to with the spec changes and then finally there was some we are still kind of debating if we should make the system contracts behave one way or the other but it's Irrelevant for the Cs and I think this this is basically the result um today PTO uh from prism has raised um some concerns regarding the ordering of requests but these are in fact already resolved in the latest specification um at least the one that we're targeting

right now so I think we are basically done with the design right now it's just all very messy because the specs are still being updated and the whole thing is just a bit like in the air right now because of the last minute changes that everyone wanted but it's basically good now from my perspective

Alex Stokes: okay thanks Felix um the one thing with the contracts like we did have an RFP for an audit and so like I think we should resolve that as soon as possible um was there One Direction you were leaning because I know there's an issue with like the type bite either being admitted from the contract or it handled somewhere else

Felix Lange: yeah I mean the the the changes to the contract are very

small um it's not like a big change to the contracts at all to to put this bite and um we don't have to put it either and I think the officially we are just soliciting proposals right now and the proposals will be in by mid or end October and then the work on the audit will actually start I don't think people will really seriously start the audit before they have been selected as um as an auditor so I think we

still have

Felix Lange: couple days left to add these op codes or potentially I have I have personally have some plans to make some refactorings in the uh in the contract but just to try it out if it's like a

better approach but it's not again it doesn't really affect the state of things like the functionality of the contract at this point is kind of logged in we just have to make the final call and it doesn't change the output from the El at at all this is just internal stuff basically

Alex Stokes: right um pus do you have something to say

Potuz: yeah just uh the the abstract problem on this API changes and by the way as as Felix said I mean we were already implementing and I was reviewing a PR for Prism without knowing that there was a comit of today changing completely how the comet was so so this

is this is what drove that discussion um so after this latest changes of today uh it seems that the cl is receiving the requests in the same ordering the canonical ordering that the pon block has them and the CL can return now now now the CL and the El would be speaking the same ordering which is what was bugging me and the only thing that I would uh try to come up with an agreement which I don't really understand why we are disagreeing on is on the way of sending a hash I think it shouldn't be a problem for us to compute a hash in whatever mechanisms uh helps the El if it's only like hashing sha 256

bytes that we already have uh and we already have the ordering and it doesn't require to include new encoding like rlp I don't see why we wouldn't do this I mean over the Json

Felix Lange: no the main difference is that instead of the like on the C on on the C s side in the CL block we are using the hash tree route to create the commitment for the requests while on the E side we comput this request hash which is not quite um the hash rout but it's kind of similar to the hash Tre root it doesn't I mean there could an argument could be made for just using hash root on the E and this is what Matt has also alluded to at one point but I think it's not necessary

because there's no need to create proof about requests because the requests are just an output that follows exactly the transactions in the block so basically the request hash on the El side is just a check sum of the activity that happened within the block which is fully triggered by the transactions so it's just this the the value of this commitment for the El is very low because it's literally just an identifier for like something happened or

not happen

Potuz: understand but so the the the thing is the the current status I think is the worst of both both words because we're sending data over the hot

path which is block validation uh we're sending data over Json over hot path which is block validation and I would want to just send 32 bytes instead of uh this of course for us a hash root would be trivial because it's already implemented for us and uh it would mean work for the El but but if it takes us to like Computing a sha 256 of bytes that we have already I I would be willing to do that work to save the sending the full request I think we should come into agreement with this the I don't mind this but sending the full data I think is the worst possible outcome of this

no

Felix Lange: I mean this is where where this is something that has to be

resolved between the CLS so the there there were some people who were who would did not like the fact that they would have to compute two different hashes even though the hashes are pretty trivial but they still wouldn't want to compute like two different commitments on the CL side hases are M microseconds

Potuz: sending bites over Json is milliseconds I think this is just a no-brainer that we don't want to increase the Json side

yeah I mean

Felix Lange: I don't know it's I'm fine with either it doesn't change the El implementation all that much if we reive the request we comput it over the request if we receive the hash we just put the hash it doesn't matter to us in

the end like how it's sent this is either way totally works and it's a very cheap operation if you feel very strongly about sending um um sending the the hash and well it has to be computed on the CL side it's a trivial thing to compute honestly it's just you take the s lists of the requests that are in the beacon block and you have to write them one by one um into chart 256 and collect the outcoming hashes and then basically hash concatenation of these hashes again so it's like a two level tree kind of thing uh it's very trivial and all the bytes

exist so it's not like it doesn't require any encoding I don't know I can look into the hash free root as well but I think the has route will be more complex it would be more operations maybe it's fine to make a definition for the El I don't know if this is really really something that you guys must have then I will look into it and figure out how to specify it in a way that doesn't require introducing like we we don't want to introduce ssz in the E with this change we are basically walking a very fine line here between like dealing with ssz but also not dealing with ssz too much because it doesn't appear to be time yet to change it it's not for this Fork to introduce

ssz into the

eels I agree

Potuz: and I think I think just Sha of each list and just Sha of that would be trivial for us to implement it would be three hashes this is I presume Collision resistant and that's it yeah it's actually Four hashes I'm sorry and four hashes is much better than sending this over Json

yeah

Felix Lange: just let's let's Okay this part of the spec is really not that complicated I think the main stuff we have is just like the design is pretty much locked in right now it's just that with this thing maybe we can give it another two days or something to

resolve it in chat because I don't think we will resolve it today or can we quick maybe quickly get a show of hands from the other CLS what they think about this issue I'm seeing in the chat some people writing just send the stuff and Jason it's fast also like not everyone seems to believe it's a problem to send the full requests in new payload

Alex Stokes: yeah the concern for me is just having like yet another it's more conceptual where it's like you have to think about a new way to compute the commitment and granted in this case it is very small so if this is the best thing we can do then let's do that um but yeah I think it'd be nice to avoid

like yeah another bespoke commitment scheme

Miguel

Mikhail Kalinin: I just wanted to add that I think it's nice separation of concerns the SE sends the data uh and the AL compus the commitment this was already mentioned I also want to add that if for some reason we decide that this is not optimal uh for I mean like data transmission takes to too much time uh we can switch from in the next version of new payload we can switch from from the entire data to the commitment I would not just do the pre preliminary optimization here

Alex Stokes: okay I mean to Felix's point it

seems like from the CL so far they're leaning towards flat request meaning just sending the data over with no hashing on the seal other than maybe prism uh how do other SE clients feel about this or it's fine if you haven't had time to take a look but an update would be nice okay I'll assume that means no one's had time to look um okay yeah thanks for the input everyone oh go ahead

yeah one one

Mikhail Kalinin: one

last bit uh the PRS that are to the consist back and the engine API they are now updated with sending the entire data and also uh there was previously this uh bite prepend in each list in the type bite it's now dropped as well so there is no type bite and the type should be derived from the index of each request uh each P sequence so if it's zero then the type is zero and

course

Alex Stokes: okay thanks um okay I wanted to make a decision on this today I sounds like we won't F

resolve every question which is okay I think we should try really really really hard to have this completely settled uh by next week's call so yeah what's the right place to continue the discussion uh there was like a very long thread on the R&D Discord is that the right place Felix or Mel you guys are yeah okay um I think it was the Json RPC API Channel if I'm not mistaken uh so yeah please weigh in there otherwise some decision will be made and yeah um you know maybe just for like broader context like I think at this point we should aim

to have like pectra specs Frozen by Devcon that's like a month um if we can do it sooner that's great uh but yeah I think at this point we should be very focused on on that goal uh I can message you after eth dreamer about about it um okay so that was I think the biggest thing there's also a number of like Downstream things to how we answer question so yeah it is quite important to resolve as soon as possible otherwise okay so there were a few other things for pectra so in particular uh there was this one I think

it's actually let me just double check the number here right so 3918 this was an update to how we handle uh request for validators to switch to compounding and we're going to Leverage the uh execution layer consolidation request sort of mechanism for that I put a link to the pr here I think it's in a pretty good place um I think we're in a place to merge it later today but uh yeah if there's any final feedback or comments now would be the time okay I'll assume not uh so yeah I'll

take a final look after but I think we can merge that one today which would be nice um great yeah Mel's just saying everything's been addressed and yeah I took a look the other day I think we're in a good place with that one Downstream of that there were then some implications for I think this is 43 oh no that was something else sorry let me grab the number it was 3818 uh let me grab this link here and again this was handling um how request how deposit request are queed now uh particularly in the beacon State there were some performance issues there so this is like really important to resolve uh I say it's Downstream of 3918 because

uh some of this is touching on like consolidations and deposits and their interplay and all this um yeah I guess I'd have a question for Mel do you feel like uh this is moving along pretty well and do you agree with my assessment that uh yeah I mean my read is that it needs a few updates after 3819 sorry 3918

Mikhail Kalinin: yeah it's I mean like the updates on the client side right

Alex Stokes: okay I guess then is the ready to review or no

Mikhail Kalinin: PR is ready to review uh there are couple of things from Recently um kind inputs couple of inputs in the

pr um I would say that they're not significant so I will review them and apply some suggestions yeah it's it's ready to be reviewed it's ready to be merged uh after these recent things are addressed

Alex Stokes: okay thanks

and yeah and I think that we need this uh to get merged soona because it retails engineering work on consist client side one this foret for

Alex Stokes: right yeah definitely I mean we did a test here and it caused issues with like a high deposit count so this should be the pr that resolves that and yeah I would agree it's definitely uh very

important for pectra so okay maybe we'll leave that there for now then and let me just see if there anything else we covered there requesting okay anything else anyone sees on like um at least for devet 4 Petra otherwise we'll move to a few other PRS that might go into pectra but I think need more broad discussion okay so then I think the really only

remaining things uh up for discussion for Petra would be these two PRS uh on the specs repo there's 3900 and 3787 so these are both touching the attestation format of various parts of the stack let me just grab links here in case that's helpful for anyone um but yeah this is I think kind of the biggest open question question for Petra at this point so it' be good to go ahead and make a decision today um ultimately yeah so these are refinements of how we're handling the attestations following the attestation EIP and Petra already I think it was I always get this number wrong but I think it's

7549 um in any case yeah I I guess we'll start again with another temperature check um maybe AR the duck I think you're kind of pushing for these if you want to uh make a case for them

Jacek Sieka: uh I can just summarize some of the discussion so um I think there are three options basically we can delay everything till the next artwork um there exists something which I would call like a complete conversion this includes um changing the simple at uh the single attestation

format the attestation format and possibly any Downstream apis um personally I'm not that afraid of this option because it's kind of a limited opt it's kind of a well-known option um but the feedback has been that this would cause a lot of engineering effort in in many clients uh so the third option that I that I think is maybe the most reasonable to pursue right now is to is to go for a limited implementation that addresses specifically only um the security advantage on the gossip channel of the single ATT station

and then leave other changes for the next hardw uh because uh of two things uh first of all uh the difference that the full set of changes brings can kind of be implemented in code they don't really depend on this spec that much like if you want two types for you know onchain attestations and uh Network Aggregates then that's perfectly fine to code your client this way and then in the future if we decide to do the full thing in the spec as well all that really changes is a constant which is the size of the list um

so uh if we focus only on single attestation the benefit that it brings is this uh idea that we can uh check the signature uh before Computing a shuffling and based on experience from past outages both on mainnet and on test Nets every time we run into a case where a shuffling has to be computed we've kind of seen instability uh and my suggestion is thus that anybody that or the way that we would introduce these change is to really keep it tight and focused on the gossip channel so that if clients want to

implement it in such a way that they just translate to at a station and then change nothing else that would be uh an entirely minimal change also to client code bases like it should be at least um for Nimbus we're we're fine with both option I think it would be sad to delay the single attestation change to a hard workk in the future because this is this is like a thing just waiting to happen and when it happens we we would regret it

Alex Stokes: yeah thanks yeah thanks for the update um right so what I think that would mean then is

going ahead and closing 3787 for now and then focus on yeah like you said uh just these like networking level concerns of 3900 so yeah I think there's been some other input across different client teams uh how do we feel about this approach um I'm not sure if there's a refinement of the 3900 PR to make it clear to like just scope it to the the gosip player maybe just like a not on the would be helpful um but yeah like I hear the security argument um around again this do Spector and I think that one has a lot of weight so I lean towards doing that for Petra but I would

love to hear other clients input uh yeah e dreamer you got your hand up first so

uh yeah so Lighthouse is opinion we've had uh a time working on this and I mean he said that we could have a spec compliant um version pretty quickly at least like on the networking level but we wouldn't necessarily have all the changes propagated through the client and I guess we could push that to a later time um and I guess it just depends on timing if we're trying to ship P Petra as fast as possible then he would like slightly lean towards

no um but um I feel like if I I feel personally like if um that I agree um uh with with gasic that I I think it's worth doing even uh if we can have a spe compliant version and and propagate the changes later but to get it to get the fork done and deal with the gossip or deal with the Doss tack I would feel it's worth doing

yeah that makes sense HRI

Enrico Del Fante: yeah um so we were discussing about this for a long time and um internally

we we are we're still uh leaving the door open for the single attestation super minimal uh implementation and I haven't had the time to to complete my my my first Spike over over the simple simple approach we we uh we think that it should be a minimal even if not super clean might be ugly but we could have um something that is uh good to go relatively quickly but we' uh would like to confirm that later

okay terance

Terence Tsao: if it's minimum like now I

wonder if we even should have the validate inter changes because I was originally the proponent of that it just naturally feels right to have the validate her gossip of the single atation but that of course is more inv that of course it's more invasive in a way so I guess the questions to everyone here is that uh would it be better if today we take out the validator side changes I am personally in favor of it but I'm also open to not having that as well but but but I gu one way or another I think the security thing is quite important and I am personally supportive of this

change

Alex Stokes: right uh so how do you see it perhaps even just in prism if we have the validator guide changes does that imply you need to touch your validor clients and all those apis or can you just still Adit it to gossip

Terence Tsao: if there is a validator change then yes validator client will change and then the API will also have to support that right

okay uh AR the duck

Jacek Sieka: uh like this is more of a point of order but in theory we can keep the that change and still keep the API because the two formats are interchangeable in the sense that the full attestation is a superet of the simple the single

attestation so we could actually get away with not changing the you know BN VC communication protocol even if the spec reasons in terms of uh uh you know single attestation it to me that mainly sends a signal uh whether we want to uh pursue the full change in the future as well uh and in that case I would leave the uh language as it is if it like let's say that today we decide that we do

3787 for the next hard workk as well we aim towards it at least then um when we introduce those changes we could also discuss changing the beacon API but again um I'm happy to change the beacon API today as well or you know for the next or whatever to me that is an kind of a separate discussion like we can we can decide on these two things separately in the spirit of uh not ballooning this change Beyond where it absolutely has to go to solve the security

issue

Alex Stokes: right so yeah I mean I think that makes sense in theory and then my question would be yeah how to handle this in practice because there's not going to be some like extras speec communication that people need to be aware of I'm open to ideas on how to handle that

Jacek Sieka: uh I mean in one way like I'm happy to propose the like make a PR for the beacon API as well and then we can concretely see what it will uh entail if we today agree on on shipping simple attestation on the gossip

Network um I think that's also an important step for clients to to see like how much uh change it like how much work it would be to um expand that change to the beacon API as well um and I'm happy to make that PR to the beacon API as well so that we can see how much it changes the language of the beacon API so that we can decide that you know in two weeks or four weeks or whatever it will be for for for a future ah somebody says some this is already on on the beacon apis back great I haven't really been following there to

me like uh I really think about this change from the point of view of the network and to me single attestation and and the proposed um aggregate attestations those are envelopes and just like you know Aggregates on the go Channel today they have an envelope already uh which is called I don't remember what it's called it's called something weird which is why I don't remember it but this is all like just just for the purpose of simplifying communication between clients on the P2P layer and we shouldn't you know force that into context where it doesn't belong

right hrio

Enrico Del Fante: just a comment on the pr of the about the API changes so that specific PR I think is not just something that is impacting the communication between VC and BN because it's also considering changing the event of the event stream which I think could have some other Downstream effect outside VC and again I might be wrong here by just raising the flag that if we go down that path maybe someone else could say hey you're changing something else here

Alex Stokes: right I mean there's at least tool

in and stuff that would use those channels so it would break them if there's a breaking change um yeah

r on the dock uh my

Jacek Sieka: personal opinion would be to not change the event API actually because imposing this change on you know um third parties that just observe um the event stream I think that's completely unnecessary uh I feel there is a weak a small argument for updating the beacon API uh it's not as strong as updating the gossip Channel but um the thing is that uh you know when you have a list you have to compute that

list and you have to verify that it's correct that it only contains one element that the element is in the right spot and so on um so if we change the beacon API to speak this same language when signing uh an stations back and forth um I think we'll just end up with a simpler API that has fewer uh ways to fail so it's just one less thing to check for so and in in the bcv and communication and because uh the bcv uh the BN VC communication is something limited to you know client

implementers and not passive observers or tooling I feel that that's kind of different than changing the event stream

Alex Stokes: okay um so to move forward um it sounds like we think 3900 is like in a good enough State um if that's not the case we should discuss that now but okay so we have that one um I guess yeah AR the duck if you want to review this 472 PR on the beacon API just to make sure it aligns with what you're thinking that'd be helpful

and then what I would suggest to move forward here is that we sort of you know you know soft include uh 39 for Petra devnet 5 not devnet 4 that gives people a bit more time to implement just the very like strictly scoped gossip you know uh layer implementation and so we'll have a little more time to understand like if that's actually like a pretty you know well scope change that given the security considerations pulls this weight um then yeah we have like another ACD cycle to uh to think about you know formally putting it into DEET 5 does that sound like a good path forward for

everyone we have a plus one and a thumbs up um does everyone feel like they understand what they need to do here with respect to their client implementation because I think that's like my biggest concern at the moment is just like uh there's not like a super direct way I think to make it super clear just from the spec what we're talking about okay there's General agreement on this so let's uh move ahead with that and also yeah just to be clear it sounds like we're going to um ignore 3787 for Petra uh which should get us to

spec freeze sooner which is very good cool so okay I think that was everything on

Petra

Alex Stokes: is there anything else uh anyone would like to discuss otherwise we can move to um talking about some blobs okay great so for the blobs um I keep asking and the situation doesn't change too much but I will ask one more time uh are there any updates for the

peros pados dev Nets we're still working on it

Alex Stokes: yeah okay

thanks I think yeah people have been working on it and yeah it's so just moving along as fast as I can

Barnabas Busa: yeah so basically we launched devet and uh we have been on finalized for well over a week at this point and today it's it's been turning to the verse and uh we're considering to do a relaunch with exactly the same spec uh we had a bunch of different client fixes for uh different bugs we we we have a lot of debugging uh going on and we had a good call uh just on Tuesday in the breakout room so I think uh we are on track

Alex Stokes: cool thanks for the

update okay uh another relevant really exciting thing is that we did finally merge uh this engine get Bobs V1 PR so what this does is essentially lets the CL query their local mle for blobs and it unlocks a lot of Co use cases in particular um very likely supporting blob propagation you can imagine if I am a proposer and I don't have the best Uplink um I can essentially leverage my peers mols to do the availability check for me so really cool to see this merged and yeah I think immediately I'm just curious about implementation status are there any CLS

who have not implemented this yet

Terence Tsao: we are implementing it but we have not completed yet I see there's a g open PR so I'm looking forward to testing that

yeah

Enrico Del Fante: for Tech we we merged uh yesterday and it will be part of the next release going out soon

Alex Stokes: cool so yeah I mean I wanted to bring it up because I think it's especially in light of last week's conversation I think it's like a really critical thing to to uh at least make it easier for all Network participants uh

to handle the blobs as soon as possible uh so yeah I would consider this a top priority to get merg into your clients my understanding is that there's kind of a couple phases of this like the first one is just implementing it and being able to like read and then separately there might be another phase for the right path or like when you go to propose um maybe it's a bit early then to like discuss all of that but I guess just something get on your radar uh I believe this is something we can do even without a hard Fork right so you know if we get this together even like the next few months there might already start to be impacts on reorgs and you know um all sorts of things like that so yeah consider this uh super

exciting and very important to implement ASAP there was a related cons specs PR I don't know if we want to discuss this now um I think the main open question ohar do you have something about this or this other PR

oh

Ansgar Dietrichs: 100% familiar with the other more like to the general topic I just wanted to briefly remark that it's not super urgent but once this is rolled out I think we should at least look into the possibility of explicitly prioritizing um broadcasting the block over the blobs because um what for now what we will still do both for the build

local Builder them itself but then also the individual notes as they receive both the book and the blobs that they will rebroadcast those kind of with equal priority and so they all kind of compete for upload bandwidth which especially for the local Builder often is the crucial bottleneck in terms of timing um and given that basically with the M Pool we expect that in most cases basically all the blobs will actually already be known across the network um really the block itself is the only kind of crucial missing piece of information and so so I personally think that there's at least a good case to be made to to explore whether we might want to delay put a small delay on the lob um broadcasting so that like the block itself usually is basically already

fully submitted by the time we start clogging up the upload bandwidth with

flops

Alex Stokes: yeah thanks yeah and this is what I meant a second ago when I said like the second phase to this um I my understanding at least is that that's directly the intention um because again that directly helps again say solo stickers or you know nodes that are under resourced relative to others on the network so again I think that's super important to uh to figure out as soon as possible and related to that uh there was this uh again related PR uh this is 3864 onp repo and um right I think the question here is essentially

like it's almost like a May or must around node Behavior if you let's see let me just double check actually I don't know enrio you open this I yeah I can

Enrico Del Fante: I can summarize very quickly so essentially is the pr saying that in the on on the on the spec we are saying and there is a new way of getting the blobs and if the client wants to leverage that new way of getting data what what should do essentially there are two things that that PR uh focus on is one is the must around publishing the reconstructed blobs side car based on

the blobs received by from DL uh which seems like something that has been discussed over um several several channels and we all agreed on and so this saying that if you rebuild the blobs side car you have to publish over the over the B2B G um this is one thing the other thing is more a Nuance over the interaction between this publish and the gossip rules we were arguing that the client should take care of updating the uh equivocating caches why when we do that to close the door of eventually

additional blob site car coming over the P2P that was essentially equivocating The Blob that you reconstructed in sent over the network so it was kind of making sense to us to say a client just make sure that you update those so you don't have uh you close the door over these additional blobs

Alex Stokes: yeah thanks um gender in the chat says that it should be a May rather than a must any other clients have a take on this

Enrico Del Fante: well to really help the network I

think you you really should do that um so

yeah as anything it should be required to rebroadcast Okay I

Mikhail Kalinin: uh there is no actual way to enforce the must but yeah I mean language wise May or must it doesn't really matter because most of the clients will do that

Enrico Del Fante: you cannot even enforce the the the um

the dissemination of the of the things that you receive I mean it's not enforceable you're just participating as a good actor into the into the network like is a must that you should disseminate messages that you that you receive the same way you should publish this at the same at the same level of of of criticalness to to me

Alex Stokes: right I mean the spe here is for like honest Behavior so if we think it's better for this to be honest which I think it is then that's how we handle this um but yeah maybe zoom in out just a bit um I think this is something we

should resolve soon but I think there's a little less time pressure um especially given implementations are uh in progress um yeah so anything else for this PR we should discuss right now uh I think that was some helpful feedback otherwise yeah uh there are a few more things on the agenda okay um yeah I kind of just wanted to leave some space to discuss uh again you know our strategy for raising the blobs uh my understanding from the call last week was essentially that we have you know the core pectra eips there are

a batch of say like three or four eips uh that we were considering um to include to address the blob count and how we Implement that so yeah I mean there was a lot of discussion I think around you know solo stickers and you know notes on the network and what we should really be supporting um one option well yeah so I think there were like kind of two immediate things we could do to like start to address uh the concern again of of these under resource nodes uh one of them is this engine get Bobs to be one which is why again it's really exciting to see that uh moving along another one would be uh essentially having a way for

a node to specify when they go to build a block uh essentially like a node local Bob Max and I either didn't see or I missed a conversation of this route last week so I wanted to leave some room for that now uh I think there was some conversation in other channels and it seems like people were kind of divided um yeah I don't know if there's any anything to update there my sense I think was people generally kind of prefer this SK blob's route and then kind of see what that buys us in

terms of head room before thinking about other options okay osgar has an interesting proposal Uh custom in priority fee which could kind of start to get at the same thing everyone is very quiet on this topic I guess everyone said their peace places okay yeah I mean I think ultimately there's you know we're going to need more data to actually make

decisions here and we haven't really quite had time for that so yeah that's fine and in that case uh that was everything on the agenda today uh Final Call for anything else we would like to discuss uh sure Perry's asking what data we would need

yeah okay pus

Potuz: yeah so on that I do have an opinion um so I I think if we still need to to to check if it's true and if uh if Ton's data uh that points to less reor since dun start starting with client

optimizations I think that would point to stakers being able to handle the maximum blob on regular sync on on regular gossiping uh if that data if we discriminate that data for home stakers and that data is still true and and reorgs have not increased a lot although Tony posted something that uh that does make this clear then I think uh tip I mean sinking at the tip in gosip is not a problem and we should be thinking on what would increase with a Target increase without a maximum increase so we are already have data that proves that stakers uh can handle the maximum and if we increase the target what will

change effectively change will be uh transactions in the menol we will have more broke on on the menol at at gossip but we will also have much more time for syncing and I think what this affects is the speed at which a node can sync in when there is a period of non-f finality I think this is the crucial measure that we want we want to have a client after two weeks of nonf finalization and check if it can actually catch up to head or not uh I don't even know if this holds today and it seems that it's hard to check to test this short of like making holeski not finalize

Alex Stokes: right so this isn't even really

a node or like a client issue this is more just like a particular node in their bandwidth right that's what you're concerned about

Potuz: what I what I'm concerned about is if we if is this is the fact that there's going to be actually more blobs in each uh block that we we have and more blobs in the mle floating around more transactions with blobs in the mle floating around and if we are in a period of non-f finalization while we're sinking a note that is trying to catch up while while it's sinking it's not going to fast forward to the next finalized checkpoint it's going to request all blocks with all blocks from their peers and it's going to execute them all so this I think is the critical thing that will effectively change with

a Target increase and I think we need to measure this we need to measure whether or not we can handle this situation today if we have some slack in to handl in this situation today that would allow us to increase the Target

Alex Stokes: right I mean it seems like a one

Parithosh Jayanthi: I do want to make one point that I also brought up in the um Club metrics chat if mnet was had stopped finalizing two weeks ago we would also by now have had a lot more for so I don't think this version of likeing the client and its things to head even would exist you would probably have a most users would just checkpoint sync to the fork that we socially agree on is essentially the

Canon

Potuz: I don't think that's true so on dev Nets you've seen this because clients are like experimenting with new software but on test Nets we've shown that if we stop finalizing because say like a percentage of the nodes go offline we are very good in our for choice is quite stable and we want Fork but at any in any case like the fork situation is has to be strictly worse than the non Fork one so I'm I'd be happy if we at least get the data of what happens in the non-for one and we just need to sync I believe that our clients are like stable enough that if 33% of the network goes offline we are not going to start foring which is simply not going to gather enough

attestations to finalize which is what did happen in

girlyy yeah

Parithosh Jayanthi: yeah that's fair I guess then the question is is there any situation where we can even connect this data I mean I guess we can coordinate nonf finality on hsky but that won't be that trivial or easy I guess

I for

Potuz: it's very hard to simulate this it would be nice if other CL clients have analyzed if they could simulate non-f finalization on their own clients without uh without making the actual Network non finalizing but we've tried on prism it seems that it's

incredibly invasive to change this

uh I

Jacek Sieka: I can only speak to the effects of what happens like even if the network mostly follows one work uh what tends to happen is that uh more and more Forks kind of appear uh because you know somebody's halfway through sinking and creates a block um and these Forks they're actually legitimate from you know a for Chase point of view uh and then the number of them kind of just keeps growing if you're online and if you're not online then obviously

you just see the one main kind of uh event but uh I know in Nimbus we don't really have a good rule for when call the number of forks because there kind of exists none the the best we have is kind of yeah let's just you know put at least recently used cap on the number of works that we track and that's it and that's maybe the best thing we can do in this case of long known finality but but it's kind of not entirly satisfactory and we haven't really tried this you know since what was it PR that died last and we tried to

revive it didn't go very well

Potuz: yeah this this was actually my concern that girly we actively tried to save it and we couldn't uh clients could not SN to head so it's not really clear to me that we are in a situation today that we're robust enough to sync and increasing the target would make it would certainly make it harder

Alex Stokes: and maybe this is obvious but we can't just have like an infal devet that we spin up because we want more realistic

networking parameters

Potuz: yeah defet would suck for this I think that the idea the ideal situation would be if we could Fork a client to do exactly what he would do if it wasn't finalizing but then keep the network finalizing if if we have a solu to that if some C if this is not so hard to do for other C clients that that that will be the best scenario I think

Alex Stokes: why can we have a debet and just take say a third of the validators offline

Potuz: yeah but then you don't really get the data of what it takes I mean we we have done those experiments and we do

finalize back on small Dev Nets we have done those experiments of attacking the network on De Nets but whenever this happened on an actual running test net we couldn't get back to to sinking so so I think the the P2P side of like test Nets is much is is very different than the b2p side of dep Nets topology apparently affects a lot yeah

AR the do

Jacek Sieka: uh I think I can articulate one thing which is uh when when when when it would become a no-brainer to increase it which is actually that we have kind of a lot of uh attempts to lower

bandwidth and as we deploy them uh so for example this e get blobs thing um we kind of should see a decrease in general in man with usage and if we consider what we're using today kind of a informal ceiling or informal minimal requirement of what you need to run an ethereum node and if we decrease from there that is obviously room to increase blog hunts um in the future so that that's kind of like a way to to to to say at least like where where we're definitely happy to to

increase the block CHS and then there of course there exists the gray area in between where we might just do it and uh hope for the best I don't know that depends on other concerns more yeah non technical concerns

Alex Stokes: okay uh there's a little discussion in

the chat um yeah any other points anyone would like to bring up for today

Ansgar Dietrichs: yeah maybe just one last question I would have on the Block front um it looks to me really that like maybe we all leaning towards kind of making this decision basically as late late as really reasonably possible within the kind of the for cycle um to get as much real world data as possible also on these kind of new PRS that are being deployed and everything um I do Wonder though at what point would it make sense

to try to already have a blob throughput increase part of the devet so that it would be ready to go it seems to me like easier to revert back to not having that and removing it back out than to basically added rushed very late into the definite process so I'm wondering whether people might be willing to consider having like an optimistic addition to the Deets for for BL BL through put increase

pus I

Potuz: I think this these changes are symmetrical so it's just changing about by a couple of constants so it's exactly as hard to add than to subtract to I'm not involved in Def Nets but I I would personally avoid making a change change

that I might need to revert it especially if it's the same change uh but having said so we we really need to like commit to shipping these changes as soon as possible like have a release immediately as soon as uh the get blobs V1 get gets merged uh I can say that my personal node I enabled quick and it made a huge difference already on my own bandwidth so so there are some changes that are already been shipped that that are in the in in the released uh client as optional that already change the bandwidth consumption so if we sort of like start advertising our users to use those changes and we commit to shipping everything immediately I think in two

weeks three weeks times we might have already some data

Alex Stokes: uh Perry you had your hand

Parithosh Jayanthi: yeah um just to mention one thing I don't think it is as simple a change it's not a constant change for for a lot of clients they include the blob count at compile time so they have to first figure out how to change how they consume the library which is a a a bit of work they have to put in in the future as well the question is if they put it now or later and then the second question is if we want to include 7742 and if we do that means engine API changes and all of the stuff that that implies as well so I do think it's important to make the decision earlier

rather than later because it isn't just a constant change that has to happen

Alex Stokes: yeah for my understanding if people want to accelerate this uh for pectra it sounds like 7742 implementation would be the thing to Target uh let's see well there's a 7623 question but you know assuming we'd be okay without that then like the most minimal thing would be 7742 and then any IP to raise the Target or even consider raising the max um so yeah if if you you are Keen to push Bobs long uh 7742 I think is is the place to focus for now

pus

Potuz: apologies

Alex Stokes: all good I mean I guess one question that hopefully is easy to answer would it be helpful to have an EIP that does actually propose bumping the target say to four or something like that um because that is something where like we do talk about the set of eips that we would possibly put in the Petra uh there isn't an EIP for an actual Target increase and that is something we'd want yeah

baras

Barnabas Busa: I think we should make a decision whether we want to actually increase the blob with 7742 or if we going to just

play around with some constant and change the constant everywhere and if we do decide to change it with 7742 then and we're actually considering an update uh of The Blob uh BLC in Petra then we need to include 7742 in

Petra

Alex Stokes: yeah I mean my read is most people if not everyone's in favor of 7742 so I think that's going to happen yeah good gindra was asking there was uh

I believe Perry had ANP there there have been a couple floating around um but yeah someone wants to like polish one and uh start entering into the discourse I think that could be helpful although it is more of a minor point okay great all that is a target increase already yeah I forget exactly what this EIP does um but yeah anything else otherwise I think people are pretty heads down on devet 4 and uh yeah we will keep pushing things along

okay then thanks everyone I oh one last thing

yeah there's

Parithosh Jayanthi: uh one more thing I did want to mention we do want to do a named test net for Devcon um it would be nice if clients could maybe plan a release with a release flag for the name testnet we'll basically be reusing whatever we use for devet 4 so it does that sound okay for clients um if not then we can also work around it and just have custom Flags but yeah I think having having a name release would make it really easy for people to interact with it at

devcom will devnet 4 be ready by Defcon I would really hope

so

Alex Stokes: I would also hope so but I I feel like there are still a number of spec things that are kind of in flight um yeah I mean perh go just in for that

Parithosh Jayanthi: yeah the the main idea is that there's a couple of VIPs like 774 772 that would make sense for people who are at hackathons to test out and this could be the place that they could easily test it out

Alex Stokes: yeah know I mean I think it makes a lot of sense I guess my question was just if we want to look for deut 3 or deut 4 in terms of specs DEET 4 would be great

Barnabas Busa: um yeah because the the contracts will

change between def 3 and Def four so ideally we want to Target

def 4

Lightclient: we still have five weeks that's a long time we could have done that five by then

Alex Stokes: okay then yeah let's let's plan on De 4 for Devcon test net um there's been no opposition so I would say it's thumbs up to Perry's question okay anything else going once going

twice yes everyone keep focusing on de4 as Barnabas said in the chat okay cool then uh yeah I'll see you all around thank you

thanks by bye everyone

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