EIP-4844 Implementers Call #23

Transcript

okay uh welcome everyone to our 23rd uh 444 Implement those calls um there was a couple uh spec items uh added in the comments and the agenda um I think the main thing we should try and do today is align on the spec for definite six uh we can also get a quick update on the Note 75 as well um but yeah hopefully if we um we head out of here with a clear understanding of definite sex um teams can get uh yeah working on that uh but I guess to start

um Mikhail you wanted to it's Mikhail on yes okay yeah yeah you wanted to bring up uh the engine API versioning um yeah yeah so I have to bring it up because we kind of have um there is a time to spec out Cancun spec for engine API and I think this version in stock is very important to be resolved to be solved before that or to come to conclusion on to come to decision and consensus on what we will do about method versioning in particular so I

would share my screen for yeah go for it yeah to to make it easier to give people the context okay can you see my screen yes okay so uh what's the question is about um currently we have uh yeah that's for example we three method that we'll use for parade for four and we can see here that this method supports all um execution payloads data structure versions that we have up to date and why is that here basically because when we were discussing this back in

time back in time uh we made a decision that it probably will be convenient for consensus player client once it see the new version of any engine API method um just to stick with it and use it for um communicating any previous payload or whatever method call it is so any previous data structures and so yeah that that that should be convenient to reduce complexity outside which is actually questionable I know that taku at least tackle in the house uses this so they really use V3 for you know for if it is available for uh for Bellatrix

sorry I'm sorry for Paris portion high and foreign I've heard that prison doesn't use this feature and they just use the V2 and V1 and V3 methods separately for every Fork um so that's that's questionable um tell me if I'm wrong but probably it's not that provide that much convenience to CL size but it brings more complexity to this pack and buy this pack I mean not just you know write in this statements here but also testing um Mario can have some input on that

because once we have V3 method introduced we basically have to test all these things that for Shanghai for instance there is a withdrawal field for Cancun there is the excess data gas field and for Paris you know the payload corresponds to this and yeah and all the all the errors are responded correctly by execution layer client that's the spec complexity it also involves testing and we have like El client complexity so for instance get code we have here sorry

here we have like V2 methods and we have V3 method basically these three method is not spec compliant at this stage because these with three methods will uh to to comply to this spec which has to support V2 and it will have to incorporate this logic and recognize that the given payload is from Shanghai check withdrawals and so forth instead of just you know saying that okay here's the V3 method it only accepts Cancun payloads and it must display load must contain excess data gas and withdrawal Fields otherwise it is invalid here we see another complexity the other

example is Basu for get preload methods they also do some um and some some checks here and yeah so what's what to do about that we have two options here basically we have this issue and both options are described here so the original proposal was was as follows if we have just if the data structure version is just the only one change that we actually have for a

method for a new version of a method but we don't change the behavior all the change is the um we add a new version of a payload for instance and this new version is backwards compatible which is almost always the case and will almost always be the case backwards compatible with the previous versions we can just you know say that okay we're not adding a V3 well we're just you know modify and B2 and saying that we do now support uh the V3 um payload and so forth um that's the that's one option here the other option is to to make a step

back and say that okay uh there is the V3 method that just supports the execution payload of the three and that's it I I'm kind of leaning towards the um the um the letter because it it is more clear one method one responsibility and uh um less complexity on the outside and probably not that much problems for CLS to deal with that but the main obstacle here is that something else already uses this logic and uses this approach to version it relies on it um so and we'll have to

um to they will have to change change there um their clients their engine API clients clients code so that that's basically this is what I uh was going to bring up for discussion today and describe the problem um so any any inputs on that any opinions yeah just wanted to confirm that prison doesn't use this feature so it doesn't really affect us I will probably prefer what Mikhail said whatever it's the easiest path for this bet to implement I

think we would prefer that I guess another complication here is that like what happens if someone sends a V2 payload but with some blob version hash right so you have some kind of like weird like hybrid scenario like do you consider that's invalided given that it's a well-be meeting payload but you also someone made a mistake and entered some weird blood brushing hash so it does gets pretty tricky so yeah I kind of prefer we kind of prefer the simpler approach which is the later one uh Lucas

uh so I was designing this versioning code on nevermind site and we have it like in steps so first step is trying to when we get the execution payload we are checking if it's um correct payload and calculated into its version and then in the second step we get the version that we um we got it to the version of the new payload methods and there we can check some checks if if this version is enabled and based on that correctly and based on that we calculate so it's not that complicated code actually so I

