All Core Devs - Consensus #140

Transcript

for [Music] J h

[Applause]

Alex Stokes: okay and we should be live hey everybody this is consensus Slayer call 140 I put the agenda in the chat there and yeah there's quite a bit on the agenda today okay so let's go ahead and dive in uh quickly just to kick things off uh there was a Specs release version 150 this is Alpha 5 I think it's

exclusively things for pios um but yeah just a heads up there and I believe this is the target for puros devet 2 so might be relevant later in the call but but uh just be aware and take a look if it's relevant to you cool so then let's jump into Electra and if we could start with updates on devet 2 that would be super nice looks like there might have been a bad block recently

Parithosh Jayanthi: yeah I can give an update on that so if we go to if you guys are interested in more details please have a

look at the interop channel on uh e R&D Discord there's a few bad blocks we've noticed on the network they seem to have been produced by gu but are also not importable by gets so we need to look into why um I have a timeline there as to what I'm seeing at least please validate that and there's two threads right now uh one for debugging the get bad block and two uh Aragon has forked off but each Aragon node seems to be on its own Fork so there's also something going on there that needs debugging um but yeah we don't really have more than just a few questions few open questions right now um and there's a link to the

trace of both the specific bad block that has been posted earlier as well as in general which bad blocks we've seen on the network over the last like day or so

Alex Stokes: okay awesome thanks Perry um yeah so please take a look uh we can work on debugging that

and otherwise

Parithosh Jayanthi: I think that's it for me um yeah mainly it's yeah Marius looked in and he said it was likely 7702 even though we did not actively test that but yeah

Alex Stokes: okay thanks yeah sorry I was actually muted um but yeah just saying thanks and yeah we'll take a look at that otherwise it seems like DEET 2 is in a pretty good

place uh yeah any other updates from anyone else on devet 2

Parithosh Jayanthi: oh yeah there's uh one more thing we noticed that's Jason RPC standardization issue uh we tried making the eth call that we spoke about at the testing call and then after some debugging kind of found that the uh the nether Man team uses a different default from than the get team so when you send like a raw RPC call if you don't specify the from then you don't really get output in nether mind it seems like an under specification of the Json RPC right now um and there's a similar bug in bezu

where if you call debug Trace call uh it complains that the gas price is less than the base fee but if you send a regular eth call it works fine so yeah um I guess the teams have already been notified I think they're looking into it but yeah if there's some update on that then please bring it up

wait

Alex Stokes: okay um good should we touch on devnet 3 I don't know if there's anything we really need to do um if 7702 is the issue with

this devnet 2 bad block then yeah maybe that will just resolve naturally in devet 3 any 7702 updates worth discussing right now

Parithosh Jayanthi: uh someone from the r team brought up if this um EIP 2935 chain should go into the next DEET or if there's still like an open discussion so I wanted to bring it up here it's been merged as an update I'm I think I'm more in favor of having it ready for devet 3 but yeah up for discussion I guess I've posted it in

chat

Alex Stokes: thanks yeah anyone working on that uh car to chime in as far as I understood yeah there was something around the semantics to clarify so I agree it would make sense to put into down three I don't think it's a huge change or departure from what we had before so sounds good to me

Lightclient: I mean what does what needs to be put into

devet 3 uh PR Perry put

Lightclient: shouldn't change anything okay there's like no semantic change it's just saying like you have to

call the um system contract to do the update but I think everyone is doing that and you can still not call it if you want but like you have to make sure it's right

Alex Stokes: right okay so yeah let's just go Ahad and assume this goes in demet 3 but it should be transparent with the behavior we had cool um anything on devet 3 to talk about I think we had said last week that we' aim for two weeks so next week uh would be devet 3 launch but it sounds

like it's going pretty well not sure if there are any implementation updates or anything else to discuss there

Parithosh Jayanthi: yeah I think once client teams have branches please just ping them on the interrupt chat or DM either babus on me and then we'll update configs and start sharing them around and yeah Marios posted the spec release for DEET 3 as well so the El specs

Alex Stokes: okay great cool then next up we had let's see

this was a PR to update the max e EIP let me grab a link here I'll put it in the chat so essentially yeah I believe this was only an issue sort of like an education maxb where if there was a lot of eth staked say like more than 30 million uh there was an issue with Consolidated validators essentially like validators with a lot of stake um interacting with the calculation of the correlation penalty for slashing and essentially there's an overflow with the way that uh we have the spec today and this PR fixes that uh it looks like in a pretty nice way so

let's see I don't know if anyone like is Mel on the call I don't see him yeah oh hey would you like to say anything else about this

