All Core Devs - Execution #164

Transcript

foreign [Music] [Applause]

Tim Beiko: welcome everyone to acd164 um we have the folks from the execution specs uh repo that wanted to give a quick presentation on the new testing framework today uh they have to hop off so we'll um we'll start with that uh try to time box it at around 10 minutes and then um we can do some question and conversations about it at the end if we if we need more time um and then after that we'll discuss a bunch of the dencoon stuff and um uh finally the erc's eip's repo split uh at the end um

but just uh damn you're the one

reading this right yeah yeah can you use we can so uh yeah go for it

Danceratopz: okay perfect hello everyone yeah um thanks a lot for the opportunity for us to show um the new execution spec test wrapper um so I'm Dan um I joined the EF testing team uh just in April a couple of months ago working alongside Spencer and Mario and Demetri um who are going to help me with this presentation so the testing team just before we jump to the rapper I mean just to broaden this go up a little bit we you know our aims are really to ensure

that like client implementations for um for features for upcoming political upgrades you know David spec and you know sometimes the spec can be a little bit difficult to interpret on you know maybe not so clear when you actually come to implement it so we also try and provide really a source of Truth for client implementations for teams to meet and just more generally though um we'd really like to help the entire ecosystem improve the development cycle so we really want to help all the client teams like have a faster cycle for their work so the you know I just started April and Spencer start in January so we have a bit more capacity and you know we'd love for you to get in touch and

give us ideas feedback let us know how we can help you and if it's in the scope like that we can scale it in our relatively small team then we're happy to do it okay uh moving on to the repo so uh just a quick background I mean it's a framework in a library that enable the implementation of like test cases for execution clients in Python source code and um like client started the initial development at the end of 2021 um just to explore like the different um approach to to writing test cases for clients and then it didn't like receive initial huge adoption but after discussions in

Devcon people like the idea a lot and test case development started in Earnest like late last year um and the focus being on new tests for uh Shanghai so for the upcoming release and now um we think it's a good time to show you the stuff because um there's been a lot for you for four uh test coverage added to this framework or to this Rebel and there's been a lot of framework improvements and um some new online dock generated which makes it helpful and good to use all right so um most people here will be familiar with ethereum tasks so what's different about this approach with this Repository

so ethereum tests the tests are Implement is yaml and here the test cases are implemented as python code the other difference is the repo itself contains the tooling or the libraries and the framework to to generate fixtures using transition tools and this helps avoid the two-step approach that's used in ethereum tests where some yaml spec gets checked in which is perhaps generated from some source code which is often not available and then from the Amazon spec Json fixtures are generated generally from I think it's retested so and why do we like this approach and I mean basically the main reason is we

have test cases as code I mean from this we have readability um due to the structuring of the repository we have a single step to generate Json fixtures to test clients against um as code the test cases are easily parametrizable with a few lines of code test cases and framework version together which means you'll never have any clash between like different versions it should just work the code is easy to modify the documentation is in line with source code so you can generate beautiful documentation from the test cases and all this makes it a lot of fun to implement tests with you can drop into a debugger check the state of your test

and so on so so we're looking we're focused on the on the big long box in the middle of the execution Spike test so on the right you have a command line using the framework fill and you refill tests and the test cases here on the left the test directory and these use external tooling the evm binary from Geth currently so a quick comment about that is that the transition tool from evm1 should soon be integrated and we'd really love like all client teams to have a transition tool available and we'd be very happy to integrate it in this in this framework if it is

yeah so this using this stuff we also use cell C just to compile some you um and based on this we generate output which are fixtures um Json files which then can be consumed by um the test cases and consumed by clients in Hive or via client executables directly so now we're going to have a quick look at more detail to the test cases themselves so I'll hand over suspenser for an explanation of what kind of tests we have

uh thanks Dan um so yeah so those familiar with ethereum tests will know that we have two test types State tests and blockchain tests and summarize them quickly

State tests are designed to verify the behavior of a single transaction or operation within a block whereas blockchain tests focus on the effects that occur From the Block to block interaction in the ethereum state it's worth highlighting that thanks to Mario we now also have for transition tests and these are a branch of blockchain tests where for example block one and block two could be in Shanghai the block 3 in Cancun highlighting the transition there so all of the test cases so far have auto-generated documentation many thanks to Dan which we're showing off here this example here is probably one of the most basic state test cases that exists

um which simply verifies one plus two but it helps us paint the picture a little clearer so at the top of the test case we specify from what Fork the test is valid from so here we've specified homesteads this enables the test to be filled multiple times for each Fork from and including Homestead we have the pre-state where the first account holds some mule compiled bytecode for a simple s-store of the ad operation a transaction from the test address to the first account which executes the U and then the expected post date with the result of the ad operation in storage so yep one plus two equals three and now the top of the page and we have

um this command line so the python code here can be filled using this command at the top and to the client consumable Json file okay so this is a simple single test case what if we wanted to expand on this and for example easily specify different parameters for the ad operation or even change the op code we're using well with the new framework we can use um Pi test parameterization so this test here is for point point evaluation pre-compiles and specifically for invalid blocks and we have a bunch of cases here

and so this this test case is marked valid from Cancun and as before um we scroll down to the bottom a little bit of the test the test and we have the pre and the post state and an individual transaction but instead of the these being defined inside the test function and they're defined outside the test function as a global Pi test fixture now these allow us to use them within other test functions where the values input into the test functions are entirely dependent on the parameterization of the test so here we can see we're parameterizing by the specific point evaluation vectors and the main idea I want to get across

here is how easy it is to add another test Vector so for this case if anyone here can think of other examples for an invalid pre-compile call all you essentially have to do is add to the list of parameters and specify a descriptive test ID that describes the the new test case added and so yeah super simple and if anyone is interested please feel free to contribute if you want to know more about the specifics of each test from the docs and you can look into the git Source from the link at the top of each dock page so thanks and yeah I'll pass smash you over to Mario

thanks Spencer so yeah over the course of the last couple of months we've been

using this uh this readbook extensively to test the 4844 EIP um and basically the EDM changes to the 4844 so that comprises the block type of detection sections which is the minimal version of the network version and the Beloved hash code the new block headers which are the exosetic acid that is used fields and also the pre-compiled point evaluation that was already highlighted in the example before so I I really want to highlight a great practical example of the efficiency of prioritization in DVM test and this is a recent inspection engine import which is

