All Core Devs - Consensus #102

Transcript

foreign [Music] [Music] foreign [Music] [Music]

[Music] foreign [Music] [Applause] [Music] foreign

[Music] foreign

[Music] [Music] [Music] thank you [Music] foreign

[Music] [Music] [Music] foreign [Music] [Music]

foreign [Music] [Music] foreign [Music]

foreign [Music] [Music] foreign [Music] foreign

I'm on two hello Danny

Danny Ryan: you can hear me

okay yes

George Kadianakis: yes

Danny Ryan: could you not hear me when I kicked off the call like a minute ago no

yeah I just joined could not

Danny Ryan: I'm sorry we're taking off the call can somebody give us an update as to the uh current

Chappelle test Nets

Barnabas Busa: yes sure um so we just uh had two days ago the fork on uh to Chong testnet and

we would like we had a great success I feel like we managed to pull everything off uh we didn't encounter any issues actually

so great did we send that blocks and things

Marius van der Wijden: no we didn't um I don't think we should on on this public test net um but one issue that we found is uh some get nodes syncing up would encounter a bad block and um no the issue is most likely that some

client is not RP encoding the block correctly and um so we we most likely we're not 100 sure um most likely we get a block from the network that is not encoded correctly uh we decode it and um then at some point we we error because instead of the withdrawals being an empty list it is nil and so our encoding and decoding is correct we we checked that um and so yeah I would encourage all other execution layer clients to also make

sure or create a test that they encode and decode withdrawals uh correctly

Barnabas Busa: this did not happen when you were thinking from Genesis right

Łukasz Rozmej: um yes like it it can happen if you think from Genesis it's dependent on the peer that gives you a block the block like the peer might give you the block um in like in a wrong profit um basically and uh so uh yeah it really depends on the peer this block is correct or not

and usually we would we would uh like discard these blocks in an earlier stage um but uh because it is a valid RP encoding it's just the wrong RP encoding we only find this when when trying to execute

the block foreign but can you maybe like uh log disappear when this happens especially um it's not work

Łukasz Rozmej: yeah well the problem is that it's it's very unreliable because it only happens on uh on MP on blocks with empty withdrawals which is

only the first one I think because now we have this uh the withdrawal credential set um I can I can try to um I couldn't try to do more things and see if if actually like like there's a there's a lot of things that have to go right for for us to notice this right uh we have to think this specific block from this specific from one peer that like um that has this book and so yeah I can try

it's like another block

Danny Ryan: you could presumably just ask for that block from a bunch of peers but people could also just look at their code

Łukasz Rozmej: yes I think everyone just should should

create some unit

test for it

Barnabas Busa: I can also just spin up a new network uh where we don't do any BS changes and then this would be a very small knife but we would be able to test this

you did

Łukasz Rozmej: yeah and now I think in the end we we would uh we will probably be able to reproduce this with a with a hive test um uh with the hive sync tests but um yeah we don't have those yet for post uh post Shanghai

I think

Danny Ryan: okay thank you Marius uh yeah I mean

even if we find it in a test that this should definitely land upstream and you know tests so please take a look anything else on this

test nut ter

Barnabas Busa: we haven't done too many business changes on uh to allow different users to test their neutrals and Bs changes so I don't even intend to do any more of them so if we need to do more BS changes I would advise to just spin up devnet seven I think where we can do some more of that

but I'm just curious if anyone has Stillness to do some bills change testing

foreign [Music] devnet7

Danny Ryan: to do BLS change testing or hopefully hit that sufficiently another nuts my God is that people are pretty comfortable with that at this point okay um someone raised a relayer builder testing

um I believe this has not yet been tested on any of the devnets nor on the current test net does anybody know the status of being able to test these

basic flows

Barnabas Busa: I have tried to reach out to flashbacks regarding trying to get someone on board on to this new testament that we are running but I have heard nothing back

all right

Terence Tsao: Alex's latest update he said that he had implementation from Mev booths that's Capel already so if anyone wants to test they can ping him but I think the block right here is just to have a capable

relayer and Builder that is what's missing today so yeah the sooner we can get through that the better

ready to test the Builder changes this is

Barnabas Busa: something we should be testing on separia only or should we bring it to the public

