EOF Implementers Call #30

Transcript

yeah I don't actually have the agenda in um in front of me but um um okay maybe let's start with the client updates first um um Dano is first on the list so Dano if you want to go first I've been on vacation for two weeks so I haven't gotten much done um I listened to the allore dev's call I guess that means we're not canceled I don't know um I'm getting some tasks finished at had then I'm going to Pivot back into making sure that um what we have the mega branch on Basu matches what is with um evm one um and working on getting testing and

differential testing done I know there's a lot of things that I haven't updated is the specs have changeed because they were kind of floating but now that we got confidence the spec is mostly done I think it's worth putting in time all right yeah we should get back to the testing question um after the the client update um Iman you you want to go next okay your mic is not working um so you got back to implementing um the meas

speec I suppose awesome um what's your status um what kind of Parts have you implemented hopefully you're typing oh nice most of it um all right hopefully you're might going to come back later for the call um yeah keep writing if you have any more updates um otherwise I'm going to move on to okay you're still updating the test

from the previous implementation um are you using any of the yeah I mean let's get back to a testing um discussion after the the ram um I'm not your maintainer uh which team you are with but you sound like you're maintaining a client and maintainer that e uh if you're talking your mic is muted uh all right apparently you won't

talk um I know I pronounced your name last call but I still don't remember what's the the proper is it scor bagio score I don't know sorry for theing yeah scor bajio um yes since the last meeting I I took a look into a uh old implementation that uh was done uh long ago for the ethereum JS client for e and I've just kind of been digging into that not all the way up to date but um yeah that's that's the uh the main thing since last time so so that's on ejs right

yes um so what what um is is this implementation from like uh 2022 December um I I don't have a specific time but yeah it seems like it was uh completed a while back when it was uh going to be included in one of the hard Forks but it was delayed so it just kind of sat around and uh it needs to be updated yeah I think the the base format shouldn't really have changed too much but obviously we do have a lot of um yeah a lot of other changes um yeah just make sure to to look at the

the meas spec and uh yeah if you have any yeah I think we could probably point you to the spec of that era um the December 2022 version and then you can compare it against the meas spec and it should should help you see what needs to be updated yeah um is that uh a link uh will be shared in the chat or is it is it just going to be in the same repo maybe like uh in an older commit or something um so the meas speec is is in repo now um Let me give the link um but the December version is is a notes uh just a heck MD I will try to

find it in a sec okay appreciate it um okay why I look for the link I think we could move on to to charts I know you're not a client but you're uh Viper but if you want to give a short update uh the Viper implementation no updates I um did submit the vlq the variable length spec update though we can talk about in a minute if

you're ready all right so so you made you made progress on that I think last time we discussed that you could make like a PR just to see what what kind of um uh change to the EIP just to see what level of changes it would require right yeah I um just I I thought for some reason that the this meeting was tomorrow so I I procrastinated but I just submitted it right before the meeting so it's in the it I pasted the link in the Discord I'll paste it here too all right yeah let's discuss it after the r um okay then I'm going to call up ipsilon and somebody from Epsilon first

just give an update on the implementation like evm one part and then separately maybe testing and uh and then finally we can move on to spec discussions pavl Andre Ric yes so in the implementation we implemented returna load and almost finished I think updating D and swapan for the UF spec and uh another thing is we have evx instructions on review so this is only the instructions

implementations part as I understand and yeah some uh some things are still in progress like create instructions and um stack validation new algorithm and exchange of code still not implemented yeah that's about about implementation uh any updates on the testing aspect uh like test generation we didn't do anything with

this uh last week we still have this PR on test repo with the tests in field format for that's only for creation for create three I think um yeah we can work on generating fers out of that too but I should note that these tests are not all of the EF tests that are needed these are only for creation actually create three and create four I think so we will not cover with this all of the tests needed I think there were like several