think we do not need to revise that but it needs to be like if you if you like separate those two concerns and do not copy paste it then it's like manageable yeah it means so you can reuse the validation logic right but you will have to discern right you will have to understand which payload it is I mean like based on timestamp based on the fork trigger so uh we decide which payload it is uh based on the more of uh yeah

um yeah we you have to like correlate all those right but we kind of designed based on what values it have so for example if it has withdrawals we its execution payload V2 and then we we check uh timestamps uh based on if the Shanghai was also activated Etc things like that so oh so you go like the other direction right so you see yeah I say oh yeah interesting we check data data uh um data and based on that we decide okay this this is trying to use uh payload V2 okay so now we can check the timestamps right so this is payload V2 is payload V2 uh correct in uh and the new payload

this version which we also like uh just just put the version number there and okay if if payload version is bigger than the engine new payload version then it's wrong right it has to be smaller or equal and then we can also check that time stamps depending on the on the version yes yeah interesting and okay and Terence made a valid point that we have with three right we have a Blog version hashes um here but blog version hashes doesn't come alongside to V2 right and yeah it's probably something I don't know if it

adds more complexity but we can't in this in this case V3 is not anymore it seems like it's not possible to use it only if these seconds parameter will be no no so this kind of like weird thing something compatibility and yeah to address Matt's question [Music] I think that we can also delete old versions you mean like data structures or methods method versions uh both or I you know I guess for us we don't

necessarily Implement like every single data structure we kind of do it based on what is there and so like yeah if the version of blob hash is there then we would like consider this to be V3 um but I think I guess I'm referring more to the methods like we don't have to support new payload V1 after uh Cancun right um kind of yes you don't have to definitely don't have to support new pre-law author B2 after it Cancun if we find a way to pass something here in this parameter right so let's just you know omit this uh yeah but yeah so you can this is why I'm thinking uh and that this is why

there is a proposal of like do not introduce a new method because you can extend the old one right and avoid like removing the old method because you know it just becomes unusable so do not add a new one that's I think more reasonable but yes yes General yes so that was the idea to to deprecate uh V2 for instance also so am I correct that sorry I'm not sure if I understood the proposal it's just using V3 for like everything right now so we'll name it like to or can you kind of

for all the blocks for archival sync let's say the V3 yeah the proposal there are two options so we can leave it as is three options okay so we can live with the v as is and in this case we will have to do something we'll have to either support V2 keep supporting it because V3 is not Backward Compatible or find a make it with three Backward Compatible so backwards compatibility broke here as I can see it with this new um render uh so the other option is you know um yeah the other option is just to you

know to get back to one method one data structure version uh concept as we had at the at the very very beginning where so they will be just you know payload B3 in this um execution developer three is the only um structure that is supported which makes the El code cleaner but we will have to do something uh with the CLS CLS that already relies on this you know um like method supports all previous versions thing they will have to change their logic can you not just pass null in for the blog version hashes yep yep that's the

option but I to be honest I don't like it oh yeah I mean like it's it's ah I don't think it is you know a clean way of doing it but anyway why to be honest why do you don't like now no no we can do it but why not I mean like it's um if it's null it means Okay so this is one of the ways to make it backwards compatible but that's the um kind of okay if we want to support

backwards compatibility I think that this is the only way to make it so I somewhat agree that we don't need like double versioning because now we are versioning both execution payload and the method and to suffice to version only one of that yep I know that Marius was one of the proponents to get back to one version one one method version one-to-one relations between matter and the data structure but not on this call or just have a

one method version right and version d by the execution payload sorry say it again so we either have three methods each one take one execution payload or have one method and version based on which execution payload UK you're getting right so either one or the other probably yes yes yeah yeah so and if we if we say that we get back to the um one-to-one relations um so we we will leave week two as is I guess we'll not change it but for V3 we will just you know

like a differently and move onwards with other Forks it's probably uh having these checks uh here like a lot of checks here it's probably like will not happen so consider I I doubt that we'll have 10 works that will change the payload structure probably we will not not more than 10. so probably it's not that terrible but still so that's kind of it

I think that you know probably need to come to any solution right now yeah what's should we just use the pr they keep discussing it and I guess when when does this at what point does this block us from having a solution yeah so if it is possible I would really get back to one method version one data structure

approach but if it's not if it's really a complexity and if it really delays uh uh the um dinner delivery so that's probably that the other option like which trying to make this method backwards compatible will be the one that we go with I would say that and to understand that I think that we need to heard from CL clients we need to hear from sale clients client developers to understand what's the complexity of you know um foreign CL representative are here today right