Tesla that you just launched you mean XI Jing or another one

Barnabas Busa: yeah that one

Alex Stokes: I mean yeah the plan is to test on XI Jang if uh you know if things are ready in time if we [ __ ] supplier

then we may as well just test there but yeah that being said I know flashlights is working on I'm getting something ready and I think in the next couple days if not next week so pretty soon

protest

Potuz: I think we shouldn't even talk about pork in separia without testing first the Builder

Marius van der Wijden: I disagree

Alex Stokes: yeah I don't think we should really wait because there's no reason to so all clients have a fallback in the event that this metaboose pipeline fails

Danny Ryan: any other inputs on that

um I do think if we're moving toward assuming the order of sepolia orley main net if we're moving into Gourley and haven't had this tested I I think we should certainly be having a conversation um about timelines and and making sure that it gets tested

Dustin Brody: one concern um I would have about not testing this before sepolia um is that there are we have basically two chances before it may not to test um to test the transition the fork transition behavior of this and to the degree that there's anything particularly interesting around that and

there may well be then that's it like we have sepoli and we have a girly and that's it and so it's I think adding that one chance by having um some kind of devnet or some other situation where we can get some sense of of what the Builder and melee are going to do and the different clients they're going to do is useful I I would agree with POTUS on this

Danny Ryan: so at least and what we're about to talk about timelines um the date tossed around is you know 27 28th so we're talking about 20 days

um those that have been working on that boost those have been talking to two flashbots and others is that a reasonable timeline to have this up once pulley is that what the expectation here

Alex Stokes: I think it's hard to say without having people from hot spots here I was just looking I don't see them on the call um but yeah definitely that would be the the intention

Danny Ryan: got it

but without

Barnabas Busa: moving forward with forks I

don't think flashback is going to move forward with development so I I feel like this is something to

me it could be forced

Tim Beiko: right I do think generally like we've not sort of waited on infrastructure providers and mostly because of that reason like the the protocol already moves pretty slowly and so if like we're not the ones to sort of set the pace then the the fork just never makes it to the top of team's priority list um I understand maybe boost is like a bit different than something like say inferior something like that but um yeah I think uh

there is sort of a risk if if we start sort of moving your timelines based on uh everyone in the ecosystem being ready uh that will sort of be be blocked by by the

Solace once photos

Potuz: so the way testing works is uh so we're gonna go without having ever tested a builder uh and 95 of our blocks go through Builders currently so we have a couple of stages that that will save us uh the first one is that if there is a bug and the bug is in the Builder not in the relayer then we're just going to fall back to local

execution this is not really being tested at all either then there is if the there's more serious bugs and blocks start missing because the the bug is in the relayer which again hasn't been tested then we're going to call back on using uh using this uh this check that if certain number of plots are missing we're going to fall back to local execution but this also hasn't been tested so we have like an entire system an entire work which is hanging on completely untested software I don't feel comfortable at all signing off my own clients my own work on something that I haven't tested

Danny Ryan: um I hear you is there a reasonable way

to test those flows on our chestnuts um because I think that's ultimately what this group can be responsible for um and I think given a map boosts implementation uh we can very likely hit both of those right

Potuz: I think it's very easy for us to agree not to support Med boost at the park for a while and just ship at at a later date a fix when the Builder is actually tested we can agree now that every client is not going to support map booster at the fork and fine if if there is a pool that actually wants to Fork

our clients and risk it so

bit

Tim Beiko: and what does it mean to not support nav boost is it um yeah I'm curious how you would

do for example

Potuz: execution right so we can easily Forge local execution on acapella block

Tim Beiko: okay so not even just being a because you could imagine a softer version of this where you just put like a big warning right like or you just say in the docs or whatnot like you know this is untested with mephus run it at your own risk but you're saying you go a step four beyond that where uh the the default code paths are turned off is

that right

Potuz: I'm saying that the only two reasonable things in my mind are either waiting until this is tested and then delay in the fork until we actually have tested this or just disable map boost support disable any non-local execution on the CL clients until this is tested

Sean Anderson: uh so I mean it's off by default and I I think that we shouldn't have the timeline be defined by external like infrastructure um and we can test as much as we can test which is specifically like the consensus client interaction with MAV boost slash

