Verkle Implementers Call #18

Transcript

all right let's get started uh this is imp veral implementers call number 18 uh this is PM issue 1027 uh in the PM repo uh okay uh let's start off with any client team updates would anyone like to start things off can I nominate you sure you can um yeah we've been we've been busy in the past months was it months months and a half maybe um we have been uh we're reworking

the the gas schedule especially with the interrupt but before and after that as well uh there's been a re vamping especially at the interrupt of uh of 2935 so the veral the veral everything that is like concerns verle hasn't changed but there's been a lot of uh nitpicks um so for Whatever Gets activated at Prague so there's a new EIP I hope Gabrielle is here to talk about it um cool um and uh otherwise yeah a lot of effort has been made into the

testing uh so ignasio has worked on test vectors I have worked on testing the the conversion so with the with the testing team um we yeah we have some working prototypes where we need to merge all those branches and there's a couple bugs that I was investigating uh I hope someone from testing is going to show up because I have a couple questions and and otherwise what am I forgetting oh there's been a couple specs update that we asked uh for example the state rout uh so I'll I'll cover that briefly afterwards um we want to add the state root to the to the proof and um I think oh yeah the

conversion so we finally managed to have some all the data we needed to perform a conversion at a at a very um at a much more recent height so it actually finished a couple minutes ago um so it took about 16 days worth of blocks to to process so that would add 2 yeah 2.7 days to uh to a full sync uh like like extra um that's actually much better than I feared so far at least uh in terms of uh full sync um the bad news is that yeah it already took roughly um two uh sorry 16 days worth of uh of blocks

so that means the the transition will already take um 16 days assuming it's using 10K like it transferred 10,000 leaves per block so we could improve that by increasing the number of leaves but it's not uh it's not something I'm comfortable doing at this point um so that means that the more we deliver as expected uh the longer this conversion is going to last uh so we'll have to see how that evolves over the course of the next year but uh yeah that that part is not as um is a bit more worrisome than I expected it's not the end of the world but it's uh it shows that the state is growing uh faster than

in my initial estimate um yeah pretty much all for me ignasio do you have anything else to add um no um just to repeat I work I have well I can speak more about this in the testing section but yeah work on the um testing vectors for 6800 and 4762 uh I also did an implementation of The ipsilon Proposal of cod chuning um and I tested with some the vectors that F gave me and everything seemed too much so if anyone is interested in a go

implementation of that we have it already to experiment maybe in the near future and yeah just did some extra back fixing get um for the replay that now is working as Gom mentioned but nothing else for me I can talk for bz so uh we did the some optimization in the Bas side during the interrupt so we can import block um much faster we we had different issues that

we we fixed recently uh we also um implemented the the proof verification using so we are using this library for verifying the different proof I did some test in the Cur devet for the moment it's working fine uh Gary I don't know if you want to add some information but you want to start um to work on the migration and also on the snap implementation for verel and we also started to work recently on the new gas cost modification so I started today to look

at this park as this part and uh started to modify B in order to match the new specification and we are we also have one guy that will start to work on proof generation like that uh we will be able to generate new block but uh we just started to work on this part so no no new for a moment uh I think I'll go next uh on NE mind so regarding sync uh updates from before interop like we now able to sing cost and using work sync but since cost

is a small Network we can like only we only were able to test the ranges pH so after interop uh I'm still yet to test the healing but uh we like I streamlined like how healing Works in nether mind so it's much faster now but still not tested on cin we found a bug in nether mine and still need to debug and fix that except for that uh we implemented the most recent gas cost changes though it's not finalized but whatever is finalized we implemented and except for that we also started working on uh using rust tole for like some operations so now proof verification and uh creation is comparatively much faster than before

we're also planning to switch to using the uncompress version of vanderwagen uh for serializing and dzing nodes and uh H yeah that's it all right I can go with ethereum JS so aside from the progress that was made that the up we have made some uh we have an outstanding PR that implements all the gas changes from 4762 including you know the basic Leaf data and all those related changes uh we haven't merged it in we're just waiting