discussions to use the um the new testing format as well um for Mario's team do we do we know what what is the status of that are we still generating the state test format or are we generating um that other format are we generating both we're generating the old format because new format is just python code and it also in the end generat gener Ates blockchain tests of the old format so it wouldn't make sense to generate python code so we kind of generate the final form

currently and what's the status of the effort to write tests in new format I'm not sure probably no updates um regarding the the clients other clients and testing um everybody is still using the the state test format is my assumption so this approach still uh still is valid um is everybody using you know the same version of the test we have or how do we

yeah what is the current way of coordinating the testing approach are these the tests in ethereum test SL sdo or wherever it is yeah but I think it's it's in a separate repo now right because it's not upstreamed Andre Okay yeah no I think it is um it is already mered in the main um atum test and yeah I think the the the latest stest are are already merging in the main I think it's develop Branch yeah but I think that it's mostly

execution tests that are still working according to current spec and there are many tests that use creation and they use still create or grade two so these need to be updated for New Creation so it's a mix of some tests still should be working and some are outdated I think so one test format that I think is missing is the validation format because we went through a lot of validation format fuzzing about this time last year and had set up a uh file format but that wasn't accepted by the ethereum test

team uh it was what I mean there is one and it's also in merge and develop there are some number of tests for validation this is in it's not the same thing um they're they're running it through uh Creator which is much slower rather than just running the validation directly and getting the output unless they've changed it since last time I've looked what their first pass was was just another set of tests where they try and make create fail which was not the same thing yeah that was the first approach but this I posted the link there is a new format specifically for validation doesn't run creation it's just well these are adjacent tests maybe I'll link the

f it's just bite code unexpected error this is basically the format but is it's not spitting out the discovered code sections that's what I liked about the format that Marius put together or Martin whoever it was is you either got an in a failure or you got the list of the code sections and maybe we should put in the data section here as well it would show some some more validation about that you parti it correctly not that you just elect detected invalid parsing and I'm looking at this and

there's is there any examples that P yeah it just AB true I think we're missing signal from this new format that we had in the old format I don't get what it has error message at least is no the error message is one failure but there was when when passed we passed in a string that represented all the code sections we found so so mostly what Mar did was that the tool that was running it was expected to also in the in the case of e being valid he he was outputting some

details about like and that was kind of roughly specified what supposed to be so mostly I think it was just context of the of the sections I believe something like that so like the the container was removed and the section were just separated by by space something like this um so this is not their I think we can add it I'm not sure this is like super stable super stable test format that I all the people are interested in this are already here so I think we can modify it I I'm not sure if if they are up to date that's

that's the main issue okay yeah I haven't run these yet I haven't gotone through that did we made any do you have any tests on the um creation on transactions so um deoration transactions probably not yet but we might be able to generate them easy like similar to what we have for GR three uh probably not sure maybe it's because

it's a new kind of transaction maybe it needs some special support on the tests I guess it does like at least new field for un codes yeah yeah I suppose it's not a blocker for the client implementations yet if they um mostly for have to be up to date with the this spec um but yeah I mean if if um implementations Do complete then it's

it's going to become a blocker do we have like any estimation how long it will take to to get those tests like at least the first version of those tests out Andre do you have any estimate uh for creating the transaction test if we come up with some format for these tests then I guess we can generate them at least from those unit test that we

have um yeah we can have something in the next the week or something yeah but also in state test format or like in this new format derived from der from state test format awesome yeah I think that that I do see that as a as a tiny risk you know as fighting with the testing format and transaction so it would be nice to at least get you know a smoke

test running uh to understand if um if there any questions there all right do do we have any other comments on testing before we move on to spec discussions yeah yeah I have um so I think like rather quick summary is that we can follow like the the kind of regular regular kind of I don't know pipeline of producing tests which will end up in this AUM SL test kind of scheme and if we were doing that it's a bit slow because there's multiple tools you need to have to do it but I think this works but this open this like some