the relay because we can make like fake relays but we like I I don't think we can just wait for a relay implementation to appear

oh

Danny Ryan: there's definitely some comments in the chat worth servicing I think people are worried about the precedent of uh getting hung up on infrastructure providers I think it's also uh people would be deciding between the profits that they are seeking or not having those versus running non-canonical Forks um also those large infrastructure providers are large staking providers are going to

have private nav deals regardless or run for clients regardless so then you get the highest symmetries between those types of providers and home stickers um are there any other comments people want to service from the chat or on this in general

Alex Stokes: one thing I can add is uh around the merge we started work on some kurtosis tests to test the fallback in like an automated way um that's something we could definitely stand back up and run from Kabbalah do you think it makes sense to do what is you know is within our control and then separately you know watch lots

however others timelines are their own timelines

Danny Ryan: right and and we aren't just I think that's important we're not just talking about flashbots there's a whole ecosystem of people that run relayers and Builders um that are highly incentivized to to do this even if not on our timeline

Tim Beiko: and also it's worth noting so like say we talked about 14 sepolia late February which is still like 20 days from now uh I don't believe there's any like significant Builder infrastructure set up on that the Builder infrastructure is set up on on Gordy I believe so that means you'd probably have another week or two you know before you forked Gordy assuming zipolio went well so then

you're sort of like at I don't know call it like early mid-march um which is you know over a month from now and then after Gordy you'd probably I you know I think Gordy is what you'd want to see hopefully something like any of you boost be ready and and relay implementations be sort of ready to support it um it doesn't seem like a month is like a insanely short timeline and then even beyond that you would get a couple weeks after Gordy forking you know before the midnight upgrade um so I think basically the the sort of timeline pressure we would be putting on by by moving disability now is something like in the next month you know

ibv boost uh nav boost uh you know software providers would need to like be ready and I yeah it seems kind of different to say that than say like oh a week from now they should be ready

Danny Ryan: um so it seems like we could potentially test backup loads and kurtosis we could potentially test backup flows in um Hive although I don't know if my Boost is integrated and I have at all right now um and we could potentially test them on a transient devnet do we have

the resources to do so I know that we don't we wouldn't be testing necessarily the flashbots relay at that point but um we can certainly Sandy check that these code pads that we care about work

Alex Stokes: yeah and it's worth calling out that you know with this fallback like it almost doesn't matter when other people you know do their thing for example if flash loss doesn't update software in time then like the very first step will fail and you'll fall back to local production and you know the chain will be fine so um it's I think most important to focus on that

Terence Tsao: I guess the concern here is that we haven't even tested the fallback so that

we don't know if the Callback will work at first place

Sean Anderson: we've actually hit it in Lighthouse on a test net in the past but not with any of the current code

[Music]

Alex Stokes: so we can definitely go ahead

Dustin Brody: uh one concern is that from for me is that it's it's not and people are articulating these scenarios where it either just works or it doesn't work and my concern is sort of the broad Middle Ground where it's kind of glitchy it's technically there all the clients well okay maybe not um produce here but but like most most

of the clients maybe claim to support it um flash plus payments to support it but it's basically just not been tested all that well and and then it's if nothing else setting this expectation of will the fallbacks be expected um there will be a lot of support requests I think in that case of people expecting it to work um but it's not experiencing it not working um for any number of reasons so either so so this is my concern not just that that it will not work or it will work even if the fallbacks work as designed as in theory they they should um then I think there's a downside risk um on for the

Sea House

Alex Stokes: right so I think to mitigate that risk we want to do like a stage roll out so like you know let's say that none of this stuff is ready in time for like chappella then like we basically are using the fallbacks and then each ranking team can decide like once they feel comfortable then you know basically add support for the new thing

Dustin Brody: sure that that's that's one approach

Danny Ryan: okay I think importantly um it would be really valuable to to test these fallbacks in a more automated

way or at least in a in a Dev net [Music] um does anybody have a vision for how to do that or do we need to take this to um an issue

so

Alex Stokes: does anyone know what the status of like Hive would be I think we feel pretty comfortable with working with hives otherwise um yeah I can work on the curtosis stuff

Mario Vega: hi greatly there is no support for any Meb boost related stuff in half we need to rework Hive in order to be able to test anything