on ctin and 7 for testing and then we're gonna make that our merge that to our main branch um aside from yeah that's pretty much it on our side we've also begun a veral try implementation but that's not really relevant for syncing or test net so I can leave that out but we have begun some work on there cool any other client team updates uh so for every I was able to update the

gas cost uh in an out PR but of course uh we're not sinking yet we got busy in other things um I was able to regenerate the three images files uh with a slightly different approach and I created a description of it and act and the the total size is now 28 gab instead of 14 I'll just put a link to the short description on this chat and uh perhaps some element um that's it from everyone

cool if no one else we can move on next up we have uh testing updates anyone from the testing side yeah hello I'm here but um I'm not the main person working on Bal at the moment uh that's Spencer but he is out of the office but um yeah during the interrupt um as far as I know the testing filling process is finally working for Burl um there were a lot of things fixed uh between the transition tool and and the testing filling process that we have um I think main one of the main issues is that we were not able to um we weren't able to communicate correctly

the the data objects that we were passing between the uh filler and the transition tool and that that is now part partially fixed and we were able to fill some of the tests not all of them but some of the tests were in the interrupt also another thing that was uh accomplished was the hi instance uh that is specifically bural um uh is now working and we got it working during the interrupt also um uh the rest of the test I think we are in the process of converting and also making sure that they work um but I think there's no other important developments during last week yeah um actually there was one um so yeah

there was a book fix that uh because a lot of tests were not passing like a lot of the tests that got translated um that was due to some uh remnant of an old conversion problem um so a conversion PR that got merged and yeah there were two variables that did the same thing so they were uh not behaving exactly the same so now I deleted that variable uh but there are still like 10 tests that are not passing and um I was able to well I debugged one um so there seems to be an issue that preimage pre-images are not cached and then uh the last the other problem seems

to have to do with the the way the conversion is is running so I still have to run in like I still have to debug this one just FYI I thought I had a question but actually I just found the problem so uh yeah no more question on my side yeah small update I think is that me uh we have the um we're preparing like uh pre-releases on the on the execution spec tests um repository uh so how so the way that this should work is that um we only have a a prototype for EF so now um we are going to be able to tag releases with only EF changes and

only veral changes veral is still work in progress and we can probably do it in the couple next weeks but the approach is going to be that all the all the client teams that are are working specifically on a branch that works on Burl should be able to go into the releases page and get the last um baral uh baral focused um test release from from the from the repository but we will keep you updated this is not um finished yet I just wanted to add that uh the work that I'm doing for all the rest of the test vectors can be found in this branch that I will share

awesome if nothing else on the testing side can move on uh next up uh Gom you had a PR that you put up for uh adding the state root of the parent block into the proof you want just to flag that real quick yeah it's very quick um let me just share my uh screen assuming the right screen yes um sorry right window sorry uh yeah okay not sure I get a a weird message whatever um yeah so it's a very simple change right um I will in fact copy it right copy the link right here but it's

coming from a request by ethereum JS that they wanted to verify it so they they implemented like Gabrielle said they implemented verification as well Pro verification I mean not just block execution and and what happens is that uh they discovered that they need the state route of the parent block inside the proof otherwise they would need to also get the previous block um which is a bit silly just for 32 bytes so we just uh like there's there's an update uh there's a proposal update sorry uh an update proposal against the the

consensus spec uh repository that just adds this uh that just adds this field to the execution witness um yeah so feel free to comment but I I assume or I expect it to be implemented for the relaunch uh of devet 7 uh so that means there's a tiny bit of work expected from the from the CL devs I don't think any of them are here today uh but I can uh yeah I can chase them so it's only nether mind sorry it's only uh um load star oh right there's there's a

load star Dev in in the chat um but otherwise it's Lighthouse and teu currently who support uh who support this this test net so I guess if uh if gajender I mean can give us some feedback and then I'll I'll I'll H down uh Matt sorry Mac and um I don't know do we have any contact at tku actually um I guess I'll just ask Paul Harris um I think it should be pretty easy to add but G I think we earlier talked talked about uh sort of having the witness as opaque byes for the C maybe

