EOF Implementers Call #32

Transcript

all right hey everyone welcome back to the next EF call uh for this one we actually wanted to uh at least from Epsilon wanted to create an implementation Readiness Readiness Matrix um we did create the template for it but it doesn't really have all the details in it yet um I'm going to share it in the chat um I think it would be good good uh if you agree that this is like a good approach then this may be like good to keep updated and um everybody should feel free to create PRS and uh link to the uh the work or PRS they have um the

goal of this would be to judge where the implementations uh where the specs and the testing uh is in terms of Readiness um but since we don't have this uh fully ready for this call um let's just do like a usual rant first and then we can can come back to this discussion so oh Dragon yeah go ahead dragon mean was so maybe you should just start this time U I'm perfect fine starting but I don't have a lot to report I still need to start working on it uh I hope that

this is going to be the week the first thing that you need to do is like figure out how to integrate new interpreter new Stu site rvm and go with that yeah let us know if uh if you come across any any design blockers and um you know while trying to implement it we'll do thank you uh thanks um Deno you want to go next yeah um I've been updating our old big eof into Mega eof um the zero based index on our jump fee is something that caused us to update a lot of our tests the add addition of the

non- returning section flag um had update a lot of tests and a lot of unrelated tests because it changes validity of bof um did some validity changes everything's live in our Mega eof Branch um one thing I think we should add to the Readiness Matrix is is a location of where the current branch is um it has all these one of the columns I don't know if that's the measp column um but as far as Loose Ends we don't have create three and create four um updated yet we don't have Exchange in yet uh we don't have good tests for um dup in swap in we don't have exchange implemented I think those are the ones that are missing um so I almost wonder if

um we should also list the reference tests for where each one of those are for for these various spec versions where those are located as well um yeah I think you it's time to start doing Readiness uh Matrix so we can plug all the holes and start going down that path um but it's updating the test was more of the time than updating the code for the changes that went in so far that's my update that sounds promising um yeah we can come back to the discussing the Matrix should be um formatted after the round uh all right um okay any

implementation updates from ipsilon well since last week we've merged return data load and yeah finishing up stack validation new algorithm now it's also mostly fixing the tests I was updating state test that we have for St validation today and yeah almost this is almost done um yeah I think that's that's about it sounds good um Charis do you want to

give any updates from Viper um pretty much the whole Viper team has been out because of various illnesses or other accidents so sorry uh I hope you're you're feeling better now and the team as well thank you um all right we have someone new Meek saki uh sorry if I pronounce it wrongly um do you want to briefly introduce yourself all right let us know in the

chat if you if you want to talk later no worries um okay so that TR was quick um do we have any brief spec updates from ipsilon uh besides the implementation updates um some minor U fixes to the meas speec went in but nothing uh substantial just typo typo level errors fixed and um and also we are working on updating the eaps uh so the APAP

3540 the base ef1 is up for reviews uh so I encourage everyone to to if if you're up um for an earily review then just just take a look um because there's a lot of changes there and also we're anticipating the new create uh EAP so a lot of a lot of content on that previous AP got removed and um and I just pushed the pr for uh the data instruction EIP update which is much more I think that's

it uh all right then so maybe we could spend a few minutes on just discussing the the Readiness Matrix and and what other information we would like to introduce uh or include in it um I don't think we should you know spend the the call on updating the Matrix um but we should spend some time to agree on what we want to record um so maybe just a brief response to Dano what you said in the beginning so I imagine that uh uh yes we do want to link to to PRS where there's like a PR outstanding um I was wondering if we should do that you know it's a separate list below the table or we could also do

like a you know footnote style or um you know footnote style links uh where there's just a number next to the um you know next to the the cell um just to not you know overwhelm overwhelm it with all the data um so yeah what what kind of feedback uh do you have there so I don't know that we're going to have links to separate PR we have a separate Mega eof and um we would have to rewrite some of our old PRS to come up to spec with a new PRS to get a single PR for like say 4200 or 4750 um because it's it's already across multiple PRS with the with the big eof and then the changes coming from the

mega spec um so and also another thing we're doing in basa we haven't pushed it out to main yet it's being operated entirely as eof as a whole on a separate Branch so that was you know my request is that if there is a branch that you know has the mega implemented that's one of the things that's listed with each client so if you want to test it new differential testing you know which get repo to go to and download and which one has you know most everything um because some of these items they they interact very much and so having one branch that has one spec and one one one EIP one branch that has another is really