Mikhail Kalinin: yeah just a quick overview of of the problem and the fix as Alex mentioned um so this is the about the correlation panalty computation um the panel to that is apply in rough 18 days after the water gets slashed uh and actually the cause of the bug is in the inter division uh and the um the result uh the outcome the potential outcome of of the problem um uh is uh quite U becomes much more

severe with the max effective balance increase uh so to to highlight the problem we should consider two cases where uh where where the same balance say 248 e is distributed between uh in in the first case it is just one while uh which has the all this e on its effective balance and the other cases like 64 wers that has each of them has 32 e and uh uh under some condition uh each of those 32 e will get um zero penalty so the total penalty the total correlation penalty appli to to

this balance this entire balance will be zero for 32 e while but for 1 1248 while uh 2048 e while there will it will be not zero so this is where we get the discrepancy and actually um this uh PR proposes fix to this problem also the other problem is the Overflow um in the same computation um but yeah it's the detail of the Overflow and this discrepancy and the amount of correlation penalty wi can be found in the description uh so the fix basically um uh changes a bit the correlation penalty curve uh it makes it linearly

dependent on the effect balance on the effective balance on the number of effective balance increments so it's like 32 2048 and uh uh the side effect of the fix is that uh we'll get correl correlation penalty U for even when the um one wer gets slashed but this penalty is going to be negligible in this case um the detailed analysis is also in the post um and you can take a look at this as well uh so what else is here uh yeah the correlation penalty becomes bit higher uh on average but the curve is uh much more smoother than uh when I was uh

with the um before Electra um comutation so we can see it as well and the total s penalty will anyway uh go down and decrease with this in Electra because the initial penalties is significantly decreased so for all these details you can just read the post um yeah that's the that's what this PR is about I know Franchesco on the call and want to give more information

Francesco D'Amato: no that's that yeah that's enough for me

Mikhail Kalinin: cool so it it would be great uh for more eyes to take a look to to this PR

because it changed the penalty that uh we used to have for all the time and yeah but from from from our perspective the fix looks good and I I think we we can I think we just aiming to merge it some sometimes next week uh maybe if if there is the desire we can wait till the next call and make the last call the next time

Alex Stokes: cool thanks yeah nice catch um this is a very important computation for slashing penalties so please take a look uh I looked the other day and yeah it

seems equivalent to what we had say if we were working with like the real numbers the issue kind of comes in when we move to like integer arithmetic that we use in the spec um and then you start hitting different overflows and things and uh yeah so take a look uh we'll probably at least I'd probably wait for like a few other client teams to chime in on the PR but but after that should be ready to merge cool if that's it on that one we can go to the next agenda item so this one I think has had a bit of uh work put into it and essentially it's refactoring how the execution requests are uh put in

the data type on the beacon chain and the reason we want this is because the sort of natural thing to do is just mirror the E here where the execution request would be and the execution payload in the beacon chain type uh generally I think all the clients uh pretty aggressively prune these because there's no reason to have them duplicated both on CL and E and so if you do this then you don't have access to these execution request which you now need for the C State transition so there was another proposal by pus I think there's some back and forth and people have landed on this uh new PR here I just put in the chat and yeah it looks generally pretty good to me um yeah again call to take a look

I think there was still one thing we'll need to do is uh pass the request to the E say in the new payload call uh that was missing but otherwise it looks pretty good so uh I'm not sure if any other client teams or anyone else has had a chance to look at this or if there are any questions about it at the moment yeah

pus

Potuz: yeah so one of the reasons uh we um well I guess you can ask the author but one of the reasons that this approach uh

turns out to be much simpler to write in the python spec than having an extra envelope than having an extra layer but the problem is still that you need to have like tests for this and pass the pythons tests are we going to agree on like starting Implement that's going to take some time so are we going to agree on like uh starting implementing this thing on clients before having test on the python spec or it's fine by me I actually want this so yeah

Alex Stokes: I mean they can go in parallel um but yeah I guess the sooner other client teams can take a look the better at the

pr

Potuz: the pr looks good it's just that the

N tests

Alex Stokes: right so yeah I mean it might be simpler to just move ahead with this PR just so people have like a Target say if it gets into a Specs release um test can come along the way and yeah I guess it would be nice to have a few other client teams take a look at this PR go merging

Mikhail Kalinin: okay I just just wanted to add that this PR is nice because it does not actually does not introduce any changes to the execution p struct on the CL and also I think that uh I've been putting this comment into the pr uh thread but I

think that we uh could remove the payload bodies uh version two request from engine Epi because CLS will not afla those request from from their databases but yeah that's that's what I was going to to to to look for uh I mean like the answerers to this question whether this correct or not to ask scale that's about it like yeah does it make sense to to just not um have those um get payload get payload bodies uh method in the description definition