we should think about that so that basically C client does use it at all so having CL client to basically write it type and sort of pass it while passing it around from cl to El or from El to CL I think that is unnecessary but uh I mean it's not really that important but maybe we can treat it as op bites at some point um there was a lot of echo I didn't quite understand uh what you said sorry could you could you repeat a bit slower maybe okay um must be gone

janish uh yeah I think what G was saying that uh we had a discussion that like instead of using a Json object for proof we can just use some like bites so that like CL doesn't have to encode and decode while sending and receiving it from the El and like I think the final conclusion for the that discussion was that like right now it's easier for debugging to like print just print the Json but eventually we are planning to like move to opaque bites I'm not sure if that's what we concluded last time but yeah that's what I remember so the the proof the proof part could be moved to opaque this is what we talked about indeed in uh in Kenya uh the proof part should should be opaque

currently it's quite useful to debug so I don't want to do this if I can uh if I can prevent it um but uh yeah like the the stems and everything like this I mean we could make demop as well but it's so useful to debug at the moment that um I would say the cryptographic part I don't I don't really care anymore um we have libraries that that work I mean not everybody in implemented proof so it might be worth just keeping it this way a tad longer um but currently um currently I think it's a good idea to to leave everything in the clear even if the if the proofs are larger because it's really really useful to thebug

cool anything else on that topic yon uh no yeah I think uh that's a good uh that's a that's good feedback we we need to think about this but yeah currently uh let's just build one test net with h with this format and see if we find any problems don't expect any but um yeah it will be it will be quite useful sounds good uh next up there is a potential issue caused by the removal of empty accounts from State uh the interaction of that with EIP 7702 uh gu gam did you want to up right uh so no presentation for that but um yeah so the idea is

that until now so there was this EIP I forgot the the number I think it's 6710 or something like that or 7410 something um it's about uh deletion sorry it's about uh collisions if you find yourself um creating a contract at the place where an account exists already and uh it this account already has storage then you need to delete the storage um this is what the dip said if I remember correctly the problem comes with veral uh because to check if an account an EA has storage you need you

simply need to check the the state route but that State Route disappears with veral um so there are several uh so until now this is not a problem because we don't really have any uh way that an a new account that would be empty uh could have U Storage right but um but now because of uh 7702 you could actually create a uh contract or uh you could create an EA that has zero nons some balance that you could transfer during the execution of uh of that uh 7702 transaction so

because you delete this um because you transfer the the um the content of the balance then the account effectively becomes empty um and so it should be deleted now the question is how do you delete a vertical contract there's a reason why we uh deactivated self-destruct I mean there's many reasons but one of them is because deleting uh an account in a veral context is uh an account with storage in a veral context is is impossible um and now with 7702 there's a new Corner case in which an account could be marked for deletion because of

uh EIP 158 but at the same time uh cannot completely be deleted because uh if it has storage then um we don't know where that storage is there's no storage route there's no there's no indication really I mean even if there was an indication that an account has storage you still have to find that storage um so my uh I had a couple conversations with people from the guest team and we came to the conclusion that either you completely disable storage in 7702 or uh and I think those two things are independent and both should be done in any way uh we should just uh get rid of EIP 158 at least uh make it more like

the self-destruct in 76 uh sorry 6780 namely that if a contra if an account gets created during a transaction and then automatically gets deleted or becomes empty uh then 158 should still apply but if um if it it's already present in the state then it should not be deleted so exactly like self-destruct it's basically matching uh EIP 158 the be the behavior of EIP 158 uh to self-destruct and and uh yeah so this is basically what we uh we the guest teams think is the best idea the best approach

um I wanted to know if there were questions push back uh counter proposals I have I had one question regarding the second part where like uh I think it's the behavior right now as well that like if if there is something the account is created in one transaction and if it's empty by the end of the transaction then we delete the account but I remember we had a discussion during interop like related to storage that if we set a storage value and then we like like set it to zero again and we used to delete it in the current testnet but we decided that

