All Core Devs - Consensus #141

Transcript

[Music] J [Applause]

okay we should be live and let's get started great

Alex Stokes: so this is consensus layer call 141 let me grab the agenda I'll drop it in the zoom chat here and yeah there's quite a number of things on the agenda today so let's just dive in uh first up is pectra and we have devnet 2 and three um I think mainly we're focusing on three at the moment is there anything we want to quickly address with

devet too

Parithosh Jayanthi: uh yeah I think prism found a bug that they were tracing down last week with non finality um I don't I see

Nishant is just joining in but I don't know if they want to talk about it

with you

Terence Tsao: so the bug was fixed over the weekend the pr was merged the tldr is that we had basically uh we forgot we forgot to copy something for in this example the Val data balance so the stay replay was wrong but yeah it's fixed and then yeah so I haven't see any issue since then

Parithosh Jayanthi: yep um so that's about it with DEET 2 um I think at some point the Explorer couldn't handle the nonf finality so it's dead so considering no one else is really debugging on it I'd push for deleting the network today um devet 3

key work is ongoing uh there's a curosis conflict that I've pinned in the interrupt Channel um I tested it the nodes are able to stay with each other and special shout out and thanks to the testing team because they were able to convert their tests into a format that I can run them against live death mats and Mario's already created as well as addressed um the failing test with re and nethermind and there is one more uh failing test with Aragon that I've created a thread for every things in inup so please have a look there and just a side note I also tested consolidations and the spec issue from the last devet has been fixed so we have the first successful consolidation on a

devet with an effective balance over 32 which is really really nice to see um yeah and I guess the next question is adding more CLS to the mix I've only gotten the CL branch and version to use from Nimbus as well as Lighthouse so it would be great if other client teams can just drop a message on interrupt as to which branch we should use and we will expand our testing accordingly um once once we figured out the spec issues I think with three clients we're kind of okay to already launch devnet 3 unless there's some reason to hold off and launch DEET 3 with all

cents

Alex Stokes: great thanks um yeah any other clients want to

chime in on Deet 3 Readiness it sounds like we could go ahead and kick it off uh even if not everyone's ready

uh lsar

should be ready so maybe unstable branch on lsar for devet 3 can be used

Parithosh Jayanthi: and also if client teams aren't ready at the launch that's still fine we can make deposits and add you guys later so not that anyone feels like left out

cool

Alex Stokes: anything else with devet 3 sounds like it's moving along pretty well um yeah I know that on the El side there were some things with 7702 I don't know if it's worth touching on that now otherwise we have a number of Petra PRS to to discuss okay let's move to that then

so first up uh we looked at this one or two calls ago but it's um essentially handing handling an edge

case in the correlated penalty calculation was slashing uh there was essentially an overflow with maxb at high amounts of stake and this PR fixes it so this PR has been up for a little while now it's 3882 on the cons specs repo and yeah I think it's pretty much ready to merge uh we got a thumbs up from a few different people so yeah I guess this is uh final call anyone opposed to merging the Sun okay uh if you're a client team and you

have a few minutes please take a look otherwise uh sometime later today or tomorrow I'll go ahead and merge that in next we have another PR we also looked at this one in the past as well so this was refactoring how the requests are structured uh in the beacon block this is PR 3875 and yeah a number of people here have been working on this PR I've believe it's ready to go so again last call um anyone think we should not merge this in okay Mel says there's a small thing

to be fixed okay I can take a look I'm not sure okay yeah there's a comment here I see okay uh I can take a look at this and yeah we can get that fixed otherwise anyone opposed to like this general direction there's been pretty good support so far so looks like we just fixed that thing and we are ready to go okay next up then we have another PR to

execution apis so this one it's another pass at structuring the request passing them from El to CL and essentially this is a slight different approach I forget the number but there was the pr we discussed before to essentially have the engine API structure in the way that the Els can just sort of copy paste the way they represent request on their side as they then are faed across to the SE this is a slightly different approach and let's see Felix is that you this says yeah that's mine okay yeah would you like to give us a little overview

Felix Lange: Yeah so basically this the

first one the first PR which uh you mentioned also the it was number five 65 so um there Matt proposed the this this approach where we would just instead of returning the request as Json as we do right now and and also in oh no sorry instead of returning the requests as like separate lists we uh to the CL so like one list per request type we would just return the like unified list of all requests and leave it to the cl to actually figure like split them up into into the types for inclusion into the CL block because as far as I understand in inside of the CL block structure this the each

request um type has its own list um however um this was not universally liked because I don't know it's just I think it has some some problems on its own like picking apart the request type from the Json and so on is maybe not this is where I come in with my PR so I personally think that the purpose of the whole requests mechanism uh in EIP 7685 it's just that it should be generic like these requests originate within the chain and their destination is the consensus layer so ideally the execution layer would not really know anything about these requests I mean it has to extract them from the chain but it