sorry

Alex Stokes: would you not still need those yeah would you not still need those say if uh you know someone ask their CL for a block and they need to go fetch the execution payload from the e say for like a historical block

Mikhail Kalinin: uh yes but we already have so those wi version one uh methods that can serve transactions and withdrawals um so request will not Beed from the database yeah we don't need to update those

Alex Stokes: gotcha okay uh I think you had a comment on the pr about that so I can follow up there and yeah I can also look at test

in the next week or two so then my ask for client teams is to take a look at the pr uh and we'll move ahead there but yeah generally this makes sense okay anything else on that

Mikhail Kalinin: by the way what does you mention tests what kind of tests do we need to merge this

V

Potuz: well the problem is that this change uh it's going to break

essentially every test that we already have so so fixing those test until those tests are fixed we're not going to have spect vectors to pass so we need to fix the existing tests have a release with those tests that are going to be applicable for DPR and then we can just run spec test in our CI ourselves so that's that's the that's just the the inconvenience of having this large change on the

BP

Mikhail Kalinin: got it so you mean that it's not about the ppack tests right

Potuz: right so whatever we have now currently on spec test is going to start failing once we merge this in our in our develop

branches

Mikhail Kalinin: yep I see thanks

Alex Stokes: okay so we'll move to the next agenda item this is uh related around the execution request and how they are written or represented in the engine API so like client had this PR uh like client do you want to give us any more additional context here

Lightclient: sure uh I think we talked about this a couple weeks ago but just bringing it back up for final call from

clld devs the idea is on the execution layer we don't uh make the distinction between requests in the block body uh and so what we do is we just have this sort of Union like thing where we serialize the request with the type prefix this is the same thing that we do with the transaction types I'm trying to expose that same type of that same data type to the engine API instead of what we're doing right now which is during the engine API call we have to actually go in and Mars out each individual request type from the list of requests so really it's just trying to have better parity

of the API versus like the data that exists there are a couple issues with how it is formatted I think like if we were to add more request types in future Forks it won't be so easy for us to parse it out it's still possible and if this is like a blocker for CLS like we can do it but I think that it's better for the API to match the data type that exists in the block yeah if anyone has thoughts on that like happy to hear it otherwise probably merge it later this week

Dustin Brody: yeah I I I think some of the issues there have not been addressed in that GitHub issue and I would personally say

I agree with at least at least one of them um so for example this ssse uh question and I think it's it is useful it is going to be useful um to be able to have a an ssse representation of this in the hopefully not too distant future I think there's been a um some consensus although there's been not on timing from the Els but there's been some consensus that ssse is probably a good direction to go with um representing data in ethereum in general El and and cl um there's been yeah and some enthusiasm whenever it's

been brought up toward towards moving towards that direction um again yes not everybody's ready with their ssse libraries and Etc but um and we have to time that for in other ways but this would actively make that more challenging and to just kind of toss in well maybe use an SSC Union is is um not sufficient because ssse unions I understand they're in the ssse spec they are not used I need to emphasize this they are not used um they effectively don't exist they don't exist in all libraries they they they should not be relied upon um and as such I there is no corresponding representation of this in SSD currently so that that's that's I

I'll I'll stop there for the moment but that's one one of the issues that the

Lightclient: I mean this is just not an ssz API though like we not only do we have one solution which is the ssz spec that says there are unions so if you want to go down the right path we have that and if people don't want to implement SS unions then we could just revert back to what exists today which is separating them out and setting them over as individual list just because we're changing how the jsonrpc is representing this today does not really affect how people want to represent it with ssz

Dustin Brody: well it it does to an

extent

um so it it you can

Lightclient: you can like when we when we do this in ssz like you're going to come up with your own SS spec for how things are represented so it's like up to the ssz designers at that point to decide how do they want to represent it if they want to represent it as a union like I think it's the best thing to do but if they that's not possible then we could do exactly how it's represented today

Dustin Brody: so so generally speaking the the way these SSC transitions have been mapped out not universally and and various other people here have been involved in some of them so um and is is that they are um structurally isomorphic maybe is how I I'll put it um that that

not universally but in general there's often a goal to have them be closely equivalent structurally so there's they are just the same um kind of Hier information hierarchy but with a different encoding rather than saying that they are um just a completely a complete reimagining of the API and if you look for example at the the beacon API which has offers SSC I know this not El related but this shows a model for how this has been worked out um the the ssse representations are as close as possible this is not a different API it's the same API over ssse um and this

