All Core Devs - Consensus #147

Transcript

[Music] J

oh [Applause]

okay great

Alex Stokes: everyone uh this is consensus layer call 147 and let's see there's the agenda in the chat it's PM issue 1211 and yeah we have a pretty big agenda today hopefully we can get to some sort of closure on pectra and yeah let's go ahead and dive in so uh first we could just have like a quick update or check in uh with any devits we have going on uh we have Mong and then otherwise uh today we'll talk about de 5 so I'm not sure if there's much else to discuss there but I'll open it up are there any updates uh we should

discuss any bugs or issues we should talk about

Mong

Barnabas Busa: is the very stable so there's no update on Mong side

Alex Stokes: okay great I guess one thing you it did go to 36 million gas right

Barnabas Busa: yes

Alex Stokes: cool and yeah so it's been stable so that's good to see cool okay then yeah let's get into it um pectra duet five so uh there's a spec and yeah today there's a number of things uh as potentially finalizing that spec so we can move forward with the devet and yeah okay so the first one here this is kind of an FYI um there was

a PR to rename a field uh in the pending partial withdrawal and it's been merged it was just simply changing the name of one of the fields so yeah just kind of a heads up uh that's there and we'll be in the next release and yeah from here there's like a number of things to discuss uh people wanted some time to engage with this question around changing the gossip limits uh let me grab this PR as kind of a concrete thing to ground the conversation and yeah so this PR uh proposes raising the gossip limit uh in the sort of in the spec that we have from 10 megabytes where it is today to 15 and this came up uh sort of via

investigation into raising the gas Summit on mayet and yeah it's the million today there have even been calls from the community to raise up to 60 million over like a pretty short timeline um one thing that we consider doing here uh is changing this gossip limit um yeah I don't know if anyone wants to add any more context or otherwise we can discuss if we want to uh include this change for hea if not sooner

Barnabas Busa: I would ideally like to see this gossip limit change at a fork instead of just change a

value so maybe gossip Max size with Electra if we end up bumping it

Alex Stokes: right because I think otherwise it would be weird if some nodes had different limits and there was a block that triggered it

Barnabas Busa: exactly

Alex Stokes: yeah okay I think to be

fair we're kind of getting into that situation where that might happen anyway because um some clients are talking about changing the uncompressed limit on blocks and that would cause a similar scenario to changing it at any time in the clients so I think whatever we do do we we need to be consistent across all of the

SE yeah that good

Dankrad Feist: right yeah I mean I agree I think like we need to make make sure that there's no like consensus failures due to this limit and I think like I feel like that should just be treated as a bug that it is the case right now and we should fix that like right now and that independently we can raise that limit but there should be no case where like raising the gas limit leads to a consensus failure or like in ineffective consensus failure

Alex Stokes: right yeah HD you have your hand

up

yeah um so I've taken a little bit of a look at um what the implications are of this limit so basically we're talking about a limit of the gossip message size when it's uncompressed like the payload is uncompressed um and the payload is of course the block itself um using the ssz encoding and in the ssz encoding um all of the fields are actually um constant sized or rather they have a constant upper bound um except for the

transactions and the way we encode the transactions is simply a bite list of nearly infinite size um so this kind of simplifies the problem a little bit at least uh because it means that let's say that we have you know 10 megabytes is the the the maximum CIP size um the maximum transaction list size can easily be derived from there and it's roughly 300K lower than those 10 megabytes so we could say that um we have you know 9.7 megabytes of space available for

transactions and this is the only thing that determines whether or not this limit gets hit so um in this way we can actually reduce this uh problem into you know an upper bound on the on the transaction size that an execution client can possibly create which is good news I guess because then at least we can also explore other kinds of options where um well the two that come to mind is that either we compute a maximum possible gossip size um from the gas limit with a little bit of SP

handle gas liit going up and down um and we can do this Solly based on this transaction field or uh layer clients can actually inform the execution layer that you have this this much space available transactions uh anywh you wish um and then uh then the other nice thing about the transaction field being the determin it is encoded using you know or whatever it is that uh there but but it's nothing that the consensus layer

has to care about they don't have to know about the encodings and so on and conversely uh by by giving this limit this way the execution layer doesn't have to know anything about the gossip layer either so I feel like uh going forward there are a couple of Fairly straightforward ways of addressing this problem uh properly uh um regarding an increase um I think that this is our one of the few mechanisms that we have to protect against spam against amplification

attacks and is fairly blunt uh the smaller it is the better as is uh a 5 megabyte increase there can give an attacker like 13 gabt of traffic uh um if you compute the full amplification and the reason for this is that we validate the execution uh component of the block way later than we do gossip propagation uh and the final thing I wanted to say on this topic is that I have a PR up that also fixes the ambiguity um in Spec the spec is a little bit poorly worded so there has

been a little bit of confusion of compressed versus uncompressed uh but um kind of summary of that PR is that we do want to Target the compress the uncompressed size with the limit for for a lot of reasons one is because it's easy to reason about uh it's easy to derive a transaction limit from it and so on uh it also protects against Snappy decompression bombs uh which is good um and then from that limit we can actually compute maximum allowable compressed size as well and this is based

on uh the fact that Snappy has an upper bound on how much uh how much data can expand when you try to compress it and this is uh about 10% more than I think it's like 13 or 14% more than the incoming data size so we can put a bound on the uh compressed message by deriving it from the uncompressed maximum size and this is also good news and there's a PR coming up for this yeah soon

