Verkle Implementers Call #19

Transcript

hello welcome to veral implementers call 19 uh this is issue 1064 in the PM repo okay starting off with client team updates who would like to start things off I can do a eum JS so we are working on a veral try uh implementation while waiting for the next test net to test on we are we should be ready for cost and 7 in terms of gas cust updates and like the basic Leaf data and the way these things are are going to be now architected um so I can can continue

with bzu uh s the Java client um on our side I think the um in terms of the gas cost was decided to to to wait for a little bit more uh stable spec I don't know how like so I missed a couple of the of the of the last uh implemental call so I'm sorry if I I missed some some things but um I think the the team decided to to wait for uh test frame frame framework uh for the gas cost um we uh meanwhile are uh thinking about uh the migration the sync

and uh uh and how um in particular we can uh retain the the plat DB while doing the migration uh so there's an issue uh that we have that um uh since we are uh storing uh with veral try uh the flat like sort of the flat DB is by STEM it's like we we we store the values by STEM and we index them by STEM that comes from a hash from some sort of a hash from the account and and storage key uh but before we had uh get check of the of the address and get check of the of the code or something like this um we

can retrieve that information from from the stem so we are wondering if we'll be doing uh you know like sort of two reads to to make sure that we like you know trying to read in the verticle or if it's not there then trying to read uh in the old flat DB during the migration we're trying to avoid that and we are not exactly sure how to proceed at this point uh but that's yeah so that's one of the question and I don't know if like uh Gary is there you could comment more on the on the gas cost uh but we also have uh meanwhile also another thing is the um we're trying to optimize the storage uh between flat DB and the and

the nodes what we're going to store so that's where we are now okay um yeah we've been uh working on the test frame work and like adding tests so both I and ignasio have worked on different aspects of it with with the testing team of course um and otherwise yeah we've been collecting data to uh study a series of U answer some questions that have been asked over the years or over the last few months actually uh for example the the extra gas consumption with or

without eof um or the size of the witnesses things like this uh also the the size of the like the time it's going to take to make the transition uh we don't have so we collected the data we don't have a complete analysis yet uh it will be published uh yeah in hopefully the next two weeks um or yeah before the before the end of the summer for sure and um we were also working at uh uh the spec upd changes um I think yeah I mean we we kind of had an agreement

so addressing what thas has said um we the spec is pretty much uh set in stone it just needs to be updated so this is what I'm doing I mean it's never set in stone until of course it's been uh released but we we have a pretty clear we have a pretty clear vision of what we want to achieve now uh yeah I don't know you've got something else to add um no just to expand a bit on my side on that is uh for uh 4762 6800 and the other one that I don't remember the number

um yeah um I I already finished the the spectors uh everything is a bit on the air because there are some Library changes that we need to do for them to be filled um but I already assume the 4762 gas changes that we have been discussing so probably after the testing Library um pending changes are done and all that I can probably uh fill all these test and as soon as I have the fixtures generated I can share that with other clients for them to run um and

regarding um this other analysis stuff I've been collecting around uh 1 million main transactions on the tip of the chain the last few days using the GU live tracer and my idea is to um basically collect all the program counters that all the transactions um touch when running and using this to simulate um how much gas the 31 by chunker and 32 by chunker will use um first you compare both options because we have like some theoretical

understanding on pros and cons of them but um I mean the only real way to really know is by like kind of simulating them on real transactions and apart from that comparison just knowing uh how much uh of gas overhead uh will cod accessing add two transactions which is pretty important to to know from data from real data so um yeah probably in the next big call I will have some Report with all these um and I can share the results and we can go on from there

cool uh any other updates uh yeah uh so no major updates from nether mind we're still working on improving the cryptography performance and like getting the S to work I probably have some more updates uh in the next week I just add one comment I think the transaction further is not working on the the question six test net so if you can fix that it'll be better to test the S cool anything else any other