I this does impinge therefore on how ssse would represent it um and and again union doesn't effectively exist right now

Lightclient: I mean I just don't agree so that's just why I don't think that this is an outstanding problem I understand this maybe you guys do but I don't think that something that we might do in the next one year should impact like what we're doing right now when it like like can can it easily be changed in the future if we need to

Alex Stokes: have other CL teams had a chance to look at this PR

yeah

Potuz: I looked at it but personally I can't speak for prison uh it sounds like something reasonable I also think that it's easy to change if you want to change the that representation later so I agree with Matt uh although Ethan left a comment in that PR that it's also reasonable to me either way works for me um they both look like reasonable changes so that's why I'm asking Matt in chat what he thinks about that comment we just concatenating the uh mer patri 3 roots of the three requests and then hash them and use that

Lightclient: yeah I mean it's not a bad idea in General I just prefer to keep things the

same when we have mechanisms that look the same and the reason is is that every time that we make a small deviation in an implementation then that just creates a lot more complexity right now the way that it's implemented is exactly how transactions are serialized and merized so we get to reuse all of that tooling if we change that then we need to like write more code around that and then it's kind of starts to defeat the purpose a bit so I think like the way that it's written is simplest and I think it's like the most maintainable for the long term because if you have to understand the TX route then you get to understand the request routs for free you don't have to go and

learn how this other mechanism works

so

Potuz: so my understanding of this is that the it is actively simpler for you guys to implement your suggestion and for us it's a very simple change because it's just extracting out that quantity that that we don't care the type and just use the right uh the right sterilization to to match it into our internal object so it's very simple change for us as well I don't see why not to include this now

Alex Stokes: yeah personally I lean towards merging just because it sounds like it simplifies implementation on the eel and especially given the uncertainty around ssz and like How It ultimately looks

like uh it just sounds like something to figure out down the line

Dustin Brody: I'm not sure that the comparison to transactions is I mean I understand from a um yel perspective that they they may well be represented similarly and or or repres similar structure let's say of distinguishing types from each other they that is relatively speaking compared to most of the CL data structure is kind of a um let's let's say from from a little bit from the outside and unmaintainable mess it it it has problems and the fact that and so importing that

into the CL World which has mostly avoided these problems I'm I'm not sure is a positive step

Lightclient: um yeah I wasn't really commenting on how it's represented on the co I'm talking about on the EO like we have these roots that exist in the execution layer header and I'm trying to keep those in sync with each other rather than having every single route means something like slightly different the way it's represented on the beacon chain is like totally up to the consensus ler teams

so

what yeah

Potuz: this doesn't change how we represent these things I mean our internal structure doesn't change at all this just changes how we deserialize over the engine API we just grab this thing grab the quantity say ah this has to be distalized as a request for for withdrawals and then this other thing needs to be uh distalized as as some deposits but we don't change the SS type of these things internally we don't change the consensus layer python types we don't change anything so that's why it's very simple change for us if it makes the happier why not

Dustin Brody: and I do see your complaint about the

future as a z but then in that case we can just change the API it's it's it's not it's not a hard for so if it bugs us when we move to SZ on both layers then we could just change this again

Alex Stokes: right so again yeah I think this makes sense and it would simplify implementation so I would say Let's Do It um maybe we'll let it sit for another week and I'll try to get another client team or two to take a look and we can go from there is that un reasonable to everyone okay I that's

yes thanks okay so that was all we had I believe for Electra uh any final comments on Electra otherwise we'll move to pios Okay cool so first I was just curious uh if anyone wants to give any implementation updates I know clients have been working in parallel on here stuts uh anything worth discussing there any questions anyone has or anything like that

Barnabas Busa: yeah our goal to lunch DEET 2 pet 2 uh hopefully tomorrow if we will have

enough clients to participate So currently I have done some local test with prison lious and Nimbus and uh pris and like house seem to be working fine nimbus have some uh Oran block proposal issue but uh it's being investigated right now I'm interested to hear from taku and lar possibly they have an update

Gajinder Singh: for Lord are um I think it should be ready I'm not sure are there any issues that you're saying

B of us

Barnabas Busa: I haven't tested yet with L start just uh I haven't heard anything either that it would be ready to go or not

Gajinder Singh: so basically with metad V3 included uh I think uh you can test it out

Alex Stokes: cool uh anyone from tuu on the call here who can speak to

puros

Anton Nashatyrev: uh yeah uh from De side we also have uh met V3 uh yeah I think yeah I think we are ready

to to participate

Alex Stokes: cool thanks and there was a question load start uh is this the pios branch is that the right one to be targeting and similar question for