Alex Stokes: okay thanks yeah that's that's

helpful to know uh your connection was a little garbled but essentially yeah it sounds like uh you're open to raising this limit or at least thinking about it more intelligently um then the question is yeah on what timelines do we do what there is a number of comments in the chat around yeah how we do this um the catch here is that like the only real guarantee we have that all nodes have a certain profile is that a hard Fork uh then the question is like yeah let's say we want to change this ASAP uh how would client teams thinking how would client teams think about you know pushing this to their users and actually making this happen

like for example there was a comment I think from Preston just to put minimum versions on this pump the gas website do we feel like that's like a sufficient directive

I can answer that I think that it's you know wherever we're pushing the message of you know hey 40 million is okay or you know even 60 million is okay you say as long as you're looking at this because there's a known issue my support for releasing as soon as possible this change is that the gas limit will change outside of the hard fork and we know there's a problem and

we can fix it so why not fix it now it doesn't seem that uh controversial to me um yeah some validators don't update often but you know they're missing out on other bugs that happen on a regular basis anyway so you know they should be updating frequently I think as well

Alex Stokes: right yeah I mean it does seem like it's a little bit split like one option is to go ahead and try to get this updated as soon as possible uh would anyone be against that and yeah there's another comment uh that

made a good point it's like with pectra this should all be resolved 7623 here helps quite a bit then the question is just like between now and then how do we want to handle this um what we probably don't want is to have different clients do different things in the meantime so ideally we could agree to do the same thing whether that's no change today or that uh push for some raay uh as quickly as possible yeah

ATD yeah so I'm kind of against upgrading on principle um I think that we still have a little bit of time to uh reason about this problem it seems that the response from the community

about not going into a um gas limit situation that exceeds this bounds has been fairly positive so far uh and like this would effectively mean that we're changing the rules of the protocol outside of a hard Fork which is uh a new kind of expectation that we have on the community like normally we should expect that unless there's like a DI hard bug um we should that users should not have to update their clients between you know hard for ex as it were uh but if we are going to do this we should certainly do

it all together we should certainly also uh update the config because there exists the possibility for users to Simply override their local config and use whatever version they already have uh and then we should put out that recommendation as well uh I think the the risk here is is indeed the unupgraded nodes uh because what happens with unupgraded nodes is that we effectively create a split in the network right a network based split instead of a consensus based split but at the end of the day um those nodes that have an old version are still capable of building a new block or following uh a new chain or building a different chain depending on

the relative weights of validators that they have on them right and and this is this is not pretty either like none of these two options are really fantastic

Alex Stokes: right I mean one small push back is like if there was say a consensus failure today like we would go fix it today so you know it's not that can never touch the you know the protocol in between hard Forks

this is

Dankrad Feist: effectively a bug like this is like we like there is like if this limit was enforced consistently then there would not be a

problem like then we would just have like an effective additional block size limit so the problem right now in my opinion is just that it's not consistent we don't need to raise it if every client has exactly the same way of determining it and of course if we stop uh self Builders from building blocks that are too large

I mean the spec is unambiguous um or the spec is yeah in s correct um the differences in interpretation are rather minimal to the best of my knowledge um we all talk

about the limit being on the uncompressed size except maybe a few older versions of clients or maybe this has been fixed recently uh but by and large in the tests that at least party have run um we certainly see this limit kicking in right it it it does disrupt the network when blocks become larger so it's in so far as practical reality goes it's correctly implemented

Dankrad Feist: okay so then what's the problem then we just don't build blocks that large and then it's fine

uh the problem is that uh execution clients or like we don't know if for

example Builders uh uh can build smaller blocks once uh a large transaction hits their M Pool whether they are able to exclude large transactions from their um mol when they are building blocks and this limit has been exceeded so uh somebody posting a really large transaction could kind of poison the meole and it would be hard for Block Builders to not include this transaction except by you know a lower gas limit and they would have to implement a new feature in order to put a limit on the total length of the transaction

rlp which is which is the the real limit here or the size limit I mean that that's a feasible way forwards as well

Dankrad Feist: I think we should do

that that that requires their agreement

yeah you

Enrico Del Fante: yeah so in that case I guess the short circuit breaker will save us and uh anyway progress the chain with some bumps and they Builder will be forced to implement something to fix quickly um so I would say that in in general I think that

um I agree with d that that there is a bug around here and this this has been must be fixed to to have all the clients behave the same and this is the most important thing and I also agree with um yasek that having something better in in controlling how the block uh is is is built is definitely uh a very good thing to have that give us a better control over the sizes of data floating around and I think it's this is a valuable thing to to implement and if if it is safe at the end to have uh to Li to to

to remain with a 10 megabyte limits for a while I think it makes sense and uh by we have time to to address this these details and have a better uh control over the block size and we may not need to move this this limit uh never essentially

teren so just to clarify

Terence Tsao: on The Bu a little bit Po's also mentioned in the chat right because now the issue is that the attacker could just FL the local Mano with chip transactions and then like do the one like probably like will be whether there whether they will be fast enough to react that's a different

story but then like the problem here is that say today like no one can build the block anymore so the only way to fix this is literally to send transactions to the main pool they end up paying more to the attack uh stuff so I don't think the circuit breaker can save us unless today we basically override those those transactions on the public pool

all

Enrico Del Fante: right right so you're not so yes was meant meant to say that this is a problem in the building process of every execution client is not a builder problem

Alex Stokes: right well a little bit of both and like yeah maybe to summarize so far