doesn't even really have to know what's contain like the format of these requests unfortunately right now it does have to know the format because we have to convert the format Within El like three times so actually two like yeah so we have three different formats for these requests implemented within the El and they are like specific to each request uh type so it means we have to have a lot of code within the E to handle these different types and I feel like it's unnecessary and um so an important observation we made is that for the newer eips um for consolidation requests and withdrawal requests the data which is returned by the contract is basically

valid SSC and it's not 100% valid SSC I'm working on a patch right now to the contract to actually make it that but um basically what they return could just be pass directly probably be more convenient for the cl to parse it like more convenient than parsing the Jason anyways and um the for the deposit contract obviously doesn't return valid because we kind of gather the data from the logs and it's AI encoded but the transformation to like going from the log data to valid s is a very simple one and it doesn't really require any kind of SZ handling it just means we have to shift the bites to different position

basically and it's something that we can Define and we have to do that anyways because we have to parse the API encoded data already so I don't think we're it's not going to add code right now so in total this change is if we go through with this is going to remove a significant amount of code from the Els and I also believe it will remove some complexity in the CLS

Alex Stokes: cool thanks yeah I've taken a look at these and generally agree with everything you're saying um this does simplify I think both things on the E and cl which is really nice uh yeah thoughts

Felix Lange: I have to note that it's all a bit contingent on a bunch of changes to eips which have not been made yet so there's this is more of

me just proposing this General mechanism but it has to be said that next week on acde I will also be presenting the changes to all of the eips so that um yeah I mean it requires cooperation from the uh El developer uh group as well

Alex Stokes: right and tier point there are changes but they're not anything too massive so uh SC like it simplifies things quite a bit with a pretty low LIF so yeah I mean we will need El b as well so I guess for now any cl's have you had a chance to take a look or have any thoughts about this

approach any feedback

I like it but I'm just a little unclear on what the C will be receiving like I think it's a bit underspecified at the moment

Felix Lange: yeah so there's no example in the spec so the the the Pro request um has a long description but it also has um the content of the pr so um and in the content you can kind of see that literally um basically um at the moment in the current spec for Prague for the engine API Prague we return three separate lists which uh called deposit requests withdrawal request and consolidation requests and

these are arrays of Json objects so there's basically one array for every request type and our change here is to return a single array called requests and it will be an Json array of hex strings and these hex strings will then contain the um encoded requests and the encoded requests have a single request type bite in the beginning so it's like zero one or two and as the first bite and then the remaining bites will just be the s the structure of the request and this structure is defined in the CL specification so it's identical to what is already defined for these request types within the consensus layer

specs it's yeah I I agree we could specify more

well I don't know that the bite the the distinguishing bite is specified right that that's new right or am I wrong

Felix Lange: I mean yeah it's kind of I mean it is if you look into into the pr you kind of see that yeah I mean it has a it has this array of yeah I mean I guess I should

no

I mean I'm just clarifying

Alex Stokes: um so this comes from the different eips and again I forget the number but like Clan also had a PR that basically gives sort of a general structure for this request type

and request data so Felix is saying is the request data is essentially ssz you would just cut off the first fight deserialize the remainder and you're good to go

Felix Lange: yeah I mean I don't want to say the word but I mean this is like a union basically I mean so the main thing is that it's not a we were debating if it makes but I mean since the union was being removed we didn't want to call it the union but I mean honestly we got to put it put this information somewhere for for the for the SE to distinguish the request and um yeah so basically that's why it's uh it has this bite we we it I want to note

that we we have this bite already in the E level encoding so at the moment in the current specs for the E we do use this type of encoding with the with the with the initial bite for the request type and it's in all the eips it's just that with this change the CL will have to handle that as well anyway uh iy to answer a question from Portos right now

Potuz: yeah it's just a a comment it's the same comment that I that that I told Matt uh so it seems that someone will have to do this this work which is uh we have this list of uh requests and each request we need to put it in a bucket

and what you're suggesting now is to just send this list with this extra data that we don't care about what we only care about to to decide in which bucket we're going to put it and then the CL needs to arrange these things in different buckets and then get the corresponding n object which is the list of requests that we care about uh on the other hand the same work could be done by the L you could in principle send a list of lists so a list of list of hex strings which is ordered and then you put all the request type one first then all the request type two then and it's exactly the same work that you would be doing or our or we would be doing uh

without having this uh this bite that it's non-existent today in the SE so again I don't I don't really oppose I don't have any any strong opinion is to who should be doing this work it's just that it's clear that this work has to be done by either the CL if you give us if you give it us one list we will make this nested list of list list or if you give us a nested list of lists then we can already consume it uh and the same amount work on one or the other on so I don't really see why the push to have this the separation of the first bikes on the CL side when you for us easier it is

Felix Lange: it is way easier for us

though because then it it just means that we don't have to care uh about basically in the E implementation it means we when we are processing block we will just go through the system calls append it all to a list and then just basically send it off to the to the to thec we don't have to think and I think this is quite important for me because this mechanism is like defined for the for the benefit of the of the consensus layer like the the ex execution layer does not care about these requests at all and it should not really have to think about it too hard so from my point of view it makes more sense for us like this it kind of SES steps a bunch of these issues as well that were mentioned