updates anything on the test testing side hey guys yeah so um I believe last time um last time we we spoke we had the transition tests working um filling and executing on with some failures um but that ended up um being somewhat incorrect so we had some false positives um of I guess the the test that that we filled and this was this was on our side um but now we've uh We've resolved the bugs for that H for the most part um

and um we're now filling and executing the transition tests on gu with um yeah very very uh small small number of number of failures so there are uh I believe 12 failures right now all specific to withdrawals and I'm fairly confident it's um a small bug on our side that I just need to um still need to fix but at the moment we have we have all of these transition tests passing on gu um we hope to make a release of these transition tests um for every client to to utilize um and uh during this process um there was a some back and forth with gum

uh regarding the transition tests and I guess it led to some some sort of Overkill way of how we can really throttle like overly test the transition especially on the transition block um I can maybe share something real quick if that's okay yeah sounds good are you able to share give me one sec you guys see my screen okay yes I can yeah yeah so um I guess the the the with regards to transition

tests the I guess the three types of tests that um I guess the conclusion we came to is pre prefork transition tests um the the mid mid Fork transition test in the post Fork um so with the prefork um ideally we want to um so I guess before I get into this um these are tests that we already have tests that um test many things on all the forks previously um uh so these are these are filling tests that we already have that we want to utilize um for testing verticle so yeah so the the prefork

transition tests um what we want to do with these is we want to um execute all the test blocks before the vertical transition block um so that the MPT is filled um and then afterwards we add some dummy blocks after the uh vertical transition block so that and we can verify that everything's executed properly and we also have uh these mid Fork transition tests um so this is where we execute the test blocks on the vertical transition block um so the basic approach is just

um for for existing tests and the first block the first test block for an existing test and that block would be executed on the vertical transition block but ideally we want to update our framework so we can and for example let's say we have a test with with four blocks we want to execute each of those four blocks on the transition block so um for one test um with four blocks we' we that would essentially um output for um specific to the test block executing on the fork transition block um and then we also have these kind of p uh post Fork transition tests

where ideally we start with some dummy initial MPT and we we perform from the vertical transition and then once the um or once once the transition starts and there's some stride enabled and we'll then execute these test blocks um and we can get kind of somewhat crazy with this um at least with the way we fill the tests um so the I guess the most basic form would be with zero stride which is what we're doing right now and um for the the pre the prefork transition tests and the mid Fork transition tests um with no initial additional

MPT um but ideally once we have these tests ready and clients are passing them we will then um I guess add some initial MPT so we have a really large MPT um and then also stride as well so and we can kind of fill these tests um accordingly um and my hope so this this is specific to our framework but my hope is that we can fill the tests with these kind of fields uh true so if we want to fill the pre fill tests for prefork transition mid Fork transition horse Fork transition the amount of um MPT accounts um add additional npt

accounts that we want to add and also enabling right so ideally we can just write the fill command with these parameters um and very easily generate the test that we want regarding the transition specifically um and yeah my hope as well is that we can kind of make a make simple releases first and then build on top of them and make them more complex um but yeah currently the tests we're focusing on for the transition tests are these mid Fork transition tests the basic approach were just the first the first test block that we have is executed on the the vertical transition block um and yeah that's that's kind of it with regards to the transition test

it's something which um I personally overlooked when we were generating the test before um but it's a step in the right direction um and yeah so just to summarize that once we finish um get finished with the basic transition tests and we'll create this release and then um we'll focus our attention on all the test vectors that ignasio has been writing um for the veral specific eips um so then we can fill the um the Genesis test so starting at um starting at veral um if anyone has any questions regarding this please speak up if you

think this is a good approach um or if we can approach this better um uh I just have one question uh if I may so you're using uh changai uh for the pre-transition uh so most likely will be Denon for pre-transition and you know even if we do pass this one you know do you have to rewrite those tests for uh benun or maybe we could just focus on because writing the test anyways might focus on uh then to veral transition

directly because I think uh it's not going to be much time after maybe you know three or four months that we uh sort of you know uh hack you know continue doing this hacky way I mean nothing against it but you know there something to think about no for sure that's a great question so I guess the good thing about our framework is is that it's um written in such a way where you can fill from any Fork so it will um on our side literally be changing the fork name um and it should just work straight away with filling filling the test from tenun