it sounds like a pragmatic path forward at this moment would be one like ensuring that all sale clients have conformance to the spec around this limit as specified today at 10 megabytes and then separately the ask would be to change the transaction rules in E clients such that you can't get these massive transactions was that correct

I think that's correct in so far as that uh proposal goes the counter proposal here is simply that we just wing it and everybody increases their limits to a point where you know realistically all these blocks get through and we hope

that people upgrade and and maybe there will be a few chain splits along the way right and then we also increase the attack surface uh and we deal with that later

Alex Stokes: right I think the

urgency of the matter is is is is the Crux here I think most of the things get solved by pectra where which addresses the root cause of this problem which is a gas mispricing in my in my view uh because it's simply too cheap to create like the thing to remember here is that is is what the EIP about increasing the gas uh cost for certain things says which is basically that the average block is something like you know uh let's say 100 kiloby or or less even and and that's the useful kind of

transactions that people post on chain and then these uh attack transactions if we will these message transactions they're um first of all fill with zeros um which means that they compress well so so it's not not that bad but um the second thing is that uh it's the gas pricing that allows uh people to create these transactions and the gas prices don't correctly capture the true cost of of transactions this big so increasing the gas price kind of solves this um in the same way that yeah in the same way that Shanghai we had a gas mispricing on you

know hard drive aess and and the gas price failed to capture the the true cost of of that particular thing

Alex Stokes: yeah so pus has a good point here that you can still do this with many smaller transactions so yeah that kind of puts a hole in this proposal to think about limiting this uh just at the

E well no the E can still bound the list the transaction list size like an entirely dumb implementation in the in in the in the transaction pool is actually to just construct your list of transactions as normal and then cut it off at the limit like that will solve problem and it's a bite limit on the rlp encoding so

it's something that the E can comfortably do on its own if it want if we go down that that route

okay

Alex Stokes: so then it wouldn't necessarily be about changing M Poole propagation limits but just when you're Building look at the actual size

um yeah that's one possible solution and and it's not there's not a lot of interaction going on here between uh El and cl the the eel can implement this with a chain constant basically and I've put this the exact value for this constant in E3 search we can easily derive it from the gosip max limit it's a simple function

Alex Stokes: right yeah I mean my one thing with this proposal is that then we need

El's to make a change and then the question is like can we coordinate ASAP um you know the next acde would be next week and it's also I think the last one is here so just something to keep in mind like logistically um you have your hand up I can't hear you if you're speaking but you did unmute yeah I think yeah I think you might have some audio issues Dan

c

Dankrad Feist: yeah I mean I think like so right now we're on track for an increase to 36 million so it's not like something that will have to be fixed right now in a way because I don't think um many people will will increase beyond that uh but I think generally speaking like whatever else we do like even with 7623 like um like still having having an inconsistent limit and having like an El that can can create blocks louter than that is still a bug in my opinion like even if we now have a like have a fix that means oh yeah like we can't imagine hitting that again like well who knows in five years we

might be at a billion gas and suddenly out of nothing the same SP hits again like I think like we should just really make sure that we squash this once and for all even if it takes like a few more weeks but I think like it's not acceptable to have this

this grab Andy

Alex Stokes: yeah I mean I think everyone agrees with that um and it seems like the path forward there is having this gossip limit somehow be a function of the gas limit um yeah just shant your hands back up I don't know if you can talk okay he had a comment in the chat

uh my point was that it's easier to change limit in the CL rather than mess with the yeah okay um well okay so it sounds like the immediate thing we can do is again ensure conformance with CLS in Spec and yeah I don't know if any elevs are on the call and want to speak to the complexity of bounding payload sizes during build time yeah I mean

you're it's

Ben Edgington: more complicated and you're also just pushing a consensus

failure into a different place because then you've still got the issue with all the El's trying to coordinate outside a Fork to get the right version you know it doesn't it doesn't make the problem any easier

Dankrad Feist: well the eel's not doing anything would not make like would not create a consensus failure it would just be a failure to produce blocks by those Els who haven't upgraded

Ben Edgington: so they would only would only be in Block production they would accept blocks oversized that's that you're saying

so if a non-upgraded e produces an oversized block you know that's fine okay now you put the problem again

Dankrad Feist: no the that yeah that block would just be like not accepted it would just disappear

Ben Edgington: and if you also change the validation rules for the Els to reject blocks too large

I don't think anyone is proposing

Ben Edgington: in which case the El would accept the blocks and you hit CL issue inconsistency

Dankrad Feist: all all blocks like to be accepted by the El a block has to be

accepted by the CL

Ben Edgington: yeah which has inconsistent rules

Dankrad Feist: right there yeah this has to be fixed for sure

Lightclient: what is what needs to be fixed um like it seems like the E will never even received the block because CLS will not be able to send it over gossip yeah so what is the change propos for

El's

Alex Stokes: me okay so yeah for for seals there's some question of like following the spec as it is today and so that will be resolved ASAP then the question is like what do we want to do now versus

you know wait until Petra and option would be thinking about bounding the size of the payload produced um the other option I'm kind of hearing is we just go with a more sort of reasoned solution that might take a little bit longer but again given this isn't like an immediate issue today we probably have some time to do that

Lightclient: is there something that we can actually do outside the fork like we are putting 7623 in the fork and that's going to solve this issue on the El side

Alex Stokes: yeah so the longer term solution here would be having this gossip limit be a function of the gas limit which would is like solve it for all time

Lightclient: um but why

