Stateless Implementers Call #36

Transcript

Okay. Um, hello everyone to the stateless implementers call number 36. I will share the link to the agenda in the chat. So, as a brief overview, we'll have the usual team updates. Uh then Karim will present the hood state recon conversion presentation and then Gon will talk about the EIP 4762 revamp. So yeah, let's start with team updates. I can start. Um I've been working this last weeks mainly on the CGVM benchmark suite uh stuff. uh

probably in the next s or the other I will do some presentation to explain a bit more what this is all about. Um but yeah that's kind of my my main update. Um I'll go next I guess I have been still working on getting some stuff merged into G um like guest master. Uh that has actually happened. There was one PR merged last week. Um so I'd say another another eight to go and um otherwise I was working on the rebase of the Calian with Chappella branch who uh that whoever has worked on the on the

previous test net knows very well. Um so there's a new branch called the Calian with Spectra. It's uh not passing all the tests yet, but I think we're slowly getting towards the ability to launch a new u a new test net. Uh yeah, so probably over the summer there are some uh changes to consider. Um but yeah, overall uh I think it's starting to look good. Um and uh right over over uh over the the the northern the somewhere in the northern hemisphere. Um and then uh I was working on the seven uh sorry on the

EIP 44762 update um which some of you might have heard of and I will uh I will present it afterwards anyway. Um it's also supposed to include 7702. Uh but yeah like there's still some uh some work needed. Um so yeah any input is is welcome and I was also working on the implementation uh the binary tree implementation and the binary tree implementation has some differences with the spec which I'm trying to resolve today. So hopefully I can uh fill the tests and and share them. Okay, maybe not today but uh but tomorrow. And the

last thing is we were started on uh like I resumed the work on on Fent the stateless client and uh yes it's uh more or less able to compile with the latest version of the compiler. Um the only issue is compiling to risk 5 uh risk 532 which I'm currently working on and that's it. All right, I can go with the Ethereum JavaScript. So we've done work on a few fronts. The main one is uh working on the conversion testing with the test vectors that Ignasio has coded. So I've asked some questions in matrix. Our

implementation is uh is in a much better place now than it was. We we have added the conversion logic to the VM and we have an overlay state manager that handles like the dual uh pre uh fine. So we are able to do all the fallback logic and the conversion logic. There is still some bugs related to the pre-image uh saving. Some of them might be just related to how we are using it in the actual test vectors since it's a bit different that one what we would do in actual production but u yeah some pending questions and we've also helped out with EIP 4762 I think the one that you were talking about Gom um in general

I'm very much a fan of simplifying that that uh EIP I think it's in a much better place now especially with the comments from different people. So yeah, that's it for us. So on Bezos side, still working on transition. So I will uh I will show you some result I had. And uh this transition test was uh really nice because it helped me to find some issues uh in the basel code. So I'm continue to investigating and trying to fix the issue I can detect. Um I also shared with Thomas the last update. So Tom I think it would be nice if we can

switch to the binary tree implementation. Uh so I think we will start in maybe this week in the or the next week to start implementing binary tree in Bezu and uh yeah I think uh it's all on the BU side. Yeah. Yeah. Yeah, thanks for the update. Yeah. No, so we we we stopped. We were we were working on on stateless education, but yeah, so we we'll do the binary trust. It's much better idea.

Also, Louis, I think you worked on a on an RPC modification in the tracing. I don't know if you want to to share your your modification, Louis. Yes. Um the PR actually went in today. Um so I added um a debugging for this uh the witness the access witness into the traces. So which up code now prints out the uh the access witness at that current state uh that current up code. And I'm still missing in maybe adding a uh access witness hash

which was requested in the in matrix. Um but uh yeah I I will be sharing I had to make some adjustments to the format. I'll be sharing the the new format in the in matrix. That's all I think I can go next. Never mind. So after the rebase, we are now passing all the hype tests on the vector branch and I'm very close to merging the transition in the vector rebase as well. So I'll uh run high test and transition and update like how going then after that I'll maybe also start uh testing the transition with what Karine did and uh try to transition the hood uh hoodie

