All Core Devs - Consensus #107

Transcript

foreign [Music] [Applause]

thank you welcome to awkward

Danny Ryan: devs consensus layer

call one zero seven this is Sue 756 in the PM repo okay uh the first agenda item is a bit ceremonial I think that we don't have much to discuss uh the capella Fork was last week and we did have the execution layer call soon after and did a bit of a retro there um just in case there are additional discussion points on capella before we move on now is the time anything else on

Capilla can do

computer okay utahn has a an Al art Speck

Etan Kissling: um it's more about the documentation thing just we displayed the owl on the merchant on the on the capella transition and also displayed whenever someone converts a credential it's just a spec to document the actual Behavior was nice

thank you okay

Danny Ryan: uh yeah vanity art specs take a look if you feel strongly about it uh maybe we can put that in there um okay anything else in Capella before

we close this off okay congratulations

great work okay moving on to deneb um there's a couple discussion points from Tim before we get into uh discussing a few features that are under consideration in addition to 4844 and a couple of engine API points um Tim can you kick it off on you had a link to some potential blockers for the query before devnet 5.

Tim Beiko: yeah so actually that yes there's three things they're just things that came out in the call um so the potential blockers it's not that there was a blocker but we said that we would just check in with the

client teams um today to make sure that if there are any issues as we're trying to stand this up we can bring them up on the call um and then hopefully have the devnet up sometime next week um so yeah I guess if anyone has I guess or I guess you know if anyone can give an update maybe I'm like setting up the

definite and any potential issues you're running to that might be uh um maybe I can speak a bit to this uh Raphael is sitting next to me right now and trying to run off the test not so that

the Lord star and ethereum JS are the two that said they want to be involved in the diagram but if other fans want to please give us your images and we'll add you to the trailer but the current plan is to have devnet 5 next week

Tim Beiko: anyone else have comments or thoughts on that okay um okay and then the next one Mikhail I believe you've put up the pr that was mentioned but it was yeah do you want to

chat about that engine API calls

and to try and get this uh live on the devnets as soon as possible and so if people want to review the specific PR so we can get it merged in the next couple days that would be um that would be ideal um and then the last item from the 444 call Danny was the new payload and reorg stuff um yeah do you want to get some context on that I think Peter is also on the call so yeah I can give quick

Danny Ryan: context and certainly Peter can chime in um yeah so I think what one of the things that came out of mempool discussions at Edelweiss was how to handle and reinsert blob transactions into the mempool upon reorgs

um which is a facility we can provide to users today because all the transactions the full nature of the transaction is in the block uh given the decoupled nature of the blobs um you might only have blobs available to do these reinsertions from what you've seen on the mempool but plenty of things do bypass the mempool so you may not have the blobs um I think the two potential paths here are to have new payload insert the blobs and the consensus layer such that the execution layer can have them and choose to do what they want with them like cache them until finality um or anything like that the alternative is to not provide not be able to provide this quality service to users that

bypass them pool and just leave them payload as is and if you want to handle your transactions only handle what you've seen in the mid pool and can locally do I think this is two paths on that Peter you've been thinking about this a lot

Péter Szilágyi: yeah well sorry I have a sort of thought that it's a bit harder to talk um yeah so uh I guess you kind of summarize it kind of correctly um in my my opinion it's kind of nicer to to provide that service for everybody so if their consensus client has the blobs anyway I mean the blobs aren't that big so uh the the new paid I mean

currently the limit is set to two to four blobs per block so that's a 500 kilobytes I don't think that's such a big overhead as to be prohibitively expensive to just give that to the execution client my two cents would be to just um just send it over and if for some reason we think it's main maybe it is kind of a bit excessive then we can always make it a bit um we could create a ping pong API where you just tell us that hey this block contains these blobs and if I don't have them then I can return some specific error message and then you can reissue