not just make the gossip limit 50 megabytes or something much larger like what function does it actually serve

Alex Stokes: it prevents dos attacks so you know like it as a seal client you don't want to like have to think about handling a huge block and then you know the resulting propagation through the network and everything that

in

Dankrad Feist: I feel like also here there's something weird like does the current like my intuition is the current limit doesn't really effectively prevent any attacks like does it can someone speak to that

Alex Stokes: like we just someone if someone sent like a if someone sent like 100 megabyte block that would just be

rejected whereas like if it's much smaller then you know you don't have to think about but that

Dankrad Feist: that's that's just a local thing right like that is my appear of mine because like I will not forward the like 100% that's an invalid block so I will never forward it anyway so the only thing that could happen is that one of my peers sends me that block but like AP spamming me with messages like is a problem that you can't really prevent anyway so I don't really exactly know what do prevents why 10 megabytes makes a difference there

Lightclient: yeah I I agree with that and also I

think that the in general you're always going to be able to make the pier do work um where you have some sort of message that you send a pier and they do an amount of work that is not really um that does not really correlate with the message size that you sent and that attack is always going to be worse than just blindly dossing them with big pieces of data

um so I can actually answer to that this limit exists because if we don't have it there's an amplif ification attack and the amplification attack happens because uh the execution payload is validated asynchronously with respect to gossip propagation so the way it works is that we receive the message in

full we perform a couple of Gossip pre-checks we can call them the most significant check there is really the proposer signature uh but other than that we don't check anything really so in particular we don't check that the execution payload is valid so it could be stuffed with invalid transactions it could be stuffed with junk we don't know we don't care we give that to the El to validate and then the El takes you know it's one or two seconds to validate the block but all that happens asynchronously by this time we've already started repopa the message

um so uh what happens basically basically is that we we can ask the network to propagate invalid messages through this little loophole uh so for example I did a quick like back of the envelope calculation and uh if I did the math right which I don't always do but in this case I landed at like 13 gbt of traffic for a 5 megabyte increase and this is because you know um we have a fairly High uh fan out on the messages s sish eight uh and this kind of repeats for every op so you you cause these big pulses of

data just flooding the network if you're hellbent on on on executing this this particular attack and the reason we have the limit is because that amount of data is like feasible to clear within the slot and we get a new chance for a new blocket the next slot to to sort of clear the pipes the larger that limit is um the more potent this particular attack becomes and the easier it becomes to kind of make the next guy miss their slot because the gossip sub channel is busy spamming this massive message around so that's what we're protecting against here

Alex Stokes: okay uh I do think we should time

box this to get to other things on the agenda what I'm hearing is okay one first off like CLS should uh double check that they followed the Spike as written today correctly uh if not definitely need to send out updates that one's straightforward then it sounds like what we want to do is take a little more time to think about what like the nice solution here is with respect to the scup limits and the gas limit um the other sort of path would be moving ahead with bumping the gossip limit uh to me given the fact that yeah it'll be you know a messy roll out or at least you know it could be messy and what I mean

when I say that is just we won't know you know which notes have updated which have not uh that to me feels like more of a nuclear option that we should have in the back pocket if we need it but again given that gas limits probably won't raise before Petra in a way that's going to be an issue we have a little breathing room there um does that sound like a good path forward to anyone or does anyone want to suggest something else okay I'll take the silence as agreement there is some uh thumbs up in

the chat so let's do that and yeah I mean I think everyone's very aware of what's going on so please just keep an eye on things um you know if for example the gas limit does raise uh over the next few weeks we'll need to be pretty active in addressing this cool so we'll just table this PR for now uh but it's here okay we can then move on to other things for de5 um the next I think big thing I want to talk about is 7 742 and there is some helpful context here uh reaching out to rups um what do I want to say so yeah maybe to like yeah kick things

off so 7742 uh right now the EIP proposes passing the target to the e but not the Max and as people implemented this uh we kind of found their places where we would want the the Max uh for the eel to have uh in particular this came up with the RPC there's like an API Ino that gives you like The Blob fee history uh I think it's something like blob gas use ratio or something like this where you do need the Max and then there's from there sort of the bigger question like are there other places where the E might want the max um another place that kind of came up would be the m poool and in any case it sounds like um yeah just passing the

target is probably not the way to go so then the question is how do we want to address this um we did reach out to roll call that happened the other day and asked them if they use this particular API um Carl I think you had some updates there if you want to give us just a quick overview

yeah very quickly um so of course we don't have necessarily everyone on the call who was able to answer this question but from the people that were there/ of. after uh roll call um currently scroll ZK sync arbitrum and uh the op stack chains uh don't use this

blob gas used ratio uh endpoint um and the only one that I have heard back that does is linear um they said if we were to remove it they could figure out an alternative solution but uh they have a preference for leaving in if possible um and then the other concern that was raised is um potentially wallets might use this for uh pricing in the future but this is not something that anyone was aware of happening at the moment so overall I'd say weak preference for leaving this end point in yeah that's that's all I have on that

well thanks

Alex Stokes: so yeah I mean someone does use it um but yeah it sounds like

they workarounds and otherwise there's not like a it's not like critically used uh generally so that being said um then the question is okay like if we do want to keep the max do we send it over uh in the engine API how is that structured there's like a couple different options uh one of them is just sending it over with the Target on every block we then probably want to put it in the header um or at least we it needs to kind of live somewhere that the E has access to um and to that point another option would be some sort of like status sort of exchange when the El and boot over the engine API uh and then the eel would