so I think that maybe this Thursday is this uh AC DC maybe yeah we can also bring up there yeah okay and let's try to get sorry guys yeah just trying to comment that uh yeah I can confirm that taco is actually leveraging this uh transparent way of dealing with back of back compatibility uh so there would be a little some changes on our side to go back and have one one relationship definitely but we are about to uh start working on the this new V3 with the additional parameter and I would say that we

probably go for for the null version of it for the background public ability so we're probably gonna stick with the if if this discussion was not happening uh we were just passing now and then the passing version at the version transactions when P3 actually enables okay and yeah is it like is it like more complex I don't know to um to use this one-to-one thing instead

of like what you currently have yeah at the moment it can't I can't tell right now because now the the thing is so so embedded in the in our you are structure that kind of fully transparent everything so to evaluate what would be the impact it takes probably some time maybe it's easy but I can I can can't be sure at the moment I would be um cool if it would be great if you can evaluate it before they um

give some feedback on that it was a very current problem it let some clients sent military version when it should not be available uh but uh some guys some uh clients research this rule I mean Retreat can be sent by some clients pre-con right and yeah maybe we could agree on some rule at least in these terms so for

example we all can agree that we don't need to check future fields and V3 is acceptable for example and we it will be preparation step for the rest of the pier because we have no like agreement on this part at least if um so what do you mean by the preparation I mean that uh your peer potentially will lead to one uh version of API with like Hills I

appended to this version and so on right oh yeah there is no APR actually it's just an inspire you mean the the proposed change or how I respect now it's a specific implementation according to your advice uh means that we will right yeah yeah yeah yeah if if we decide to you know to to have uh one-to-one relations between data structure versions then yes and we'll just accept one version okay and with every every modification to

execution payload for instance uh now we will just you know introduce new uh version of new payload methods and the previous versions will have to be supported as well because um if somebody wants to run a sync and walk step then we need previous versions as well because yeah to support previous works but as a currently uh specified and as it currently works you don't need to support previous versions um yeah but uh considering that some clients do not rely on that so we have to support them either way so yeah that's that's all true

uh does it mean that if uh after it becomes the reality if I send some field developed with some default value from a feature work right this work before this work it will not lead to any like error like that email currently um after change your proposal if you if you submit a

with some new value for the using the method version the existing method version and just add some new value this is what I mean which is not satisfied oh that that should basically yeah it should be ignored I guess I don't know how it depends on the clients you will just this particular method will be used for a particular um data structure that is used to buy some work starting from this work and onwards whatever work is changing the data structure so but some extra field will just be ignored by this method I guess

but for now um search fields are checked for options so if they exist it's a problem it's an error no I don't I don't think that clients are following that are doing these checks um just also to be kind of mindful of time because we're already halfway through the call um does it make sense to table this now and discuss async and bring it up on uh awkwardness this Thursday yep makes sense too

okay uh I guess so okay so Matthew had uh the uh data gas used yeah let's Okay so that's the zoo data guess used and then we can go over the list for devnet6 of um all the other open questions but that seems like the biggest uh biggest one to agree to yeah Matt you want to give some quick background another one yeah I think a lot of people are probably aware they talked about it on I guess was it all creatives last week yeah yeah um so we shot a little bit just to tldr

again currently whenever you're executing a block and you're Computing the cost of the transactions and you need the base fee you just pull the base fee out at the header and you use that to compute like the total cost of the transaction um for Access Data gas it's slightly different you actually you need to get the access data gas value from the parent header pull it out of the parent header and then use it and then at the end or you know sometime during like executing the block you have to compute the excess data gas based on the parent header and the number of blobs in the current block uh and validate the new header that you have that you're validating has the correct Access Data gas so it's kind of

the same computation between both of them like uh there's this new like exponential mechanism for calculating the actual value but the idea is the same really the main difference is that instead of the value that you're utilizing in the block being in the header itself it's in the parent header and so this is different than the base fee and so it means that whenever we were implementing this we noticed Peter mainly noticed that there's a lot of changes that had to be done to the code just to support like plumbing through the parent header in places where it wasn't really necessary before from that we decided to make a proposal to actually make it so that the actual