the new payload it gets a bit messy so I I will try to keep it simple first and if for whatever reason isn't sufficient maybe then complicated so and the exit so um the whole overhead of execution clients maintaining these blobs until finalities pretty much insignificant so yeah the only thing you need to do is maybe create either in memory or on disk just a small key value store where you map block numbers to blobs and then if there's a reord you just resurrect

the blouse back into your buff pool if there's a finality event you just delete everything that's below some threshold there might be some very very weird quirks or even that um sorry some of the execution layer block numbers might not correspond to the finality so I mean in a very very weird situation can happen that you have New Yorks with Vera in depth and finality belonging to varying block numbers but I think protecting against that kind of weird behavior isn't really relevant

so I mean we don't really expect reworks to happen at all and if they happen and we can handle requests for it that's fine if something really wonky happens and we lose to block transactions then yeah they can just resubmit it so my my two senses uh the simplest solution would be for consensus clients to give the blobs to execution clients when essentially when they send a new payload and even now the new payload you can't really say that this would maybe make it a lot more expensive because the the maximum permitted transaction size in a in a block in a new payload can be quite significant even now so it's not

like uh we all of a sudden permit some wild big numbers to be passed there anyway it's a bit random what kind of those are my thoughts

yeah

Danny Ryan: yeah and I think there's probably two primary counter arguments one would be the and I know we've hashed these out before one is this just kind of further breaks the abstraction between these two layers uh from so from kind of like an abstraction cleanliness standpoint maybe not to go down that path the other one is more future looking is that a on average a consensus layer node in the event of data availability sampling wouldn't actually have all the

blobs um and would have sampled and might have a subset and so we're then creating a facility and maybe a user expectation that is not coherent with what we believe to be our most likely future um and I know we can push back on that and say I don't want to design for what we think is going to happen in two years um but that's that's definitely the primary counter here

but

Péter Szilágyi: there's uh maybe so I have no idea what the what that future will bring but the quick question uh is this so this whole data available is something is this relevant for the

next executable block so so is the expectation that in the future consensus clients will not even have the blobs for the block just produced by the network

Danny Ryan: correct yes the network as a whole has the blocks as has all of the blobs whereas individual pull nodes Super Bowl nodes people that want to download them certainly will uh but it's more distributed across the P2P and you've sampled to prove to yourself that they're available but not have all of them

Péter Szilágyi: that's kind of interesting however

um I so currently the the expected flow apart from Mev bundles is that essentially the transactions including the blobs kind of originate from the execution layer my guess is that the general expectation is that most blobs will Traverse your machine because they will pop into your executables

Danny Ryan: um yeah I mean in in such a design um if you build locally you're likely building smaller than the potential maximum blobs and otherwise you're asking higher powered specialized nodes that you pay to package blobs

um you know if you move into a regime in which you have 10 megabyte or 20 megabyte um total blobs then the average node is not going to be touching them all that's I mean it that is the in theory the design of extending data availability beyond the capacity of a single full node or a consumer machine is that you have to bypass touching all the blobs on the normal case

Péter Szilágyi: I see yeah so my my gut response to that would be that uh maybe we should try to cross

that bridge when we get there so if we if we want to allow that to happen then my guess is that it would require a bit of redesigns on the Block pools too and on on the so we would need to change the expectations on what happens with these blobs over the network in general across entire network so I don't think it would be too big of an expectation to say that okay Until Now it worked like this from now on it will work like that

Danny Ryan: a crazy thing to make such a shift I just

designing the apis such that we don't even have to necessarily think about components of that shift would be nice in my opinion but this is not like a major sticking point I don't think I I would like to hear if other people have opinions about the API and about this you know handling

reords sort

Gajinder Singh: of discussing this in the uh data Channel and uh so one of the points was that uh since the transactions that