just like capture the Max and like save it somewhere um but you know point being is as we started exploring all of this uh we kind of even asked the question like should we have 7742 at all um the reason we initially had it was to well I mean a couple things um I think two big things was one it wasn't as flexible to change these limits uh in seals and Eels and this would kind of be a forcing function to make this more easily configurable the other thing is if you do go all the way with 7742 you do uncouple the E and cl and then you could imagine a CL only fork um where you change these Bob limits which is just like really nice flexibility to have so that all being

said um there was another proposal to handle this differently where you just essentially have this configurability notion you would remove 7742 from pectra and then you know for example you can imagine in like the Genesis Json that clients have uh you in the configuration they have you would have these wets there instead so you still have them coupled uh you would kind of lose the seal only fork option uh but it would probably be a much simpler implementation it would take an EIP out of pectra uh and probably simplify things on that front so yeah there's a comment from my client in favor of removing uh anyone else have any thoughts

here what could also be helpful is if others have implemented this just speaking to like its complexity I mean it could be the case that yeah given that we want to ship pure ASAP and where we are in the sort of the development process it we might just prefer a simpler solution

Dustin Brody: uh yeah so this was actually something that Mel um observed um but I would agree with it and and that the 7742 creates this assumption effectively or bakes it in that every single block is coming over this engine API or some other interface whether you however it's specified I I figure I assume that if

7742 happens then people will like realize this and backfill this and look out every other way to specify a block and say oh we need to add it there too but the point is that El's will will start assuming I mean that the the point of how this works is Els start assuming that this is how they get sort of let's say full complete block uh packages um and Nimbus and at least I believe at least one of Cl has a situation where it will send will uh verify block cash locally that saves a lot of time while sing to send every single block we've benchmarked this Etc um that creates

problems and again I'm just s of repeating what male kind of said in Discord but um especially around Forks uh but but in general like there's this uncertainty of well what if the number of blobs changes Etc if it is truly Dynamic then it might change frequently and at that point the El needs its own access either to get hear about it from the CL every block or for it to be not that important or to have access in some other way but if it has access in some other way then it doesn't need the cl to provide that information

Alex Stokes: right I mean another option is we essentially do 7742 but then still have like some could pig in the

Genesis um yeah I mean it' be helpful I think to hear how we're feeling around implementation complexity or even like the testing load I think that would help us think about uh Petra inclusion yeah Mario

Mario Vega: yeah I think I in terms of at least execution later testing we're almost there we have all the chains implemented um I think the max limit inclusion wouldn't be such a burden um but yeah uh it's it's it's basically a almost there

okay

Mikhail Kalinin: um um a quick question even if max value is included in each El block so El has information uh won't it be required by any potential use case that e client should know the max in advance so if the max is going to be updated since the next blog maybe somehow also needed like what I'm trying to say is that uh probably there is the use case where elel needs to know uh this the

schedule of U the schedule of Target and Max for for kind of like dependent on forks not only the historical Max and Target

Alex Stokes: yeah I'm not sure if any Els can speak to that um but yeah I'm trying to keep up with the chat here I mean it looks like there is some preference for going with the simpler Approach at the moment

Lightclient: yeah I guess just from my perspective it this the proposal is just not really doing quite what we had

originally hoped and we realized like we're realizing with many things like gas limit gosip size on the seal there's not a these things don't live in isolation and it's just not realistic to expect there to be one uniform place to change these things when we have two different clients with two different Stacks with two different networks and we are just seeing places where Max blobs are needed in the E so we're going to find a way to get that data over there and if we're not changing the value of the max blob count on like a per block basis it's still on a per Fork basis then it's pretty straightforward for us to have a unified config between

the two clients and adding it to the engine API adds just like unnecessary complexity adding it to the header adds unnecessary complexity

Alex Stokes: yeah I guess a question I have there if we go with the route to just have it in the config on both Eon CL like how like do we need to specify this somewhere like how do we uh actually Implement that I don't believe there's like an EIP for this Genesis config structure

Lightclient: I think that the Genesis config most like we can create an EAP we can create a gist doesn't really matter

but if this is how going to be doing the dev nuts then every client is going to implement the thing or else they're not going to get included in the dev nuts so I think that's like a pretty strong foring function for getting people to do this

Alex Stokes: yeah Dan CR do you have your hand up I'm not sure uh if that was from

Dankrad Feist: sorry I forgot to un uh yeah like I think it's crazy to have this in both clients and keep this as like something that has to be kept in snc between the two like to me that's Tech that and we should eliminate it like back when we started with the two

like C and El we were like yes this is cool so we can iterate on both sides independently but now we end up having always having to have all hard for exactly in s and like yeah I mean my prediction is this is going to be okay so now Petra has to be coupled to the next El fork and then I mean that that's just insane to me like that we that we're okay with like uh slowing down something potentially by month like because one constant has to be changed in the other time

Alex Stokes: yeah I mean I don't think there' be a slow down of months

Lightclient: yeah I mean

Dankrad Feist: right now we're talking about like a constant being fixed in the CL in order to have a higher gas limit and we're already practically saying oh we can't really do it before pectra um I think practically speaking it does feel like that's where it's going to end up

Lightclient: if I me I feel like it's not that we can't do it before pectra it's just how are you going to get everyone to update their clients to support this new constant before pectra like do you want to just have a new hard for work in one month that just does this config

Dankrad Feist: but isn't this the same thing like I