the the value of its maximum blocks per block count so originally in the 4844 spec the maximum number of blocks was four and was just recently it was updated to six and with this parameterization we were able to Simply update one single line of desk code and the test cases for all the new combinations were automatically generated for us um like I said we did need to prepare extra permutation parameterization code beforehand to account for changes like this and also this type of change at this moment this manual since we're currently from the python test code we do not parse directly from state government but yet this was definitely made the process much quicker at the

time of the change and it's also were mentioned that we can do this from this change over and over again we can just change back to forward or change it up to eight or whatever the spec uh defines and here on on your last view you can see the original uh number of testises with four maximum four blocks and on the right you can see that the the the new test cases so a great thing about the new recommendations that you can go inside the doc and see exactly what we have implemented and exactly all the number of this pieces so in this case we have the blocked on Section test cases as you can see every single test case that was

developed and you can go and and just look at the Easy Digital test case and and just if if there is any um coverage missing or if there is a in particular text ID apology that you feel that it's not tested by this you can definitely we are open to feedback and we can obviously add more test pieces of admin as needed and just to finalize here we have the uh the both the links to the repo and and uh the link to the documentation preview so please feel free to um access this these links and as I already mentioned all the desk is that

that are currently implemented you can see them in this dot preview it's very it's very cool and um if if there's any coverage missing I'll just please feel free to reach out and we will make sure that we include more more test cases so any I think I think that's that's it from us um are there any questions from anyone

Tim Beiko: uh Ruben

okay

yeah I just wanted to ask will there be any pre-generated Json files hosted because I noticed there is a Shanghai Json files are now in ethereum

tests repo right yes definitely so

Mario Vega: definitely we we the current release that we were following it's up to change if uh but basically every release we package all the generated uh Json fixtures and we've actually met another file and we upload that uh next to the release we have two kinds of releases which is the the currently magnet version so we have all the tests for the mainnet for what's in Mainland now and we have the upcoming Fork release so right now uh we only have 4844 but we will we plan to include

all the aps program here so we will have a Cancun release which will contain all the all these files um as for um when the release is coming we are planning to release uh very soon and we are finishing up the change to the framework so when we when this is done we will release uh the new the new framework and we also will release the all the Audi pre-generated fixtures for you

thank you

Tim Beiko: any other questions

hello

yeah

Dimitry Khoklov: hi uh this is Dimitri the former retested developer and I it's really cool to see what you guys are doing with the pie test and um I think it's really cool especially the parameterization part but what I also want to say I would like to deliver the message to client developers to implement the transition to protocols that we are using to generate the test this is a transition tools used both in Python and currently in retested which is still maintained and generate all the tests in ethereum test report and as many clients Implement transition tool we would be able to run the test and generate the tests and

using python for instance and see all this new implementation and new aips because of transition to implementation from a calendar so I really encourage calendars to do that it's not so difficult and yeah I would like to see more more teams joining in the club come on

Tim Beiko: thanks um any final questions comments

Martin Swende: yes I have one comment yes yeah um yeah Mark and sander here there's a comment to what to what Dimitri said so at least in the case of gef the t8n

implementation does not correspond to get execution J10 is written to be correct and it's written to be is used as a backend to for generating tests but it's not as reliable as if that's executor and test Runner as the execution of state test so I I don't think where it should be used to test like get compliance you should not use TA down for that you should use to get State tests that's it it might be the same for other clients I don't know

Tim Beiko: got it

yep

Marius van der Wijden: um I agree but in general it is very

nice if everyone implemented this because then we uh we could start implementing um new tests in a new new eaps and other clients right now it's basically only really possible in gas and and maybe be so um to implement a new feature and fill fill these fixtures so if other clients already also implement the g8n tool um would be really nice too so so we can so like researchers control to type in their favorite language and don't always need to rely on to do it

Tim Beiko: okay any

other comments questions about application tests

Danny Ryan: my phone crash at one point so maybe I missed it but is there the ability to fill with eels

Marius van der Wijden: um they're working on it as far as I know

I got you

Mario Vega: yeah I think I think there's gate and support and as long as they have that weekend we can definitely use them

using the field

Danny Ryan: yeah I mean as most of you know I'm the consensus player yeah we write kind of

the the python specs and simultaneously get to do testing and filling out of that um there are certainly drawbacks but it allows for pretty rapid generational test vectors along with the SPEC Building

Mario Vega: definitely I think I think a different integration is definitely possible um and it's something that we should definitely discuss um it would definitely for example right now we depend on Manual of this as I mentioned for 4844 because uh once the aspect is over here we have to manually go inside and change maybe some one or two parameters for for

the for the destiny of the spec but yeah ideally ideally you should be it should be automatic if we reupdate the ill suspect which you are also somehow consume this update in the in the execution factors and also automatically the updates update the

the desk

Danny Ryan: the other thing is I'd love to talk to you all about the consensus spec test just I think they could use some of they could use some documentation um I'm sure there's a lot of things we clean up so um maybe worth chatting soon

Mario Vega: definitely that is is The Mastermind behind the documentation right now um he

was the one that uh put up all the uh python scripting that was necessary to automatically generate um from from the dark strings of each test case we basically just grab that and then just your

ultimately generated

Danny Ryan: very cool I'll still write the test I promise I just I just want some help to make them pretty

Tim Beiko: cool anything else okay well yeah thanks uh thanks a lot

for the presentation guys um and yeah people can reach you on the RND Discord uh to provide feedback or ask questions okay next up uh we have a bunch of Dan updates um so first uh just a small change to the 4844 pre-copal address Alex opened the pr I don't know if there's any contacts you want to add but um seems pretty

straightforward yeah um yeah

Alex Stokes: yeah I mean I was just looking at pre-compiles for four seven eight eight and uh I just noticed that basically 4844 uh was not tightly packed in the

sense of just you know having the one right after the current glass we compiled about it on marionette uh and this EIP or sorry this PR suggests putting it there

Tim Beiko: I guess does anyone disagree with that then if if not we can have this for the next devnet

the net seven

Marius van der Wijden: uh just as a background it was like uh the Gap was because of the BLS pre-compressed but I agree we should tightly pack them and the BLS pre-compiles and not going to be on mainnet uh um this fox so looks good to me