state and apart from that I'm also thinking about starting working on the binary implementation. I'll go next then. Uh so from my side, I've been mainly working on including all of the scenarios in spam uh for bloNet and also had a call with the Nethermind team uh last week in order to start coordinating how to set up the whole test net and how to start um bloating it. Basically uh the research at least from my side is completed on uh state bloat attacks and the easiest radio to increase the speed of filling uh the

whole test net. Uh but welcome any ideas uh on how to attack u nodes when state is massive or how to make the state bigger at a faster pace. Aside from that, uh I've mainly been working a bit on the on some survey that we're preparing uh for wallets and dabs at least the major dabs and major wallets. Uh which is kind of related to strong statelessness. Uh so basically similar to the post that you might have seen from Vitalic to date. Uh I will link I will link it down here. um where the

idea is to basically allow um allow wallets and dabs to basically supply some auxiliary witness uh which basically results in a discount for all the reads that the node doesn't need to execute. So basically we are saving X amount of IO and the outcome is X amount of gas that you basically don't pay for. Uh maybe some other kind of uh reward on the top of that. Uh that could heavily alleviate the amount of data that you need to um access as a full node especially when the state becomes much bigger. And the counterpart is wallets uh have a really nice feature to give to

the users which basically provides them savings and where they are able to take a fee if they want. So the idea is to see how wallets would see that uh what do they have in mind if they have any other plans if that is good or bad UX how we can make it better and try to see if there some kind of weak transition that we can do towards a bit more uh stateless related uh regime let's say um so that's it for my Anyone else want to leave an update? Okay. So, let's now move to

Karim's presentation. So, whenever you are ready, Karim. Yeah, I try to share my screen. I don't have permission. So, I can maybe give you a link. I don't know if you have permission in show. I should, but I'm trying to see how this works to give you permission. Okay. Um, let's see. [Music] Not really sure how this works in Google Meet. Does anyone know?

I can send you a link or you can maybe try to share directly. Yeah. Send the link and I can present it. Yeah. Yeah. Could you try? Yeah. Give me a second. Okay, let's see. Can you see my screen?

Yes. So, it's it's not a long presentation. just wanted to explain uh what I tried to do during the several weeks the last weeks. So uh what I started to set up is um so it's a CL using Nambus connected to hoodie and I'm using two kind of bas. So I have a vania bzon node it's a basode using a patricia merry and this one is just following hoodie following the head and generating a pre-image. So uh Gary from the Bezu team added a feature into Bezu like that we can just generate pre-image and save it in the database like that I don't I don't have to generate every time a new

page I will just have to ask directly this node in order to have a pimage of an address of slot in order to do that I added a specific RPC endpoint to this node like that I can just ask a key of or slot and I will retrieve the premium age. So it's not really good regarding performance to do that for each key asking RPC node using RPC request. But uh it's not really a problem because even if I was doing that uh the block time was one or two second and uh it's not a problem because slot time is 12 seconds.

So I didn't wanted to try to have a really performant block import time. uh just wanted to check the transition and uh I also have a second bas. So it's a basode using veral. So I'm starting a basode with the bonsai patricia tree and after a specific ve time stamp this bas is switching to veral and starting the migration and asking this vania b node in order to have preage. Okay. Um so you can go to the next slide. So uh just to explain quickly uh what we are doing in Bezu in order to manage the two stateates. So we have the we don't really have an overlay tree

what we have is more two state working together. So we have a war world state vel and a bonsai wall state using petri and we have a facade and this facad will manage the two kind of wall state. So depending where where we are if we are before the the vertical fork it will just uh redirect to bonsai if if it is during the migration it will redirect to vertical with fall back to bonsai and if it's after the migration it would just redirect to ver and this facade will also manage the different record of the different state uh regarding what we need. So yeah, just wanted to explain that. So you can go to