techer

Gajinder Singh: yep that's the branch

Anton Nashatyrev: yeah we have we also have Branch the same Branch as before

Barnabas Busa: one more question uh can L now be super node or that's still not implemented

Anton Nashatyrev: uh you mean uh subscribed uh I mean you mean like cust in every all subnets

Barnabas Busa: yes

uh yeah yeah I think yeah for for Te

Barnabas Busa: it is but for loar we didn't have it for lar last time

loar

Gajinder Singh: can also be the Super node and I think I posted uh the param that you will need to supply to make it a super

no

Barnabas Busa: okay

Alex Stokes: okay sounds good so next up uh I wanted to follow up with uh some questions around the blobs so the first one is uh there was some work to think about uncoupling the blob counts between the

El and cl so right now basically there's like a Target and max value and uh the max at least is like hardcoded both on CL and E and you could imagine that it streamlines development uh and just generally you know opts around this stuff if we uncouple them to the extent possible so I've been working on some stuff uh recently and it has culminated in an EIP to suggust this change this is EIP 7742 uh I can go grab some links uh but yeah generally oh thanks I think Justin put this yeah so Justin put the CL PR here there's now this EIP 7742

and then just the other day I started on engine API changes so that's all here and yeah I think there's generally pretty broad support to go ahead and include these um yeah I guess that's the question now I'd suggest we put these into tectra and curious what people think about that

go

Mikhail Kalinin: I have a couple of questions a couple of clarifications um so the first one is the do we need to pass the Max L count to to payLo attributes as well

Alex Stokes: I think not so right the the El just needs the

target for the the fee accounting and really how it is right now is the max is like kind of redundant on the E so this EIP let's say uh these three PRS they kind of just take the max away from the e and all it does is pass the target

Mikhail Kalinin: but if if El will include more than the max value on the CL then

the

Alex Stokes: right but the the CL will validate so like before the El sees it the SE handles that check

Mikhail Kalinin: um right but then e should know that it should not include more than the max value more more transactions more

block transactions and so that the max

I see yeah okay okay yeah that probably you

Lightclient: either need the max or you need the E to just like have hardcoded a percentage of the max so you could say that will just like quote unquote always Target the Target being half of the max if you want fancy stuff like rabus is saying then I do think you need to be passing at both Target and the max to the

EO

Barnabas Busa: I think in the future it would be better to have both of them F because uh we might want to do something like with higher blob numbers we might want to uh change the Target

only but keep the max at a higher level

Alex Stokes: right and I was kind of the thinking with this as well is just to give us that flexibility

Barnabas Busa: yeah I mean if you're already changing it we might as well pass both of them

Alex Stokes: all right okay so yeah I can update that

Mikhail Kalinin: yeah it makes sense to me as well and the other question is about Target block count so the taret target block count uh will um will pass through payload attributes to the uh payload build process uh so the E will be able to compute the excess

uh L G gas right or block count right yeah but in this case the kind of the target blob count is required to validate the El block so in order to not break the optimistic sync the target block count will need to be to become a part of the execution layer block

Alex Stokes: right so the zip put that value into the header

Mikhail Kalinin: okay so there is the target block count in the Y walk header right MH oh I see okay um

interesting okay got it I just probably missed miss this this part s good

Alex Stokes: yeah no worries um cool so yeah I guess then everyone take a look uh do we want to talk about pure inclusion or should we wait until these changes are more in a final state it would be good to get a temperature check now we have one thumbs up in the chat anyone against including this

inetra this should simplify development and I think already the pios implementers are moving to rebase puros onto Electra and soon so I think this makes a lot of sense yeah we got another plus

one kind of follow yeah sorry

Mikhail Kalinin: just a quick followup question um can we just pass the excess block count from from seal or not I mean like it's already in the block probably the target

is not that meaningful for El if if the excess will be passed which was computed by C so we would not need probably to add one more field to the Y block

Alex Stokes: right yeah that could that could be a good compromise it kind of gets uh so denr had another proposal that basically hoist like the entire computation into the CL and I think we kind of stood away from that just because to the extent we can it's nice to have the separation of concerns between SE and eel where the SE more needs to think about just you know dust concerns and things like that around the Max and then the eel primarily just needs to know yeah excess in some sense for the V cting

so that's kind of why we settled on this um but it could be yeah I'll think about this some more it could be an option to pass the EXs around rather than pass both Max and Target like we were just discussing okay so yeah there's an update then for me to make on that and generally it sounds like people aren't bored with including so I'll bring this back to the next call and yeah we'll go there cool so the next