difficult for differential testing because you don't know what it's going to look like when they combine and merge together so I mean you know links to uh specific PRS isn't going to be you know ex maybe the create three and create four we could do that but for anything that's you know evolved from Big E we won't have that yeah I think I agree I mean in terms of um yeah I would say that the create and the stack instructions are the ones which you could I mean it's mostly just a stack instructions which um I think is kind of

separate um but then you know in terms of like compiler testing you do need all of it uh and I I did imagine that the the reason we we could track all of these individual ones just to see see you know where the the given implementations are but um I do imagine that there's going to be like one you know meas speec uh Branch uh in each of these clients or it's just going to be merged hopefully under some future Flags yeah so I think the columns are fine I just we won't be able to Del link individual PRS in each of the columns now for the columns I think maybe not in

this table maybe in a breakout list below it I think it would be useful to list where the reference tests and unique test cases for each of these are so we can use that as our objective to judge you know it's like are we done with 3540 well it's this list of reference tests and if you don't pass all of them you really can't say you're done so I think you know a list also pointing to because some of these are still coming into reference tests in separate PRS and since these won't interact in quite the same way as implementation I think separate PRS reference to the um PRS that are going in for the reference tests I think you're fine too because the tests can be easily severable from the implementation so I think you know that the test cases would

provide you know some example because then like say if if basu's got an issue with one of the grade 3es we could put you know uh X and do like seven out of 13 to give some indication some finer grade rather than complete U but what do you mean by reference test here uh so for example um there are tests for like the uh the jump the r jump operations there's actually two kind of test there's R jump validation which is under the eof test SL EIP 4200 is our jumps I think um and so those are under one directory but there's also going to be eof tests not eof tests

General State tests that will also exercise our jump I think those are already in um so link like either the pr importing them or you know a list of which directories in the uh you find the test for those and would be what would be useful for for those particular tests so the the eof test the test validation and the general state test the test execution um enumerating those or the PRS containing those I think would be valuable in a separate list below this Readiness table um but are you looking for a grouping and knowing which of these like directories belong to which feature set or are you just looking for the complete list of tests you need to pass um so the

complete list would be the the sum of all of them but I do think that if we want to break out in columns we should break out by group so each column should have a list of here's the tests that constitute Readiness for this feature and it should be as easy as pointing to a single directory because the reference tests are already fairly well split out by directors you point to a couple directories and say you can find them here here and here um all right any any feedback um or opposing opinion on that I would yeah first of all ask ipsilon because you know we maintaining most of the tests is um yeah is this proposal

linking for the specific tests feasible or are they kind of [Music] intermingled yeah I think it makes sense they are intermingled in some sense like in the same way like as implementation PRS are also cannot be one PR for one feature but there is split to directories currently and I think it will stay this way so kind of yeah at least some approximation of splitting the test exists and I think it makes sense to link them um all right and any feedback from um yeah dragon or chars on

this no not really u in the end does matter a lot some test are going to overlap some tests are going to be Standalone what's matter is that we have test that cover everything all right uh I think we will yeah I think the the the shape of the this Matrix is good then um we yeah I suppose we will add the links to the tests um and then merge it and then it should be open for everyone to to create PRS against and yeah we definitely ask all of you to uh create the pr uh and

Link or update your specific client or anything else in this um yeah Peter do you have anything on this topic otherwise yeah yeah I would suggest moving the meas spec from a column to a row and then we can put dick marks demonstrating that the meas speec is actually ready in 100% okay for each of those you mean for the eips yeah we just we just we just need to make the mega spec or or is the specs we have the specs row and the mega spec column so I would just have the measp row yeah we we can do that I wasn't oh yeah and decid yeah and then and and

then sorry and then an EIP row as well I don't know it's maybe a bit silly but it would demonstrate how ready the eips themselves are in terms of the content um maybe it's easier if I do a PR or something so that we can see what I'm proposing okay yeah yeah we can we can discuss that um also we should probably have a like an in progress icon for for example for create for even one it is very much in progress yeah yeah we can do that yeah I mean we have

similar uh similar similar icons on the Epsilon website uh for other stuff so yeah we can we have the working progress icon there um all right I think we spent 10 minutes on the Matrix so we should be good um all right so for the next call we should have this Matrix ready and the idea is that you know based on this Matrix we should be able to judge uh the progress and which areas we we need to focus on in order to uh finish those areas and it should also help us guide uh some of the conversations we have to make U because of that so I think going