the next slide. Uh so in order to do the the the migration, so what I did is to not modify the genesis because I didn't want it to have a fork invalid fork ID. So it's not really a shadow of fork. It's more a bas node following the hoodie network and trying to generate each block of the hoodie network with the vertical state. So uh like that I for the moment I cannot really validate the stateood but I cannot validate the execution of the same block and compare the gas um gas used for each block for for the m the ver milestone the vertical time stamp it's coded directly in the

code but I want to have a specific flag like that I can I don't have to rebuild every time to to restart a new test but for the moment in order to be able to be connected to the others in the hoodie network I didn't addit directly the vertical time stamp in the genesis so if you go to the next slide uh for my test so um I started to have 5,000 leaf to migrate from the patri tree to the ver tree uh by block and when I was uh using this configuration I saw that even if we are just uh migrating 5,000 lift by block in reality

we are inserting in the veret tree more than this number it was between five 5,000 to 9,000 leaves so it's uh it's logic because when we are creating by one per account in reality we have to insert two kind of leaf we have to insert the basic data and the cut ash so we need also to have in mind that uh when we are choosing a number in reality we inserting more than that in the veret tree. And if you go to the next slide. So on my test the migration it was 13 hours for hoodie with a slot time of 12 seconds and uh I also saw uh state fruit uh performance issue u on

bezu. I don't know if it's only on Bizu but it was one second to generate the state route with 8,000 leaf in general something like that. Uh we have all of the optimization normally um in in Bizu uh the way to not uh calculate all of the commitment every time etc. But I didn't really wanted to look at this part because we are uh talking about changing the crypto and so I didn't really wanted to look at this part and trying to too much to optimize the stateood computation. Uh so if you go to the next slide so as I said how I'm validating

the migration so for the moment it's not perfect because I cannot really compute validate the state root but uh this kind of test help me to find some uh reorg issue and also a roll back roll forward issue because in bizu we are just saving the head and we are using uh trilloclock to roll back the state or roll forward the state and thanks to this state I was able to find issue in my trial log u because in hoodie we have sometimes some uh some reorg etc. So it it was it was nice to do this kind of test for that and I'm also validating the migration using the in natural reference test and what I said before I'm using mainly for

the moment the gas used for each block uh to be sure we are executing this block in the same way. So uh for that I just disabled the vertical configuration for the for the gas and I'm using the PR configuration and I'm also checking if we don't have in invalid nons or something like that. So this is the main test I I I was able to do for the moment. Uh if you go to the next slide I think I have still one. Yeah. So what I want to do for the next step is um I need to to test with a a network with more transaction uh because I want maybe to find more H cases. Uh Guom said maybe he will be able to give me a pre image

for mainet. Uh for that I was using Bezu I was using hoodie because it's really simple to to sync uh a not with the hoodie network and generate a pretty but for manet it's more complex. So if GM can give me maybe a pre-age for mainet I will be able to do the same test and also if we have more clients that can do the same thing like that will be able to to compare the state root. Uh so it will be also nice. I think it will be the best test we can do and yeah it's uh it's all on my side.

Yes, um yeah, I was thinking another way. So, yes, if we have more clients, um it's true. It's hard like as long as you're alone, you're it's it's really hard to to uh test the state roots. There's still a very useful and important test. It's the ability to produce blocks and reinsert them back. But of course, if you're just following the if you're just following the test net, u it's hard for you to produce blocks. Um, this being said, if we have more clients, you can also check what the witness or at least the state diffs look like because ah right now, but we would not be providing this, right? So, you could only verify this after the end of the transition.

Yeah. Um, okay. I had a couple question. Um, one of them is, uh, actually it's not a question, it's a remark. So when you say, uh, you don't have an overlay tree, but you have a facade. Um, it's the same thing, right? The overlay tree is is effectively the facade. Um, what's that called? Pattern object pattern. Um, I forgot what is the the object-oriented term for this, but it's a pattern. Design pattern. That's it. Okay. So, you have something similar. Okay. Yeah. No, I'm just I mean yes, we I do I mean we do um but we I call it a transition tree in the code, but it is it is exactly that, right? It's it's just a tree that