thing yeah the so all needs some help from the client teams but from what I've been hearing it sounds like some implementations essentially have these Bob parameters hardcoded so for example if we wanted to iterate on a you know even very Emeral devet with changing these values it would mean a recompile of the client so I'm not sure if anyone here has anything to add to that um generally we would like these to be configurable uh so it's you know very simply just to change very simple just to change some configuration and not need to recompile the entire client if we change blob counts does anyone here I don't know barest I think you raised this point I'm

not sure if you know if there are particular clients that had this issue

Barnabas Busa: I think it was something to with the ckcg library where some of the blob values were hardcoded but I'm not 100% sure anymore we haven't been playing around with the variable number of blobs uh yet uh so yeah

Sean Anderson: I think we would have had issue in Lighthouse um pan is working on going through and making it um easier to runtime configure blob count right now so we're trying to fix that

Alex Stokes: okay cool so yeah I guess then just

a general notice for everyone uh to the extent that it is runtime configurable that's much much simpler than the alternative so please be aware of that and yeah I guess we can just follow up on that asynchronously Perry was asking if G had this issue as well yeah Barnabas

Barnabas Busa: yeah one more question so right now we have uh the max blob limit in the config as a as a value that you can set but we don't have Target on the C side so maybe we can also add that uh so we can independently configure both of the values

Alex Stokes: all right yeah that's a good point yeah like client or I don't know if anyone else from gu is here uh can we speak to this question

Lightclient: sorry can you repeat the question

Alex Stokes: uh just how easy is it to change the block parameters in G Perry was asking he thought there was an issue in G as well to change the parameters for a hard fork or to change the parameters like on demand VI the engine API uh well just so like if you build gu uh those numbers are fixed and then the question is do I need to change the

source code to change them in gu and rebuild the client or can I just pass some configuration

Lightclient: yeah you have to change the source code right now

Alex Stokes: okay are there plans to update that

Lightclient: I mean no but we'll change it when it needs to be changed if there needs to be plans we can make them um I have a PR for the 7743 so that would make it configurable by the engine API if we want it configureable by Genesis like that's something that we can also look into but I think that's going to be a little bit weirder because you need to specify it for like multiple

Forks

Parithosh Jayanthi: I think by engine API makes more sense if that's the approach we're going with anyway we can configure it on the CL and the CL passes it through to the El

Marius van der Wijden: great when we get blocks from the network we don't know how to how to test this right we don't know how to verify that we have enough blocks

Parithosh Jayanthi: I think that was the same question also for sync right because even if you're sinking you kind of need to know how many blobs should have been there for the estimation

Marius van der Wijden: yeah I I think we can only change the

set hard F boundaries anyway so I would make it dependent on the

Parithosh Jayanthi: or we put it in the header

okay marus your connection's not great for me I didn't quite catch that not more Fields into the head up please

Alex Stokes: okay he's saying no more stuff in header um right okay so we might need to do a little more designer on this uh but yeah this

has been good feedback and I think we can take it from here

Marius van der Wijden: um while we added one thing I would really like is um if we could have a limit on Max blobs per transaction so that we don't have like one transaction sending six blobs or like the maximum amount of blobs per block um and this was would make also our lives transaction pool and everywhere easier um because right now someone could just like always send six blops transactions and either they will get included uh or they won't and then no

one else so yeah

Alex Stokes: right okay so I mean there's some chat content around just saying one blob one transaction having that be the limit uh or otherwise it sounds like maybe we just want a fixed whatever the maximum is we just say like that is the actual limit with respect to a single transaction because I think with 444 right now it's just not specified

onar

Ansgar Dietrichs: yeah I would personally relatively strongly oppose enforcing such a limit on the protocol level just because it seems like there's no strong reason for it and it just removes a lot of

flexibility in the future because it's really hard to predict these usage patterns once we go to this like larger blob counts I I do think though because I've been hearing that quite a bit that like it it it causes problems on the mol side so I think it's perfectly reasonable for the El clients to just coordinate on a maximum to enforce in the men pool and just ignore all transactions above that maximum um that way L topace can choose like if they have a specific way to just reach Builders directly or something they can always just like send transactions with higher accounts but uh the public mol is basically just open for transactions up to certain size to me that seems like a much more sensible minimally restrictive

approach

Marius van der Wijden: in generally I don't like this pattern of having um some transactions or most of the transactions valid by the public man pool but some transactions not and so we need to go those people need to go through the builders I just a general comment I don't I don't really like this pattern uh this in shines the builders way too much gives them a lot of power

Ansgar Dietrichs: but it's it's not just about kind of like like private ways to reach build or something it also just like the protocol should only ever enforce rules