Alex Stokes: what does rework mean just like

is that involved like invasive changes or just like adding support further new piece

Mario Vega: I don't really know how much of a change it is but it's not um it's not something that we instantiate the clients currently with so at least the configuration and all that should be changing in fact [Music] um but you have to know how much people deep of a change it is I need to take a look

Alex Stokes: okay I mean I think most of what we'd need to do has already been done in kurtosis so I'll start there and I'll Circle back around with you

Danny Ryan: okay and Perry says Barnabas and I can work on a

transient test night we can set up a mock relay and then boost on and up nodes we can disable the mock related test the fallback um so that that will test the secondary fallback which is when uh or no that'll test the primary fallback but it won't test the like fallback in which the relay sends a bid and then does not send the um full block nonetheless I think with tests

well there's no fall back there anyways right

Danny Ryan: that's the uh if I don't see an enough blocks on chain I stop using that boost so that that is

there's a call back here

Sean Anderson: yeah well we could we could also test those scenarios

on a transient test net though because we could just like

all

Danny Ryan: right we could just turn off blocks uh validators okay okay um Perry Barnabas Let's uh make a plan outside of this to test those fallbacks um simultaneously let's hopefully get Alex's map boosts in some sort of testing tested form and we can dig into hype support as well um my gut is to not currently halt sepolia but to paralyze a lot of these

testing efforts and continue to assess over the next couple of weeks

Barnabas Busa: I think personally that Mev should not affect at all Shanghai

time [Music]

Danny Ryan: yeah and I believe there's an they're certainly contingent large contingent here that that agrees um I do think that we can do a lot more diligence on on testing what we're in control of though okay anything else on build a relay a boost okay the uh next item which we've been

partially discussing is probably of work date on the executionary call last week there was a general agreement if the current test net went well to pick a sepolia work date um I've seen discussions of end of February so that's something like the 28th to put it on a Tuesday that's about 20 days from now let's open it up for comments on potential dates or rejections of readiness

Tim Beiko: maybe just one thing there if we Fork on

the let's call it the 28th I think it would be great to have the blog post out on like you know the 20th maybe the 21st and so that means ideally we get client releases out like next Friday or the Monday after that like I don't so just to put it in perspective for Crime teams

Danny Ryan: right so week lead time in sepolio which is a gated validator set is probably correct but that becomes you know a week and a half release lead time foreign Tuesday because of our

biases when we testing proof of work works we wanted to make sure it didn't accidentally land on the weekend but a um Monday Fork is actually fine because we can well time it so Barnabas did say about the 27th at 2 pm UTC which is epoch 56700

Tim Beiko: one thing that's nice with the Tuesday is people who forget to have the Monday like we can kind of make a Last Call on the Monday for people like infrastructure providers and whatnot that like the forecast tomorrow so I have a slight preference for Tuesday but not a hill I would die on

sepula

Danny Ryan: is a closed validator Set uh but

it's also they are humans and we've seen issues

with work I'm the human

Danny Ryan: did you say I'm not a human yeah um okay I think the I think a Tuesday date given people waking up on Monday and saying oh [ __ ] and doing their work um accounting for that is probably reasonable here I don't think we gain or lose much in that plus or minus day in that realm um can does anybody

fundamentally opposed to that as we also parallelize our Builder relay fallback testing okay the opposition um we will do this as default but we will circulate this in public all core devs for the next 24 hours before this begins to be announced Etc um for anyone who's not here to speak up but I think we're in pretty good shape to move forward I will say that Paul did

leave a comment he said March 27th and that we're very comfortable moving forward March 27th I think he meant February 27th can anyone from lighthouse comment on that

I also think he meant February 27th

Danny Ryan: okay um great okay um so the 28th uh we can do a we'll look at Adrian's Tool uh it's on symphonius and pick a fork Epoch um and in the next 24 hours we'll kind

of put that up in an issue give you a thumbs up and we'll keep moving okay anything else on chappella for today

Barnabas Busa: any discussion about the early maybe go to timelines or would we want to wait till support is finished

Danny Ryan: I think especially given the um Builder relay testing that we want to achieve that we should um put that more of a discussion point at the end of February

hotels

and