does the redirection. So that's I mean as far as I know that's the way to do it and that's how it's been designed to begin with. Um I'm not sure it's exactly the same but yeah okay we can discuss about that later. Yeah sure. Uh there was another question regarding um the the size. Do you know how much uh size is the state of hoodie? I I should have checked that but I I don't know it from the top of my mind. Uh I didn't check. I started a new migration. I can maybe give you the number after the do you do you mean after the migration or before the migration or maybe comparing the two sides? Before the before the migration and also after actually yes. I

can I can give you that uh when the migration will be finished I will take the size of the state and after I will go back to the state before migration and I will send you the two values. Yeah. Yeah. Um yeah cool. And there was something else. Um yeah it's about the speed. Um so you took 5,000 leaves and you said like the worst case you got or was it the worst case like 1 second or was it more like an average case? Oh no. I think it was more average because uh as I said it's not it's not a good number because for each uh key I'm asking a second bas request so it's impacting the block time. Uh but for for

me it was not a problem because it will every time it was smaller than 12 seconds so it's not really impacting the the time of the migration at the end. But uh yeah it it was this number is not really is not really interesting. uh what I was interest what was the number that was interesting was the stateful computation time it was uh sometimes 1 second sometime more and also the block time sometime it was 1 second sometimes two second or 3 second so it's uh the the block time for the month is not important as I'm asking a second bas request mhm um okay understood yeah that's true it's not very if I mean that explains

why It's not super efficient. Yeah. So for the moment as we don't really have a way to we don't uh we don't for the moment have a way to to get a pre-age or to save a we don't have the process how we will retrieve the preage. So I'm preferring to have this kind of mechanism like that. I just have to restart the for a new test the vertical node and I don't have to manage the preage every time. So it's it's more easy like that. But uh uh uh okay. Do you select um so you said you were hard coding the vertical time in uh in your codebase? Yeah. Um but what like I'm trying to understand like what what prevented you from creating Oh

yeah, because you wanted to keep the the chain ID and be able to follow the chain. Yeah, I see. Yeah, I wanted to be connected to the other pier. Um, but could you not simply deactivate deactivate the fork inside the ch the fork ID computation thing? Yeah. Yeah, it's just uh the way I decided to Yeah. Yeah. to do, but yeah, it's it's just possible. Just um I think it's more simple like that, but yeah. No. Okay. I'm not saying it's uh it's better or worse. I'm just trying to think if we want to build a version of get that does the same thing. Um how would I do this?

But u on my side I was thinking maybe just to add a flag where I can specify this hardcoded value uh like that I don't have to rebuild every time but also modifying maybe genesis and ignoring this specific for could be also a solution. Yeah. M um the last question I can think of is did you write um any data that you you know for example like the the state diff or the things um or the state route or whatever uh oh yeah no you don't have the state root but um I have the state just I cannot validate that but I can give you some state if

you want but true um yeah no the question would be what happens if um if instead of you know building the entire guest thing I would just import the blocks that uh as they are and as soon as we detect the the guest fork happens uh basically getting rid of the whole pier thing you see what I mean like just uh um it's not as impressive because it's not technically a shadow fork but as a way to test it's much faster because you don't have to look for a peer and do all those things. I think I think it was also interesting to to to manage a real scenario with uh connecting with spear importing block switching to a migration to the

migration part and finishing the migration. It helped me to find a lot of issue in my logic. So I was able to pass all of the migration test for macho but all of the logic to to manage reor during the migration to to to finish the migration and go back to a vertical mode without fallback. So it it was also interesting to do this test because of that the the main part of my test was related to the logic on this part and not really related to the migration. Migration was working correctly. It was the other part. Yeah, fair enough. Um that's true. So the migr the reorgs is something that's missing because uh for for me because I uh yeah I I haven't managed to get stuff into into guest but