forward the goal would be that you know coming into the call we should have like an updated version of this Matrix um you know to have like a conversation uh starter um is that is that okay uh are we are we able to to make updates to this you know PRI prior to the call okay sounds good all right let's move on to spec discussions uh Char already posted a link I believe which probably is a spec oh yeah the variable length en coding um

I feel like the variable length en coding is as a long discussion so I will ask if there's any other spec topic uh we wanted to discuss now we should start with like a shorter one uh anyone has any any spec points all right all right then Charles uh floor is yours yeah I um I think we already talked about it a few weeks go but um I just wanted to um kind

of I think there were a few kind of minor concerns um there's some open questions right the open questions are oh I should actually add these to the PR but um what do we do about R jump V and I think the answer there um the concern is that each entry is a different length right and I think the the solution there is just to make the length of anent Entry the same so it's um if you have like an R jump one R jump if if one of the entries is like one then you just need to Pat it with enough

zeros so that it's the same as the maximum length of all the entries in the in the jump table and then there was the exchange and swap in and I think a really good benefit of the variable length encoding is that we don't really need to choose or like add both of them to the spec we can just have a single Master swap instruction which um does some slightly clever encoding of which items to swap and I haven't exactly figured that out yet but I think it's

similar to that it's going to end up being similar to that spreadsheet that uh Dano made very nicely a little while ago where you just map each natural number to some in the SWA triangle and um I did make a little bit of progress uh after the last call that I was on which is I I added a reference implementation and I think there was a bit of concern about speed and I don't think it's really a big issue because it looks like um in general decoding

these variable length quantities is about the same as decoding big endian things so I think we're okay on that and I think the the there are really a lot of benefits to adopting it these variable length and codings because um one it makes the spec more elegant in my opinion and it also makes things a lot more future proof so if we want to increase contract size limits or anything like this we don't like um let's say we even want to increase

them 50% right then inate code needs to be increased by 50% and that's like already over 64 kilobytes let me check yeah that's 72 kilobytes and so you need to have jumps which are like larger than two bytes or the pointers are larger than two bytes and um it's going to be really difficult to do that unless all the all the pointers are already Dynamic length in the spec um did

you manage to implement some of this in in Viper by any chance no we didn't get to that yet because yeah like I said we all we all all the whole Viper team is out yeah I think last time the the two conversations were one uh should the encoding mostly be for the header uh versus the instructions and the second was specifically the r jump V uh where I felt like there was concern you know argm Fe is already kind of complic Lex uh making it even more complex uh seem

like a big concern yeah I mean the yeah I mean it's more complication in the encoding um which I personally think is worth it but I can understand the counter arguments here yeah probably the so one of the maybe different views on the implementations come from how you would Implement uh an evm interpreter

uh I think most of them are kind of like simple and they really go like uh you know bite by bite um but you could imagine an implementation where you do load the code and you translate the code into um you know an instruction set um specific to your implementation where you don't actually go bite by bite but you pre-process each of the instructions into whatever format you have if you have an implementation like this then the instruction in coding is less of a concern because you're always going to translate it but the the other case where you go bite by bite in the variable length encoding are jump V that

means that you have to parse the entire encoded instruction every single time um while current version you can just skip ahead because you know it's fixed size and you know which point to skip to yeah I think uh so my idea about that was um to to pad everything so like if everything in the r jump in the jump table needs two bytes then you just Pat everything to two bytes because there's because the vlq incuding allows ambiguity in the in the length so you would need to parse so if you hit an R jump V you need to parse the first entry in the table to see um what the variable

length size is for all the entries in table so if the that be the size of the table or the number of jump destinations the number of um that's interesting I don't remember off the top of my head what R jump fee does right now R jump fee has the number of jump entries which because it's a fixed width you know the length of the table um but then we have a variable width size indicator for variable width data which each entry is variable width I don't see how thatas done without parsing the entire instruction set so like let's say the jump table has the entries like one 256 64,000 or something um

yeah have three what Char means by this but seems Seems doable not sure it's worth it uh it's mostly um you need to make sure like the encoding of every entry in that table is same the same length yeah and this is this is possible with this like varic length en coding um which we rather should kind of avoid in other places um but yeah I mean like it is possible to do it this