Lightclient: mean it is the same thing but like I feel like this doesn't really have to do as much with the Cel breakdown here it's that CLS are also

focusing on shipping their own portion of the fork and it's kind of a side quest to just update this constant and push the releases out and get everybody on board with that

Dankrad Feist: like exactly and will be let's say like we're like we're ready to ship Pier dust but like the E needs another two months for their side of the next El Fork you don't think we'll be in the same situation where El clients will now say oh yeah but like it doesn't make sense to make this mini release now let's just do it together with the hard

forg

Lightclient: I just don't think these things are in like pure isolation like bumping this constant on the CL for the gossip Max size this is not something that you could just mindlessly do just as you can't mindlessly increase the blob limit

with respect to the trans Action Pool on the execution layer so I I think that the conversation is just always going to have to go both ways there's always going to be discussion about the safety of doing these things has the other side implemented the necessary protections to deal with this higher load

Alex Stokes: right so there are a few other updates around the CP that have come in so maybe we'll take a look at those uh and that might give us a sense of you know impact for pectra um one of them is pretty simple but there was an EIP update that uh the eot kind of merged on me when I didn't

want it to um it's this here in the chat and it was just clarifying the EIP because the Way It Was Written well more than clarification but the Way It Was Written it was suggesting to look at the current uh Target blob count when really we should be using the parent uh so that's all this does but point being is there's a small change here and that will then you know will'll need round of updating testing we'll need around updating implementations uh so that will take some time the other thing is uh there was another conversation on the engine API and again this is somewhat minor uh but

I think we'll probably want to uh refactor some of how this uh PR is ready um to align it uh with essentially how we handle the parent beacon block rout it's like a similar thing where the se's passing this data um so again pretty minor change but uh we will likely need to address that so that all being said um it does feel tight to do all that get it ready and then have devet 5 and say like the next week or two I guess maybe then we could check in

like do we have a timeline for devet 5 I mean I think we'd like to get it done this month but then realistically that is only a couple weeks LED and then I guess the altern yeah Mario

Mario Vega: yeah I think I mean from the side of testing at least for the execution part um we're I think almost ready uh the problem is that even if we make a release let's say today or tomorrow with every every change that we had already considered before this call uh even then I think there's going to be like a lot of in my opinion a lot of issues that need to be addressed when the clients start consuming this tests so even

optimistically releasing today I don't I don't see de 5 happening even maybe next week I don't but I'm I'm I'm I'm not that that optimistic to be honest um yeah just want just want us to put that out

Alex Stokes: right I mean the other option is if we go with the configuration route for the time being that will also take some time to to build out um yeah and it seems like since this is somewhat sweat on this I see some comments that say preference to take it out there's definitely a demand to leave in um h I mean I guess one question is like how

much thrash would it be to take it out now like is it the case that it's pretty much there um if we do move ahead with it then we'd probably need to think about this RPC in point and I think for like devet 5 let's say we could just kind of leave it as is even if it would be broken um but yeah that is something we need to address down the line I will say I very much like Simplicity um and while I hear the benefits of having sort of the full 7742 if we do think it's just simpler at the moment to go with the configuration approach that sounds sounds nice um wrath we need to undo some work

so then if we leave it in um yeah would we be yeah I think this is a hard call to make uh so if we leave it in then we would want to figure out some way to handle the Max uh but then we could just kind of leave it broken for de at5 and then we need to address in

at six

Barnabas Busa: why can't we solve it the same way as target

Alex Stokes: well so we can but then it's just like you're sending over this this

number that basically never changes and then it's just there for all time um yeah yeah and then there was this comment like adding them to the header is probably more work than undoing it yeah I guess that's the other

Barnabas Busa: what that this number will rarely ever change like when

774

Alex Stokes: right right and but we also didn't think we would need to send it over to the Y h i mean it feels to me like removing it

would just simplify Petra honestly um and then going ahead with the configuration change and having that for devet 5 yeah says keeping it in but without the max seems like the worst option yeah okay I mean I think that's what I lean towards and I mean there's always the option to revisit this in the future um and go for you know a more sort of at least having more time uh to think about how to handle this without then having to delay pectra so yeah I mean there's some other

comments here in favor of simplicity so yeah I mean I think we should just go ahead and take it out um anyone super strongly opposed to that otherwise I think we just go ahead and do that um yeah which simplifies the yeah so E's will need to do that but we can just kind of ignore the EAP the engine API we can ignore that um and then yeah there was some work merged into the seal specs but yeah I can I think Justin Trav made a comment but yeah I can help you

with that as well Justin uh we can get that done ASAP so yeah let's go ahead and do that um I suppose that like if there's a compromise here the compromise is that uh we cannot let like for example if we're ready to like ship P do or change the Bob counts in any future Fork we should we cannot let uh the El's kind of quote hold things hostage here so let's just uh yeah all all agree to that okay let's keep moving

on

Alex Stokes: uh so that's 7742 okay so there are a few things

around 7251 uh what do we have here so this first one Mel had a PR to uh limit the consolidation balance via the effective balance um I have not had a chance to look at this yet but there is there are some approvals on the pr uh Mel would you want to give an overview of the changes here

Mikhail Kalinin: um yeah sure so um just recall on how consolidation happens first uh the source is exiting where we CH validator which on the effective balance

so which is actually the balance that that is exiting um and then after it exited we move the balance um when the withdrawal comes and uh um the existence spec uses max effective balance as the limitation for the balance that of the move and yeah this a bit of we uh create some asymmetry and discrepancy because we like the one to use it's more reasonable to use effective balance in this place as well because kind of effective balance is is exiting and then we we move it with the um effective balance of Max the balance