um hopefully no worries uh cool awesome thanks for sharing this any other questions or comments on the stuff cool uh up next on the agenda code size in veral and whether it might make sense to raise that to something as high as 2 gigabytes Dano So based on the comments in the is I'm not sure what the current state is but the basic concern I have um right now

code sizes are limited to 24 kilobytes and there's a lot of pressure from the um solidity Community to raise that number um you know we could one of the issues why we don't raise it now at least prior to Shanghai was concerns about jump test analysis and having to do that jump test analysis um every time we load the code from memory um because of the way veral well two things happen number one um we charge for init code now um when you deploy a contract so if you're doing the jump test analysis when you're deploying the contract we charge you gas for that so the size of the analysis really shouldn't impact the system because it scales linearly with the gas cost um so creation at uh so the analysis at cre time shouldn't be a problem um however

what veral adds is an interesting twist is they kind of store and cach some of this analysis in with the code um whether they're going to do the overhang method which is the current plan of record or whether we go with ipsilon bonds Only Store the places that matters method um that analysis is cash so when you load it from um from the veral tree you don't have to do the analysis and in fact because you're loading it chunked you can't do the analysis um except for the stuff that you do it with So based on that it would be reasonable to increase or uncap it um there are contracts that um there's a diamond pattern where contracts are currently using to deal with Li's limitation by switching between the various contracts and some of those are easily larger than 64k um I don't know if they're going to get

up you know much larger than you know um they're probably not going to get two gigs in the next five years but the short answer is that using two bytes to store the code size I think is something that's going to become problematic in in the near future not the far future um as in within months of the verical um Fork the next Fork we might want to increase it and we don't want to be up against the limit when we decide to increase it so so my pitch is that whatever we do for it the code size in storage is it is it's more than two bytes um three bytes would be better that would give us 16 megabytes um I don't think in you know three to five years there might be you know reasonable contracts that aren't explicitly trying to exploit the memory

size that would Target that but you know as far as um design processes um casting four bytes to a native um data size in a programming language is a whole lot easier than casting three bytes for Native data size it's a lot quicker so if if we were going to increase the size four would be the next logical by length to do it with but generally speaking two is too short um for the solidity Community um yeah sorry I wanted to raise my hand but I couldn't find this thing oh it's right here okay uh I have a couple questions so yeah 16 megab that was actually going to be a suggestion I

was going to make 16 megabytes uh because right uh this this is what I've wrote in the issue uh currently I don't see uh you know 4 gigabytes worth of code being uh ever practical right unless you have a different insight into this uh no one will ever deploy even two gigabytes right um you know 640k has got to be enough for anyone for a PC it's hard to predict the future Beyond five years but I don't see it happening within five years okay um right so what I was going to suggest is to uh So currently indeed in the spec this is I remember having the

conversation that you mentioned during the like in the in the issue um I remember I remember having this conversation and yes we we were discussing 64 as a limit saying it it would be I don't exactly remember what the full context was but I remember what we sort of agreed on which was um 64 right now and then in the future we could expand okay so now you seem to think or you you think that uh that we are going to need a higher value pretty quickly which which is reasonable my my only five years yes within five years okay fair enough uh which you know I mean depending on how long Petro takes

um might be okay I'm not going to say veral happens in 5 years but looking at it veral is not happening before uh end of 2025 at best in the really very best of cases um so five years is like tomorrow uh so that's that's a good reason to to expand what I was uh saying like my my semi counter was uh I don't want to allocate bites that are going to be uh you know sitting there unused when they could be used for something else like there's other people suggesting uh so if we if we make the code size two bytes right that leaves us five five

Reserve bytes in that uh in that basic data field right uh there's a lot of people eyeing those those five bytes uh at least there's a few use cases maybe not a lot but a few there's uh Resurrection counters for a state expiry for example there's uh definitely State uh soorry there's definitely code size uh there could be other other extensions like like if we want to do c obstruction things like holding the holding for example a bit for whether or not uh whether or not the the contract has storage um yeah there's a lot of people contending for this but uh three bytes I would be quite happy with