they

Danny Ryan: probably should uh

simultaneously adjust the BLS pre-compile EIP just so that we don't have conflict if

there's testing on it yes Alex I guess who's going to do it other than me and I'm not sure that like 25 37 is exactly what we'll even go to mainnet eventually so you could even add it at like plus eight or something just get it out of out of the conflicting Zone if you don't know

Alex Stokes: sure

Tim Beiko: Okay so perfect let's make the change on 444 and

then reflect it then uh 20 the BLS EIP as well to not yeah to not have a conflict there um and then Alex you're second PR on 478 you want to give some context on this one

Alex Stokes: yeah uh this one is much more involved than the one we just discussed so we had discussed 4788 as a very quick brief reminder this is taking the beacon block route which is a cryptographic accumulator so you can make proofs about consider State uh taking this route and putting it into the VM

it unlocks a lot of cool applications uh you can go to the EIP to see a little bit more about that and we've had a little back and forth on exactly how to implement this with the API looks like ultimately there's a pre-compile that will expose these roots and the one thing was essentially like yeah what is the API of this free compile look like um just going off of like the data the El has they have like a time stamp and like this route really handy so the question becomes okay um you know do we key the the essentially API to the pre-compile by like the timestamp by The Roots uh it has this work

and there's like some different options here one option is just to write by timestamp but there's not a nice way to basically then bound how much storage this thing uses which generally is nice we don't want this like unbounded thing growing forever so like five ten years from now you know you look at this pre-compiles storage and it's you know gigabytes something like that so anyway point being I made a pass on changing how these things are stored so that uh the storage is bounded uh there's only a certain number that will ever be in the pre-compile of storage and yeah the only

thing that's a little funny uh is basically there's two ring buffers simply because if we only had one ring buffer so if we have a ring buffer then we can bound to storage because basically for every time stamp there's like one sort of slide it goes into the issue there is that if we have a missed slot on the CL or just in the chain broadly then what's going to happen is you basically have like a prior right that would then basically correspond to later time stamp and this could theoretically be used to like you know attack some dap let's say that's like using this so that's no good and the way you get around this is just basically record both the timestamp and the route and one more caveat from there just because you know the storage size of

these things is only 32 bytes and the roots are 32 bytes uh I can like tightly pack them into one storage slot in the in the state and so now there's like two ring buffers so if you look at this there's like quite some change but it's mainly just this complexity around juggling these two ring buffers uh into the evm storage but otherwise it should be pretty clear and yeah I think at this point I mean I'm happy to answer any questions if something wasn't clear but yeah please take a look uh I think this is essentially the best option just based on all the constraints that people have voiced and yeah this looks good we'll merge it and this EIP will pretty much be settled for

Cancun

Danny Ryan: oh yeah it's kind of a funny approach when you first look at it but I do agree given the constraints that it is actually a really solid solution um I guess the other design option could be like instead of two ring buffers have ring buffer where it's you know and and plus or you stagger you you stagger them rather than having them as total separate but this is totally fine I like it

Tim Beiko: any other comments questions okay so yeah folks want to review that

and then assuming there's no issues we can get it merged uh the next couple days okay next up uh Powell just wanted to share I I don't think he's on the call I don't think he could make it but uh there's the M Copy tests that have been merged so I'll put the pr here but if clients want to test against that I mean I see already base you and ethereum JS say that they pass uh they pass the test there I don't know if anyone else had thoughts comments on that okay um and then if not

Mikhail you had a PR for the Cancun uh engine API spec do you want to give some quick context on that

Mikhail Kalinin: yeah um sure so yeah there is a PR open with the specification and there is the um the aim is to merge to get it merged like next Monday for this kind of last call um yeah and what's what's in this specification basically the main thing is blob extension specification and that everyone is very reason the other one is like exchange transition configuration deprecation notice and the most recent thing that was added is the

payload attributes version three and the choice updated version three um this is to accommodate the parent beacon block route and make it into the payroll build process because we need parent beacon block crude because of VIP that because the 4788 so that's basically it and more eyes on it would be great so if you have a look before Monday that'd be great um also yeah really appreciate more approvals on that PR any any questions related to to the Cancun's back of the engine API

did the 4788 changes make it in there are they still I think

Mikhail Kalinin: yeah yeah they are there so

all right

Marius van der Wijden: might be a stupid question but how do we get this timestamp for the parent beacon block can we just take the parent execution

this is a four seven eight eight question

Marius van der Wijden: yes

Alex Stokes: uh well so you don't like you just have the header letter has the timestamp and there's a root and that's all you need to know

so we use the pair the parent the

current timestamps mapping to the prev the caller needs to map those things together I see

Marius van der Wijden: I see okay perfect thank you

Mikhail Kalinin: I know if it should be then by the way because we had Paris and Shanghai before yeah but open to rename it to them connect people are okay with that

Tim Beiko: yeah I don't know if we want to retroactively rename the other ones but it seems like given both sides use it and probably makes more sense but if there's anything that depends on it it's also not a big

deal

Mikhail Kalinin: if we will keep having this kind of like combined names for fork then it probably makes sense yeah and the El is the server yes that's why it is named as it is so why why they form that is on the outside it's really good

Tim Beiko: okay and did you want to talk about the deprecation a bit more I know you had your doc uh yeah

that you shared

Mikhail Kalinin: yeah sure so here is the doc yeah so the The deprecate Exchange transition

configuration gracefully uh we should have a procedure of doing that because if we just drop um yeah because if we just drop the support of this methods in uncoordinated fashion than users Myst regret messages in their logs that this method either not being called for some period of time or it's not exist on the on the L side my CL calls it so yeah I've made this document and the procedure uh looks like really a simple thing so the first step would be El clients should stop logging an error message that if this method hasn't been

called for for some period of time for any period of time and then El should cut all your clients should cut the release on that with this change in the release after that yeah CL uh removing the this method or just stop calling it or entirely removing it from the code base and make release as well and this release should be either the nerve or or um or earlier and after then Kun happens um yeah El clients are free to remove it as well so why why is this uh um like why why this so complicated at the first glance it's not complicated