in the earlier PR this is kind of where we're I don't want to get like too deep into this discussion because there were a bunch of things like yeah can't you do it like this or whatever this is not I mean we have come up with this approach because we think it will be something that is the easiest to implement for everyone like mostly for the Els and uh splitting it in in into these separate lists for the purpose of put put it in the beacon block uh I think it's okay to have to se do it in my view

I I

Potuz: I also think it's not that much of a work for us I think the the biggest complain concern that uh that Dustin

from from from Nimbus had was that eventually if we move to having as a z then this list that you're proposing will have to be encoded in a way and it would be very different if you had a list of lists if you had a list of lists is something that we can handle it today with our SS libraries but if you only have one list we would have to come up with this new type which either is an SZ Union or whatever whatever new type is

Felix Lange: I mean it's just going to be a list of of like bite vectors or something I think honestly that's basically what it's going to be I mean it is kind of a list of bite vectors right now in

adjacent yeah so I don't think is going to be inherently a problem to oh so

Potuz: you're suggesting that we we we take it as a list of of of of bite slices yeah that's that's that actually would work if if the SZ object that you would be sending is not going to be the szz object that we expect uh that that should be fine for us Yeah

Felix Lange: so basically the whole proposal is just sending like an array of like bytes objects we encode them as hex because it's ajon RPC but then basically yeah so I mean if we ever convert this stuff into as said then I don't know this will handled in some way I mean we handled this it's the same for transactions right now I mean for transactions we send uh these like opaque hex objects and they have the

first bite containing the transaction type and then the remainder is this data which is totally opaque and specific to the type and I mean it's it you could say it's a kind of Union but honestly it's just because yeah that's what you got to know which object it is and um I don't know yeah this like list of list thing it has some disadvantages as well it's it's yeah I mean let's see okay how about this we won't really make the final decision today anyways next week is acde I will be presenting this change also there from the perspective of the E I guess you will also be there um assuming and then you can listen in

again and think again and I mean yeah that's it doesn't have to be decided today I really just wanted to bring it up

it's it's

Dustin Brody: it's interesting for sure I would note one difference from the transaction case is the sales mostly don't care about the details of transactions um I mean I will I can't speak for you know every obviously um case here but but generally speaking transactions are a blackbox so whatever you know Union like structure they might have internally is is typically not that relevant for this purpose um I mean beyond what whatever the El's want to do with that and but

the CL but but it has no bearing the engine API aspect has no bearing on this one way or the other but in any case that said this is definitely an interesting um proposal

Alex Stokes: yeah and to Felix's point the requests are kind of black box for the E so it's just kind of the inverse here so yeah yeah thanks for Felix um everyone please take a look and it sounds like we will touch on it next acde cool so the next thing we had on the agenda was PR 3818 so the wrong spot in the chat there

we go there's a link in the chat and so this PR is kind of big but it's important it's a followup to 6110 um I think the core issue really as far as I see is that there's no sort of rate limiting uh in the deposit contract just because of how it's written and so what that means is that there could be unnecessary load on the CL or like unacceptable load on the CL if someone went and made a bunch of deposits say in one block uh with the request structure under 6110 and this PR essentially adds some queing uh to mitigate any issues with too much

load and yeah M I think you're here would you like to say more

Mikhail Kalinin: um yeah just um yeah quick overview um this pair was kind of while there um opened we were working on tests so now it's kind of pretty to get merged from the testing perspective as a good test coverage um yeah the overview of changes is as Alex said trade limits the deposit processing PA ook to sets to 16 actually the purpose of that is to rate limit the signature verification operations um also uh for the transition from Eon

bridge for the Ethan Bridge deprecation um this this Q is also important because um it allows to whenevent the front R attack um where the Ro credentials uh can be front end uh by the new deposit requests so it actually sets the stre to of uh deposits being processed so the first um yes the new deposit request will will be um we'll wait for until the eth one Bridge deposits are fully processed um that establish this strict order and prevents the pr attack and yeah there

are some other things like finalizing deposit request position before applying deposit um we have been discussing the that this is not super important um but just nice to have since we introduced the que it would be nice to have this functionality as well um and one thing I would like to pay attention to is uh this switch to compounding validator call um which is a introduced by max effective balance increase and uh yeah there is the the new feature where uh one can top up its validator and switch to compounding

credentials uh this uh operation requires signature verification so the signature should be valid in order to do the switch and this PR actually moves this switch to campal to process deposit request which actually means that every deposit request um um that has this operation is not going to be is going to be like on top of the limit of signature verification that we have for processing so it's kind of like not rate limited and know if it's uh if we think about it probably it's not that bad the purpose why it's done this way is just because somebody will have to

for the entire deposit Q if it's large enough to switch um to compon credentials which is kind of like not that good you but probably um it's not yeah if we highly want to also make the signature verification um put it under the limit that we have for processing um for this operation then we can yeah move it to the que as well I mean the switch compounding operation so that's probably one thing um that is questionable with respect to the design proposed by