that was that has exited so now it's yeah it's it's different and there is uh there are some edge cases with that as well um that are listed in this PR description so yeah basically that's that's fix um for this small um discrepancy and also um there are some tests in the pr um more extensiv testing the balance that is moved the balance moveed during consolidation so yeah this I think it would be great to have this in devet 5 so we need to just merge it and if there

is an opposition from client teams to I don't think it's like deal to implement it it's basically fixing one line so if there is an opposition please let us know

Alex Stokes: yeah has anyone else had a chance to look at this um but yeah I mean I think that makes sense it seems like a pre simple change uh I would think we go ahead and get it merged you know in the next day or two for de5 so yeah an of time if anyone wants to review this async yeah take your feedback to the pr uh otherwise yeah Mel I can work with you on getting this

merged uh this seems like a straightforward change okay so there's that one and then the other 7251 thing was this PR um this one is a little more complex um but essentially there is an issue with with uh like the distribution of like sampling when you go to think about proposer shelf lanes and also the SN committees uh given the way that we have this like Max CB um basically the math kind of just doesn't work out uh with what we have using sort of one BTE as this um point of comparison and this PR suggest using two bytes um there's some

really nice uh there's a nice spreadsheet here that makes the math I think pretty cre um and it essentially just Smooths out um all these different um probabilities let's say uh given Max CB so again I'm not sure if people have had a chance to look at this um but yeah it's a pretty straightforward change and seems to make things a bit nicer so um yeah any feedback on this at the moment I don't know if there's something else justess in to add this was a

Pras uh nope that's that was good thank you

Alex Stokes: okay we got to let's merge I mean

this one is a little more invasive uh even than the prior one but uh yeah it does seem to make things much nicer so um how about this yeah please see all clients take a look uh and even later today definitely by tomorrow um otherwise yeah the intent will be to have it in the next release for devet 5 cool um okay I think from here there were some eel Focus things and one of them was another comment from Roll Call uh Anar brought up this in the chat and Carl had a summary in his comment here on the agenda and it was around 7762 uh ongar Carl I'm not sure if you

want to give us an update there

Ansgar Dietrichs: yeah so basically actually this is basically a noop update because um last week we decided temp preliminarily to not include uh this EAP which is this uh EAP to to to basically establish a um minimum um blob base fee I had argued last week quite vly that that we should add it um and so we we we decided to revisit this week with some um feedback from from rollups in between um and in the past there had actually been quite a bit of Desire from from rups to to to have have this um but now on roll call we talked about it and it seemed like basically um rups have been able to more

or less work around this for now um so actually it is lower urgency than I I had uh perceived it so with that feedback in mind and given that we decided last week to only included if if really there was a strong case for for that it seems to me like the best thing to do here is to just go ahead without it for for pectra and then um given that on inaka we wanted to make bigger changes to the fee Market anyway I would assume that it will be part of that change then and apologies for taking up so much space last week then given that that seemed to be lower urgency than I expected it to be

Alex Stokes: okay and sorry uh I was looking at something else basically you're saying we don't need to think about the CIP for

pectra

I'm

Ansgar Dietrichs: I think it would still be a good change but given the situation in P I think um yeah it's fine to leave it out

Alex Stokes: okay then I would suggest we don't put it in and yeah thanks for the update thanks for reaching out the roll call both of you uh that's super helpful to get L2 inputs on these questions okay uh there was a point to follow up with the BLS pre compiles I know there is a separate uh thread of work to finalize the gas I'm not sure if anyone here has any updates there on the progress Mark

Marek Moraczyński: yes so we split it into three PRS

to discuss different operations separately and first PR uh this includes simple operation like add multiplication and map and we have a strong consensus among all people uh second PR for piring I think we have consensus here as well at least no objection and third PR this is for multiscalar multiplication and in this case we got consensus from all clients because numbers from benchmarks are correct across all clients however pav r a valid coner today but if we proceed with the current pricing it will create a weird pattern in smart contracts uh where they might Implement a fall back

to normal multiplication for multiscalar scalar multip with a single point and pav just sent new numbers that take this issue into account so uh clients will have to add a small simple if with AA B to M multiplication on their side and we will Benchmark it again and uh I think that's it

about BLS

Alex Stokes: okay um and the idea would be to merge all of these PRS I haven't had a chance to look at these yet

Marek Moraczyński: so I think after we uh we we merch them all

together so after we Benchmark this third PR with a multiscalar multiplication we could um merge it

Alex Stokes: okay is that something we can do by next acde

Marek Moraczyński: yes we have to

Alex Stokes: okay great um cool okay then yeah any El clients listening take a look at these PRS um thanks everyone who's been busy working on this I know there's been a pretty active uh investigation to get this over the line and then yeah we'll have these final benchmarks for the MSM and uh sort that out next week okay I think that was the deet five

stuff were there any other like spec level issues or concerns people had yeah so that was my next question Barnabas so then yeah we can turn to timing um you know there's still a number of things that will change uh from today's call and even next week's call then the question is yeah how quickly can we get all of that together um it would be great to launch de5 before the end of the year but we are halfway through December so that is what those um yeah Barnabas says launch it on