way yeah and you can make the encoding probably slightly more efficient because you can have some but that that coding would be more complicated so you would say like okay every entry in this jump table has like three bytes or something or every entry has two bytes and then you can just use the big en um I think it's okay to allow a bit of complexity in the encoding for r j v um and you can still get this property that um it's a one traversible yeah I I think it's technically doable

um although many of the you know conversely many of the variable length encodings uh were aiming to have a canonical encoding which is usually the shortest form and this kind of goes against it um yeah but but as pav said yeah if he would uh I suppose we would need to have two uh two numbers in the beginning number of entries and size of Entry um because just you know having like the the length of the encoding doesn't tell you anything so you would have to need

these two properties in order to decode it in the same manner we do it right now with the petting I mean you can get the length from the encoding from the first entry yeah I mean it's not very elegant uh but it's like I think technically is possible looks really bad I think in terms of like elegance and because like exactly what we want to avoid in all other places is to avoid the pic so we probably if we go with any kind of perodic encoding we will just restrict the encoding to be the shortest possible that simplifies a

lot so validation will check this and explicitly in this like jump V it will be like the the opposite rule somehow that yeah so there's like two options right one is like vartic encode everything but make everything the same length and the other is have this uh little piece of um maybe add another bite to our jump fee uh which indicates the length of every entry in the jump table which is like one two or three basically and that is probably slightly better size because VAR attic en coding

everything Wast bits us about what this demolishes is good chunked execution um with the current uh fixed width byes um if you do a vertical chunk execution you don't have to bring the entire table in if there's 32-bit runs or 31 bit 32 byte runs or 31 byte runs that aren't used by the jump table in execution we could skip those U with the vartic encoding we'd have to have the entire instruction in a chunk execution you don't you still don't need you don't need to pull the entire jump table into into memory but you would need to have it in witness because you can't infer the

location just by doing some index math you'd have to decode the whole table and know where each one starts to to know what the correct execution B number for it is for yeah so that's what we're discussing so like for our jump V we have some special encoding which ensures that every entry in the jump table is the same length then why do very coding uh so that we can have larger pointers um I I would much rather see an our jump V4 than vartic en coding and also in the common cases I think um it's going to reduce code

size uh just want to add in the future it seems that work and Witnesses and everything around that there's possibility that only chunks of the bite code is going to be sent or read or used by light client whatever there there are status client so with encoding in place could be is that possible or not possible basically the middle of the bite code use that code whatever that is are you asking like in eof in general or specifically to this jum

fee uh specifically for the workl because with workl at least what I followed uh bite code basically bite code is chunked in 256 like bits and idea for the future is for witness to load only the chunks it needs but if you encode data and need full container to decoded that will like make that make loading data we would need to load a lot more data and put into the

witness yeah yeah okay uh I don't think any of these like prohibits using only like CH chunks so in general there no issue with I okay main question is if you have arbitrary code whatever it is would be decoded or is or you talking about different accoding what I understood what I understand is like you are talking about the coding of the bite code so so generally you don't need the

whole e to execute it you need wholef to to validate that one it's one it's valid you can execute individual chunks and and whatever you go to what chunk go to you know it's valid so you can just execute there when when you go and that's how it works so you don't need anything else precisely the bites you you're going to be executing um you'll also need to link tables of the code sections for CFS so there is part of the header we'll need but we won't need the types data yeah there are some details that kind of is not straightforward and like

probably this jump Fe like it's something we have to take a look at but I don't see currently like anything breaks it uh very much yeah I think we just make a slight change to the um normalization rule which is that normally we pick the smallest um encoding for a number smallest withd encoding for number number but for our jump V we pick the length for all the entries in the jump table to be the same

um to analyze this by the way I think that the most common use case for our jump V is actually um for selector tables like every single contract is going to have our jump fee for the selector table basically and selector tables more or less jump randomly into the code so they're going to be large poters um and also the number of entries in the jump table is probably going to be around 80 for large contracts but it could be larger if we

increase contract sizes yeah I think getting actual statistics on um on the selector use case uh I think would be fairly uh straightforward um even getting it from ether scan but if you look at um intuitively you know at some of the the big um uh erc's so like you know erc20 or maybe the more complex stuff like 46 26 and um any of the nfts like 721 so each of those have you know maybe like um an order of like 10 and points and then you know contracts have their

own management um end points Etc so maybe a good like a guess would be on the range of like 25 30 entries on on average is what the contracts would have um so I think that's maybe like a good you know good number to go with how many entries you would have in a selector maybe like 25 yeah and um I think contracts max out around 80 methods that's just how many you can fit into the spous dragon size liit yeah so if you look at the 25 entries you know how much how many bytes