Access Data gas value that's in the header is being used for the that header's block for validation rather than digging back to the parent and to do that we need to add an additional field to the header data gas used because the excess data gas is sort of this like neat trick that by using the number of blobs in the current block you get to avoid the amount of data gas used in the header because it kind of exists that information exists as part of the block body so to have the same functionality that basically has which already has gas used in the header we have to add data gas used um whenever we talked about it last week I think I was pretty uh ambivalent on on it but after

a couple conversations with people I'm feeling like more that this is the right thing to do like bringing alignment between how the base fee is calculated and used and how excess data gas is calculated used because it's a small confusing difference for a mechanism that's very similar so that's kind of a bit of background I'm curious like what other people have thought in the last few days about this in my intuition is that I mean I'm I'm like I also don't have a very strong opinion um but my intuition is that it's not really the same in that it's a different mechanism and you just call a function to derive the correct value so it

doesn't feel like it has like I mean it's sufficiently different that I don't think it should cause confusion I mean adding an extra head I feel that's definitely like I I don't know if it's such a trivia Costa in the end I I mean I don't think that I don't think there's much a difference between adding one thing to the header and adding two things to the header well that's so yeah because you're only thinking about the complexity of doing the change but like for um for light clients it means like one extra field that they have to download as part of the header chain right I mean it's like an extra eight bytes so not yeah well how much is the head how big is the head I know without it

uh it's like 300 ish 350 maybe okay so oh no it's probably bigger than that yeah I mean yeah it's like yeah they have to download some more data but like I don't know it's like an over optimization in my opinion like we're adding additional complexity that's confusing to a lot of implementers just to save some hypothetical like questions what is the additional complexity that I don't understand well right now whenever you are um like process like verifying these headers all right now whenever like we're syncing the headers we don't have the parent header like readily available

we're kind of just utilizing um whatever like the active header that we're trying to retrieve so and the reason is because like for the base fee we have like in the code a specific place where you verify the base fee and in that part of code you have the header and then when you go back to the syncing you don't have the parents anymore you're just focused on that one header and like downloading these These Chains of headers and so like the complexity is just like it's a different the values are like utilized but but one second you can't verify the correctness of data gas used from the header anyway can you no you need to block for that anyway so I don't see what like that doesn't seem like an argument you need the parent you need the parent

header no but even if the parent header and the header you can't verify that access uh data gas is correct well of course you have to still you have to still validate that data gas used amounts just like you have to validate the gas used amount like it's just making it's making the mechanism the same as the base fee the difference I mean I think that argument is quite weak because we want to change the base fee anyway right we want to um ultimately we want to have it all be the exponential one yeah but this is this is orthogonal too using exponential or not this is about like what when do you do that computation do you do the computation um for the block that you're currently

validating or do you use the one in the parent header and right now they're not in line and so if we update basically to be yeah it's still not happening how would it not be in line then both would use this mechanism like then again like if we did update it then we would update the the base fee mechanism to be the same as what we're using now for blobs again now like the actual way that you compute to the base fee value it's orthogonal to use it like be using this exponential value or not like this this is a totally separate argument versus where do the

inputs it's nice because you could literally like you could not like the this mechanism that we're applying here you cannot use without the exponential mechanism because then base is really dependent the only reason we can derive everything from excess data gas is because of the exponential mechanism so it's not orthogonal um yeah I don't know if I follow that so like basically I mean are you proposing to get rid of gas used yeah we could basically like we could make the we could make the the mechanism for like the classical yeah p1559 be exactly the same as the

one that we're now using for the blocks that's why I I'm saying it's not such a strong argument if we agree that um we want to adapt that one anyway because it's the more elegant mechanism I mean I think it's I agree it's more elegant mechanism I just don't see why there's any different like why there's a huge difference here between Computing using the exponential Val or the exponential mechanism on the parent header versus the current header because right now the base fee and the current header is the base fee for that block but are you saying that you think we should move the base fee to mean the base fee for the next block also right well I mean I don't know honestly

it does no I mean we don't even need like what I'm saying is you don't even need the base fee to be by a part of the block header for example like it's not a necessity once we move to like to me basically is simply a derived value like it happens that in like there simply there should be a function that's given some inputs say current and parent block header uh outputs the base view right in that function you can just treat it as a black box I mean that's like that's like that's that's simply like a spec implementation detail what exactly that computation is um and uh and if you have that function uh then like if you if you use the

mechanism that we use for the blobs now you don't need to store that um That Base fee anywhere in the blob like it's simply unnecessary so in the header so do not store anything related to the base fee and the header then basically yes so why do we need to have access data gas in the header well you do need that because that's an accumulator that's like the total the total amount but you need that for base fee too right exactly okay so you would replace the base fee per gas with this accumulator exactly yeah okay so again right right but then the question is like when you're calculating what the cost