will sort of bypass mempool will most likely be Mev transactions which are directed at a particular State uh so so they won't actually actually be in mind they won't mind being dropped if there is a reorg because that state won't be valid for them another thing that Mikhail product was that uh uh so in in case of if CLS wants to optimize and wants to sort of send our uh sendover transactions new payloads to uh evaluate even before they get all the blobs uh so to do some sort of a parallel optimization uh even in that case uh this assumption breaks down that the cl

will be able to pass all the blobs to the El I think it is very it would be very clean uh if basically we make the assumption that the blobs that bypass that block transactions that bypass the mempool they won't be included in the

the

Danny Ryan: other strong thoughts or hands on this I do

think that the execution layer folks who are not vastly represented on this call might have more to say

Péter Szilágyi: in general it's um it feels a bit uh a bit strange to have this use case where certain transactions that can appear in blocks cannot be Resurrected so that's definitely what would be a new behavior on on ethereum Mana since that currently the expectation is that if your transaction was included in a block then okay you if a reorg happens there's always a very slight chance that it gets

lost for whatever reason but in general or you can rely on the transactions not getting lost now with regard to Mev saying that well if if you submitted your transaction via Mev that you then you don't really mind if it gets lost on a New York uh that seems like a double-edged sword I mean I I don't really want to prom so I think if you submit a transaction and and maybe where you try to take advantage of a situation and then the situation changes and you the network even helps you undo so that you don't have to pay your initial fees that seems like a bad thing it's just

I know

it doesn't

Dankrad Feist: so I mean I I want to push back on that I think in reality as long as your transaction is economically valuable which basically just means it has a tip like um even if like normal nodes don't push it back on the Chain someone will right even if it's just for Mev like they like there's an incentive to Simply like say as a block Builder to take that transaction if it was reorked and put it in my blob in my blog sorry so it I think it will still happen there's no reason why it shouldn't happen like people are definitely sophisticated enough to do that now

Péter Szilágyi: yeah but then it means that essentially

people are running a custom build or custom flag which just forces these blobs back into the execution layer will actually have the potential for more fees so essentially again we as essentially with designing by we're creating a mechanism by Design where it's it's Mev potent it's worthwhile custom code versus the stock code because the stock code by Design discards the data it could not discard and or retain

right

Dankrad Feist: but I mean like I I feel like we're talking about very minute amounts like that that already exists right like that that discrepancy is already pretty huge due to existing

me be on chain and now you're saying in the case where like someone relax a Blog then in that in those rare cases like you can make a little bit more money by including that pop transaction I my my bet would be that this is less than 0.1 or so of

Meb

Danny Ryan: yeah I I guess where I stand is the by making type transaction three be very specific and not even be able to carry non -zero blobs you know we've tuned this and tailored this to a highly sophisticated user at least an expectation uh roll-up operators and so these highly of these highly

sophisticated users are bypassing the pool they're also probably sophisticated enough to resend and and with their transactions in I think one thing that uh gojinder mentioned was uh Mev transactions um often are tailored to a particular State meaning you know they're sophisticated enough that they have or should uh have particular slots that they can be executed and they might have particular conditionals on upon state in which otherwise they would fail um and so these transactions um often replayed in other contexts do throw

Péter Szilágyi: but they do need to pay the block fees

so essentially once it gets propagated through the network the idea is that once you uh you cast the network to Bear the bandwidth requirements of getting your transaction all over the place you should actually be more or less forced to cover those costs

Danny Ryan: yeah which I get especially in the mempool um you know because the mempool even by like you can put that cost without uh ever getting into consensus if things are tuned poorly um whereas in this reorg situation uh you did put the class but you put the costs in the context of blocks which were reorged which in the normal case don't and so

all right I think the argument's a little bit less strong than if you actually were in the

mid pool

Péter Szilágyi: I mean um you're still broadcasting or propagating that block through the entire network at least in the current design so you're still

yeah

Danny Ryan: but if it's picked up in a reorgan another Block it's going to be broadcast again so it doesn't matter what was picked up in that reorg because it it's going to represent blob load