Potuz: actually if if we go with the polia it would be better for us to actually have a date or a density date so that we can include it in today's release or in next week's release so that we don't need to make three releases before

maintenance

Danny Ryan: okay um do others

Potuz: it's fine it's either the same release for girly and maintenance or the same release for simple and girly and I believe that the second option is better for us but I'm not sure if everyone agrees

thank you

Danny Ryan: right so being able to do two instead of

three I given the testing that we want to achieve between now and sepolia I am a bit more comfortable in saying let's pick Gourley and mainnet simultaneously rather than picking sepolia uh with picking gorley was to pull you today but if others feel strongly about trying to pick a sensitive quarterly today I'm I'm okay with that any sentiment on picking Gourley as well

today

Dustin Brody: I think it would be useful to see how sepolia goes first and I don't think there's much to gain from picking Germany today

Danny Ryan: okay um yeah I would like to move forward just to polia with the builder testing in parallel um and when we get near the end of the month have the conversation around um or I guess at the start of the month called the second of March have the conversation around quarterly and may not simultaneously okay

moving on to 4844 I think the biggest item on the consensus layer is the block blog decoupling there is an open PR which I've done some review on yasik wrote um and I will open back up today hopefully others have had a chance to look at it a lot of minor refinement rather than anything major and should be able to get this done out very soon any discussion around that PR any particular items that we want to surface here rather than in the pr itself okay

um that's just no no big surprises in that PR if you've been part of the design discussions up to this point we do have some simulation results Anton has been looking into what coupling versus decoupling does in a simulated environment for gossip sub Anton uh can you maybe share your screen and show us some of these results

Anton Nashatyrev: yeah so uh just a second [Music] yeah so uh yeah this is so basically uh the goblin looks pretty good so uh here

is the uh like dissemination um delay distribution uh for uh do you see my screen

right

Danny Ryan: yes yes and are we looking at uh full-time propagation or average

Anton Nashatyrev: uh yes this is a full-time propagation so uh uh I mean like uh uh uh on the uh vertical axis there is like a number of nodes which uh received uh the message or the couple or all of the coupled message uh in the like in the time slots uh on the uh horizontal axis like it's

uh so uh yeah if you can see that like for the coupled uh this is a this is fully decoupled uh messages which means like a Blog uh blog um 128 kilobytes and four blobs they they all five are disseminated um uh on on their on their own subnets yeah so uh here is like a network of uh one thousand peers uh yeah everyone has uh 100 megabits per seconds per second uh and uh like this is like a

distribution of uh of the message delay so uh the couple looks pretty pretty cool they they are all uh most of them are disseminated within a uh second and two uh and to decouple uh and coupled this kind of uh uh like two two and a half seconds so uh yeah and there are like um more um more simulations uh with networks where like 10 10 of peers have 10 megabits per seconds uh uh others have far higher uh throughput

uh bandwidth um yeah so uh the picture was almost the same here uh right uh on the right side uh there's there there are some peers that receive uh receive a message uh within four seconds but these are the peers which have like this uh floor bandwidth so uh the the uh the peers with low bandwidths uh basically uh um don't influence on the uh on the uh delivery time for uh for high bandwidth

pills um yeah and uh these these are I would like to mention these are for uh for the um aggressive sub with uh with floods uh option off uh and here is a I have another graph which compares [Music] how flat publish uh affects uh like uh the the initial initial uh initial message propagation so yeah so uh off uh when plot publishes off the

the messages will disseminate much faster uh yeah because of uh because of uh if uh Publishers have a good uh a good outbound Channel like over maybe gigabit or even 10 gigabits it shouldn't affect the results uh so yeah that's it

interesting

Danny Ryan: so we're seeing worst we're seeing worse on average on Pub publishing on whereas that's the default correct

Anton Nashatyrev: yeah

Danny Ryan: okay

Mikhail Kalinin: could you please repeat the size of the

blobs or the number of blobs

Anton Nashatyrev: uh sorry this question for me

yeah yeah

Danny Ryan: I think it's 128 kilobyte block and then four 128 kilobyte blobs and they're the coupled is that all being one payload versus decoupled that being five different payloads on five different

subnets

Anton Nashatyrev: yeah right

Mikhail Kalinin: um have you also tried to you know to perform to disable flat publish or blobs only and keep it enabled for blocks