the spr

Alex Stokes: thanks uh so this came out of uh a

lot of discussion at interop uh although we were already getting some plus ones in the chat uh anyone have any questions around this PR okay I mean it does seem like we need the rate limiting for the deposits uh for the request so yeah I looked at the sum and I think this is pretty much the cleanest solution um yeah I guess it'd be nice uh CL teams if you could approve the pr just to uh give it a thumbs up but I

guess we can take these in the chat as a signal and yeah otherwise uh we'll look to merge this pretty soon I guess one question uh I know we had discussed having like more sophisticated Q management sort of Downstream to this PR are we still thinking that that's useful desirable

Mikhail Kalinin: yeah the M the main uh reason for that was as the performance so probably it's still important

Alex Stokes: yeah I wonder if this is a

thing where we can just actually get numbers on the next evet and see how it shapes up that was definitely everyone's intuition that there would be a b neck there um but that'll be inside if we do want to do that it'd be nice to do it sooner rather than later just so we can get the corector stuff stable Okay cool so yeah take a look at that and then we'll move on to the next agenda item so let's see that one okay I did want to get a temperature check so again

there were there's another stream of PRS um to further work with the attestation refinement that we have let me just grab links here so there was this first one 3787 and this next one and they essentially just rework the attestation types uh in various places uh with the claim being that it's just simpler and easier for clients to manage things whether that's attestations from Network out station is on chain they've kind of been sitting for a little while uh has anyone had a chance here to look at them and yeah again I'm kind of I'd like to get to a place where again these like corector eips are

pretty final sooner rather than later so I'd like to push these along if uh we're serious about these

PRS

I mean I can just say two words about them um the first one no there there were also discussed at at interrupted where they're coming from and basically um the EIP that they reference they kind of introduced a refactoring of the attestation type and then um piggybacked net refactoring onto

the network types that uh could actually have remained the same um so what one of them does is retain the old format for uh Aggregates on the network and then this gets translated into a new type for the onchain thing for the onchain attestation and we have to do this work anyway so like the format there doesn't really matter uh but for the network it's easy it's like more secure to use the previous type because it's more tightly defined to match what what's going on on the network uh with the committee

size um then the second PR is actually even more interesting from a security perspective because it allows validating the signature of the attestation before Computing a shuffling uh and this is actually one of the bigger selling points of this PR um what happens right now is that you can just connect a client and maintain good reputation with your Pairs and then when when you want to introduce some instability in your in your neighbors you just send them an attestation for which they don't have a shl uh and there is no signature check on single uh vote attestations that is

possible without performing uh um without Computing the shuffling and as any client Dev knows like Computing shuffling is very very expensive so clients have a few options and they're all bad um one is dropping attestation which is kind of dumb because this typically happens uh when the network is uh not very stable that's the best time to exploit this thing uh and dropping at the stations that point just like delays getting back to uh nice St finality they can kind of process them and this eats up resources uh for computing the shuffling and then for

holding lots of shufflings in memory which canally do um they can delay processing it which which is also bad because it introduces these cascading delays in in the propagation so um the pr kind of Narrows the doesn't eliminate this possibility that you'll have the computer shuffling but it narrows it down so that only validators uh can cause others to have to propose to compute shufflings uh and this is definitely an improvement versus you know just any Rando on the network being able to do this um I like them and

they're certainly simplifying the Nimbus code base when we implemented them so so or when I implemented them um I'm kind of hoping that this story will be the same for the other

seals

Alex Stokes: cool thanks has any other SE team had a chance to look at these

yeah pus

Potuz: uh yeah just repeating what is in the chat we've looked into the this it seems to me that it's trivial to implement but last time that we dealt with the attestations and we said the

same thing well we know we are where we are uh this one does seem to be much simpler because it's only a little change on the subscriber and then the P2P side uh I like the change uh I'm I'm in favor of that

okay cool and we have another plus one from enrio so cool um let's see

Alex Stokes: I mean timing is hard but like if we could get to a place where we feel like these are ready to merge by the next y call that'd be really nice uh otherwise yeah client teams please take a look and chime in on the PRS and yeah I'll do

what I can to move these along and yeah we'll get that get that sorted okay okay so that was it for Petra uh before we move to pios are there any other pectra things we want to touch on okay peros then uh I could start by asking for any implementation updates uh I think we are looking at let's see pust ofet 2 uh but I don't think it's live yet uh anything anyone would like to

share on that front

Parithosh Jayanthi: yeah just a brief local testing upgrade uh update there's a pinned curtosis config if someone wants to try it out there are three super nodes as well as three like normal nodes in the config um that seems to be going well uh I think load star said that they would uh try it out locally and get back it works and Nimbus will get back to us on Monday with potentially something that works

Alex Stokes: okay awesome so things are moving along there um great

Parithosh Jayanthi: so I guess one quick question I had on the topic is there

some way to actually stress this thing cuz I mean right now it's just it it's running but it's not doing much else I guess besides blobs