I guess I could try to fix it. Um I I think migration is really uh it will be really tricky because I'm trying to manage that but it's difficult to exactly have this scenario but I'm thinking about a scenario where you are starting the migration you don't have the finalization yet and you have to roll back but also the patricia merry and go back to a new migration I think we need to kind of reorg during the migration before the first finalization I think it would be nice to have a test for that because yes um yeah we we talk uh before with the testing team because

today in the testing framework you cannot really create these reorg scenarios but they were planning to include this kind of feature soon but yeah as soon as we can create this kind of scenarios we should definitely create uh kind of execution spec test for all these reord cases. this. Yeah. Yeah. Because some of my test was also related to reorg is if you as I said in Bzu we are generating this kind of trial log. So this is a prior value and updated value. It's similar to a witness but it's internal to to be bas and we are using this trialog to roll back and roll forward the state and uh I will say the majority of this issue was related to

how I'm generating the trialog. So having this test would be really useful for me. Yeah. Cool. But yeah, if we can if we can just compare the state like that. So if I can give you maybe some state root and you can verify it, it would be also nice. Yeah, that would be a good idea. I mean, I still need to complete my rebase for it to work, but uh yeah, we should try to strive to do this. Yeah. Um, cool. No more questions for me just to understand this latest idea. So the idea will be to maybe do some exporting of hoodie or any other chain

decide on some time stamp where this migration will start happening and multiple clients can simply import this chain and just compare state roots, right? Yeah, I think it would be nice. Yeah. Yeah. Nice. Cool. Um, anyone else has any questions for Karim. Okay. Um, yeah, great work, Karim. This is very helpful to really uh get deeper insights into how all this

would work in in reality. Um let's move to the next item which is um EIP 4762 reamp. So maybe Y when are you ready? Yeah I'm going to try to share and also while I do this I also didn't say it but that's really good work Karen. Thank you for taking the time. Um nope as always looking for Windows. Uh oh. Is it the one? This is the one.

Yes, it's lined. Um, so I don't know if you guys can see it. Yes. Um, so yeah, there's this uh ER that's against uh Ethereum EIPs. Um it's meant to be a rewrite of 4762 because um 4762 is very very hard to understand and it's been an idea that was floated around uh a previous stateless implement call maybe six months ago. Uh but I finally tried to to do it. uh it's a bit of a I mean it's more than a bit it's

extremely difficult to to do because uh the wording is confusing but whoever worked on the topic knows that and so the idea was to try to use some uh some Python-like uh implementation to uh to to try to make it more palatable and and more easier to understand. Um so as you can see for example in this example if you can read it um you have like just a list of bullet points on one hand and this is rewritten to be uh more like um yeah code um so actually the equivalent of this is more like here yes um and the

idea so I had a talk with guru from uh from the eels team um and initially I really wanted to stick to the to the structure of Eelss. Uh the problem with Eelss is that um it's um it's not written to to be like this. Uh the idea is that they have this approach which is uh better for maintenance I guess uh but also really hard for specs that um when you want to implement a new fork you just copy everything and you modify in place and um that would have mean among other other issues that I would have had to to do that work um and then just give a link to to that uh to that to those

changes. So the approach I I tried to achieve instead is uh um just say like this is what this function does and I give an explanation before where in the code uh it goes. Um so yeah like the first uh request I would have for everybody involved would be to have a look and tell me if in your opinion this is this is actually helpful. This is understandable. Um I I am not happy with it but I think uh okay that at least that's the best that's the best uh approach I could find so far. Um while I'm at it let me note that there is a mention about atomicity.

So um this was a topic last uh SIC or the last few SIC's where we specify when um when the the gas gets charged. Um so I I described it as this function that gets called is called charge gas and whenever you have an atomic uh operation um which should happen at the end of this function here u that says like in between uh two calls of charge gas all the events accumulated will be charged for. Um there's uh there are a few issues on this uh on this rewrite. Um well some of them are actually inherited from the from the previous version of