Anton Nashatyrev: uh actually uh at the moment we the plot

published option is like a global parallel topics yeah actually it makes sense to uh probably uh discuss uh to uh this option to be uh to be topic specific so yeah it makes a make may make sense

Danny Ryan: so right now these simulation results are showing better average and uh worst case propagation times on the order of you know 40 or 50 time reduction and are also showing that our current flood publish strategy might need to be Revisited

Anton Nashatyrev: yeah

Danny Ryan: correct

Anton Nashatyrev: yeah

Pawan Dhananjay: also do we Reaper like on the gossip sub layer in the simulation do we republish as soon as we receive receive the message or do we like have some delay for the processing time for the individual blobs and blocks

Anton Nashatyrev: uh yes I had um like 10 milliseconds for validation but it uh doesn't uh affect too much

actually look thank you

Danny Ryan: okay so at least um these simulation results are very

promising uh very I think significantly very promising to continue forward with uh the decoupling spec and implementation um I think pop also has a simulation framework he's been working with so when we do get some decoupled implementations we can also validate some of the results in that environment as well any other questions for Anton or comments on these results great thank you Anton this is uh very

valuable to have at this point really appreciate it okay looking at our agenda um anything else in 444 for discussion today

George Kadianakis: um so on the cryptography side of this uh free The Blob PR um we have uh implemented the uh a verification strategy that would work with the 3D blobs approach such that even the blobs that travel decoupled can get validated if we want um we implemented it in ckcg and got

some initial benchmarks um the the verification is slightly slower than a slightly slower than the old approach with the aggregated proof which was created for that specific purpose but it's not um horrific like like it's not that bad I think given the fact that the the the decouple strategy allows us to get the blobs faster um and uh we are talking about Network latency which is usually much more than cryptographic latency I think the the delay on verification can be

easily excused uh but this is like an initial investigation and we will do more uh as the days go by but uh so that like I don't think it's a it's it's reasonable to dump a bunch of numbers on this call right now but if people are interested in discussing verification times and what we think is too much or what we think is good uh get in touch or ask in the ckcg channel

Danny Ryan: thank you George yeah and with the if we run into a wall there the fallback alternative being to send just the

Aggregate and doing the verification crypto verification at the end so I think either way we're probably going to land in a reasonable spot mm-hmm okay any questions for George great like client what PR is this

Barnabas Busa: this is changing the yeah the transaction sick hash back to Hash

tree root

Marius van der Wijden: yeah any objections to moving this in

and getting this into our specifications for the next

step now well

Etan Kissling: it doesn't work for um for the unsigned hash because there can be collisions with other transaction types like the transaction message it doesn't encode any anywhere that it is a block TX type so if there is another transaction type that that's an additional filter can have a zero value it will have the same hash

Lightclient: but it's a Merkle root so you don't have malleability of the message of the

pre-image

Etan Kissling: Roots have this problem but we can discuss in the appear there is compute signing root for cl as well

great

Danny Ryan: okay um Anton if you can jump in there so that we can have that discussion I appreciate it thank you

okay anything else on board for four uh yeah I um I opened

Sean Anderson: an issue on the beacon apis repo about the apis for signing blobs so generally just looking

for feedback there if anyone's interested LinkedIn the chat

Danny Ryan: right and so specifically this is the validator uh namespace on the beacon API to allow for the decoupling correct right okay great thank you for keeping that moving anything else on 4844 great show away you have a because this is their spec warning

Hsiao-Wei Wang: uh yes so thanks to Paul Harris uh Hey

Google that we had a PR that about with the redeeming of the old boy for for folks then we the new name would be then app and there might be other featuring The them protocol upgrades and so this PR here and oh thanks Danny posted there's PL once this pair is merged it definitely will break like we have the other like 10 open for PRS so I think by default the

big elf aka me I will try to meddle in the past maybe a little bit stand for that new car mix because I I think the I think to fix the renounce uh I mean the foldering in it's easier to use three best than add more commits uh a planned upis so but if I will try to meddling and and the process might be slow and just or if you want to update Europe as soon as possible you can do it by yourself or just ping me and I

will try to prioritize it yes that's the warning here

I'm

Danny Ryan: sorry if you said this when when is this going in