if someone is paying paying the like uh cost to fill the storage value the trunk Fill cost so we should not uh delete it because then the user will have to pay the cost again so like wouldn't the same uh discussion also apply to accounts like if in a transaction someone creates account that means they are paying The Fill cost uh for the account and if you delete it at the end of the transaction and in the new transaction someone creates with that same account again and they have to pay the cost again uh so yeah just question around that right that's a good point uh well you are not increasing this State the the size of the state so yeah you should not ideally

pay the The Fill cost but there's no way we know beforehand that it's going to be deleted uh at the same time uh yeah it's if the contract is deleted or the account is deleted and then someone recreates it uh doing the the same thing it makes sense they should pay The Fill cost um right um so my guess is uh I'm trying to remember what did we say again uh sorry to ask you to repeat but what did we say back then that if you pay the FI cost then the thing should be created after all uh yes so for storage we I don't

know why but we didn't discuss this for accounts but for storage what we decided is like if someone paid the cost once then just add it to the state don't delete it even if it's zero at the end of the transaction right that's fair um which would correspond actually to a to a complete deletion of uh sorry a complete deactivation of8 yeah Dan you want to say something um if they pay it and having in store it that's got Echoes of the of the broken meter attack of the Shanghai attacks and I don't think it's a bad thing to charge them for um the account creation if the account never gets persisted because they clear it out um I don't think we want to encourage such transient account uses

um and to create code to support special cases I think would unnecessarily make the code more complex so I don't think we should encourage this pattern but if I understand you correctly uh that means that we would not be creating this account and then oh yeah someone would keep paying is that what you say like if people start uh yeah okay keep paying is fine because if if we let them persist useless accounts that's going to that has Echoes of the broken meter attack it may not be an issue but it's enough directionally that it concerns me very enough uh yeah that's a good point

actually so we would just go back on what we said at the interrupt but that's that's fine if Tanish or anybody else is okay uh I think I'm okay with deleting the accounts but I think we had other reasons to keep the storage and like so we can like create both of those like we can still not delete the storage like if someone clears the storage at the end of the transaction but we can delete the accounts I think the argument was I don't remember correctly what something related to when you do a reentrancy check you set something and then you reset it and like if you do that like every time the the check basically gets expensive I mean if I remember correctly

the argument was that that would be unfair because you are not creating the account or the storage slot in that case um but then someone would come and pay the exact same cost when it was actually accessed um which yes it's not super fair but like Danel said it would uh it would potentially be a make a a future attack cheaper kind of I mean at least it reminds us of the pattern um so I would yeah I mean I'm I'm I'm thinking it's a good idea to change uh to change

that um yeah just um I mean we can we can also take this offline I think that's that's there there are both I mean there are good arguments on both sides uh I'm not sure I got your counter tennish really what I was saying is that we can take it offline I think that will be better prop this okay cool yeah let's let's take it out offline then cool uh did somebody raised their hand or no all right uh next up we had sorry one

second oh yes uh so there was a discussion during interrup or one of the discussions was around system contracts whether they should be warm and I think Yom you wanted to possibly revisit this conversation here briefly yeah um so I when looking at how to implement this um I realized that uh yeah we would have to basically reinitialize the the access event list every time with every single account and then makes a bit of a hard dependency between several modules in gu so now I'm more or less of the opinion that we should not warm

anything um because it makes for simpler code basically it can still be done but it's going to be a bit ugly on Guess slid so that's definitely not an argument to impose a protocol change just because it's easier for GU uh but I was wondering what would be the arguments against uh or for um keeping it warm uh so that yeah maybe other clients have exactly the same issues maybe there's a very good reason to keep it warm I don't frankly see one so I would like to change my mind but I'm happy to uh to stick back to the old Behavior if there's a if there's a good um a good reason for

it for promiles you don't have to fetch the account you know looking at the account number if it's a pre compile and don't have to consult the tree so you're not imposing any expense on weing it that was the initial logic behind keeping pre-compiled warm and the logic behind keeping coinbase warm was that you've already loaded the coinbase tree data into Data just to begin the block um so it's actually not quite true right that we uh that we don't have to touch the the state because if you for example you do a block hash you do need to touch the state uh you need to find out what the what the block hash of the pre-compile is if you check the balance you have to do that too uh it's not stored in the pre- compile at least um