are we going to save with the variable length en coding in the selector case I think it depends on um yeah that's interesting um so there's like actually two things that we're considering one is saving by space and the other is forward compatibility and if um contracts get above 64 kilobytes um I don't know it just seems like a Y2K kind of scenario where this is going to be a Blocker on increase increasing the code size

limit and like we can fix it now so but for the code size thing the the the best encoding I think um well the smallest encoding obviously is where all the pointers are variable sized and we don't have this uh restriction that all the entries are the length but I guess with veral there is this like I don't know um right so Dan was saying we we

need to do these 32 by trunks um and I guess for these commment sized um selector tables um between 30 and 80 methods we would need two to eight chunks right so let just make like a pragmatic calculation um you said maybe 80 end points I don't think many contracts have 80 end points but let's say you know we have 80 end points uh in the current encoding that's 160 bytes for all all the 80 jump locations now if you somehow manage to put all the 80 into being uh fitting you

know one bite encoding uh well in variable and case that's a seven bit um that means that you would have to have it in the first 128 bytes you know all of them um and if you do then likely they're going to jump further because there's not much left in the the remaining like 40 bytes to do anything but in that case you know all of them would be one bite locations instead of two byte locations you're saving a total of 80 bytes of code size and this tells me that uh

optimizing for code size in R jum fee you know with the variable length encoding is probably is probably something uh not true you know it's not worth it yeah yeah so we should optimize for forward compatibility is my conclusion and for that actually um you know there's this idea I mean this IDE SL one of the reasons e was kind of pushed back uh this idea that a code if there's no code in introspection that you could

practically translate the code you know in that sense even with the fix size rgp we have complete forward compatibility because we could translate um you know UF uh to a new encoding if wanted yeah yes that's true but I'm wondering how practical that would actually be yeah maybe just one more comment uh you know I I may uh sound skeptical but uh the more interesting part of of this conversation to me would be what if we

can get rid of the code size limit we have and and you know in that case will we will we extend beyond the 64k limit and that would be a more interesting you know medium-term conversation to be had I don't know if runtime code would extend beyond um 64 kilobytes anytime soon because that's um like what 2.5 times the current size but um I think a nit code is bumping up against that pretty pretty soon

power yeah I think um I would suggest into this specific periodic length and coding discussion to split this into like smaller groups uh I think we started with like the the most complicated one which is jumps uh I don't really see how much the benefit the stating jumps actually uh except for the like consistency what I mean like provided we we apply this veric on coding something someone else maybe it's also Worth to to to to apply it to to new jumps but uh I would actually split This and like

maybe find find the reason it makes sense for jums and maybe find the reason it makes sense for uh for other places separately yeah well I think there are actually no objections so far to using this encoding in the headers and pretty much the only um discussions have been really about jumps and um the the basically the new instructions with immediates jumps and swaps the same problem with jumps also exists in the code section size header you we're already parsing ready um my main objection is not on the merits but it's on the schedule if we go to VAR attic I don't think we're going to make

eof this year so I think this is this discussion is happening too late in the process we're talking about trying to get a Readiness together and trying to get this thing out the door and such a fundamental change is basically going to say let's not launch this year so My objection to this is is not on the merits it's on the practicality we're letting perfect be the enemy of better and and we need better right now more than we need perfect I mean I think what I've heard from the ipsilon team is that it's not that difficult of a change to implement um as an implementor that has a lot of things on my plate it's going to push it out of this

year yeah I don't know I mean I've been uh suggesting this for quite I think maybe over a year now and the feedback I've consistently gotten is that it's too late in the timeline so I mean maybe it's always too late in the timeline well there's always

um a struggle you know getting any anything accepted by orvs um but now the the I think the stage and the potential we are in is much higher than ever before um and so the you know kind of late argument does apply um I mean just like you know Dano said on the Merit side even in the initial design we did had variable length in and yeah I would like to have it um but it just feels like you know without having actual

numbers uh the risk uh seems to be high um you know just doing this calculation on the RJ V itself I think the the size savings is not really an argument we can make in the header I think there's a much higher chance that there the savings would be more significant um which leads me to to think that the instruction REO length is instruction in coding is something we probably don't want to pursue um considering CER changes I think we are generally more open about but given the you know if if one client like Basu is is not able to