right uh and it's still on right yeah

Parithosh Jayanthi: uh the rebase on top of Petra is for the next for for the next

um next right

Alex Stokes: right yeah I mean one option would be to like run our denb stress testing on the periodos stet just to see what happens otherwise I mean we could try bumping up the blob count

y sounds good yeah

Alex Stokes: which actually does call

mind go ahead

Parithosh Jayanthi: yeah uh I think we kind of having the same thought uh how do we increase the block count

Alex Stokes: yeah well and I was going to ask about 7742 um the PRS to the very specs are all still open um I wasn't sure it might have been discussed on the breakout this week um but I guess if clients have that it does help simplify raising the blob limits okay uh is coordination for this

mainly in the pios testing channel on the e&d Discord

par

Parithosh Jayanthi: yeah exactly

Alex Stokes: okay so yeah we can just take it there and we'll push this long asnc cool so thanks everyone for that next up so this question came up from the breakout and essentially I think even already we've seen some problems around Computing the puros proofs um especially if you have like a sort of under resource ource node or a low resource node I think you can take something like up to a second um maybe even a little bit more to compute all the proofs that we need um and

especially as we move to like a higher blob count so like for example um I think there's even discussion of say 1632 as like a Target and Max limit for pios that's great because then we have more data throughput but if it's going to take so much longer to make these proofs on the CL then we have an issue because let's say you build up until till pretty much your proposal deadline and then it takes you another you know second plus of blocking work to actually get the block out so this came up and yeah let's see I have a link here to the puros notes with a little more context but there was a question around how to handle this um

there are a few different options I don't have the link but uh ASN actually had like a nice summary somewhere on the Discord and some of this will be dependent on what the El's want to do uh let's see if I can remember the options here I mean the first one is just keep it as is um you could imagine maybe the validator then knows in the SE to like start block building or like the when it goes to fetch the block that's been built it does that a little bit earlier to offer time uh another idea would be to move this proof generation to the E just sort of like to pipeline it and then we gain some you know time there this is kind of a violation well

it's definitely a violation of separation of concerns between the Al and cl which is not nice uh even if it is say like a pretty straightforward option so that then te this up to a third proposal which is essentially to have like richer communication between CL and eel so that um you know one way to think about this is like the E would essentially post to the CL through the engine API for every blob the CL can then start working on these proofs in parallel to the buildin process um and then we go about it that way so that was this sort of high Lev overview of the problem and some of the solutions that have been proposed does anyone here have any context i' like to add or do any of these feel like

promising pass forward for p dos right now Sean

um yes

Sean Anderson: I talked to Jimmy about this yesterday he said this um uh change that Michael's proposed to allow the seal to get blobs from the El's men poool could help to some degree um this is because you can you don't have to wait on blobs over gossip necessarily if you already have them in your men pool so it's kind of an optimization there another thing we talked about was um and I don't know the exact details of this but like another more I guess radical option is to have like a

decentralized sort of um proof generation so like have nodes across the network generate roofs with some sort of like responsibility um division but yeah again I don't I don't know too much of the details there but uh that's just another option we talked about um I think that's it

Alex Stokes: cool yeah I mean the thing is I think you still need to make the proofs in any case because like one you won't know for some you know remote peer what they have their mol um so you'd always need to do this and then the issue is say you're

the home Saker with like only a little bit of hard R thr this problem um then you're kind of host so yeah I think we need to do something um the question then is what

Dankrad Feist: I mean I think like we should definitely push harder on the distributed building I think like that's the more sustainable solution anyway and like if you have such low resources it's also likely that your bandwidth is low so like you'll struggle sending out those proofs anyway so um like in almost all cases your best

stry will be to send out your block first and um bet on other people adding those proofs which we can definitely do like if they in a member that like will accelerate things um and I think like otherwise I would yeah I I really don't want proof generation to leak into the execution layer because like we're currently trying to decouple data availability more from the execution layer like that's why for example we also want to um have the block limit only in the CL rather than having it set in both the CL and the E and I think like in that context it only makes sense if we make

sure that like all the proof generation logic is also in the CL because further upgrades to data availability will require us changing that again like we will want more samples want a different type of samples for example 2D samples and so on and we want to make those upgrades without having to change the Els well so yeah I mean I do think like we should find a reasonable way of like getting the blobs into the CL so that it can generate the proofs but I think like the act more promising Avenue um for home stakers will be uh getting other nodes to generate the proof for them and I think like yeah there many things that

can be done about that

Alex Stokes: right yeah that makes sense and I think this is a good point about not having things leak into the E because as you say down the road it'll only get more complicated so cool uh George put this link uh in the Discord so yeah take a look there and I guess for now just consider this uh open question we should all be thinking about and yeah otherwise I think we'll just keep keep uh keep thinking about this okay anything else for

pios

Dustin Brody: so I do have a question about this I guess I'm I'm reading the notes and it it I mean it uh from link tier for example it break out breakout room notes it say it can take up to 1 second um kind of under what circumstances or or what kind of Hardware kind of concretely um is as we're talking about running a Raspberry Pi or or a I mean an average laptop or yeah