yeah looking right when this was done we didn't have the block hash and all pre-compiled were strictly calls there was no balance stored in any block hash it was relevant so if you I think that was loophole if you check the balance of a pre-compile but nobody can do anything with those balances uh no I agree no I mean now someone can do one thing which is to have them needed in the witness and so you need to adds to the witness and therefore you need to pay the the cost for it right but the beacon chain and the block has contracts are not packed into the first sets of contracts so our client detects those free contracts um just by counting

the number zeros and seeing if it's less than a number once we get enough zeros um we don't have a list we consult except for like coinbase which you have to put at the beginning of the block so for us detecting a pre-compile is just examining the number and seeing if it's one of the first at this point 32 I don't know how many smart contracts there are going to be but one of the first it was nine up until Cancun yeah um yeah I mean that yeah indeed that doesn't uh really um yeah that's that's easy to check but what do you do if you are asked for the block hash and the balance then so those are traditional um pre-compiled contracts go go through different segment of code

so and those are arguably system contracts because they keep State you know if you want to get talking about definitions of kinds of contracts compile just R code so if we were to change this I would want to see if my my proposal would be to keep all those preil contracts in the first um hex thousand blocks that don't keep State keep those warm but the other system contracts like Beacon chain and um blash those are not Pride exemptions and those must be warmed so that's where we would put the distinction and any contract that would keep state would not go in one of those special reserved addresses it would have

to be predeployment if because U I don't know maybe it's my connection but uh you dropped off a bit um you're you're saying that uh okay what what is the argument exactly to keep the system contracts warm for the transaction uh from the the system contracts the pre-compiled contracts I'm only wanting to keep the pre-compiled contracts that are below 1,000 hex those don't access date um those are just the swap in code there's already logic in there that we have to put in to see if it's like the um the EC recovery address we already have to have logic in to special case and switch that because

we're never accessing the account state to run those those I would propose we keep as the pre-warmed the the contracts they're not in that reserved space um like the the beacon hash and the block hash those can be subject to the existing warming rules okay warming rules being yeah okay pay to cold cost and then they're considered warm okay yeah right uh okay now that makes sense yeah because otherwise uh I mean if we start treating every single uh that was my argument if we start treating every single system contract as pre-compiled might as well make them pre-compiled um yeah okay that makes sense um I thought I had a question but I can't quite remember right now

um right now block has and Beacon route are not warmed right right so we we would keep it this way right the question was with the coinbase as well um the argument would be that it's currently being warmed or um I think it's already being loaded in the state by to a block being processed but it's uh it's done that's done at the end of the block oh it's done at the beginning of the block is it okay uh well the loading of it's done at the beginning of the block now um because even if it's done at the end of the block sometime during the block the system is going to be responsible for loading and paying for the cost of the coinbase

okay um yeah okay I I'll have to check the coding guess but maybe uh I mean it's probably it's probably true um and uh okay so that's what we would do then um we would warm the contract we would War the system contract yeah Tanish uh but then like we have the same problem uh with coinbase as with system contracts like we'll have to like add it to the access list every time for every transaction the argument that we have for system contract not warming that them up the same argument kind of goes for coinbase then no that's not quite true um I mean it's yes it's it is indeed similar but

you don't have at least in gu you don't have dependencies on other modules like the like the the states it's uh you know what it that coinbase is uh and it's just the address you don't need to find out which of those storage slots need to be accessed and things like this so it's it's it's less complex let's say so while I agree that yeah there's a lot of similarities it's not completely the same and complexity wise I don't think it's as bad okay that makes sense but again like from outside perspective like people who don't know code like from that perspective it is because system contracts also gets executed before