that physically unnecessary because say in the future the men pool we have a somewhat more efficient implementation of the pool and then we can go from I don't know maximum of three to maximum of eight or something once we have higher kind of maximums in general um in in in that scenario it would just be really unfortunate to have to wait for a year for a hard work because if that limit if that limit is just not inforced in the protocol we can always just change the implementation in on the mle side whenever we want but enforcing it on the mle just significantly restricts our design space or if say an individual client wants to have like a higher limit or something thing it just to me seems like way too heavy-handed to enforce it um

yeah

Alex Stokes: so the max would be whatever the protocol level Max is right so it's not that we would say like I mean unless we wanted to really restrict transactions to say like one blob or something

Ansgar Dietrichs: wait that's my proposal my proposes to restrict per transaction on to something that's much much smaller than the block Maps potentially all the way down to

Marius van der Wijden: mhm yeah I don't want to take it down to one but the the problem is when you're fetching these transactions and you fetch a blob transaction and you don't really know

yet how big it is and then it arrives with like eight blobs um that's like I don't know how big that is but it's it's way bigger than than a block transactions with like two or three drops so um yeah I don't know

Dankrad Feist: fix just by by fixing the net Dragon protocol and announcing how many blops it has right

yeah could what it is because as a V

Dankrad Feist: exists anyway I can always send you pretend that I have a huge like tax and send you like megabytes of data

but then you

Marius van der Wijden: but

then you're violating the protocol and we can kick you

Dankrad Feist: well you can you can do the same for this you can also say like right now it's the valuation of the network protocol more than uh k transa k blocks like you're still free to do that that's independent of what allow uh in consensus like basically you're trying to use consensus to define a rule for this but like that rule can also exist on the networking layer

I just do you have a comment

Potuz: yeah I'm not sure how relevant

it is but uh I would ask for input on rollups of about inut in a limit a say of one blob per transaction I saw frances's uh comment that amortization eventually that's it but uh but but this might actually benefit some rollups over others like rollups that are posting blobs uh without execution versus rabs that are posting blobs with like expensive execution in the same transaction uh would see a different benefit into having a limit of one blob versus six blobs um and depending on what's the price of call data um this might actually make a big difference so I would ask them for input on this

matter

Marius van der Wijden: I'm not just to be clear I'm not advocating for a limit of one block per per per transaction um what I what I also see is that if we had some rule about this that you cannot like that one rollup cannot uh fill up a block um full of blobs with one transaction uh I think it might actually be more competitive um because uh and then you cannot like just fill up the blank space to to be sure that your transactions go in and and the the others don't I don't

know

Dankrad Feist: I mean you can always just create two transactions with three blocks and like use uh use build to get those in as a f like right now you can send fs and they will get in atomic you so this only makes a difference for uh for self blocks anyway

Alex Stokes: okay yeah thanks for the discussion

everyone uh sounds like a thread to keep pushing on and otherwise let's see I had the agenda somewhere what was next right okay so that was all we had on PS for today uh yeah any other closing comments on the blobs or DS or anything okay uh I will just call out eton's comment here uh let's

see there are some updates for stable containers let's see let me just check this out now there's a couple things in here uh there was this PR here so I think that this is generally um informational or at least rather it's not like a critical issue to fix at the moment uh but please take a look at this PR um there was something with the engine API and around transaction serialization so everyone take a look at that and what else was in here um updates for stable

container and yeah I think that's it um cool so we had that to follow up with and right

next up uh I did want to Circle back to the name of the fstar and I'll just grab this eth magicians link here but ultimately after you know some Community input both well from many different people looks like there was some support around fulu and you know we could call the combined name between the LCL faka so yeah I think it'd be nice to go ahead and pick a name for the

f-star anyone opposed to moving ahead with fulu Barnabas says fusaka rather than faka we got another fusaka okay so yeah let's move ahead with Fu then and yeah fusaka is a perfectly fine portamento cool so that was that and then I think

the last thing to touch on today uh would be an update from probab I think around some work on Gossip sub uh let's see someone here from probab on the call yep

yep I'm here can you hear me yep y do you mind if I share my screen I have some slides prepared yeah sure do you know if the action is limited is it not letting you share your

screen I'm not able to find the option okay let's see is there like a share icon at the bottom that you see I just have participants check ration more but nothing like sure you should yeah it see you should be able to um at least on the settings I Can See For This Zoom room

interesting yeah sorry I'm not sure it like there's a way to like disable it for the room but it's enabled so I'm not sure why you wouldn't be able to do that maybe you could just give us uh just a brief overview yeah so mostly what I was going to do is make a small introduction of a report we did uh on the performance of gosip up uh at probab in collaboration with uh the the foundation uh my colleague gum did previous update on The Last Call on the Discovery five status and this one was going to be on the