implement any such changes then I think it's definitely off the off the table yeah I mean about the code size thing I just want to point out that we've only discussed it in one place and I think in general it would save more uh kind of small things that add up yeah I think the case where it it saves is um uh short helper functions right because that's the only case you're going to have uh short

jumps there's a lot of short jums yeah it would be really beneficial to to have some some actual numbers right that that's a piece we are struggling with um getting numbers from compilers um I think that's a fairly simple calculation but um yeah I think the the importance um it's actually more about forwards compatibility and it's also nice um to have space savings and I can

compute that for junks after this call yeah I think that that would be awesome um we yeah we are getting too close to the end and I did want to discuss like one more piece um which is you know besides the the Readiness Matrix um I think it would be nice to have one or two goals for each week uh and one of the you know goals we can focus on and make sure that you know there's progress made on those um is there any any goal we could uh put out for for next week one or two goals to reach and I think these have to be specific um you know it's not like go

update the specs or whatever um does this sound like you idea we could uh we could go with is there like um you know some certain goals we could uh Target for next week I like that idea I mean maybe we make a particular EIP the focus of making sure everyone passes all the reference tests and proposed reference test that fill holes um validations another category I mean reference tests for execution and validation make sure that we're all up to date um and we feel that the reference tests have enough coverage so I I like that idea and I think it would work best if we focused

on a a particular category like the the jumps or the functions or create yeah since we don't have NE mine on the call and drag and you're still ear early in the process I I suppose um you don't have any any feedback on that uh at least for for you know the next week um yeah yeah exactly yeah um but for the next week um I suppose this discussion is now between ipsilon and Basu um yeah what do you think is this uh is this a good idea um yeah it's a good idea um I recently

committed all the um I ran all the eof tests which are validation tests and the reference test and I just last night got those all those up to passing um they were generated by by you know whether or not they pass or fail was generated by evm 1's current implementation but I think that's probably a good place to start is just container validation um we can you know well that gets also code validation and stack validation of all the various items um one thing I don't think we have implemented is the proposed change for um uh the code validation the the forward only references and the um uh the the the accommodations we were doing for variable stack variable height

stacks for things like um reverts so maybe that's what we should focus on next week is have tests ready and implementations ready for that particular change in the uh validation algorithm because I'm fairly certain the reference tests don't touch that um Andre Peter pav uh anyone else uh for Epsilon uh are we okay focusing on that I would I would I would like to see the eaps uh update progressing we could have the 3540 and maybe the create

thep uh ready somewhat at least so that these are not so uh horribly outdated and then the rest probably would be much oh the stock validation is also a big one I think but apart from that I guess the rest of the ATS are not that huge to update and then we would be in a better shape I guess I don't know that sounds uh reasonable yeah I mean how about focusing on the the validation you know test and theps everybody is looking at the same thing

uh can you repeat I didn't understand yeah so how about focusing on the validation related thep changes and validation related tests uh this code in stack validation once right yeah yeah that's that's what I like as in focus more than on the create and container format ones I think the create one is also very important because it's this is like a new piece and uh has not been accounted for at

all yeah so we yeah even in the Readiness Matrix to create this kind of an it it it it leaves a bad impression yeah so we we don't need to do like full you know project management here um you know just looking back to the goal so I think what um what we should try then is you know at least some people from ipsilon focus on the dev validation testing and uh um and then as well and then maybe the goal would we we need to like set a goal you know where do we want to get with this um next week so I guess ideally Maybe

Bas who passing more of the validation related tests um could be a goal yeah I can work on enumerating the tests on that Readiness sheet too as to which ones are there and which ones are yeah get bases update on those and then have the evm ones as well because where there's disagreement is probably where you know obviously one of them is not implementing the spec right and I just need to figure out which one goes with the spec and which one doesn't because I don't think we want to get into the situation that they had on the consensus layer um where G implemented it wrong and everyone aligned with G just because it's G so I think you know we really need to have

the you know we need to change the spec in advance of everyone just aligning with the first impl to get it done all right I think nobody is like really objecting so we should try this out and uh yeah we can evaluate on the next call um all right let let's get this Readiness Matrix updated by then and hopefully we make good progress on the the validation

related um test and yeah I mean let's let's try to get the creation IPS because that that's like you know one of the the blockers for the Readiness Matrix as well um we also about time so any last comments from anyone before we uh conclude all right then um thank you all have a nice day and see you next week thanks everybody thank you bye bye bye thanks bye