opportunities to improve the system and and maybe that's that's confusing that we talk about different things than uh but I think we can follow the old path for now and unless someone has suggestions how to change it I have a feeling it won't uh you won't get any feedback before people start using it other clients start using it and then um once they do then there's going to be a lot of complaints if something doesn't work okay I mean I think it's fine we kind of open for like comments like because there's like multiple levels of of issues like first

one is like the format itself the Json that is missing some information sometimes it's difficult to debug and all of that I probably familiar with this uh so I think there are some options to improve that but I don't think we'll do much unless someone actually have like specific request or I don't know um yeah so I I don't want to like prolong this but uh that's more less think overview sounds good um okay one more question on testing do we expect to Upstream everything um or do we

expect to have like um a separate repo for the time being for these tests and if we do expect it to be up dreed what kind of um uh run trip time do we have for merging the the changes I know some of the old ones took like consider you know very long time but maybe it's different now I think we can probably merge them as like because for now this tests go into this e folder which is for some

future updates and they don't care that much I think about those tests yeah obviously merging at Upstream is the the best option and hopefully hopefully it's going to be merg quickly um all right before we move to actual specs I see there's a one more personally qualify I think it's written in Reverse maybe Mech ali uh would be the name I'm not sure um if you're with a client do you want to give an

update hi I'm not actually I'm with block works I hope I'm not intruding I regularly attend the ACD call on YouTube and was curious about eof doing a follow-up story I cover a lot of the ethereum ACD calls if that's all right I was just fly on the wall yeah that's fine this this is fully public uh it may be a bit dry you know conversation wise but um happy to have you here all right let's move on to spec updates um and discussions because we only have 30 minutes left um I'm not sure pav or Andre do you want to give an update uh regarding spec uh

changes um and then I think we can discuss first maybe the proposal from chars I think the only change was we added return thata load into meas speec and yeah no nothing was change in terms of design changes just a a minor sounds good um Charles you wanna you want to get

started um do you want to maybe briefly present what you did and what you have found yeah um so I basically went through the spec and um everywhere there were this like an offset or length I replaced it with well okay first of all I decided on the encoding format and I just picked um vlq because it's big endian and it's fairly easy to understand there's a signed version and an unsigned version um uh basically the unsigned version is easier to understand and then the signed version I should write a reference

implementation so it's clear but you just sign extend it and then um encode it like you would in unsign integer the weird thing about the only weird thing about the sign thing is that you sign extend to multiple of seven bits instead of a multiple of eight bits like you used to um should I share my screen or something that might be easiest yeah that sounds good so this is um lab 128 right that's the the encoding no I use VQ the difference is Big versus little Indian yeah I I think like going like

what's specific encoding we want uh it's probably like too much of bike shedding at this point um but yeah I think that The quick summary it's like lab one to8 just like the variant of that so it's kind of similar complexity what I've read like before the call so let's see like variant of this I would think it's like good starting point yeah I'm I'm not did we lose audio it cut out yes hello

welcome back thanks um I guess it does that when you screen share it switches to the audio of the tab but anyways um where did I cut out I I think I was saying I'm not too concerned about the um specific encoding but like it's should be something that people expect and it should have this property that it's small for common cases uh where the Val value is small and um yeah I think variable length so it it just kind of scales with the size of the the the input is good um anyways so we can go through I think

your samples for 127 and 128 are wrong on the sign P qes yeah I think I left a note to check double check it it should be 127 should be 87 F and 128 should be 810 the positive values yeah that sounds right because you might have a 80 in the case where the low bit is a positive sign indicator and that's the only case you can do an 80 in I think what I want to do is actually implement it and then that'll be the um Implement a reference implementation that'll be I guess the final say um but anyways so you can see here like a lot of stuff is just simplified

because we don't actually need to like decide beforehand how big things can be we just say it's like feel H oh one thing is I decided to um add um a size bound um because I think most implementations want to use a native word to store these things when they actually um not during encoding but during actual running of the thing and it's easier if things are sit fit in a pointer um okay so I just replaced a lot of these with the maximum is variable um there's some interesting things here where um I actually should change this to variable because the 1,23 bound is actually