that uh my my question is uh what did you say three byte like four byte is better than three because you could just apply your mask and that's pretty easy to do right unless I'm missing it is easy to do it's more bites it's more hassle it's more ways to make mistakes um in in the absence of um resource uh constraints that would be preferred um but if resource constraints are legitimately strong then three bytes would be better than two so what I would suggest uh is that we reserve three bytes but we kind of uh so we we put like uh the way we organized the those 32 bytes for the for the basic data data is that we put uh

the zeros in such a way that if we ever need to expand three bytes into four uh you know it will have priority basically so I would say we put uh the version number then those uh four reserved values then those three bytes then whatever is left in the basic data account so this way uh the code size can spill over into the the reserve size if if need be fairly easily what would you think of that so what I me that would be fine we would need tests however um to put um to fill in those reserved byes of values and make sure that things still par so we could if we reserve those we need a test that those don't interfere

especially with the design spill over um that is one test particular we want to make sure that people don't just take those four bytes and rely on that Reserve bite being zero so we would need testing to cover that case right yeah fair enough um I I can add yeah Ino just was going to say that 3 by sounds good to me and regarding like where to place them I think it's it's not really that relevant because if we want to expand this we have to set up a new version so the whole interpretation is different so this is not like placing them in another place kind of facilitates anything because if we if we

want to use those spites we have to change the version and that's a completely different interpretation of slots so like if if it was like a minor version where it's a forward compatible change where those have no meaning and the 1.0 but the 1.1 have meaning I think clients could handle that but if you're changing the order of things then yes you absolutely need a new version yeah that's what I was going to add indeed uh you don't really need a new version you just need a new Fork to say well this bite used to be to always be zero but now we remove the 16 megabyte limit so beware that that fourth bite can no longer be uh zero all the time and this way you would not have

to create a new version that was uh because honestly I would rather Reserve those four bytes right off the bat instead of uh forcing a new version uh just for just for a code size like a change in the size of the code size but my anticipation is that a transition from needing less than 16 megabytes to more than 16 megabytes is going to be at least five years off and is probably going to involve a new version would be beneficial anyway so it's not the worst case scenario if spilling over requires a new version okay okay fair enough uh I'm still going to modify CU I'm I'm currently editing

that EIP I'm still going to edit it the way I um yeah but at the same time I'm just thinking those Reserve bytes would probably be like I mean correspond to a new version anyway so might as well maybe I'm just being overly cautious here it preserves design space we don't have to use it yeah yeah okay let's do that then uh I'm going to say three bytes put them really at the big right right after the reserve space so that we have indeed uh an open design space in future and I will share the the updated EIP so that everybody can can give feedback and and disagree thank you appreciate it um it

solves a lot of problems now that we won't have in the future because we have more options for space sweet cool if nothing else on that topic we can move on next up we had uh any discussion on the test net relaunch just because we don't have a lot of time left on this call maybe we can try to keep this relatively short um I don't know gam did you have any specific things you wanted to ask with this testnet relaunch yeah I mean this is a question I want to keep asking until we seriously look at restarting the test net so the goal is still to restart the test net around Midsummer by which I mean like end of July right uh this newe test net would

have a few of the buck fixes that were uh seen on the current cting test net just uh add the new guest model the one we agreed on um at the at the interrupt and in the meeting last week and also finally implement the The Fill costs uh yeah the question is very simple does anybody else want any other feature for this otherwise uh I mean I will keep asking at every Vic in case people change their minds we still have about a month to to to the launch uh so teams should be working on the new test net which I think every team does except us uh but yeah basically the question is

any other wish list for this for this test net are we going to have the pre-state route included in the execution witness sorry I might have missed some of the updates that are going to come in the next test uh you're right I the the the answer is yes but I forgot to to write to write that down so yes we would we would put the new test route in this uh in this new version all right cool thanks sounds like no other wish list items for now cool uh then we can move to the last