Péter Szilágyi: yeah but if it gets lost then you just broadcast it for free anyway yeah it's kind of very subtle so it's not like

yeah I know um I kind of as I think about it if I I guess it's kind of um if the generally the general long term direction is to is to try to only have a sample of these I don't know maybe in that world it might make sense to do this limitation now I don't have to think about it

Danny Ryan: yeah why don't you shoot on this week and we'll also ask the Executioner folks to consider this and we can try to make a decision on the

execution layer call in one week time

reasonable

Danny Ryan: cool thank you Peter for joining us um any other just final comments in this before we move on we have a pretty packed schedule today great um Kim do we cover everything in your the devnet of potential blockers

Tim Beiko: yeah that's all the stuff that was from the

foreign

Danny Ryan: great so I want to spend some time um at least looking at some of the features that are sitting in the future

directories on the consensus layer specs that could be uh under discussion for danab or at least we can start figuring out if not deneb um where they fit in the priorities for potential future quirks um my feeling uh is that there might be room for one or two small things that are not cross-layer other than maybe four seven eight eight but that the opportunity for additional cross layer things beyond that is probably low and for example like the uh deposit in protocol deposit processing

um but let's take a look at some of these uh so 4788 is cross layer that is beacon block route into the evm and that was discussed on the execution layer call last week I do not believe the decision was made but Alex can you give us uh the quick on that and then an opportunity for people to signal if this is um you know coherent and simple and fine enough to get into the neb assuming that El also agrees

Alex Stokes: sure yeah uh so at a high level the idea is we want to expose some cryptographic

accumulator from the consistence layer into the execution layer so this could be like a state route or a block route the way the feature is written now is passing the previous block route into you know the current block which is then just you know passed along to the evm uh where it's exposed there so if you want to look at the El details you can look at the EIP otherwise this feature is pretty lightweight at the consensus layer basically you just need to get the block route and then you send it through the engine API

Danny Ryan: cool and just is the general appealing on the

execution layer call it this is has a High chance of inclusion or is this on the contentious Zone on the execution are very unsure

Alex Stokes: so it's super valuable for staking pools and many other use cases uh for the CL it's like I think a pretty lightweight lift you really just have to send over this route and uh maybe like one slot number but that's it

Danny Ryan: I guess assuming there's an appetite for

the complexity of the springs in the El um does anyone strongly against uh the additional overhead this is going to take to get in in addition to 4844 which is our primary cool yeah this is about as simple of an EIP that can exist on the consensus player um okay so let's continue the conversation on the execution layer with respect to this one um and we would if there's a green light over there we'll do a Sandy check again

on this side but generally a good feeling here

um dap lion did write a consensus layer spec and we associated with a new EIP eip6914 to reuse indices on the full Suite um this we brought up a couple a call ago and asked if anyone can take additional look in here it seems like there's some design discussion points that we can still have and should have um but I wanted to get a feel for a lot of this the intention here is to you know reduce the unbounded growth of the validator imbalances lists uh I

wanted to get a feel for whether this is urgent whether this is something we should consider a couple of forks later like does anybody have strong opinions about if and where this should be placed and when we should take on this complexity if we do

Alex Stokes: I personally would rather see 48 4844 just like ship days up and it seems like this thing is complex enough that it would delay that maybe not but that's just kind of my feeling so in that case you know I think this is something that's promising and we can keep developing it uh but yeah I don't really see it going to the next hard Fork myself

Danny Ryan: yeah we'll say there were enough

discussion points on the original PR you know it doesn't feel like we can click the button today that this would be multiple you know at least a couple if not three four weeks of discussion and back and forth and refinement to get it to a good place um so under that lens it also I think that reinforces your opinion but do others have opinions here I guess in the abstract like does do all the consensual clients think that this is this or something like this is um must go in eventually or is this a