checked during code validation actually let me push my changes that I just um I do have one comment I it actually didn't occur to me that uh we were planning to use the encoding also in the instructions um I thought we were mostly concerned by the headers yeah yeah I ended up just putting them in the instructions and it turns out that everything works quite well um but let me finish here first uh

the only weird thing is that we use Ox 80 for the non- returning functions I think oh that's a mistake um and I think that was proposed by Andre and it's a little inconsistent with everything else so I would suggest that to indicate a non- returning function you set outputs equal to the max stack height + one and that's the the new Sentinel and I can update the code validation rules um I also took the liberty of yeah as

Alex point out it's the liberty of um changing all the offsets in all the immediates for the instructions to be variable length to and I think this actually solves a lot of problems because we don't need to decide how big things need to be so for example I remember there was like some kurur fuffle about R jump V like how many bytes do you need to encode the immediate where did this go there um and like this guy and like now you just

don't need to have a limit on how many things can be in the jump table and a lot of things improve in the same way for our jump I don't like what variable links do to the implementation um when it's fixed link it's a lot of assumptions you can make about code location about you know where jump five is going to be it's a very simple math now you have to parse and read the entire table um which goes on to my second critique of of this which is it's going to make mer mer merization verticalization harder in some cases because again if you get an R jump into a large table that goes across multiple chunks you can skip those chunks um but in this case you have to parse the

entire table so when I went through my analysis our jump is where I decided that variable um link not actually reduce utility um of some of the instructions that we have um the fixed link actually serves a very valuable performance purpose in our jump V uh that's interesting I yeah we can revisit R jump V I think that for R jump and R jump I they should be variable length um because that makes it easier to um lift some code size restrictions in the um yeah and same here with CF it opens

up the number of possible code sections um in the header I think we can actually remove the Terminator um because we know I I actually was confused why there is still the Terminator field because we already know the number of code and um data and container sections so I view that as being forward compatible if we add new type Fields um this is a signal say we're done with type Fields so if an old system tries to read um a new version with new type fields and they see like type five before they see the Terminator they know they can't validate it so I've always you know the Terminator is is the signal that we're done um that makes it clear

that we haven't added unknown types and it preserves forward compatibility so with the terminat Terminator in place you can still implement this uh as a s simple Loop uh like reading the header yeah it's probably not what most implementation's going to do because kind of fixed header but technically it still makes it possible I mean I don't really understand the forward compatibility because like what's going to happen is you run into a type kind that you don't know how to validate and then you need to bail out anyways how would you distinguish that type kind from the body section what if

the body section starts with a five or an eight and we have a kind data that's eight you know how do we distinguish a kind type header from legitimate data of the next section because all sections start with kind right but there's we're adding in a future version a new kind that just happens to be um whatever the first valid input number of your body might be how do we distinguish those the way we distinguish it is we have a zero kind which says we're done with the

header and then you move on to Parts in body yeah okay um I guess that answers my question [Music] um yeah so I think it becomes like a little bit important for these to be um variable length um if we want to increase code sizes in the future and by the way I noticed that data load n is cheaper than push n um which makes it preferable for compilers to use push

and I think it would be nice to fix that but I think we we restricted ourselves uh from from changing gas C of existing instrctions just to limit like the number of changes I I I don't think there's reason there there's no reason in current TVM to push be have value three so much like even if it was more expensive I would see compilers using day load n for duplicate values across multiple places anyway let's say you're pushing the same

Conant it's like generally better to use data load and except for like maybe small values like push zero and push one basically um by the way with the excuse me with the variable length immediates we can actually refactor swap in in exchange which was like kind of contentious for a long time and the main difference is that like is the encoding of the nibbles um so I haven't completely

thought through it yet but if we can use maybe Doos encoding and like take the we we can do something like the the immediate always has to have we just divide like the number of bits by two and then the lower bits are considered like the low um the first stack item and yeah there's there's some way encoding but the the lower bits encode one stack item and then the other bits encode the other stack item and then like solidity and Viper um all