the actual cost of the transactions are the debate here is not should we use this exponential mechanism that it puts the accumulator in the header the debate is should we use the header value itself or should we use the parent header value right I see so if you change a bit so the problem is that when we are dealing with headers we go through the parents right and it's easy to have a header parent header to do some validation but when we are dealing with both for this we generally are dealing with the same header and now we will have to pull parent header to do something there right that's the problem which currently is not there yeah this is I don't know this is what I

was saying I think it's it is orthogonal to changing the mechanism to use exponential because it's not like we can still replace we can still replace it with the exponential calculation have the accumulator in there it's more of a question is the value in the header what's used for that header's block or does that block rely on the actual value from the Parenthood that's the debate uh yeah and I I support this change because currently we need to as what what Peter said we need to wire a parent header into more places where it was needed previously and it's confusing and there are prone so I think we should make this

change yeah does anyone disagree that we should make the change I'm not strongly against it um but I feel like I think like the the total size of the header might might we might undervalue that how important that is because currently clearly we don't have very good client supports but as we're improving in the future the total size of the headers will become more important in my opinion

and even like I mean several of relatively easy changes which are there to add more gas but yeah important I'm wondering if there's still some old Shields in the header should we reuse like an old field to do this instead like we let's go let's use let's use the uncle's hash I but but I don't know like does this actually yeah does this actually make a difference like if we use again that's that's a different question we're now updating the mechanism so that we need

um like eight extra bytes in the header um and technically yes if we can get rid of all values that's like also nice but like replacing no no so yeah I guess I okay yeah it doesn't make a difference well I guess because those old values are like zeros now which I assume is like one bytes it's like maybe we save one byte but also we can simply remove them in the future no we there's some weird reasons why it's really hard to do that because of like hard yeah sure but yeah we could do anything yeah I mean we're always in this trade-off space of like trying to trade off space efficiency and then also on the other end trading off like

consistency and I think here the caught the space cost doesn't really outweigh the benefit of having a more consistent protocol so I think like I mean I I see the argument stronger that it might that like that it might be more difficult to pass always like parents and adders themselves like I can see that argument consistency with the normal base view mechanism I feel find very weak because to me that's just it's just a function it's just two different functions but like I mean yeah it was anything well I mean of course like the theoretical mechanism there's no problem with it but whenever the code is all

written around how the base feed is interpreted and then we sort of add this new thing that has a slightly different requirement then you have a lot of other things that fall out of that or around the sink and around verifying stuff so that's like why I'm saying the consistency there makes the change simpler for clients and less error prone to the block header we'll have to change our state transition function from Japan depend on the state and the current block and add a current block header as

well right and cache tag I mean like you have to pass parent block header to a state transition function to execute a block come do it because you can't compute the cost of data Gasol for sure yeah I mean technically you have to pass the parent block to the stage transition function anyways like that's why in in the theoretical sense this isn't really that big of a concern it just is like more practically when you start implementing these things in the way that the clients have already been designed to handle this stuff they're not designed to do all their functionality uh also assuming they need the parent header like there's times

where you can only reason about the current block with its header see oh yeah you have to pass it because you have some I mean yeah yeah of course and so that's why originally it was like oh this is that big of a problem because you already have to have the parent header it just turns out that the way that a lot of clients are implementing this stuff there are times where it's okay to just not have the parent header you've already verified some things and so now you can just um you know make assumptions from the header that you have yeah yeah so currently apparent header is not that deep in the block execution obstructions right that's what it's about I mean like if it extends the time to

work and like we'll have to but client developers will have to write additional tasks to you know does this change or whatever so it increase the complexity um of Deliverance I think that makes sense to add this field the other that's one of the arguments that so do people have a strong opinion so I guess

I don't know my feeling is we should go ahead with the change even though it makes the headers slightly larger not try to reuse an existing field if it's not going to be a meaningful saving and what when we're at the point where we're bottlenecked by like clients and header sizes we can revisit all these decisions but it seems like today it's worth that cost yeah we could just ZK everything at that point yeah does anyone disagree with that Matt

does your did the current PR you share basically do this it adds a new field with the data gas right that's correct okay so this is what we would merge yeah I'm gonna rebase it I we got on scars PR Verge so there's some conflicts I'll rebase it though and then we'll get a approval from an author and then yeah let's merge it sounds good um okay we only have 10 minutes left uh Barnabas you had the devnet six spec dock we just resolved the biggest open PR on it um do you want to maybe walk us through