ghost up one uh the main idea was also to prepare the tool that we build uh to generate this data which is called Herms um which basically acts on the network as a light network node which has like a custom P2P Tracer uh with light Network note I don't mean like this is like a light consensus client it's mostly like a networking uh note who supports uh all the protocols uh let's say Discovery 5 goit sub and all the dptp protocols like pinic chains meta chains uh all these ones and the interesting thing is that it's generate PL with a trusted prison

node uh which allow us to reply any chain status that someone is um asking us in an honest way so that we keep honest connections and stable connections this is the biggest um let's say change if we compare it to other toolss that are out there that pretty much do the same thing um and the final purpose is that we want to reproduce the stability of any node that it's out there in the wild um what do we do with this uh basically this custom lip2 Tracer it's streaming all kind of bents at the lip top host level uh let's say connection disconnections uh send and

receive rpcs but also at the gossip level so we have uh we have control and we Trace down all the control messages that are happening at the gosip sub level let's say craft that pruns at any mes that we are subscribed to on all topics uh subscriptions to these messages control I have and I wants uh internal PE scores and also like message arrivals to each of these topics and there is um some extensions towards ethereum field where we are able also to trace down uh request response on BS beon status metadata chains so on so on um I don't want to take much of your

time but the idea was I had some slides with some graphs um and the idea was mostly to introduce like some of the outcomes that we um presented previously in some e research posts I'll try to make sure I share um on the GitHub issue at least the link to the slide so that anyone that is interested could check it but something that we um were really excited about was that we were able to retrieve the gossip sub Effectiveness um this means how many I on do we send or receive based on the ones that we send or we receive sorry my my voice is going

over but something that we identified is that this radio of I on we send or receive per all the iabs that we send or receive it's pretty low which isn't bad per se oh sorry um but it shows that the network is healthy enough to the point that we might be spending a lot of bandwidth on control messages and this was something that was pretty much a stable for all the topics except for the blocks which had like certain spikes where we could see radius of 600 messages per each I one that we were sending or

receiving um there was also like further um interest on researching duplicates this was a pretty well-known issue but there was no public data on it and this is something that we were consciously uh analyzing and what we realized is that of course the bigger the message size the bigger the number of duplicates that we received but something that we uh were able to trace them with all these traces was that the time between the first original arrival and the first duplicate um on on a mean basis at least for blocks uh it was around 80

milliseconds going up to a full second in some occasions which means that um for example the we we were pushing a lot uh towards a protocol upgrade towards I want I don't want um because we understand that the the time the time games that it's or that are involved on ethereum um allow us to pretty much send I don't one messages and try to avoid all these extra BWI that we are using because right now um all the message that we are sending and receiving represent around 64% of the total bandwidth and if we are able to reduce

the duplicates from a let's say a million of three four messages uh per each unique message ID we were saving like a huge band with holy I'm sorry um and yeah I have a band of links and interesting outcomes that we came up from this study some of them were related to the Java virtu machine implementation where we were able to identify that the they weren't implemented the control messages especially the IH haves on the same way as the other on were doing which mostly were making them uh not taking full

advantage of gossips at all um and furthermore we also push a little bit more uh towards the one. two version of Gossip app to be only a scope to the I don't want message uh inclusion um and this is pretty much the the update that I have for you I'm sorry that my voice is pretty much stress like with all these AC's it's it's pretty much over and that I couldn't really share the slides but uh I will make sure I make them a PDF and I will share them on the Sal for anyone that is interested um something that we are also taking care at the moment which

is a little bit on um work in progress is that we were also analyzing the block arrival time and we are about to make this on an automated way in our website so I would like to share the link with you here in the chat uh feel free to drop any question that you have out there um any feedback there are possibly new collaboration with the foundation towards p does so yeah happy to reply any question if I can

Alex Stokes: great thanks yeah know super exciting uh I think that from what I hear your analysis kind of correlates with other analyses people have done

around this so super good to see see some confirmations and just more data um yeah if you have um yeah any links we should take a look look at uh you can put them in the chat or otherwise yeah just follow up uh on the GitHub issue

thank you very much

Alex Stokes: yeah thank you okay so yeah we'll be looking uh for any links there on the issue for the analysis and otherwise I I think that

was pretty much it for the agenda today uh I don't know if anyone has any other topics they'd like to discuss we could Circle back to the blobs if there is more to discuss there okay well then that's it for the day uh thanks everyone and I'll see you next

time thank you bye

Che everyone

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