on

Dankrad Feist: x86 CPUs it takes like 2 to 250 milliseconds to generate one proof per like on One Core so for example if you

had 32 proofs and four cores um then it would take uh two seconds um each core would generate eight so yeah it depends on like both the numbers of blobs we include and how many cores of what type you have and Raspberry Pi is going to be more of a problem because that um there even like it takes one second to generate all the proofs on One Core um like arm is just a bit slower at at the moment and I think uh but I I don't feel like Raspberry Pi is currently really like a common choice for stakers like I think

like that was like our Target five years ago and like I think uh we've probably moved on from that and we have like slightly more powerful topical devices now like it's feels even hard to get less than four course nowadays

Dustin Brody: sure no I I mean yeah that I I don't I don't mean to put particularly seriously the idea of like it must run on Raspberry Pi but just as I again it getting a sense of um what the sort of quantitatively what the numbers here were whether we're talking about a like a a relatively um beefy home servers or or whether and it had had to be yeah

yeah

on

Dankrad Feist: on a bey Home Server Like with like 16 cor say like you could easily get it done in a very short time like

Dustin Brody: okay so so this is so this this is more of a case or as uh um as as Justin posted the um like the rock five because that is that's that's actually a better Benchmark here because the from a ners perspective it's not clear that the Raspberry Pi is a super viable today as a reliable node um although people might try people to try um but the rock five is that's definitely a yeah I agree

Dankrad Feist: I agree and I think that is what we should I I I I feel like that is what we should be looking at at the lower end of the

nodes at the moment I think Raspberry Pi is starting to look unrealistic

no I Mak sense

Nishant Das: so uh I just want to add that you know uh outside of benchmarks in main you the node will be doing a lot of other things rather than just Computing cell proofs so what whatever Benchmark you do get you know the actual number if you're running this on Main would be higher

on yeah I

Ansgar Dietrichs: just wanted to say that

um what I said in chat just now that like one not super obvious thing is that the fail modes are quite different depending on how we approach this so if we basically do the D thing and just have the CL compute the proofs after the block is requested from the e then that adds delay to the critical path and that means that um basically if there's any kind of issue or it takes too long then then that means the block just won't won't make it in time to and it will basically be unle which is quite unfortunate and pretty bad fail case whereas if you were to just do it in parallel with block production so if the El had some way to initiate the kind of proof generation while it's assembling a block it basically ignores blob transactions

until the the proofs are finished for them then basically the failing mod is much more graceful because then it would just mean that as a weak note then maybe you just don't have all the proofs in time and you you have to ignore some of the The Blob transactions and so you can't you may be missing out on some super like long tail of the of the fees but otherwise your block is completely unaffected and the timing is completely unaffected so I personally would very much recommend we don't do this D thing of of generating the proofs on the critical path

Alex Stokes: yeah makes sense a question I have with this sort of I mean I think first we just have to spec out what we mean with like decentralized proof gen a little bit

more um one thing is let's say you have you know your rock five sitting there you push out your block with uh you know commitments to the blobs you rely on someone else to make the proofs for you is there any dos concern there um I feel like that would be like the first problem we'd run into where if I just get a block I don't exactly know the the rest of the context of the block um maybe it's fine but I'm not sure if anyone's thought about this

Nishant Das: well there's no dos concern it's just uh repeated work across all super nodes in the network so if you have the commitments From the Block you can U

look at your local El m and if you have the blobs you know you just create the self proofs from that the issue of doing it this way is that yeah it's in the critical path

so

Alex Stokes: but what if you don't have the blobs

so yeah

Nishant Das: then you can't do anything you're stuck

Dankrad Feist: yeah you do assume that some super node has all of those otherwise it doesn't work because currently you can't create any proofs if you don't have all

all

Alex Stokes: right okay

Dankrad Feist: I mean one of the ideas here would be to give us better channels to notify the supern nodes that they would do some

work like I don't think like many people running these would find it a problem because we're talking about donating a few seconds of CPU time and like there's no extra load from Distributing these because you would be doing that as part of P2P anyway so um like if we have like a nice mechanism so like one of the ideas would be what if we could um uh broadcast um like block headers before we broadcast the block like that could be much faster and they would get a heads up and then like they could just do this um and possibly they would like even come fast enough that it would still be faster than actually sending everything

um and like I guess a more advanced version would be if hom stakers like announced uh in the slot before that they won't be able to build um the S the the proofs and basically asking the super notes hey like could you precompute it for the ones that you see in the M Pool now like it wouldn't be impossible to do this um but I mean I guess like it would require more messaging because now you need a sign message from that uh from the validator saying Hey I want this proof built

Alex Stokes: right and we do advertise like you could just walk the DHD to find super

nodes right because that just means you have like all of your bits set for your custody channels that would be the way to identify them

Dankrad Feist: right I mean I was assuming we just do it through like a gossip sub topic um but yeah I mean I guess you could because like I mean this is very low band with right it would only be like like one tiny message per slot um but yeah I guess you could also do it by directly contacting them