um if you take like a deeper look into that this is because just yeah we should first break the dependency between CL and DL on making these calls and then we can remove this method so this document yeah has like deep procedure description and also has cables with the stairs of development so this is how it can be done alternatively we can do it in a highly coordinated fashion and say that El client remove this method support and client do the same but this changes all coming only into the nerve release so

strictly into the last release before the fork which I don't think I don't see it as a comfortable solution for everyone but maybe people have different opinions on that and yeah whatever we choose I think that yeah would be great to discuss it here with the Alpine developers and have their agreement on doing this deprecation and doing it in in the exact way as we come to so any questions or suggestions

Marius van der Wijden: just a quick thing from us we already removed this like a long time ago and no one really

same plan

Mikhail Kalinin: so the message you mean right

we only

Marius van der Wijden: we only give a message if um if we don't receive any updates from the picking client doesn't call any method

so and we are working exactly in the same way if we don't get any for Choice any new payloads then we print warning

Mikhail Kalinin: And to clarify Mary's you have removed the message right but the method Handler exists and if CL calls

it yeah okay

Etc

Mikhail Kalinin: oh that's great basically okay if there is no position so I would say that this is the way we do it like remove it from Miel first and can you can you guys Mark uh just make a a green check box on the clients that have already removed the error message I mean like in this document would be really useful so any other yellow client developers

want to chime in on that

you never gonna

Andrew Ashikhmin: we've never printed an error message so um it's already implemented

it's

Tim Beiko: so great

so we have Basu Aragon Gap nethermind and ethereum GX is one that left right if it's um yeah

Tim Beiko: Yeah so basically we can just move this to the CL IP side at this point and yeah that's great

Mikhail Kalinin: okay so let's discuss it on this CL call

next week

then cool of course sweet

Tim Beiko: okay so next up um I guess I'm a traditional space if there's any uh devnet updates that people wanted to talk about uh on this yeah anyone want to give us a overview

of working

Parithosh Jayanthi: yeah I can give a current status so we had to have met six relaunched on Friday um and where we went through a couple of issues it's finalizing again but just with the minor subset of clients so I think the approach we're going to take is wheat for plants to have more stable releases

and relaunch it cleanly with devnet7 I can also incorporate the pr that um yeah Alex brought up earlier today and then make a specialist and share it on the interrupt Channel and maybe one of the client teams can talk about the issues we saw

Marius van der Wijden: so I can talk about the gas issues basically there were a bunch of them um kind of completely rewrote a lot of the code so yeah basically the death nut is kind of not really indicative of our current code anymore um but the current code should be way

better uh one thing that that kind of led to problems with the that we didn't really distinguish between the network or correctly distinguish between the network form and the normal transaction format and so uh there were blocks mined with the transaction in the network format in it so basically like the the block contained the blobs um which is wrong

and didn't get even though gas created to get reject such blocks or accept them

I'm not

Marius van der Wijden: it was It was kind of um all over the place I'm pretty sure some clients accepted them um so there was a lot of going on at some point

all right

Danny Ryan: I mean I just when I hear this kind of stuff I'm like can we catch it earlier in the pipeline obviously black production is kind of a weird one but the uh acceptance of those should certainly be in

her rejection of those should certainly be a test yeah

Marius van der Wijden: the problem was that like a lot of clients didn't really work 100 percent and so like there was a lot of things

going on and it wasn't like okay only the only the guest notes um off now but it was more like the whole network is kind of destroyed um now

Parithosh Jayanthi: and we were kind of relying on ethereum JS to be like the staple boot notes but when we started the transaction faster we then had issues with ethereum JS as well so they were kind of like no stable loans on the network yeah

Marius van der Wijden: so um now it's it's very clear um that this cannot happen anymore on guess and so but yeah it's something that I would really like to uh test out on on another devnet

um and create tests for that that's that's it from my side

it seems very clear devnet7 should be for it before only

Tim Beiko: yeah does any other client want to share their experience or

Justin Florentine: yeah just briefly the the basic challenges mostly revolved around RPC interaction and some formatting

challenges that we had between the CLS and us there was just a couple of ambiguities I don't remember anything specific but they were fairly quickly deduced and

straightened out so nice that's all then Hive tests will continue please

Marius van der Wijden: yes this can be tested by half tests

do you

Mario Vega: mean the uh the block with the network type 3 transaction right

Marius van der Wijden: yes definitely definitely we can

I I think we can add that in the excuse because then we can concern that he had and we should be having a test for that

before the next step like that because it's with some states that are pressed like that so it provides them into a probably it could be a source of such work control uh and this for uh potential startup doesn't so on if it could probably do not make not

uh focuses uh posts is that Network for kids actions Capital Network because uh I still think it's nothing we are not sure that these companies or it is fixed at all and it may appear on the Note 7 as assuming we should I

your mic wasn't great but I think I made up most of that any other oh sorry yeah do you want to add something that I say yeah just uh oh your mic is better now your face yeah quickly that's so the idea is to to confuse that issue is disappeared actually because uh you know you're not sure about what exactly

uh that is uh broken form of transaction uh again we're not still sure that uh resource what is the source of this profit transactions which client send them

Tim Beiko: oh okay yeah

Marius van der Wijden: yeah I'm I'm quite sure that it was yes um yeah we just saw too much weirdness going on for I think for only

guests to be the issue so either other clients accepted those transactions um or it was the other way around that they accepted transactions without blobs like blob transactions without blobs or something so yeah I'm I'm pretty sure we will we will break another definite stuff not seven that's fine because I've exhausted uh this issue

Tim Beiko: okay so yeah I guess devnet7 uh we want

to restart as a 4844 only devnet and potentially just add this small change for the pre-compile address or do we even not want to do that and simply focus on like restarting things as they are and and uh and dealing with the address change after

Marius van der Wijden: I think we should deal with the address change when we Implement all of the Cancun

piece

Tim Beiko: okay so basically keep the same specs as for devnet6 just try to restart it and have it run cleanly

Marius van der Wijden: um yeah so uh what What's really cool is the the Mario created uh Hive test for

for 4844 so uh one thing that would be really nice is if everyone every client could make sure that they are passing those Hive tests we are missing one right now and that's the transaction propagation one um so transaction propagation is still broken a bit um but uh yeah so I would give the devnet another week or something for everyone to to double check with with height that they are passing everything that they do that like that we we don't see these issues um on the devnet for the first time