this EIP. Uh some of them are something I found while while working on this. That was a very good uh thing that uh that I did this because I could uh I could identify parts of the spec parts where the spec were were actually not matched by a code. Um, so yeah, one of the thing that is missing it's uh it's currently not charging the warm costs. So I have to figure out the best way to do this. Uh there's this question that actually if Lewis is here uh I would like to discuss again because I'm a bit fuzzy on the details. The the one with the call code and the last issue um before we maybe delve into the the call code is uh I'm looking for it right

now. Um it's uh it's that the spec or at least the pre previous version of the spec used to say that you don't charge any access for uh anything beyond the the code length and uh this is not true of um this is not true of what GU does for example and presumably any other client implementation was um in the sense that if for whatever reason uh the the code uh execution or there's a jump although that's not possible but if there's a jump that happens after the the end of

the code but still in the same chunk that the end of the code is present in this chunk will be added to the to the witness um at least that's my understanding I don't know if we have a test for this I I forgot to check with Ignasio first. Um but this is uh this is an issue that I think uh we have in the current implementation of GU at least and this is something that especially Tanish and and Tanish Karim and and Gabrielle if you could check your implementations to to see what you do in that case because we we might have a consensus bug or at least we don't either we have a consensus bug because

you you guys do it right and um and and PS does not or um or we we're just not following the spec and I think we should then fix it in the in the next uh version of the test net. Um I see Louis uh oh sorry Gabriel you were going to say something. Did I uh I saw flicker? Uh yeah I was just going to ask what specifically is the the consensus consensus issue if I'm just going to note it so that we can review it internally.

Yeah. Yeah. Um so if you if it's not clear, you can of course write me afterwards, but um it's just that if you're executing a contract, like for example, think you're uh you're having um you know, just a bunch of uh of push pushes and then your last after the last push your code ends. But the last push is let's say halfway in the middle of the chunk. What will happen is that it will try to execute the first instruction after the end of the code uh which is non-existent but it's filled with zeros. So that will be interpreted as a stop and the what's that called the exe the

witness will consider or at least the the access management uh module will consider there was an access. This is the way it's implemented in in G or if you do for example a code copy of uh the code just after like still in the same chunk but just after the just after the end of the code this uh will create an entry in the witness when it should not according to the spec it should not um so yeah that's roughly what I would like you guys to check if uh If there is a you know if you have such an issue if you if you did it properly or if you did at least

according to the way it's specified then we have a consensus bug because guess does not do it right. Um yeah that's the I don't know if it was clear but that's a general idea. Yep that's helpful. Thanks. Cool. Um, I see I see Lewis coming in and out, so I don't know. Maybe he's got some connection issues. Are you here, Louis? Uh, numick. Okay. Well, it's going to to be hard to have a conversation. In that case, I guess we can take it offline. Um but as a summary uh I noticed that uh the spec was saying

call code should uh should behave exactly like call and um and the guest does not handle this. I'm pretty sure we we discussed this in the past but I'm a bit fuzzy on the details. So um I would need to figure out uh yeah like you say we should on the review you should you've wrote we should fix call code on this side which uh basically what we want to do uh yes it's a self transfer I think so as well um right that that was it yeah it's a self transfer so um but yeah it's not it's not properly uh it's not properly specified or at least it's not properly coded in G um or

if it's properly done. It's really not uh obvious when you read the code. So I think uh I mean I will spend some time clarifying this and I will need your help if you're if you're so inclined as uh to help me. Um okay. Yeah, I guess we don't need to we don't need to talk more about this. And yeah, uh the last thing I already skimmed over, but want to remind if you guys have an idea on how to properly represent uh worm cost because uh what I did was was not good or it's it's just not correct. Um and I'm still thinking how can I best do this?