Christmas yeah I mean the one thing is I'm not like I imagine there'll be things around Petra that we'll need to discuss next week so definitely you know we can move as quickly as we can uh I think the seal thing should be settled today and so people can get a start there but otherwise yeah I am not sure how to make things move faster yeah I mean I guess yeah something that could be helpful here is like do people have a sense of like how long implementation would take given the changes today um you know is it

something you feel like you could turn around in the next week or is it maybe going to take a little bit longer

Barnabas Busa: I mean the config adding the Target and Max to a config should be very simple yes so I think the only thing we waiting for now is the BLS stuff right

Alex Stokes: yeah and there's a few other peers here uh but they're all pretty minor say with 7251 um what else did we talk about yeah and there's this one at the beginning but that's just a renaming a field so yeah I mean it is all somewhat small in

scope um and yeah we're getting a bunch of chat comments that would be pretty quick so do we want to look at the calendar here let's see yeah I don't know do we want to try to launch devnet 5 on the 20th or is that uh unwise

I mean scale changes

Parithosh Jayanthi: yeah I think at the very least we'll get uh local config so whichever clients are ready they can have stuff to test on and we'll have um Hive up so we can see how clients are doing but yeah um if there are enough clients ready I think I'm happy to launch the devet uh

between Christmas and New

Year okay

Alex Stokes: so yeah then let's you know directionally aim for dev5 as soon as it's ready and that's going to be in the next couple weeks um so yeah yeah as like client says marry grind to miss um but that being said I think the sooner we can get this together the sooner we can ship Petra so uh yeah that that would definitely be best and yeah Terrence uh we can update the the spec reflect the the sorry de five spec reflecting his updates after the call cool okay I think that was it on

Petra

uh if

Alex Stokes: there are any other comments uh please raise them but if not then we can turn to a few other things uh I put this here under sort of the the puros bucket uh there's this PR for a Fu spec and the reason this is relevant to the blob stuff is that uh this was essentially the next step for p off St nuts um everyone's very busy with Petra that being said as soon as Spectra is stable then we could think about putting pios on top of it and that means fulu so I think the concrete ask here was just a double check that we can go ahead and move forward with this uh

refactoring anyone opposed to that I I had a comment here on the PR but it looks like you crossed it out um I think this was discussed on either the another peos call or the testing call earlier this week and from what I heard there was you know agreement to move ahead with this so yeah let's go ahead and merge that then uh unless there are any final objections and I'm not hearing them so cool we'll go ahead and do that and nice okay uh there was one last thing uh Tim had an ask to discuss this

PR uh clarifying the relationship between CFI and SFI uh Tim do you want to take it over

yes um I

Tim Beiko: don't have the pr handy but um so actually the idea is to clarify the definitions of CFI and SFI based on the devet development stage um so I think there's two failure modes we run into when we plan these uh hard Forks the first is that um we're not we don't have quite a formal definition of what CFI means and it's hard for different people to uh interpret that they sort of have to read tea leaves a little bit and then the second is we

commit to uh having a bunch of stuff in the fork uh in advance of actually knowing how hard or how much time it'll take to implement it so uh my proposal would be to map CFI and SFI to devet inclusion status where we just formally say that CFI means uh these are things we want to put in the devet for the fork um so it's kind of a clear a clearer signal and it's already sort of implied by it but uh you can think of CFI is the list of anything that we think will be in any of the current work stet um and you know assuming everything goes well there probably on the main net Fork but uh there's always some uncertainty and then I'd make SFI mean the things that

are in the next def net and the the rationale there is that this could help us sort of throttle how many things we bring in at once um whereas with pectra as we saw we like brought in 20 things in the fork early on before most of them were implemented um and one challenge with that is uh not only do we not know how how long things will actually take to implement but then if we have many different things that many different teams have to implement not everyone makes progress on the same thing uh at the same time um and that slows things down overall um so basically we would say you know like in this case SFI would be the things we think will be in devet 5 and if we want to add more things to

that after the fork that's great they can be in CFI but we sort of don't move something up until we feel like in the next devet we can implement it so that's the overall idea uh thanks Alex for sharing the pr in the chat yeah any thoughts comments concerns

Alex Stokes: yeah I mean I think this makes a lot of sense um hecta was uny fork and I think it's in part because of what you were calling out that uh yeah there was maybe not as much structure around having an EIP or some proposal and then thinking about how it goes through the process to get to Dev Nets and yeah my is that this is not meant to add more bureaucracy or so of things down but

more just to give us a little more structure so that it's clear and point being we can all coordinate better around that

Tim Beiko: the one thing you would slow down is like the rate at which we can SFI stuff which I think is a good thing so we if we say we're putting 10 things to SFI we should be saying in the next devet we want to implement those 10 things and if we think that's too much then we have to pick you know which subsets do we actually want to put in the next

stet

Alex Stokes: sure but yeah so there's more discipline but the whole point is to make like it's maybe slower in the short run but it's better in the long run right

yeah

Tim Beiko: yeah that's at least my idea and I'd be curious to hear I know from

like client devs and the people who actually end up implementing this stuff like does this seem reasonable um yeah I guess if there's no comments I'll leave the pr open up for a few more days for people to review and I'll uh merge it by the ne by next week's uh award devs if there's no concerns or

push back yeah works for me thank you okay

Alex Stokes: I think that was everything on the agenda I'll see if uh there are any last minute additions I don't see anything uh yeah anything else otherwise yeah we're all very busy with pectra and we'll close a little bit early and get to shipping okay we got to ship in the chat cool okay well thanks everyone and uh yeah happy holidays and uh Happy pectra I'll see you next time

see

h

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