Hsiao-Wei Wang: I can't as soon as possible we can do it today

Danny Ryan: okay so this is going to be in the next release that's the warning

Hsiao-Wei Wang: yes

Danny Ryan: so likely there'll be a release um when we get the decoupled stuff merged and this will certainly be associated with it any questions okay

um Tim has a comment about consensus layer eips and editors

Tim Beiko: yes um okay so we we discussed this a little bit at the interrupt in Austria so um to give some background the idea that like right now uh the El and cl have very different specs processes um you know the CL obviously has the the python spec uh the El used to use uh sort of eip's in the yellow paper we've made a bunch of progress on the technical side on the El to sort of align with what the CL does so we now have a python spec uh that is basically at the main net um and and uh that said you know if we

think eips are still valuable as a way to describe sort of in plain English why it changes being done and and sort of the the high level kind of design decisions um and it would be nice to start having those on the CL side as well so let's say you know there is a change um like I mean the AP 444 is actually an example where we've done this right where there is an EIP that describes sort of the rationale why we have blobs you know some of the risks and then the specs are all kind of in the python spec um but moving to something like that would be quite nice so that you know users and people submitting the IPS just have a single process to use if they want to make a change to ethereum that said

um there's been some reluctance from the CL side to sort of move to the EIP process because uh it's perceived to have a lot of friction um and I think you know that's a fair uh concern so we've been trying to figure out like what's a good way that we could you know softly onboard uh CL folks into the EIP process not sort of uh have them burdened with all of the uh I guess overhead of the processor as as little as possible and uh so we had a meeting with uh EAP editors yesterday and one thing we landed on was the idea of having this designated CL folks uh joined as EIP editors which would give them kind of two things one is obviously like the

ability to just review and approve VIPs for uh CL folks so that I think one of the the the reasons why eips are slow is there's just not a lot of editors and so um you know you sort of have to wait in the queue uh to get reviewed so having somebody on the CL side uh who just like focuses on that can help speed the process up and then the other thing that they could do is um which hopefully you don't have to do too often is basically override like whatever technical checks the bot does on the EIP side um so that you know we could be in a spot where uh cleip sort of get merged even though they don't pass all the say like spec uh compliance checks that happen automatically the EIP repo

um so this would be a way where like you know someone from the CL side can actually Force merge this stuff and then obviously if and when that happens you can sort of reflect on like what was the thing that sort of caused the friction and can read that the process that to like minimize that friction in the future um so the ask is you know if anyone on the CL side is interested to sort of take that on um and again the scope would be just like narrow to like basically Corey IPS and even just like CL eips so you don't have to care about erc's or you know anything else but it's really a way to like enable your colleagues on the cl to like write these VIPs and get them merged in quickly so that

um yeah we can hopefully move towards something that's that's a bit more Unified yep any

figures

Danny Ryan: if you are interested Reach Out directly to Tim

Tim Beiko: yeah

what's the status of the EOC out of eaps so that's still

Tim Beiko: yeah uh still contentious I think yeah so the other theater proposal that we had was to basically split out eips and erc's all together from the repo um there's some technical overhead to do that so like I think you know the eaps

editors don't want to just do it for the sake of doing it which I I can sympathize with um I still think we should do it you know and and like especially as we have more CL folks join like clearly the processes will diverge um but I do think it you know it's easier to First bring somebody from the Seattle have them like start playing around with the process and I think that'll make it clear if and how we want the processes to diverge um yeah and also yeah just make sure that like once we do Fork the repo like I mean like if we're doing it then like we're sure about it and and we're not just incurring all of this technical

debt um and maintenance on both sides yeah there is a threat on its magicians about forking the repos I'll post it in the chat here if people want to engage there

Danny Ryan: any other questions for Tim okay and Tim did threaten if uh we don't get any editors to work on this or people to write the CL eips um then he's just gonna dump our GitHub conversations onto the eips which maybe

it worked okay um and then and oh Mikhail I skipped this um when we were in the capella I apologize I engine API deprecation PR that Mika wants to propose

to go yeah

Mikhail Kalinin: yeah the worst things they need uh so this PR yeah the topic is duplicate and exchange transition configuration which uh I believe every uh everyone is open to do this um because then yeah this this method call is actually useless after the merge and um yeah there are alternatives for for