get to have good properties um doesn't the the variable length encoding kind of conflicts with this um know the the two nibble encoding because basically what this means that M always going to be um restricted to the low nibble and n or yeah the top yeah it's n n can grow to to whatever I think that swap in and exchange should be refactored now um refactor it into to what exactly uh single instruction which

takes a variable length immediate and then uh I think the low bit sorry the let's see I think for Simplicity of understanding we just mer swap in and exchange into one that takes two two uh VQ values and then you can go wherever you want it makes swap three bytes but the only reason we were packing into exchange is because we wanted one and two by variance because we didn't have variable lengths I'm I'm concerned that if we get too tricky I mean if if we do it we should have swap in have two values and have have one be the first and the second be the Delta and exchange be limited to a single BTE that is not variable link and use the old encoding

if you're trying to save space but I think I don't know how much that really saves us I think that having a two byte swap instruction is important for code size oh for code size then let's make Swap n a three byte where it's n and M and you swap n and the N plus M values and keep exchange not make a vlq keep the current uh single bite encoding on it and not even mess with the vlq um I think that you should be able to encode a swap in a single bite basically that would be well op code and immediate operand you want the swapping

coded in a single immediate operand right yes so we keep the current setup for exchange make it a u8 immediate for exchange and that gets us up to 16 and 32 and anything belong that beyond that we use swapn which is actually has two arguments n and n plus one um n not n and n plus one but n and M and you swap n and M and M is the n plus M if you need more than one bite then you just encode them as blq values so if you're swapping 123 and 124 yeah it's going to be four bytes um but I think that you know at that point you're not really worried about code size I think it's adds too much complexity to move

exchange to VQ I think um I think there should just basically be one instruction and it takes one vlq immediate and then we can be a little bit clever about the encoding but like not necessarily too clever I think it's too clever let me write it up uh but I think there's an opportunity here to um simplify things um I and and then everything else what what other changes did I make um this was just a

clerical it's just a clarification because they can have other operant besides the I umum changed a bunch of things which refer to operand and I change them to immediates so they're not confused with stack op um push note yeah I think that's about it I think those like U smaller like fixes we probably could just cherry pick and merge anyway um yeah but otherwise I yeah I think this is this is great work I do have a number of questions first of all did you had any chance to Implement both

versions in Viper and see you know any kind of uh size differences no and do you have the the current version the the fixed size version implemented uh we have the version from 2022 implemented so that means exchange isn't implemented yet um I don't think so yeah we didn't Implement dupen and swap in either I think it would be really great to to really have some data um helping our decisions right between

the encoding of uh swap in versus exchange and then uh also the fixed size versus um the variable length so I did some of this analysis on solidity output and what I used to get my I think 3% number is I took compiler the 2022 version right yeah 2022 version yeah so I took the compiled output and I searched for the prefixes of all of the two by operands and I looked for ones that were like 0 0 and um between 0 and 127 I I looked for all the operands that were below 127 and I considered those to be reducible by one

bite and that rep there was about 3% of those occurred so I think the analysis could be done on the 2022 code with some clever gripping not for R jump V but I think we're looking at probably about three to 5% by adopting VQ but we can get hard numbers another benefit is it allows us to like not set hard bounds on a lot of these things like I noticed a lot of these things were like I don't know arbitrarily chosen as one or two bites yeah I think some some of the bounds do make sense others don't even if we make it variable length I would

probably be in favor of having upper bounds on you know some of the header stuff so that implementations I want to avoid the case of like you know what rlp and all these implementations have that it's and you basically made the decision already by hard coding what the VQ um upper bound is but you know um yeah I toyed around with um like using vqn in the spec so like VQ 64 versus vq32 where the difference is just basically the bound so it allows the implementation to have some kind of bounds or types um but it seem to make the implementation the the spec more complicated without