Mario Vega: I I added the link to the pr uh for this

contest if you need help in anyone getting this help running just let me

Gajinder Singh: yeah I can update a little bit about the 3mgs as well as load store yeah so uh ethereum Jr said an issue where we were not calculating the data gaps used correctly uh so that that was our result early on but uh most that there were no issues in ethereum just apart from the fact that ethereum JS cannot really have cannot really handle the transaction load so when uh the team started fuzzing

and you know put load on it of ethereum JS was not able to cope up so that was primarily the issue with crmjs so uh I think next time when we basically fill uh the network with uh heavy heavy blocks we should make sure that you know their the other El clients can basically support the network before doing this and the second thing about load star also today I will discovered a bug uh in Lords are while syncing uh the blobs which sort of I have uh thanks to techu guys I have sort of figured out the fix

for it and uh but I mean as such load star nodes uh went down because uh we basically wait for a gossip block to see in 32 slots which we didn't see from my debugging at particular points and then they just you know the nodes went down and they never came back up again because then there were some issues that were fixed by Lighthouse guys uh not able to sing from Lighthouse and so so these are some of the issues but I think in the next run of devnet uh seven

with the same spec we should be more stable and hopefully we can have them at it with the extended

data features um Enrico yeah

Enrico Del Fante: yeah I just wanted to add from Seattle side that most of the sync problems as far as I I know was mostly caused by rate limiting uh situation uh so once we start removing great limiting on on Lighthouse and then also on the taco side uh things

was better for the other clients to sync up so I think it will be a CL discussion maybe next week to actually uh start putting some some numbers and agree on um some agreement on about about the the rate limit levels that we want to put

Tim Beiko: anything else on the devnets if not then I guess yeah let's get

devnet7 up with the same spec and we can discuss uh we can discuss this more as well on the 444 call next Monday

Justin Florentine: we have a expected ETA for um seven being up

I think the ETA just wants to hide this agreed good all right thanks anything else

Tim Beiko: um Danny you uh wanted to give a quick

note on the CL

spec

Danny Ryan: hey uh the devnet6 stuff might complicate this but the intention right now is to release ACL spec tomorrow or Monday with the full feature build so that's four for four but also 4788 70 44 and 1745 um yes Tim it is nice that I can just say those numbers instead of trying to say the features so you're right so that's the intention so we'll have full test factors for all of those built but those will not be the target for devnet7 um in so you would use the previous

release for that but hopefully it'll unblock some development on getting the full feature stuff developed if we need to add more 4844 tests or if something is broken and with a change they make a breaking change um which I don't expect at this point we might have to do some sort of like feature branch and special test Vector build for Pure for 4844 that said I think we're willing to take that risk and potential complexity so that we can get the full deneb feature release out because uh I know some people want to get development done and we need to unblock that

obviously this is related to consensus layer folks generally I know there's something all here so if you do have a an issue with that please let us know um and we will do the release and then if there are issues um on the call on Thursday we can discuss them but I think that this is the right path given the things we're juggling

any comment or question yeah

Danny Ryan: okay uh we'll put in the announcements Channel we have a release and test figures for the fully featured

deneb

Tim Beiko: okay and on a similar note so last topic

for today is the proposal of splitting out erc's uh from eips in their repo um we've discussed this a fair bit uh for a long long time um but like client has finally put up a PR which actually proposes it proposes uh or shows what it would look like technically yeah and I guess um just for background like the the main rationale here is like the RC is mostly focused on application layer standards VIPs on protocol layer standards um and you know there might be value in

having both processes be able to evolve separately um we have a bit more EIP editors now so I think we have a bit more bandwidth to actually handle doing the split um and at least some of the current EIP editors would also stay on on the ERC side as well but this would allow for uh yeah having two separate processes so I'll pause here I don't know my time do you want to give some context on the specific PR um if not if anyone has yeah if anyone has comments

or yeah

Lightclient: yeah I could I guess I could just

say quickly you know I think the big question is how will we deal with numbering for these two things and this is still open for debate a little bit I guess but ultimately I think that the best plan is to sort of whenever this migration happens to have some sort of external document that EIP editors look at to see what the latest EIP number available is and just assign that to the ERC and the eip's I know that we talked about maybe like making core eips uh like even numbers and erc's odd numbers but I think that given the number of historical eaps we already have that don't abide by this it's going to add some confusion

so that's like currently what the proposal and the pr is to do with the number and the rest of the information is pretty straightforward if you want to look at the proposal in the pr

Tim Beiko: got it so I guess yeah I'd be curious the first year you know from the client teams does anyone oppose this and I know there's some folks on the EIP editor side who have concerns so like maybe starting with client teams and then we can go to um VIP editors who who are here

Marius van der Wijden: I I think I voiced my opinion on this uh a lot already um I think the EAP process should serve uh the core developers and it's not

right now and one big issue with it is that we have an influx of so many uh erc's that it's not really possible for someone to to stay informed of all the eaps that are coming up and have meaningful reviews on them so I'm very strongly in favor of splitting the two repositories

got it and me what else

Justin Florentine: um this is Justin here um yeah same thing huge agreement just

point of clarity I'm assuming we're not intending on reusing any EIP numbers being recovered is that correct

Lightclient: that's correct

Justin Florentine: fantastic thank you

Tim Beiko: okay so that there's a comment by nevermind as well in the chat yeah Daddy we could argue next year about saving the numbers and I guess I don't know from the CL side does anyone have thoughts now that you've all started using uh this

repo

Alex Stokes: um I'd agree with what Mario said but

just like you know there's just so much going on with having both VIPs and erc's if we can like reduce that at all it's like really helpful for people working on eips um so yeah I definitely support this change and think it's really important to do

Tim Beiko: um okay so there are definitely some opposition on the EAP editor size I don't know if there's anyone here who wants to like share their thoughts or

their View

Gajinder Singh: as well CLM Elder I mean favor of the change but as any IP editor I I want to I want to sort of figure out what is the

harm that would come to the ERC process because of this and I mean would they be at any disadvantage so that is the that there are those are the points that I think I would consider