just a nice to have even in the long term so by not

commenting

I'm just gonna say that I think we will need something like um but a sort of feel like maybe not in this current Fork

Danny Ryan: we will continue to refine this and continue to have discussions around it but no one thinks that this is pressing

enough to get into the next work correct speak now

Dankrad Feist: um yeah I also want to ask here like is um uh I mean theoretically it should be possible to get the same uh gains by simply forgetting about old validators if they haven't been tattooed for a long time right it's just like is is that just way too complicated to implement in practice or um like

Danny Ryan: so one one issue here is that even if you're fully withdrawn if you make even a 1 8 deposit uh it goes into there and then it would

be part of the

withdrawals

Dankrad Feist: again so that that would be a very like forget yeah not fully I agree but there's like an ancient database of like all validators that you almost never have to touch

yeah

Danny Ryan: and you need to at least know their Pub keys or some sort of mapping there uh for the deposit um yeah I think like one of the arguments is to potentially trade some consensus complexity for the reduction of uh client complexity here you know there are probably management strategies in terms of caching um for State Route calculations there's

probably some management strategies in terms of like shifting things around in and out of memory uh if they're old um to to keep the state the active State size or the active out there State size bound um my my intuition is the same is that it's probably possible to get the gains um through engineering complexity instead of consensus complexity but then that's has to happen five times

Dankrad Feist: well I mean the EIP also has to be implemented five times

Danny Ryan: right right um I guess it's a but it's a complexity Trail and where it goes um this feels simpler but I do not have

good eyes on that but I think that's a very important

Dankrad Feist: yeah I mean that's what I would like to understand why why does this feel simpler because I don't understand to me they are very close with complexity um but like but having less complexes consensus complexity um at the same increase in client complexity it seems strictly better

Danny Ryan: yeah I guess it would depend on the magnitude of complexity if they were equal

Dankrad Feist: yeah exactly

Danny Ryan: I agree um if they're not equal and actually client complexity can lead to consensus

failures you know for example if this historic you know these inactive validators that you kind of like keep out of memory and you know and you you mess up like your your Pub Key hit and then you make a new validator instead of adding a new deposit like that's a consensus failure um and so by having Machinery that you don't even necessarily utilize much um that represents consensus risk as well um on the on the consensus edge cases and those are even hard to these caches and uh I'll abuse that term they're kind of hard to test in consensus tests because creating a state that actually would use the historic

flows and store it caches and test it in not like very stateful manner um it's not obvious on how to do it like our consensus test against the execution Machinery so I I I can't make a full claim I my intuition is that this is simpler than some of the machinery and less error-prone um but I would have to have some engineers speak to that if anybody does anybody have additional discussion points here otherwise um I think this is not going to go into deneb will continue to

refine and certainly have to have the conversation on the complexity trade-off here but can have that a little bit further down the line

um another thing that we do not have a spec for but we would like to presumably would like to do uh it was kind of a follow-on on the historic summaries the creation of the new historic summaries was to backfill on a fork boundary essentially with a static list um to have them be complete from Genesis uh this can happen whenever the sooner

it happens the sooner we can standardize things like epoch uh or era file distribution in a simple way and other things like that um I think yasik's probably one of the main proponents here and is not here and nor do we have a spec yet um but I wanted to get a sense of if this is an urgent item silence means I do not think it is urgent speaking up means I think it's urgent okay I'm gonna Circle back with the odd

stick and see if we can actually just get a pictures back up um so that we can have the conversation but this does not seem urgent okay another item that's sitting in a feature is to not allow slash validators to become a proposer um essentially if you're slash you no longer can attest you still get put into committees but you can't attest uh but there's a bit of a degenerate flow in that if you have a very large slashing um these validators get put into the exit queue but they're still active and they can still be proposers so if you had a 50 slashing you'd actually have a 50 proposal rate at that point