gain but I could revisit that like a lot of these things could be like vq32 no problem right so yeah and I think vq16 should be some of them in the advantage there it's not complication it's about security because I could totally see um a security TCH where they create um four gigabytes um would it create four billion code sections um to try and blow stuff up and like you know maybe more than uh 32,000 code sections and 33,000 code sections to catch implementations that use um a two bit number for their indexes instead of a you know there's various places they could attack this which is why I think the limits are not

about ease of implementation the limits are not about um complexity they're about security and if we keep them low we could always raise them later in a soft Fork um where we just accept larger numbers um so I think you know putting them low on the first pass is not a death sentence to Future size increases we can easily increase them we can have newer versions except larger numbers um Dan the the measurement you did with the 3% was that the instructions only or was it the header as or both it was instructions I didn't mess with the header okay yeah I think it would be nice to have um two separate pieces of data right what is

the um saving we could achieve with the header and versus the the instructions and I'm kind of leaning towards that probably these are separate questions from like a spec um uniformity perspective it does look nice that all of it is variable length um but I'm not fully sold yet you know that the instructions I see a bigger risk with the instructions having verbal length en coding um although we already have the arum Fe is verbal link encoding you know in a different way um but this basically means that every single instruction rtion uh EF instruction with immediates would be variable length um whether that

has implications or not I think that's yet to be seen um but I would probably prefer to have different data set of arguing whether the the header uh should be varable length and um you know have the data uh supporting that versus doing the same analysis on the instructions but I mean that's that's my view um we only have like five minutes in the alloted time maybe we should uh have some rounds of um feedback regarding you know all of the all of the the spec here uh what is the what is the feeling we regarding variable length encoding in headers versus in

instructions um yeah anybody has strong opinions please speak up now I think one possible downside is it'll decrease the speed of code verification whereas for mediates right now you just get the immediate up code and you skip ahead to now you have to read each bite and do a bit check on the high bit for each bite before you continue so that's going to slow down um code verification I don't know how much of a big deal that is but that is one side effect that I see just looking at this immediately um there's prefix VQ which has fewer branches if there's a

performance hotspot but we still have to read the bite and do some bit twiddling yeah yeah I I like that like on in this header context I think like this um because like it's like allow us to expand the sizes with like future compatibility sense um yeah also I'm not so worried about like the verification time uh but like the they instraction the coding at run time um which like from our exp experience

with web assembly which uses kind of similar encoding of numbers it's yeah it's if you have a bounded size it's not a loop but it's still like relatively complicated yeah I me so I I know even implementing like push efficiently in K TVM is is a bit of harder because you need to swap the bite and all of this um so you can notice this overhead um and I think it's not so bad uh I think we can work with this but it's

something to consider so I'm not sure this is like I would prefer to like uniformly select this for for instructions or not but seems it's not so easy to do uh this especially this uh jump V instruction it's it's really problematic if you do it like with foric and coding uh because now you have to build the table every time you visit this instruction I mean I I still assume that we we going to implement at least try to implement evm interpreter in the way that it just process instructions without any

pre-processing um because I think we should use it like in more like most of the cases uh I don't think we aim to some pre-processing as a kind of uh commended step for evm implementation so I kind of considered that we will just execute instructions are there are they already in the in the in the container without doing any modification so that means you have to decode these values every time you execute the instruction um so I was kind of assuming standard uh strategy for ex implementing UF will be to like cach analysis

um but maybe that was a little bit aggressive on that part yeah I think so we kind of eliminated the need for analysis from Legacy uh so this the question if he wants to add some kind of different kind of analysis or pre processing instead because we fix kind of the issues of the Legacy V yeah I mean it's not um difficult it's not impossible to it's not difficult I mean it's not difficult execution um and if you it's I think it's fairly easy to um optimize but yeah