agenda item we have a discussion around pre-image distribution we had some of this discussion at the interop um there's been some more recent I guess discussion and ideas tossed around so just wanted to I think a few people wanted to open that back up uh anyone that wants to start things off I know Gabrielle I think you had some some thoughts you might want to start with there yeah sure so pretty much distribution we discussed that that at the interrupt one of the ideas that came is uh well during the transition period uh well as we all know the issue is that well the the some state is accessed uh from the Frozen MPT and without um we're

not able to convert to the vergal try unless we have the preimages now to most of the if someone does not have the preimages they would be not able to syn the network right because they wouldn't be able to access the state that is necessary to execute the blocks now we have some space during the transition period uh because the exe execution witness is not actually uh useful until the full transition to veral so what came to mind is why not use this space to provide the actual cre images that have been converted so a block could contain all the list of the

addresses with corresponding like story St slots when storage has been accessed leading to the leaves that have to be converted in order to uh you know perform the the conversion from the MPT to the verbal try within that that block so we could have a field inside of the execution witness called converted preimages and then someone who's validating the chain would be able to access their own local Frozen MPT know which leaves to conver convert from these pre images convert them to the veral try and also uh execute the block the main issue with with that in

addition to the space that it uses which in my view is not really a concern because we can definitely like do without my view like the exe execution witness uh anyways during that period and the size that we're talking about is not that large the main issue is that you're still not able to produce blocks you're only able to validate blocks because we still require someone to have the pre-images locally accessible in order to to build a block and provide these preimages in the first place uh it reduces the the scope of the problem uh because in you can always delegate block building you can always if you want to

have the burden of building blocks yourself download them through your own means but at least someone who didn't go through that process is still able to perform all of its Duty as a validator except the block building part so I think it doesn't fully solve the how are we going to distribute the preimages but at least we have a a very interesting Plan B for users who don't want to go through the burden of storing that themselves uh yeah I was just thinking is it true though that we can uh like those those uh validators that do not have the pre-images can delegate to the to the builders uh I'm not so sure

because uh you know in the current model what we want to do is start the sweep of the iterator in the previous 12 uh minutes sorry in the previous uh the last four seconds of the previous slot and that means that if they don't do this at this time they will have to do it when executing the block that they are being given and so there's this first the first four seconds of the block when they would have to do this so I'm not sure you can actually pull this one off how interesting unless unless you could provide the future preimages to convert yeah unless exactly the preimages you you pass are actually the preimages for

the next block like the yeah that could work I don't know if it solves if it works but I mean it would solve this a specific problem yeah well if it depends like do we yeah I hadn't thought about you know the kind of processing when we want that processing to happen if we expect people to begin converting the preimages because before they hear of that block then we need to kind of front run it by block that makes sense yeah t uh even if we add the images uh like first like getting the pre-images for the next block will be a problem like we

cannot we will not be able to add the pre-images that we'll need to process the next block in the current block because again it's the same problem that we do the preimage processing in the next 4 seconds so like it will take end up taking much more time for the Val for the block Builder to like kind of process two set of uh like sweeping operations to generate free for the next block and and another problem with this is the first block first transition block will also be a problem well you can always make at least the first transition block you can always make uh this sweep start just before like the block before so you would initialize it this way uh yeah

also start the sweep one block after and the first block is just you just indicate which ones to sweep in the next and then begin sweeping but this this whole like if we had for example an exhaustive list of all the leaves that have to be converted like with with the pre-images that's frozen at the transition time right so the let's say we just decide based on ordering that we're going to convert 10K leaves per block this is the terministic from the transition time right so someone could in theory just have all of that like ready

uh way before and of course you have to actually update the vergal try the right time so that the state matches but I don't see why it wouldn't work to just announce it one block before so that people have that time to begin the processing yeah I think then we'll have to like go back to the model of pre prees where like everything is sorted in sequence and that again that the problem with that was that the size becomes quite big because there are a lot of repeated pre-images but I think if uh like it's kind of a trade-off like if we want to do this then we have to go back