um the get proposer can be modified to not select slash validators this is likely a relatively simple change and it it does have a spec um this is something Mikhail would like to at least open up for consideration for the NAB and if not to highlight it as something valuable to get into the next port sense of urgency in relation to danab um this is again it's like on the simple side of implementation but it is um no protection under you know a pretty high failure mode

any client teams feel like this should be prioritized for the next work

uh this one seems pretty important to me and yeah the diff looks pretty big but the change seems like it should be relatively more simple

Danny Ryan: yeah let me take a look at it why is the diff big oh because it's because getting the proposer within the context of the block because a proposer could be slashed

within the block um you have to get it from the I think the inserted block header I have to take a look at that yeah so essentially the call to get proposer index um because the proser could this depositor could self slash or anyone could be slashed during the execution of the block you can't just repeatedly call get reposer you need to get it from a more static place which is latest block header and so anytime the proposer is gotten in any of these functions those functions are copied over and used you get the proposal from the latest block header instead

um an easy solution is too just forbid self-flashing right

Danny Ryan: no I don't know if it's only self slashing

Dankrad Feist: would it

Danny Ryan: no I no you're right you're right but this is also this is a very this is I would argue an easier solution it's just that it makes the diff look big because all these functions are copied over to use the new git proposer and so get latest block browser index uh is inserted in each of these functions and so it's essentially a single line change that's pretty much not changing the functionality of anything

so I yeah I agree I think Sean the diff looks bigger than the actual because of that and we might be able to get clever and make the diff look smaller

yeah this one seems worth doing to me

Danny Ryan: any other input yeah I agree I'm in favor of it

um Mikhail will

Danny Ryan: will clean this up and

get tests built for it um and maybe keep it in a separate feature Branch uh with tests and in two weeks time we can do the full thumbs up or thumbs down on it's a it's about as simple as you can get because it doesn't even touch the engine API and I personally I think we you know we're gonna always have a few pretty minor things that we want to get in and so it's worth getting an A Minor thing uh great any other items that people want to

Bubble Up for consideration under them there is the atnet revamp although that can happen independent of denev so we will discuss that a bit further down um it's on snc signature format can you make

things

Etan Kissling: sure I mean we we are still looking for the minimal changes to to um end up in this SSC world and right now with um blob TX type having changed to

0x3 technically we have this problem that there used to be this I think Stark net thing where transaction type 3 was used for different kinds of signatures um so having something that makes sure that there can never be a conflict um that the same hash is signed with different meanings depending on the could still be something that should go into the net I mean it's mostly a conceptual thing not an engineering thing to develop one of these I think it was six four ninety three yeah 6493 EIP

don't need to discuss it right now in detail but just keep it in mind

Danny Ryan: this is for transactions specifically

um specifically

Etan Kissling: for the blob transaction type um the rest is already fixed right I mean those are signed the same across all the networks but the blob transaction type because it's based on SSC means that the chain ID is serialized at the different offset So in theory um if there is an rlp transaction that materializes the chain idea doc said zero I think or or offset one and then there is the SSC type that serializes it

at a different Offset you could craft the message that is valid in both schemes and maybe trick someone into signing it I'm not sure if this is possible for the blob transaction type but it should not even be necessary to think about it with a proper signature scheme

Danny Ryan: does this affect the consensus layer or if this is adopted on the execution layers end up being opaque to the consensus

player

Etan Kissling: this is only execution layer

Danny Ryan: so good for us to be informed about but maybe something that happens on the call next week yeah thanks for bringing that up any

other any comments on that before we

anything else uh discussion points for deneb okay we have uh one engine API another engine API Point brought up by Mikhail this is uh to state the palette payload ID should be unique for each payload attributes instance um I believe there was an edge case

triggered an issue that emerged here does anybody have like the tldr on what drove bringing this into the spec sitting maybe I always had this up for a week um I believe at least some of the parties relevant parties have taken a look um if you are the engine API guy on your team please take a look I think this is