Greg Colvin: yeah I've there's Greg Colvin here I've been opposed to splitting the repos for years now so I don't I don't want to go into it right now it's Supreme mature decision I'm really glad that my client put this up but I think it was yesterday there'll be a lot more discussion I'm very sensitive to the process having

become too difficult for people to use we do need to fix that but just going we're going to split the repo doesn't necessarily fix anything and I think what we really need is to step back and get a lot more information and consensus from the people using it as to what are the pain points what are the problems if it's just well it's hard to follow a big repo then the answer could be well the repo is really just a file cabinet that we're trying to keep organized it's not the best place to

follow things a better place is the pages that the foundation maintains organized everything's there by category if you want to just check there there's an RSS fee we need to get a mailing list feed any other feeds that we can create that you can follow other pain points are that getting a draft in is a pain we're very Picayune on you know link policies everything has to be spelled right everything everything um I lose track um are these rules too tight what do we need to do to make it easier to get a

draft into the system in the first place and I'm sort of the only OG editor left and from my point of view the process has just gotten uh too rigid it's it's no longer strong suggestions that the editors can exercise some judgment on is to become a set of fixed rules that apparently are chafing people so I just want to start top up up you know up down understand really what the problems are and then we can get to whether this particular technical change actually

answers the problems and helps to answer the problems we don't start from well let's split the Repose create an ERC ghetto and then things will be better we don't know that that's the case and we've been having this argument for so very long but at this point I'm still blocking consensus so that was a long uh alongside tribe and I could go on and on but I already have in many places for a long time so that's all

thanks uh yeah all right oh sorry

yeah I just want to yeah this is Victor

yeah I very much agreeing with uh with Greg um maybe I'm one of the um the so-called ERC EIP editors that even referring to but I really resonate more as a identify more as an author um how many of you in this group uh like the current EIP process if you raise your hand if you if you think if you like it and my question the next question would be how many of you trying to uh are supporting the split of ercnaip anticipating that the process to submit core EIP would be easier raise your hand if you are

supporting because you want to make it easier there's not many but uh that's out of my expectation but how many are you supporting it because you want to make it trickier

Tim Beiko: I don't know how uh possibly will be to get like raise hands responses through this right yeah

right so my argument is that um um it seems to me that the proposal we're saying that once we've split the Ripple this problem will be solved with the for the debt uh or death and if you uh really look into the discussion between uh the editors and of the

proposer actually intended to um do the split and keep the uh the EIP to keep the court uh EIP uh submissions um Steelheart uh while relaxing uh the process for ERC which I'm in favor for ERC side but I still think the core problems that we shouldn't make it's so hard for people to contribute to EIP I heard too pain uh from discussion with Marius one is the the noise from two side that's gonna happen now that we have more different type of core EIP as well so why not split the core and consent answers things like that so

we're trying to solve the problem instead of starting with splitting and my last my last comments if we really need to um split I think the the impact on the ERC side would be that links to erc's are all going to have to to be broken so if we are starting a new repo for the core um I think I will be more in favor rather than removing ERC from this existing repo so I'm curious like how many would you would would be in favor if the direction is to move core EIP is outside of this report that would be my question

Tim Beiko: I am pretty opposed to that I think there's a pretty uh strong understanding in the community that eips tend to refer to core protocol changes if you look at you know people talk about like EIP 4844 EIP 1559 and obviously it's not like a perfect thing whereas but like generally when we say EIP people mean like people understand like consensus changes to the ethereum protocol whereas an erc's has a similar I think connotation the like the broader community of being like an application layer change like people know erc20 or ERC 1155 or whatnot um so regardless of like what happens on

like the GitHub repo level like you could you know you can choose to move the Ripple's already called the IPS so that's why it probably makes sense to keep that for the core consensus stuff but like I think I feel pretty strongly that the whatever is called EIP should refer to consensus changes to the protocol whatever is called erc's is application Level standards and then you know there's a couple categories like interface and whatnot that are you sort of need to figure out but uh at a high level I think this is how the community understands it then you you want to maintain that they're not confuse everybody about the about it

um and uh like

Marius van der Wijden: we are going to like with

this with the split we are going to break some URLs but I think maintaining the core URLs way more important than maintaining the USCS um anyway one one I wanted to respond to um because I think one one thing that you would that you uh that you touched upon was the the Erp process has become too rigid and um I kind of agree uh and I kind of that I think that's the big really the big pain Point for a lot of co-developers is that uh it's it's rigid it's uh there are a lot

of rules um and a lot of those rules I feel like were introduced by Micah at some point um and the intention behind it was that it wasn't possible for him or for for the for the EIP editors back then it was I think it was way smaller set than than today to really go through the go through the eaps uh go through the incoming PRS and have a really like deep really go into depth and and understand the changes and verify the changes on on

technical Merit and so they made up a lot of like rules so that everything that uh like it gets rid of a bunch of spam and I think that is one of the core problems is that you bunch in these this very spammy side the ESC side where where basically everyone like everyone that creates an application kind of thinks okay we have to do an ESC now and uh and open opens and and appear for the ERC um and this this these core eips where you have people like we like we want to discuss we want to like have the dprs open as like a

discussion point so that we can um where you can maintain this this open discussion more like like a request for comments uh instead of like like a set standard and yeah it's it's just two different things and bunching them together was a bad decision and so um in order to make it easier for everyone we should we should undo this decision and I'm and also I think um it seems like almost everyone is in favor of doing that um I agree that this PR that met uh

opened is might not be like the solution but I think there's very strong agreement uh that this change needs to happen and if in my personal opinion if one of the EAP editors or some of the Erp editors against this change um and then it's fine and we have discussions about it but at some point and this discussions have been um have been going on for a really long time and so I think at some point we just need to make the decision um uh to to do this change even if people object

Tim Beiko: uh Justin

I think

Justin Florentine: yeah just real quick um I'm in you know total agreement with everything that Marius um asked and I would like to kind of call in to question I see a lot of conflation of you know discussion of the editorial process and policy itself which I think we can all pretty much agree is orthogonal to this decision um I I don't think we should interpret advocating for a split as endorsement of a current perfect world um of editorial process and EIP authorship process in general so I think keeping those two separate in our mind leaves us many more options for solving this problem in a way that everyone's happy with