Alex Stokes: that's what I was thinking but yeah I guess you could possibly do both um cool I mean another

Dankrad Feist: way of doing this would be asking the relays to do that it's a bit of a weird thing because

you're not actually using relays you self Builder uh but like it could still be a service that they provide where they simply have an endpoint like uh send me your block header and I will create your proofs and send them out on peer to-peer right like it would still be trivial for them to do that and I think like if you added that to the software they would do it but um it's slightly weird that I

Alex Stokes: yeah do you think there'd be any incentivization there like with the proposed pay the relay or you know assume there's no

Dankrad Feist: I mean I feel like it I feel like it's one of those things

where like the value would be so tiny that it's really like not even worth paying for it like the the the relay does most of the work by simply like the implementation does most of the work actually doing it is so trivial it's like how do you pay for that it's like worth a mill Cent or something

Alex Stokes: right okay

Dustin Brody: does this require that kind of

now go ahead Dustin

Dustin Brody: does this require uh that kind of infrastructure in um Dev Nets uh test Nets and because we don't the V

infrastructure has historically taken sometimes a little while to come online um just I mean once the network is running and it and and Main net Forks it's it's unpr problematic but um even the first test net sometimes doesn't have it have everything ready there

so

Dankrad Feist: right right I guess that is ADV Advantage if we solve it internally um like as part of the node software then we don't have this external dependency is like are people Keen to build this distributed thing and find some way of notifying the super noes then we could maybe create a group group

and talk about a spec for this and do it it doesn't feel to me like it's super complicated we just need to like agree on something and do it

Nishant Das: I mean an easiest solution would be just to have the E communicate um uh which exact blob transaction actions it has uh in its current payload that it's building and the CL could just build them in parallel we don't need to have a separate channel for all the stuff

right

Dankrad Feist: you're saying like you're I guess the risk is that um the latest

um like e block building takes much less time than the proof computation or like Pro less time in most cases at least um so like you basically doing it like this will kind of throw a little bit away of the time Advantage you get by building it as soon as you receive the block

Nishant Das: yeah so like um at least right now we send you know to the E uh one slot before to start building the block and as part of client software we could just like regularly pull them and no them which blob transactions you know are in the payload

and yeah yeah yeah

Dankrad Feist: the

problem is that this theoretically could change completely right you could like basically add nine seconds into the slot it's blobs one two3 and then suddenly it changes completely um because of different fee Market structure or something and then it's uh 456 and um all the work you've done is usess and you now like the El sends you a block for which you haven't prepared any proofs

Nishant Das: yeah that'd be the worst case although yeah I think in the average case it shouldn't change too much

Dankrad Feist: I agree so sure like I mean if you're like

if you're happy with it being a little bit dosable which this is then I guess that's fine I agree that it works in the average case I don't think there is a lot of like competition like this on Bob markets where people OD bit each other

Nishant Das: yeah and you know even if it becomes the the worst case um you could just fall back on this distributed blob building and have all these supernes do it if it becomes that much of an issue

right

Dankrad Feist: yeah I mean I guess like if we say

like we focus on distributed blob building then we can probably say okay like we get away with investing Less in like optimizing the local proof computation because it's not really on the critical path anymore like I think most of the time with good distributed block building you're better off sending out your execution block first because that's the only thing that really has to come from your note and everything else can come from somewhere else so you're using your bandwidth more uh efficiently if you do it that way

Nishant Das: but that would always be added latency with this because you need the block a blockheaded to you know uh reach

the super node and the super node needs time to reconstruct

well

Dankrad Feist: it doesn't necessarily add latency because like in if you view it as a whole system right when you're sending out your block and samples at the same time you might be banned with constraint on that so might actually take longer for other nodes to receive those whereas if you start Say by sending out your block header first and then your execution block then like those get sent as soon as possible and the um the your bandwidth is not clocked up with the samples in addition so it's not necessarily true that like sending

everything in parallel is the optimal strategy if you have others who can do that work for you that might be a better strategy like even if you can even if you have all the proofs it's can be a better strategy not to send them if other nodes can send them

Nishant Das: yeah if you're bad constraint that that would be a strategy that makes sense

Dankrad Feist: I mean I would assume that most home stakers are B constraint because that's the hardest thing to get right like I mean getting yeah a high upload band with internet connection is in most place is not cheap

easy

Alex Stokes: right I do want to surface onar comment here that you know there are several options here um it sounds like there's support for what we're calling option three in the post that uh George linked so this is essentially having the CL poll or having the L poost uh which blobs are being considered locally so it just has time to compute these proofs uh locally that sounds like a good way to move forward in which case yeah we should work on a spec just to start to get a sense of what that actually looks like in parallel if we want to think about these more distributed proof generation tactics that also sounds super

promising um yeah so if DKR if you want to make a group uh or we can use one of the Discord channels uh but yeah I think we should move forward in that way

Dankrad Feist: yeah sounds good cool okay