to that uh image model where everything is sorted into in a way that it will be sweeped um yeah I think I think we can do that yeah there's been in in pre-image distribution uh discussions there's been mentions of like if we want to exhaustively distribute the preimages to all clients and have a in protocol way of like signaling that that's also uh that can also be you

know challenging to to for you know clients or or nodes to be able to announce that that also requires some you know additional thought and coding if we at least have that and I still see this as just a backup plan I'm not really happy with people like delegating block building I'd rather have everyone have the pre-images I'm just saying that it's such it seems like such a like engineering challenge to get like everyone on board that I'd rather have a like somewhat satis Factory backup plan to validate blocks and then uh have a a smaller scoped distribution problem so yeah we kind of can do away with like just

allowing a lot of time for people to download it but not having uh requiring people to Signal it in protocol and then begin the transition at that point which is something that was mentioned as a proposal yes on that so I think uh the pre images should be there in the previous block uh Associated to that is the question how would you know what pre-images are to be considered for the next block now at the point of uh Frozen Merkle 3 there would have to be some sort of an index uh that you know from n to n+ 10K you're going to convert to to

vle but say there is a bug I 10,000 leaves have a few discrepancies with another nodes 10,000 leaves which might or might not be acting maliciously uh by putting it onto the block we might uh have another angle of debugging as well so I'm not saying like do away with uh redistribution but I'm saying have both of them yeah yeah the I think even if so I'm still assuming that clients would like there's no ST lessed execution at that point right so everyone has the local state including the Frozen MPT and I I don't recall exactly what

the conversion like spec is but my understanding is it's defined based on like the the key of the leaves so even if if blog Builder proposes like 10K uh pre-images you're still able to validate that these pre-images correspond to the actual Leaf keys that you have locally let's say you sorted them somehow that you know that the next 10K are the ones that have to be converted and if there's one missing or there's one extra or like there's a gap or it starts at the wrong place the wrong index then you're able to like refuse that block so you're still able to perform all of your conversion duties except providing the

actual pages to be converted yes but there has to be a confirmation in protocol that you know the Frozen MPT is exactly the same for everybody of course there is the route I'm not so sure if the indexing uh I don't know so I we're just assuming that you know everybody's going to use the same index um at that point so it's a fair assumption yeah yeah well I maybe G you can uh describe I'm not sure myself like how were we planning on having consensus and which leaves have to be converted

with which block right so the way it happens is uh simply a lexicographic enumeration of the tree right so everybody I mean maybe not has the exact same index in terms of database indexes but everybody has the same uh View the tree right because it's the last block that the last MPT block so everybody has the same content so everybody can iterate and everybody should provide should uh see the same iteration of accounts and then for each account if they State you also iterate it in um in you iterate the leaves of the storage in lexicographic hash order um so what this means is that yes

you can verify like if you're given a block with the prees for the next block It's relatively easy it's a bit IO intensive but it's relatively easy to check that every single one of those preimages correspond to um to to to your next 10,000 leaves and if those 10,000 leaves don't match the preimages that you are being given in the specific order that you you have been given it then uh you should reject the previous block because that means there's a disagreement on the state of the Frozen MPT and in that case uh you are on a different Fork uh that happened at

the that happened before the tree was frozen basically uh Perry said something yeah I can also just read it out um how will this work if the last MPT block comes in really late or if it's theed out would you then just restart the transition with that being taken into account um thereby just delaying the first transition block or okay to use that is already finalized okay cool I think we want to go with the finalized oh I just saw the message from yeah thanks right and uh I thought you were

actually asking something else if a reor happens during the conversion process so the MPT is finalized but you might have to replay the the iteration of the of the tree itself uh this is what you have to do in case of a reorg anyway so it's not uh it's not connected to the three Imes I mean that's not the question you asked it's just a Precision I'm I'm giving for a better understanding yeah be curious to hear do