which ones you think are most important to resolve now on the call or if there's not that we should resolve on the call at least we can flag the ones people should try and look at async yeah sure so basically we have a couple more open uh PR's uh maybe G lemon Tech can talk because he's the one to open them he probably knows the better priority I do so who is that sorry that she said

in there yeah hey guys so uh I think it's the same as what we discussed in ACD call uh one is regarding uh ndns of pre-compile inputs and the second one is uh refactoring of the network uh payload transaction payload so uh these are the old PRS that we discussed over there I think we also need another one that's

from what we discussed a few minutes ago that if we're adding the data use field on the on the EO side that change also will have to reflect on the CL side as well so that means the execution payload and the assistant hello header will have that field and the beacon state will also change as well and the beginning block as well I just want to add that also the engine apis right okay so yeah so we need to

corresponding PR on the El spec uh sorry CL and engine API spec that makes sense I cannot those uh if they are ready to the list is there anything they don't exist right yeah yeah but I I will let them if one creates them um Also regarding five we have to turn off if there's no opposition against it uh hopefully in a day or two I feel like we're testing there and

should be moving on demonetics very soon are there any opposition teams the thing really do we want to talk about timelines for

devnet6 I mean with the latest discussion right we wanted to add data used then we kinda back to square zero because we kind of need the spec because this layer is bad changes now and then we also need to redo a lot of the things so yeah I don't think next Monday it's um viable unless we don't include data use for definite S6 and have a definite 7 that's up to everyone here but yeah but if you want to add data use then that's another probably one to two weeks personally rather we like at this point we should be looking

to get to production right and I'd rather we take an extra week to implement the right thing then just say we have one more devnet right and similarly you know Mario and others have been working on all these test Suites like I think we should be treating this as like okay let's start writing the code that we're gonna ship on test Nets you know in the next couple months and obviously yeah if we change the spec because we think there's some better approach then we should treat this as like a production change and and get it done before we we deploy devnets and I I do think there's probably value in having one more call it like spec Frozen 4844 exclusive devnet like we

were saying on Awkward devs even if it takes a bit longer but then after that one assuming that there's no more major respect changes um I would then look to start adding all the other stuff in like uh would that be dead Note 7 basically um so like the self-destruct stuff and all of that on the El and whatever else on the CL but I think one solid 444 exclusive definitely makes sense cool so okay so like obviously in like six minutes we yeah we won't be able to to resolve everything but Barnabas um we can use your dock as the canonical thing keep

adding uh PR's to that um we obviously then have the awkward devs in the next two Thursdays where we can bring us um yeah and and let's use that the coordinates on devnet6 and even if it takes you know more like two three weeks to launch rather than one or two um if that if we could get like a relatively final spec I think that's that's really good that sounds good uh so maybe we can uh specify what we actually want to have in the Note 6 last Thursday and then try to aim to launch uh yeah a couple weeks from that point yeah I got enough time for everyone uh Mario

yeah yeah I just want to take um small time to just mention the testing changes uh required for next so we have attractive or the um or other changes for the ax each inspection is um the main requirement that we need uh right now for clients is that we need they get implementation for us to be able to fill tests uh before the before we can release uh this this iteration of tests for the next event um that's basically our only requirement from from you guys uh to fill the tests and other changes um to the the specs are minor in my opinion or for the for the tests for the axle tests but yeah to regenerate uh we

need the the get implementation so yes yeah that's basically it awesome I I can also comment on hive um we we have this uh this PR uh here here we have the there are many remaining changes uh that I need to introduce what I wanted to prioritize the execution factors because that's consensus um consensus tests for the last standard and that was the main issue the main one of the main issues in the previous level so I we want to prioritize execution for

tests and we also working on another uh Hive simulator that was discussed last uh last meeting here and which is this one this is basically the beacon API and peer-to-peer simulator but I think that one is going to take a little a little while longer I don't think it's going to be ready for next step um but the the Bitcoin API changes months are the the engine API changes in the housing manager and the execution factors should be should be ready for for next development nice sweet anything else okay well

thanks everyone yeah let's wrap up uh get the specs uh for the dev that by hopefully this Thursday and um yeah we can bring up uh uh also the engine API discussion on the uh consensus layer call Thursday yeah thanks a lot everyone thank you all right