block processing so technically the logic we have for coinbase is like it's already loaded in state so technically system contracts are also loaded in state so I'll say that but let's keep same similar behavior for both coinbase and system contracts like yeah right the problem we want if we want to not warm coinbase I'm fine with that it's just we're going to get pushed back because this was a request from some Downstream users so there's going to be some uh people trying to defend that decision because it really impacted their cost so that's I can go either way on this but that's just what I'm worried about I'm not very like specific that it

should be like this just that like I feel that the both kind of fly in the same category but if there if there is like um reasonable like uh like if if we want to basically War the coin base I think it should not that that become a problem I think it shares the same fate as warming block has so I think we put it the same bucket okay um so okay so from what I understand we agree to continue warming the the block hash precompile as well at least the one that got accessed during block

initialization I I understood that you're not warming system contracts I'm not sure what's like yeah are are we like warming all the system contracts or are we not warming the system contracts yeah I mean we call warm it all right that's the that's where the complexity comes from uh we have no but either we warm all the system contracts or we don't warm any at all like I don't like this where we just warm the block has contract and we don't like warm let's say beacon block or any other system contract that we using yeah no I agree yeah we definitely need to to be consistent I agree uh yeah I'm just struggling to get a

reading on what you guys really are saying like uh am I getting some push back for not wanting to warm the system contracts or not that's that's the part I'm not clear about I think the conclusion was that we are warming pre compiles coinbase was a dicey thing but I think we agreed to warm and then we decided to not war system contracts that's what I understood that's also what I understood but I it was it wasn't very clear Ginder yep uh if you can hear clearly so uh I think what we should do is that whatever state gets War gets accessed in system contracts it should be kept as

warm because anyway we will be adding it to excess witness and most of our Logic for having warm or not warm cost depends upon whether they are in the witness or not so whatever gets added to witness gets gets warmed up if we just follow the simple process I think it should be good uh but right now we like have access witness per transaction and not per block so I think the initial argument was that like if we keep system contracts warm then we'll have to basically replicate that for every transaction and that was the complexity

part as far as I understand because like for each transaction we have yeah sorry I think our exess witness is sort of global uh we we keep a global one when we create the execution witness but while charging for gas we don't have a global we charge per transaction like if something gets accessed in both the transaction they like pay the exess cost appr I think that shouldn't be the case because uh if for example we have something warmed in the state but I'll check in ethereum JS but I think it it

is sort of global and but I'll recheck no it's not it's not Global at least that's not how it's speed um and the reason for this is because we don't want to have some uh to promote some games where you just warm stuff uh you know let people like pretty much create new me games um where you just uh wait for someone to touch one location to be able to execute your transaction behind and create a lot of complexities this way so this is why you have a PR a per a per transaction um witness I mean the witness is global yes but the charging is done as if you started from a fresh witness every time

okay um I think I heard the arguments I was looking for um I'm going to mul it over so thank you for for your input and uh we can uh we can take that offline or discuss it again in two week I think it needs a bit more more thinking uh yep cool thanks cool okay uh last up is Gom actually your PR for the gas cost updates I think there were some open questions on that PR that you wanted to discuss uh I'm trying to think uh was it um the gas cost update sorry something wrong I just dropped a

link in the chat not sure if that's the pr that you mentioned you wanted to go over here you have some open questions around that maybe I'm getting something confused oh yeah yeah absolutely uh but wait did we not have a 2935 uh thing to do before uh no so I I chatted Gabrielle correct me if I'm wrong uh but I don't think there's anything there to to discuss on this call unless or anyone else correct me if I'm wrong on the 2935 topic yeah I personally don't see anything uh additional I'd like to discuss but maybe others have things to discuss okay um yeah I mean we we can uh I guess

we can schedule this for next time then um yeah I mean I had uh so in in that case we've got uh we've got this update to the 4762 which is basically everything that has been discussed during the during the interrupt uh there's been some questions left so we should resolve them uh but it might be a bit tedious for everybody who's not involved in this uh in this uh conversation so given how little time is left in that call I suggest we schedule maybe a breakout with the people who are really interested in it so that we can