likely to be merged before at the Executioner call in one week's time okay anything else on deneb before we great I had a placeholder from last week for the consideration for an RPC to validate the beacon header to help with certain flows uh is this we wanted to have a bit more thought and

discussion on it between last week or last call and now um is there any update on whether we do want that RPC and whether there's a likelihood of that being specked and put in um I'm in support of it

I think on the last call I said I would write up a spec but I haven't had time yet um I can if other people are similarly in support it seems like something that like at

least a few clients will have to implement and it'd be nice to have a standardized but the other hand is like we're sort of expanding the scope of like what is the beacon API like what sort of things do we support

so yeah

Danny Ryan: yeah and I think the the argument was if this isn't supported then people are going to work clients to support it and if one client supports it then they will become a monoculture in uh some of the building relay I don't think there's been any strong

arguments against other than the the expansion of scope I would recommend we write the spec um and get some final thumbs up from

thanks Sean this is something I've been excited about for a while Adrian age can you speak to pr3312 the atnet revamp and the

I guess a quick on what's going on here uh and how the strategy can be rolled out is this something that we need High coordination on or can it be done iteratively I'm

not sure if age is on the call

Danny Ryan: I see his name he has not spoken or unmuted but I do see his name I don't know can't unmute the motivation is right now uh the atmos

field uh one is honesty based so you add the member of that and that's random admits in relation to the number of validators you're running um it also leaks a lot of information um obviously we make a lot of information in all sorts of ways but reducing information like um and not adding additional information leak is valuable important to further secure validating nodes and the assumption that our subnets are probably much higher density than we necessarily need the what happens here in the atmos revamp is

we take the prid and some that given a constant which is the uh required number of adnets per full node uh gives us as a function of probably the epoch gives us which at nets a peer should be subscribed to the nice thing is if they're not we can call them dishonest and stop listening to them so we get a little bit of like enforcement here where we don't currently um and uh gives us the ability to kind of like tune the density based off of all full nodes it also allows for every full node and I think like half the DHT right now because this

layer does not contribute to adnets so distributes that a bit more across all of nodes I need to take a look I believe that this is specified in a oh hey well Adrian now that you can unmute I believe uh can you tell us about how we can roll this out is this done in a backwards compatible way does this need to be done in a hard Fork Etc

Adrian Manning: yeah so in principle we can just do it I was compatible if everyone agrees that this is something we want to do so uh we can just do it in stage releases as well like lighthouse could release it tomorrow if we wanted to

um I guess mainly it's because it's not enforceable at the moment anyone can kind of subscribe to whatever they like uh ideally yeah we can just um have client teams as they build it just to slowly release it and then the network will slowly shift to kind of the new regime

Danny Ryan: would Lighthouse be downscoring peers that don't do this or would they would you turn that on later

Adrian Manning: yeah you would turn that on after a hard four um because then like once all the client teams have it and all of the you know that all the nodes are on a particular version after a hard Fork then you can start in psoring and changing the way you do Discovery but in the meantime you can just you can just kind of

add up

Danny Ryan: and what's your confidence level and Analysis and whatever that this is going to be you know give us the stability that we need did you all end up running simulations or is it generally pen and paper on density and number of nodes

yeah it's

Adrian Manning: generally pen and paper um so the the main factor is uh the number of nodes sorry the number of subnets you subscribe to node so we're trying to be somewhat conservative by setting into two uh it will mean that like client teams are probably going to have to because it'll be like a started upgrade

as as people upgrade their nodes but client teams will probably have to have higher P accounts and probably monitor a little bit closely how they how they choose their peers to make sure that you have a stable set of subnets save as it appears per subnet but I imagine it's it's tunable and it's not going to destroy the world

Danny Ryan: okay I've generally not heard much dissent on uh moving forward into this strategy and regime is that correct is there anyone that feels like we should not be opening this can of worms we shouldn't be doing this