instance for node operators they can use each chain ID or any other each method exposed in their engine API and points to test that basic endpoint is the life um CEO Quest doesn't need any kind of Bing functionality because they are uh constantly colon puncture is updated and then you pay a lot and of course so yeah I believe that we should deprecate this method and just remove it from from this um from clients um so and I see two potential ways to do this first one is simple and straightforward so we just use the um any uh we just use a hard Fork as a coordination point and uh

we just remove this method support from both sides um the downside of this approach is that if someone just you know um published a release of their clients uh without supporting this method but the um counterpartic line that this not operator is running does not support yet of it does not yet support the removal so there will be warning messages in the logs of one of the clients for some period of time unless the other part is and until the other part is upgraded as well um yeah so that's the only downside but it's simple and it doesn't require any additional um interactions the other way

is to just say that okay so clients will still call this method but if this method does not exist it will not file any error messages and the um El client on the other side will not log any error messages if this method is not called at all uh this this would be the first iteration and we will use the um in this approach we'll use the hard Fork as a coordination point to introduce this first step and then the second step is just that would not require any coordination and clients developers yeah quantums will be able to remove the support of this method whenever they want um so this this actual PR uh proposes the second approach but

um I don't feel that it's his uh will be a big issue with going with the first approach I just want to open this question up for client developers what do they think about the potential approach to deprecate it and the other question is whether there is a capacity to do this in shabella I know that we don't want to make any last changes if they are not related to security upgrades or other other significant things but this one is kind of like a side of like the main block processing stuff aside of uh main client functionality so this is probably okay to to make it into shabella so

yeah what do people think about it

Danny Ryan: I mean we're at the point where we're intending to have releases and eight or nine days uh for sepolia so this is probably on the simpler side of things but I um you know I'm not willing unless people are very very Pro to to kind of force this down at this point

um are there outspoken people for this change anyone very against

um I I'm

Dustin Brody: I'm in general for either option either the options but to happen rather rather sooner than than later I I feel they're quite low risk and this has been useless for a long time

Danny Ryan: thank you um any other comments here

yeah uh I mean given the closeness this is a very tough one to make a call on without uh comment I think by default we shouldn't be adding changes unless there's uh very strong consensus to do so so I I'm gonna default silence to not doing this for the fork um I know Dustin thank you for your your comment um but otherwise if there are not comments I think we should be called to

know

Mikhail Kalinin: yeah I agree with that so it it is okay to wait for another work so should not be a big problem

Danny Ryan: okay please do take a look at

oh I did not see that Mars and Sean um had spoken up so there are people people are pro not necessarily Shanghai Sean might look at Team capacity photos can look at Team capacity so I I guess if if Monday Tuesday all the teams on this PR say let's go you know and that needs um then then we can but I think by default unless we do rally um a bit of support of the next by early next week then we should not do this cool but Mikhail if you want to keep it

moving you can knock on

um no okay yeah

Mikhail Kalinin: yeah of course

Danny Ryan: okay Marius does not do it uh default not do it um unless a bunch of supporters

rallied okay okay

Mikhail Kalinin: so um not do it like meaning in this hard work right

Danny Ryan: correct

Mikhail Kalinin: okay so then let's just postponing to the next one thank you

okay last uh SSD transaction breakout room

Tim Beiko: yes so there's been a lot of conversations uh about how the El should go about ssding the transaction types uh and then it came up yesterday again on 4844 uh on the 444 call uh it's becoming yeah I think having a path forward on that is is becoming uh not quite the blocker yet but like we'll soon be a blogger to like uh yeah work on 444 so um we set up a breakout room next week uh Wednesday 15 UTC to discuss this uh in more detail obviously this is you know mostly in Yale thing but as NCL folks have uh strong opinions about transaction and coding as well

um so if you if you care about this uh this is a time to show up and then hopefully we agree on the path forward uh but yeah we'll see how how that goes

Danny Ryan: okay thank you any other comments or discussion points for today great thank you I'm excited to keep Chappelle moving and uh deciding on the decoupling talk to you all soon take care thank you

thanks everyone thanks bye bye-bye thank you thanks bye [Music] foreign [Music] [Music]

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