yeah I see your point yeah we need the Prototype but I think it's not difficult to pre-process the during the even during the validation you can pre-process the code in the form that is like easier to execute by expanding it a bit uh and then there's a but then you you need to store both both versions because one is needed for for like verification or like for Network like to prove that the code this is the code that was deployed you need it at some point so you need to store like the old version and the new one as well yeah I mean this kind of applies to the header too um although I guess the header isn't really really used during

runtime but um some pieces are some pieces are currently we we tried to eliminate the need for this but I think this not really progressing to this direction yet can there just be a length uh length thing in the header instead of Terminator so you just say what the length of the header is but we need a par it to get code data section so that you know that optimization only gets us so far uh code data sections we need to know where they start during runtime or during validation yeah during runtime you do a

call F on code section five I need to know what index that starts at so we need to process the header or so yeah so I think that um you need to decode these things at runtime anyways and I think that if you want you can just keep it table of decoded vlq things and it is kind of uniform across the headitor and the code one option was to put the um the call section info is the first four bytes of the inputs and outputs and have call left uh point to an array index rather than a table up table look up so you jump F to the PC not PC it

wouldn't be PC but you jump F to the index within the container um and if the container's been validated you know that's where it legitimately starts yeah uh that has a code size implication right like it's likely that the that it's going to be a two by pointer instead of a one by pointer right right but it depends on how frequently you do collapse it's not going to be nearly as much as jumps um yeah I think there's a similar issue for data load and although there's only one data section so you only need to like

figure out where it is one time I mean I yeah my current feeling is that it's okay even to do it at runtime like decoding of VQ is like mostly going to just be one or two branches and like the PCS are all like normal so the other impact is veral tree

encoding because with that we would have to bring the entire header every time we do a um a parse of it um and there are probably strategies we could do where we could put link on the header and not have to parse the header at all for um chunked execution yeah let's talk about veral a little bit uh because I want to understand how to Sol three minutes over time I'm I'm late for my meeting I need to go yeah okay I'll ping you if it's quick question about veral we can you can you can start but otherwise I think we might want to go offline with this yeah um I think the

the data for the header is like fairly simple actually you I think most of the time you can save um basically two one bite per section is that right and then there's some like constant overhead that you save or relatively constant overhead you can save in the in header

yeah I think in general it's like it's good starting point uh I think some of us might need some time to read it carefully and I think it's it's okay to comment on the prequest about details over next two weeks yeah um Charles do do you see any possibility to implement the the meas spec in in Viper in the next two weeks to some extent especially the exchange part I don't think I'll have time to do that

um but what is your concern about exchange oh it's not concern it's just um it would be nice to have actual supporting data you know in the decisions for both exchange and um swap in yeah I think that the design around exchange and swap in were kind of decided because um we just or the the amount of the number of immediates um wanted was was restricted but I think that with variable length en coding of the immediates the design space opens up a

lot yeah I think my my ask would be more generic just implementing any version of swap in in Viper and then because if we have like base implementation in Viper then we could try out any of these different options and see you know how it faes but do you think just implementing Swap and uh sorry exchange um would that be possible within the next two weeks without the rest of UF uh I think it's kind of complicated because it touches the stack scheduler um which is like yeah I I I can put together prototype but it's not going to be

really accurate it's just a little bit kind of kind of indicative if you understand um could could we use it to compile Like Ur and any of the bigger projects at least yeah I also have to check out like the 2022 Fork of Viper probably actually let let me see what what I can do I'll let you know awesome yeah I think that would be that would be really really good input you know to the decision process yeah with the disclaimer it's like a prototype yeah yeah everything is until it becomes production code okay all right thanks everybody all right thank you everyone

sorry for going over um but it was an interesting discussion um all right I think we following the regular schedule so we have the next call in two weeks um and as always we can keep discussing on Discord until then oh um the euf uh repository I was thinking it can be renamed to UF specs yeah I think we even discussed that we but probably we had some tools there I'm not sure um yeah we we can take it offline I I personally don't have any reason against or for uh renaming it all right any other closing

thoughts it's all for me all right thank you everyone it was great see you in two weeks thanks everyone bye byebye