Um I'm just thinking, yeah, I think that's pretty much it. just uh thank you to Gabrielle and and Lewis for reviewing it actually. Um it's been it's been quite useful. It caught a lot of issues. Um but yeah, there's still a lot more. So this is the first draft. Uh I will there I will make another pass at it. I'm just trying to collect feedback right now. Um so do not hesitate to disagree with what with what has been done because it it is in much in dire need of disagreement. there's uh there's a lot of things to uh that I'm not happy with and I'm always happy to get uh to get good

suggestions. Um yeah, I think that's all for me. Anyone want to ask some other particular question about this topic? There were some uh it's not okay. Go ahead. Ignasio mine is kind of parallel to to it but uh go ahead. Yeah, mine is kind of parallel too. So I was just going to ask that Guom in the last S call or the previous one mentioned that

I think that somebody was working on 4762 in the spec like in the um Python implementation. Um I don't know if that's still happening or was an idea. So on the execution specs, I was going to like uh take that I've not made much progress there. I've uh like just about getting started essentially with 4762. Cool. Thank you. Uh Aria.

Yeah, I was just going to ask so uh it seems like uh I'm not exactly sure where we are on veral versus versus uh binary, but uh I'm wondering if we have a plan for like binary tree adjusted 46 4762. Would that be another EIP or uh are we like not there yet? Um I'll try to answer that. Yeah. So what the plan is uh I would say at this point it's pretty clear that um we're going to go with binary and therefore uh vertical. We're

only using vertical because it's easier to uh I mean this is the code base we have. I am still working on the implementation of binary trees. So I expect honestly I think at this point we should the next test net should be binary but until we get there which uh might take another couple months with all the interrupts and stuff like this um you know veral vertical works um so might as well use it to solve other issues. Now uh when it comes to 4762 um the structure of the binary tree has been cho chosen so that it doesn't uh change anything in terms of gas cost. Um I'm sure there will be push back uh for

this and we will have to either edit it or rewrite it or or maybe just change it completely. Um but currently I don't think that's a good and that's a good use of our time because the thing has been uh you know has been thoroughly tested. There's of course there's still plenty of of open questions. Every time we we add a new client we we come up with more questions. Uh but at least it's well understood. Um it's um and it's still compatible. So I am as far as I'm concerned, you know, if there's a good reason to change it in the future, that's that's fine. But uh I would say we already have a lot of things to

change and to adapt to. Uh there's no point in making making this more uh more more complex by changing this specific EIP. Yep. Perfect. Thanks. That's helpful. Cool. So we have around 10 minutes left. I know if somebody else wants to mention something. Yes. Anish. Uh I think GM you mentioned that now next test we should have is with the binary tree. I think we initially discussed that we'll have one worker test net and also we'll test something for transition. So I was thinking maybe what we can do is we can uh do what

Karim did and we can for the transition testing we can just uh try to uh do the transition for hoodie and maybe we can do a shadow for work on hoodie with local for testing or do you think that we can just test this directly on the binary tree? Uh I'm not sure I understand you mean like you would want to do the shadow fork in binary already? No no that's what I'm asking like what the plan is. So because from what I remember we had this idea that we'll do a transition test net as well with I was thinking of like if we don't do that we can maybe do a shadow fork on hoodie with veral and not binary.

Yeah. Yeah. I think we should do this. I mean depends how quickly we can all get to the shadow fork. Um but I would say for now the the main uh we we do have like I mean this is what I I said before veral uh might not be what we like it's not worth developing vertical stuff anymore but it's there it works and we all agree on it. So we we already had the the interrupt of sorts. We we all agree on that. So I would say if we're going to test something like the transition, it makes sense to do the binary tree uh sorry the vertical version of it and uh start simpler for the binary tree which is to do a test net um like in a couple months. But I would say yeah, let's do let's do a a

vertical shadow fork and then focus on making sure we everybody agrees on the binary tree format and only then try a binary tree shadow fork. But that will be I guess more like September. Oh yeah, that makes sense. Anybody else wants to discuss some further topic? Um, I have two things actually.