Tim Beiko: yeah and there's a comment by Victor around like asking the ERC Community member um I think you know there's definitely been some like feedback in the past but I also there's also uh part of me that feels like you know for years we've tried to find people from the ERC Community to step up and Steward this and you know be like maintainers or you know like own this process and it sort of hasn't happened um and I think that you know splitting the eips out so that the people that so that the people who like are focused

on eips can just focus on that and you know the community can organize around erc's as well um it's probably a signal that like if they want to shape their process in the way that's better like someone has to step up and do it um and it feels a bit weird that like because they're bundled together then the people who want to do eips actually end up have to like doing all the ERC lifting and and it's sort of like doesn't lead to anyone showing up and like making things better on the ERC side so I I think it's like if everyone and it seems like all the client teams and most

of the people um who like right eips are in favor of splitting this I I don't think that like we necessarily need full buy-in from like everyone who's written in ERC like I think it's fine to say we're splitting this out you can use this and you can add editors to the ERC side but like the folks who like do most of the VIPs want a separate process and we can move forward with and there's a okay there's a couple ERC authors that are plus wanting to change in the chat I'm sorry I just got someone off

Puja thank

Pooja Ranjan: yeah I'm sorry um I know I'm not an ERC or EIP editor

but I'm someone who has been involved with the EAP process I am in helping out with improving the process trying to identify the pain point and uh as a part of ethereum Care address we are working in the this direction for past three years so I I would just like to make a few points so here from the conversation so far the two biggest problem that we can hear out in support of the pr is the influx of PR that comes to the repository and that kinds of create noise for which many people who are interested in core eips cannot be able to follow that I don't know if I have a perfect solution but I was just wondering if rssv can help with them

right we have our SS feeds for status change and everything can we have an rssu for code eaps only I'm suggesting this uh just to maybe help out ERC proposals what I have noticed in this period is like ERC proposals were in really bad shape about a couple of years ago thanks to Matt Gannett who has actively supported uh the education of the process and how to document it best he had also contributed and did the EIP editor's apprenticeship meeting for very long I guess over a dozen of meetings we have organized and it has supported a lot we do have a dedicated ERC editor as

of now but we do not have many out of the six or seven EIP editors those are listed on eip1 we do have only one ERC editor that is fully dedicated for ERC focuses I still feel that there is a shortage of ERC editor and I feel like that if we just move ERC out of that probably that would be harmful for the team for the ERC people and the other biggest problem that I have identified during this conversation is about the external link which I believe uh Samuelson has proposed this proposal 5757 and one by one we are trying to add permission to the external lens I do

agree to um marius's point that there were a lot of strictness imposed by Mica and other editors at the time to make the process streamline to make the process even better and we are reaching in that direction I am really um requesting people to consider ERC as a part of ethereum ecosystem and we can if we can extend our support to these people we should let them be there as well had there been proposal coming out of ERC team saying that we don't want to be a part of core EIP or the EIP system at all because feel we are different I think that would have been more in I would have been more in favor of uh

going uh towards people request having said that

Marius van der Wijden: uh just to that point why should why should the ERC Community have the say like there are a bunch of people like now discussing this point um like if the ERC Community wants to split out then it would be fine um but basically now the way I see it the the EIP Community is trying to split the ERC is out and um and so like no I think we should have the same say in in this

Pooja Ranjan: that is right I do agree I feel like they are intertwined and they should be considered together I have a very good example for four three three seven that is an ERC as of now but we are working towards some proposal that we can eventually in future may be able to have it supported by the um evm and by the main protocol so we I find it hard to actually separate both of them and I feel like going side by side if they are not creating much trouble to the core EIP process I do agree that there are certain uh Road blockers for new Authors who are trying to document process and I feel like working in solving their

issues after identifying what are the main problems just like external link policy was one of those I think we can come to a better place where we can live together

Tim Beiko: so I guess I have like my thought on this is It's almost like a tooling question right like you mentioned and Greg sort of mentioned this as well like okay if like too much stuff in one GitHub is is like overwhelming there's a bunch of other things we can do like yes we can do RSS we can do uh you know like the pages on each other but but then the alternative is like if you know GitHub notifications is the tool that all the core devs use then that's the thing we should use right like we shouldn't like the single

complaint everyone has is there's too much friction in this and if like all the client devs are saying I want to watch a repo that has like less issues in it and that the issues in it are more relevant then we should optimize for that I also think it's like at the end of the day this is just like a repo and URL split like the idea that you know because they're in two different repos like I don't know someone working on account abstraction can't pay attention to like Eeps or ethereum slash eats in ethereum slash ercs seems a bit weird given that like today you know contribute to ethereum we literally had a presentation earlier about like a new testing repo we have the engine API repo we have the El specs

the CL specs the eips like people in practice already follow you know like nearly like 10 repos if they want to follow everything so I I I I don't know why um splitting the repo and splitting the URLs is such a big it doesn't seem like a big change in terms of process it doesn't seem like it adds a ton of friction in terms of like if you want to write an ERC and write an EIP it's not that different than if you want to write an EIP today and have your spec live in the CL specs repo um and people do that and it seems to work so I I'm like much more inclined to just you know that splitting the repos

doesn't like sever the process and like mean that no one can ever contribute from one to the other it just gives like more clarity the same way that we have you know a repo for testing in a repo for like the specs yeah it just keeps things more encapsulated but it doesn't it doesn't seem like a huge deal to have two repos rather than one yeah Justin

Justin Florentine: so to sharpen that point a little bit the repo is actually I think the correct thing to collect this in and make that distinguishing on because the the editorial process itself

actually manifests itself in a lot of automated ways and there's a lot of tooling and hooks and things like that that contribute to the processes that we want to refine um so I actually think that's that's actually saying that there's a more of an advantage in going further with this and actually separating them out to allow people to automate the process however they see fit so I think that's an that's I I was kind of on the page like well monorepo multiple repos who really cares at the end of the day there's folders that you that you look at and I don't think that's quite correct I think you're you're leading a lot of automation potential on the table by not embracing the separate repo

Tim Beiko: yeah yeah

if we if we do customized scenes more than having separate repos obviously makes it much easier and I think yeah I also agree with the point around like erc's generally like I it doesn't seem reasonable to like halt like protocol development based on like application layer concerns as a general principle like we haven't really done this in the past um ethereum protocol changes are already like extremely slow relative to software development in general so um anything any like external source of friction tends to be just a bad idea