Alex Stokes: let's move on to the next thing on agenda and I think it was this one right so there's a PR to remove s unions from spec uh we were kind of joking earlier in the call about unions being a dirty word and this PR is addressing that uh so it's 3906 and the consensus specs

repo and I believe this PR just actually deletes the text itself the rationale here is that so yeah today we do have unions in the spec um they're I would say a pretty experimental feature I don't don't even think the production implementations see across the board have a unit implement they're not currently used in the cons specs and so you know there's no reason to implement them they yeah and because of this it's like this kind of weird thing where it's like okay maybe we could use a union for this say like the request types and then it just kind of leads to a bunch of um conversations that can sometimes be bike

shedding so you know to address all this uh this PR basically just proposes to remove them entirely I think this makes sense enough um I would maybe suggest leaving a note somewhere just like hey by the way this was here in this commit um and it was removed there you could imagine making like a features like we do for the specs themselves like the be chain specs you could have like a a features folder for ssz there are a couple options here um but yeah I just wanted to have some time to discuss uh first off if we want to go ahead and do this and then the best way

Dustin Brody: so I guess as the um author of this

particular PR I'll just say that part of I guess my perspective I regard them essentially as a as a fiction um is maybe the most blunt way of putting it I that and this is my when as you say come it creates these bike shedding concerns is people treat it I regarded as feel as inventing a new ssse feature so when somebody proposes using unions SSC unions for something it's like it's as if they to me as if they invented a new a new thing and they're also proposing that at the same time as as whatever other feature they're proposing and that's why at least from my perspective the bike shedding me internally might happen um I can't obviously speak for

anyone else here um I would certainly be happy to put a link um in that uh PR you to have it I mean the the pure deletion thing is kind of the platonic form of this PR I think but I'd be happy to um have it internally linked somehow to uh here's the maybe the last either the commit which removed it or I mean because it's kind of intertwined in the files but somehow making it easy to uh so you didn't have to manually sift through and find and get history where it is we can use G history that's what G is for but but to make it easy to find and easy to um if people want to see it for sure

Alex Stokes: yeah that was my only point is

just you know in previous itations of the specs we have used them say for like early charting designs or things like this so it would be nice just to like be able to easily restore them in the event we need them in the future I don't know if any portal people are here but they did make a comment that they are using them which is uh maybe a bit of a complication but yeah we might need to follow up with them just to see what makes sense with them but otherwise does anyone oppose taking unions out or like managing them some way okay uh I'll ask the portal folks what

they think um but yeah then we'll figure something out if they want to keep it somehow I would propose going with like this feature route I was talking about um but otherwise yeah it does seem like they kind of unions themselves in the spec complicate things uh like Dustin was saying more than they really should be so it would make sense to to address it somehow

Dustin Brody: okay and and as as far as I mean propose a couple of op I can the two most there's a feature um so so factoring it out to the one of these feature branches is one one

option another is to use git history uh another like and link to like a whole file or there a rem link basically to somehow self- referentially to a removal PR that can I guess be added later it's s two stage thing there um various approaches is this I guess my my only slight concern I think i' would be broadly okay with the features thing especially since they're uh I mean so with the portal thing uh it's that portal is strictly not ethereum and I I would want to limit that the I mean this is actually a point a little bit beyond um just the this particular obviously I care about this Pi or PR now

but um that the fact that somebody may have taken um an encoding say that that um ethereum has a consensus spec encoding of something and that if if the consensus specs don't use it or on the El side would say something very similar but somebody else decides oh this random feature of rlp is great and it turns out that ethereum didn't care um I I'm not sure I would regard that as ethereum responsibility as such I I don't know kind of maybe organizationally or or on a spec level how how that was best managed

Felix Lange: so I got to say that like portal

is very much a part of ethereum in it may not be a part of the critical path right now but it's definitely a pro a protocol which is being developed uh for the benefit of the etherum protocol and it's very much uh I know I mean it's funded byf a whole lot so I wouldn't really put it like as a way external project with no connection and I do think that um on that second point just defining and encoding is something that is kind of independent of what the encoding is

used for and S is a very general purpose encoding it is very useful it has properties that very useful to ethereum but it is a generic encoding and so changing encoding is okay and uh removing features is also okay but I mean we do have to think a bit about like how this affects things that are using this encoding or if I mean if we all consider units to be a mistake and yeah I mean there got to be some some other way to do this but I don't think it's it's a good thing to say that um just because ethereum is not using a certain feature of this encoding it's like it should be deleted from the

ethereum version of the encoding I think there's no such thing as an etherum specific version of SC it's just an encoding that we invented

Alex Stokes: yeah and I think a nice way to square these is to just move it to some sort of feature spec um and then it's there okay I will follow up with the Proto people and just see what their take is on this and we will figure out how to move forward okay I think that was everything on the agenda let me just double check

yeah looks like we got everything for today uh any closing comments otherwise we can wrap up a little bit early okay thanks everyone we'll go ahead and close out the call and I'll see you on the next one

byebye

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