people generally feel like this would be a valuable thing or uh I for one think it's a good idea but it doesn't solve the the core problem but it like you said it makes it more easy it Mak it it makes it easier to handle so I'm generally favorable to it um it's just my opinion of course and uh I would I might change it after I Implement things but uh yeah I I think uh the core of the problem is still there unfortunately but it's a it's it's a nice trick and it definitely is

helpful yeah okay that's my feeling also do we have a sense of implementation or complexity ad of of doing this my assumption was not a lot I don't think it's very much yeah gotcha I mean ask me again when I implemented it yes yeah yeah I got fre has raises yeah just a quick question um we are assuming here that for a missed slot um we do not do any sweeping right because otherwise um this due to this delay of one block at this doesn't work just to be clear that this doesn't allow us to do more sweeping or whatever more

transition if some slots were missed yeah we would not be doing any sleeping sorry sweeping um and probably no no sleeping either during this transition period uh but um we yes I think with this approach it's even worse to it would be even worse to actually have to to process because if you have a reorg uh that means your block that has all the preimages would be really would become really large yes but isn't that also a benefit of

providing the exact preimages to be converted or that have been converted in the block itself right this you can actually I'm wondering like that brings me to the the thought like since we've sort of just said that it would be helpful to have the pre-images not that have been converted in this block but the preimages to convert in the next block then what happens if that next block is you know empty I mean you might have begun the conversion process yourself but then you notice that this is an empty block and then you have you have to roll that back right you mean empty like missing slot or yeah a BL just a Miss slot like no block has been

proposed then the sweep happens in the block after that the first nonm slot after that so it's going to be useful anyway uh yeah yeah yeah yeah yeah I guess that works yeah that's right cool well I'm sure this won't be the last discussion on this question of pre-image distribution and maybe we can come back to it the next V or continue the discussion asynchronously which EIP is the

conversion process and like if I want to add this as a like a addition to an niip where should I add that is that 6800 no no no uh there's another so there the conversion has been described in two eips but one of them hasn't been created yet it's uh I'm still looking for the right wording for it uh so the first one is 60 7612 which just describe the overlay method but doesn't describe the conversion and the reason why the reason why it's split in two is simply because I expect people to say oh the conversion is a bit too much for this Fork so let's just go with the two trees and then do the conversion at a later

time it's basically to offer some flexibility uh so far people think they should come together and I agree uh but I'm expecting yeah I see it as some failure mode basically so there's another there's another EIP that should come uh but I haven't had the time to to do it yet to complete it yet um I can try to finish it in the next two weeks and ping you ping you then and then you can add your stuff to it cool yeah perfect uh we don't have that much time left but uh did Perry also want to

present something or uh or did they stream that per is here but I don't think don't think there's much to say but I can just bring it up as a general topic um there is like increased discussion around EIP for Falls and a thought around whatever methodology we use to distribute um the historic State uh the history in for Force could potentially be reused in verle as well uh but yeah that of course has the downside that for force is not defined yet and it's not smart to layer research topics on top of each other uh but yeah just a thought I wanted to put out there right I'm

sorry uh yeah my question was you also wanted to prototype this for for four fours um has work started on this yeah so there's one um proposal I made last week on E research that's using uh Torrance for four Falls um the main advantage of Torrance being that um they're an extremely mature piece of technology that has existed for 20 something years at this point and uh it gives us a lot of the feature sets that we already want for 4fs um initial reactions from C team seem quite good I think they're at least going to be playing around with it to see if it's feasible um I can link yeah uh Josh just

uh link the post um but yeah theoretically you could reuse the same methodology for uh PR image distribution as well cool anything else in the final minutes uh yeah maybe just add some information about this I have been working on uh on the conversion a bit in the last two weeks or actually the last month it takes about a day and a half to produce a uh at least that's what it

takes gu um actually not quite sure how long it takes uh Aran for example to produce this but gu would take about a day and a half to produce such a file Aron takes two hours that's nice cool all right well I guess we can leave things there for this week if nothing else thanks all for joining see you guys next time yep thank you thank you bye bye see

you bye bye