One of them uh was a question by Gabrielle. Uh, you were talking about two forks. Uh I'd like to understand a bit better why you need two forks um for Okay. So we don't need necessarily two forks for the for the transition. But something we've run into is that uh we've used a hard fork vertical as kind of a you know the the go-to fork for for uh anything vertical. So previously it's been you know a vertical genesis where execution witnesses are provided and we can do all the like stateless stuff and this is mostly what we've specialized on so far. So with the conversion we turn on the hard fork vertical but my

understanding is that this is when the conversion uh starts. So if that's the case then we have sort of a a branching logic here where when we fork to vertical we are expecting you know execution witnesses in block and all the other like vertical related validation whereas if vertical means conversion starts then this is a different handling. So my question was mainly uh am I understanding this correctly uh what I've just laid out and the other part of the question is that how do other clients uh handle this and are there like naming conventions for these different sections of the uh conversion namely the the beginning and the the

end. Um, in the case of GU at least, it's true. We never um we always have the premages when we test. So, we never did that uh that week long thing. At least we haven't done it yet. Um, but I would say for it doesn't matter because uh we just need to do two checks. The first one is I mean everything execution related and uh adding um the gas cost and everything.

This is active from the moment the transition starts. Uh for from the mo from the moment the fork happens because as soon as the fork happens you create the new tree um and you start writing to to that new tree. So all the gas cost everything is already active at the fork at the fork time. Now the only thing that indeed um changes is when uh the sweep starts and the the witnesses are available. Uh for the witness being available that's also easy. Uh you just have to check that this is verical and that the transition has completed. So that's for us we have something some flag in our database that says the the

transition hasn't started yet. the transition is running or the transition has completed. So for us uh that is that part is very easy. Um for the transition to start uh this is something that does not exist yet. Sorry for the for the sweep to start this is something that does not exist yet but we would need to have a bit something a bit similar. figure out when the forblock was um was uh finalized and when this uh to to do this we need some support by the by the CL which we never had so I mean okay that's not true to say never but let's say CL's are not really concerned uh by by this

yet so we don't really we we never got them to to implement the thing um And um and then after this value the transition starts uh a week after the this value has been written in the database. So once this has been done once the CL tells us your block has been finalized um we we just um it's just a matter of adding two timestamps and uh and see if we can start a transition. Okay. Yeah, that that makes sense. So we that clarifies things. This is kind of what I had in mind. So when the vertical

fork starts, we are you know fully switching over to vertical with the exception that the you know the the conver the actual sweep hasn't been you know perhaps started or completed. And one exception is that we are not checking for execution witnesses no presence in in blocks. Then the sweep is something that happens you know peripherally like to be determined what the best way to to do that is and then we need to monitor whether or not the conversion is complete and then conditionally uh you know require execution witnesses to be there in blocks. So yeah that's that makes sense to me. So I I think like I'm not sure where that should go

but to me these things are kind of things I've encountered while testing and and coding and I hadn't seen mentions of it in EIP. So if we can do a you know some clarifications on that as a side section I think that would be Uh you mean in the EIP itself? Yeah maybe the conversion EIP or whatever. Uh, no. Okay, cool. Sure. We can do that. Um, if that matter is settled, I have another question that I could

totally have asked on uh on Discord. Um, it's uh the the conversion test. They have a stride of zero. And do you guys remember why we we don't have a non-zero stride? The conversion tests uh were really the conversion test in the official latest release have a try of zero because there's no conversion test there. The conversion tests are in a separate branch where the try is it is not zero. Okay. Then I think the stride is seven in those other ones. Yes.

Oh, that's a good idea. Um, okay. Then I completely missed that uh that release. Uh, yeah, I'll ask for it. Okay, thank you. Okay, so I think we can wrap it uh here. Uh, thanks everyone and see you next time. Thanks everyone. Bye. Bye.