resolve all those questions what I would like to know is if there are still some open questions about about um about yeah this whole EIP update um did people want to give more push back um yeah otherwise uh I don't know we try to we try to have a meeting maybe tomorrow uh with everybody involved so I know that would be gender and and ignasio and presumably one person from each team I'm trying to look out Tanish of course um and yeah I assume B will want to to say a word as well um and uh yeah that's uh that's basically the the question I mean I can

go over but it's going to get very uh very tedious for for most people so if everybody wants to drop off except the interested parties we can start right now uh but otherwise uh yeah we could also call it and uh and and have an offline well offline uh a later online uh meeting maybe tomorrow yeah Mario you have a quick question or you want to drop that in the chat um yeah it's it's really quick but it's completely unrelated from anything else so is that okay sure yeah of course so um just is is this question regarding

the stride that we use to configure the tests um so it's got my attention that it seems like it's necessary for us to uh fill the tests with different values for the stride during the vertical conversion because there are some issues that have appeared with some configuration of the stride and some issues that haven't appear with a different configuration of the stri so my question is uh whether decline teams support this the stride being a varable either by being configurable in the Genesis or somewhere else um yeah because we plan to fill the test with at least multiple configuration for the stride um y basically that's the question I mean guest

does how how does g configur that right now uh there's a um I'm not sure I think you can get it in the config but uh yeah I can I can send you the the config option if it exists in after this call but for sure you can use the option like the command line option dash dash overlay sorry override do overlay stride maybe I should write it um but yeah it um you can uh you can um uh specify it uh like this all right all right so yeah the idea is that um we can generate the

tests with a given value for the strip and then we can run them either when you when you guys consume them consume the the tests as blockchain tests and another another run would be on the on on on the full instance of the client so this should be configurable in those two parts so blockchain test consu consumer consumer and also just the full full instantiated client we should be a also to uh configure configure it there so yeah what do you mean by strip the amount of leaves that are converted during the veral compression okay okay mhm so yeah um yeah that that was all

the question yeah I will try to dig a little bit more into this to see how we can uh proceed with the with this thing thanks cool thanks Mar uh gam are you okay with um if we do a separate call up to you and yeah anyone else uh 2 p.m UTC works for me 4 P.M yeah that works for me we can yeah finalize the time async I guess and uh yeah get that figured out okay cool uh anything else in the last uh couple minutes before we break one small thing that comes to mind uh we there were discussions about pre-image distribution when we were at the

interrupt there's been you know different ideas thrown around uh I don't see this as being resolved right now there was also a proposal from me that we could consider also adding these uh you know just the preimage that have been converted on each block inside of each block so that at least people can sync and verify blocks even if they can't propose blocks uh I think that would be worth discussing I'm not sure if we want to discuss this in this call or doing separate breakout call for it but it it seems to me like in the general vergal Fork topic this is the main main pain point at the moment so it would be nice to make some progress on that yeah agreed maybe we can reshare

your proposal in Discord see if we can get any comments on it async and then schedule it for the next Vic if that's not too far away yeah that sounds good to me yeah so just to answer uh the point that yes it's urgent but at the same time there's been a few discussions during the interrupt that uh you know wanted to maybe use EIP 44s like what whatever comes out of the e44 effort to do pre-image distribution um so I would like uh I mean okay the reason why it dropped dropped out of my mind was because of that uh but yeah sure it's it's a very interesting topic and what you had is a

very also a very interesting idea uh I don't think it solved the problem entirely because uh uh because you still need to distribute pages to some people um but uh yeah I think it should be discuss so I'm happy to schedule it or have a breakout session next week yeah whatever people people feel is most useful I'm done well yeah we'll get that figured out whether it's a separate call or on the next Vic the link in the chat here and then I'll also share it in Discord I I don't know if this is this is just my kind of quick summary of of your idea Gabrielle I don't know if you have a better

document somewhere but um cool okay anything else or should we end it there yeah that's the best document I don't have any uh thing better than what you written so yeah thanks okay cool thanks Gabriel all right well then let's end it there thanks guys thanks everyone for joining talk to you guys soon thank you byebye you bye byebye