so I I don't know I it seems to me all of the client teams are in favor of this some of the folks here who have been ERC authors as well are in favor of this there's a couple people on the EIP editor sides who are not in favor but I don't know I it seems to me like the balance is like we should go ahead and do this change we've been talking about it for years it's also something that we can undo not like that's not incredibly hard to undo if we realize in the year that it was the wrong thing

but yeah I think if all of the client teams are in favor if uh parts of the EIP editors are in favor yeah we should go for it um Greg oh we can't hear you Greg you're still on

mute

Greg Colvin: uh I nonetheless still block consensus I very much hear you there's a problem I'm not convinced that simply splitting the repost helps um and they really are we really are one Community trying to improve ethereum that this line is not so strong

and the problems do not seem to me to be with the tooling um I disagree that it is the Cortez repo I really do when the editors formed as a group we were a distinct group and really if the core devs found what we were doing useful great if not we're sorry but um it's not I'm not rejecting you I'm just saying the editors have their own integrity and the repo in the end is our file cabinet it needs to serve our work

um and not necessarily the core dev's ability to follow the work um GitHub repos are not really good for that and we need and can provide otherwise to notify our accessories are old-fashioned I don't know technically can uh can we feed notifications in the Discord for instance that that's a question

so I

Tim Beiko: like I guess on your point around blocking this there's a comment in the chat I don't think a single person can block this I think you know like

yes I can

Greg Colvin: I'm an editor and I can block consensus

with the editors they can decide what to do about it

well sure but another another can merged in PR right

Tim Beiko: so I don't know that we need unanimous consent like we we I don't think we've required unanimous consent for like any change

ever

Greg Colvin: I'm saying it's it's a consensus change of the editors I'm blocking consensus we editors can decide what to do I might be convinced um but I'd much rather see what I've said a complete plan from the top down that you know that we've really looked at what the problem is what are the pain points and know that we're going to

solve it and then if splitting the repost as just saying oh two file cabinets will work better than one and we've worked out the problems and how to fix them numbering is more of a problem that it might seem for instance you know then if splitting the repost looks like the way to go then that's the way to go but we could split the repos and solve none of the problems

Tim Beiko: but I think we've agreed to this and I think all of the client teams still want to go ahead with it and you know then it has a comment like consensus doesn't imply unanimity and I think we're you know at a point where we have extremely strong

consensus on most of the people who write core eips and engage with that process

um okay

Greg Colvin: this what can I say the editors are an independent group we'll discuss this as a

group and

Tim Beiko: so we have discussed this for years though and this is kind of the thing and I guess back to Jamie's comment is you know I've personally discussed this since probably 2019 you know on and off through this and so I think with the addition of like having all the CL folks using this process

um having had years of discussion that hasn't you know done much in terms of like moving the conversation forward I like I I don't know I I don't know that we learn much more by discussing things for another you know six months I think we will learn a lot by actually splitting and running the experiment if it's a bad idea that worst case we just reverted back and it's not the end of the world

Greg Colvin: I'm still not the only problem the only problem that's splitting the Repose actually solves is that if somebody is using GitHub notifications

to follow things or browsing the repo for following things um it will help the core devs doing that I don't know how many core devs tried try to follow it that way there's other ways to follow it

Tim Beiko: but they do like we literally have everything else on GitHub all the conversations happen there we have core devs following you know a bunch of different repos from research to like testing the specs and so it's like sure you know you can say use an RSS feed but like or whatever else but it's like we can just use the same tool like and again this is just like a GitHub repo and a

URL it it does lead you know the processes can evolve differently but if you know if it's true that like the processes are optimal as they are today and they don't change in the future then the worst we've done is we've created an extra repo for people to you know follow and you know duplicated a bunch of automation um which is you know pretty minor in the grand scheme of things and then everything else is the same but in practice if we do this change and then things do start to change from one repo to the other then it's a sign it was a good idea to do it and I don't think I don't think it's like discussing the issue for another six months on like the eipip calls that'll give us more information at this point it's like

actually trying it seeing other things we can do and you know and going from there so I I I don't I feel like I've yeah I had this conversation with many people over the past few years and it always sort of ends up at the same spot where the vast majority of people want this to happen they're a bit disengaged from the current process because they feel burnt out by it and then you have a couple people who are like very engaged with the process who um sort of wants more information when there's just like this General I don't know like discontent that's shared and and I think yeah like a bigger step

forward of actually spilling it out than trying to separate repos is probably the best the best path forward at this point

Greg Colvin: I believe the best thing is the earlier thing which is we make it very easy for drafts to get in

Tim Beiko: so we but we can do that sure we can do that in both repos then that's not the end of the world

we can do it now

Lightclient: but it hasn't happened that's the thing we could have done it before we've been talking about this exactly we've been talking about all of these things to change about the EIP process but it just doesn't happen and eventually we just have to do something because the process isn't serving the process isn't serving any of the people it's meant to serve it doesn't serve ERC authors doesn't store

core developers it doesn't assert VIP editors this is something that I think is going to alleviate the deadlock that we have in making decisions and changing the process and let the people who are really involved with their specific parts of the process develop it in a way that they see

fit yeah and

Tim Beiko: I think look we're already over time I think what I would suggest is like it's clear to me at least that from the core EIP side like the strong consensus to split this out um and there's an eipip called next next Wednesday I believe so what I would suggest is that we spend that call talking about the how rather than like the if like you know Matt's PR has some you know issues with it there's a couple

issues that came up today but I think you know having a conversation about how do we want to go about this is probably the right next step in like eipip um yeah given the strong support here um and and I guess also if if people feel very strong like if if the ERC Community feels very strongly that this is like a terrible idea and like we shouldn't do it um then they should probably voice that in the next couple days before like that eipip call and we can discuss it then but um yeah otherwise it seems like from the core side we we have like pretty strong consensus to this this the

split

date

Tim Beiko: um yeah the apip call is Wednesday 14 UTC and the agenda I don't know if someone can post a link to the agenda in the chat here but it's it's in the catharters repo okay I know we're already a bit over time was there anything else people wanted to discuss okay well thanks everyone and talk to

you soon

thanks Dan thanks Tim bye thanks bye is

it

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