um are there further discussion points that are not being highlighted on that PR oud okay not that we have the status but let's call it in last call and that we're going to merge this by the next consensus layer call unless there are additional concerns in moving forward

Adrian Manning: yeah it's worth highlighting that it's somewhat controversial as to how it's going to affect the network so if people I guess Doing Network stuff on the

consensus line it's worth having a look if you haven't already and getting yourself in

Danny Ryan: okay anything else on this one

cool thanks age uh for keeping this moving okay we have a discussion point from Guillaume on the verge specification around the usage of a number field Json om yep

Guillaume Ballet: uh right yes so exactly

um in the in the spec for uh for the Verge like when we put the the proofs in the blocks um there's basically a structure that that is very nested with a lot of arrays and the same structure is repeated over and over again and uh like this structure that is repeated is basically just representing a diff so it says this last byte which is the suffix of the key is uh used to be this value before and now it's this value and uh because this value this type of structure is repeated a lot in the in the structure it feels a bit

wasteful to encode it as a string and from what I understand currently in the in the CL specs everything is supposed to every number is supposed to be encoded as a hex string and I understand the origin of this uh of this requirement was that there is some js library that does not handle uh sorry some uh yeah exactly some some GIS Library does not handle like big numbers but this is a byte so it will always be a value between 0 and 255 and I don't know it felt a bit wasteful so I wanted to know if there was a possibility to to change

um the specs so that uh only only large value our values are encoded as strings but smaller values that are always bytes could be encoded as numbers

pretending

Danny Ryan: the Kyle would probably have the most input here he did say we can use Json integer type of this field implementation complexity should be trivial and I can't remember the exact history of uh the libraries that were causing the issues here what are what are a couple examples of the number fields that we're putting in

HEX that are a bit strange right now like all of the base fee and that kind of stuff

Guillaume Ballet: uh so I um from when I understood that came from a discussion with Mac uh my understanding is that everything should be uh in the current spec everything should be uh should be encoded as a as a headstring and so um yeah that's true of uh that's true of every of the of the base fee for example but uh yeah even smaller numbers should they should exist like the like the the block number that could perfectly fit in an integer uh is also included as a hex string

Danny Ryan: is that

the case because I I'm looking at the like execution payload V1 under the specs and I'm seeing things labeled as quantity what is that type

I mean yeah does

Danny Ryan: anybody have

the familiarity with how quantity is encoded and that's a that's like a Json common Json type that we're leveraging there not something we made up

Guillaume Ballet: no it's a string

Danny Ryan: yeah but I meant the the parsing and

encoding and definition of that string is a common like um I don't have a strong opinion here I I would imagine if you make the the pr to the engine API would get a bit more discussion um I also I guess during just to point out like this API is you know optimizing a byte or optimizing a number of bytes is probably not going to like make or break this other than just like the aesthetic nature of what we wanted out of it right

because this isn't doesn't broadcast the network this isn't like something that

um we're going to get a lot of optimizing bites down right agreed here it's mostly

Guillaume Ballet: uh it's mostly cosmetic there's there's I mean it also depends how the underlying OS you know what like if you start feeling buffer sizes you get more I mean it's it's not gonna make things way slower for sure and noticeably slower even I'm just uh yeah it's just a feeling that this is wasteful uh just to build an uh I was looking uh block number so if you say it's a quantity it is included as a string so yeah just wanted to right I just I just checked um no yeah okay I'll create the pr then

and uh yeah see and see if there's some pushback um yeah if no one else has anything to say uh that's enough for me thanks

Danny Ryan: yeah anything else in that um okay yeah so that is the end of the agenda are there any other discussion points or closing remarks for today yeah and thanks uh Mario for linking

directly the the encoding I didn't see that initially okay cool um good call appreciate your coming uh good luck on devnet5 and talk to you all very soon

take care thanks bye bye

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