EOF Implementers Call #11

Transcript

hey guys welcome to the eof implementers call number 11. thanks for being patient with me while I'm running a couple of minutes late this morning um let's just go ahead and get started it looks like everybody else was able to make it here on time could we start with some client updates what people have been up to over the last two weeks I'll start with Basu um we got most of the easier uh op codes implemented it's almost getting into the call in the create three uh that there's some you know architectural changes that might be make things easier um that I want to discuss on the call um we got the the uh the data op codes

implemented as well um just wondering like you mentioned later on if we could change the ordering of the containers I think it might think make things better in general rather than having to rewrite them but that's that's where we're at is getting into the nitty-gritty of the implementation details nice thanks for that update anyone else actually I just wanted to ask you Daniel um how much time it took um to implement the rest and did you did you find any was it like straightforward or did you find any anything um in the specs which you would want to

change um so I'm not writing tests quite yet um because I want to get you know a full and right integrated test of all pieces before I commit to uh testing in case I need to do things like um create multiple uh sets of operations for two different versions of the of the Opera of the uh um of the operation registry that's where my concerns about call and Creator are going to come in um but data I mean the hardest part is just rewriting it and it's not that it's hard instead of consume the CPU Cycles unnecessarily so it's not apart from calling create it's not terribly difficult and I don't think create will be too difficult either um I just need to you know get in and

find time to do it Paul yeah I wanted to give the evm1 update um I think we can start with uh but Alex gave uh like respect update on last all Core devs last week um and in terms of implementation so we roughly have most of the the mega features prototyped in evm1 yeah we didn't discover any substantial

issues I think they create free and create four uh has to be reviewed and like check how it's how it's looking but um so far nothing really bad happened so this is like terms of implementation progress and we we we put some effort into like firstly updating gef implementation and to to be agreed with evm1 on this like version 1.

1.0 of UF and this is done and uh we also needed to put some time into testing infrastructure but this also has finished so like the the last piece of uh needed for to close this subject is to get um get the previous submitted tests updated and means there are I think three or four requests to ethereum slash tests with updated tests uh which is not Mega spec but at least they are better than we had for some high so it doesn't conflict with the chunk High

efforts and uh I think there's some usefulness in this so uh I'm not exactly I don't know exactly what the status is like why this is blocked uh maybe just some like review details to to figure out but uh this is more or less uh where we are you're asking why the PR2 ethereum slash test is blocked um yeah I didn't check exactly is the status so if someone who's an answer but I guess they're also publicly available so you can check what is going on yeah makes sense we can also talk about it let me talk about testing some more um thanks for that update

um somebody from another mind want to give an update with what you've been up to uh yes well we implemented most the straightforward stuff from the mega eof spec kind of uh only could they create op codes and the new transaction type remain to be added and yeah thanks for that update anybody that we didn't get to that wants to give an update okay cool any use solidity Viper compiler related updates

yes Barnabas uh not really a solidity a relative question but can we start testing you off like dedicated devnet for it with like uh actually all the UF changes that we would like to see in the next uh potential Fork would that be something you guys would be interested in uh it seems like we might be a little bit early on the cycle right now somebody correct me but it seems like most of the clients are still reaching conformance with the tests which I feel like is usually the first step once they have that then it makes sense to

probably start looking at doing a testnet you know yeah let me know if this changes uh yeah you would like to start pushing for it especially is about to be cool yeah let's uh let's do spec updates and then let's talk about testing all the situations there so it seems like the spec is solidifying solidified is there any updates that we want to talk about or anything that was found during the last two weeks during implementation I have a few that I mentioned in the Discord threat

um and a fourth one that I just thought of that should be less controversial I'll just start with that one is push in not pushing is is pop in swap not pop in Swap and dupin is that considered part of what we're gonna ship with the first version I kind of wanted to but I don't know like if if we did agree on this um so I motion we had it let's put it that way formally added as part of eof I know solidity has been pushing for it yeah yeah they literally wanted this and like I think what they said like some time ago is that if

if EOS will not go into Shanghai and there will be more time to like really rework some features they would still like like uh have this Swap and then do pen yeah in the overhead this is one of the simpler ones to implement because um we've got already written this stuff to do the uh the multibite operations we've already got you know the op code filtering and stuff like that so this is perform an implementation perspective it's not that hard to add and it provides significant value to the solidity team so I think it would be a good ad testing is going to be the harder part because it's going to take more time than writing it which is the case with just about everything but

yes really um yeah so while we're on the discussion of um you know the spec itself so I mentioned in the forums um briefly but I think it would just be easier if uh maybe we kind of talked about it a little bit here instead of doing an async but um yeah so I'm working on both a parser that validates eof containers and then also um like eof code gen for the Huff compiler but so in in the parser um yeah those are uh both rust crates um work in progress I think I think it's public but it's a mess you don't want to

see that right now um yeah so on the rust implementation thing um so I was speaking with the uh I don't remember his name but the guy that's working on revum about um you know adding this eof validation and so he wants it to be like really really fast um some some pretty weird optimizations there and so I was looking to do it that way but there's some complications around like doing a sufficiently in a single pass um if you could maybe link the the existing rest eof container that'd be great but in particular the on the topic of the header um so right now you know the header is uh dynamically sized um but I think with it being statically sized and then moving like the metadata about

the size of the different code sections like moving that to the type section I think would make I think it would make the the header parsing a lot faster right you could effectively just you know use a use a mask right to validate the constant bytes and then the ones that you know maybe some other value then we could uh yeah we could extract that information basically really really quickly and it would be a lot less jumping around so if we want to check a specific code section we need to go both to the header and the type section whereas you know if we move that into the type section then it's all in one place in the type section uh Curious of anybody else's thoughts on this I know we talked a lot about this

specific header format and I don't know if there was a any kind of final conclusion that this was you know the the way that made the most sense I think it's the simplest in a lot of ways you know what we have I don't know if Alex or Paul your thoughts because we kind of have made a I don't know I think that this was one of the big rabbit holes that we went down whenever we first started pushing really hard for eof in Shanghai and that's where we ended up spending a

lot of time was thinking about how to do these code sections and type sections and we ended up having us like a couple small changes to it that substantially increase the complexity also if there's if you guys have a link to like any notes or anything that was taken around this just so like people don't have to repeat themselves and I can kind of get to the history of it that'd be great um yeah I mean I think math is right we kind of discussed this long longer um previously and uh most of the conclusion was um that well those like I think option there were two options to choose

from one was to be like to keep some like General generic level some abstraction which is what we currently have so they are like sections and uh and in the header you just have information where the sections are and like this like one deviation from like the very very specific one is like when you have the series of this section of the same time you can encode it differently and that's I think what Andrei also tried to explain on the um I think magicians right where you ask that um and so we kind of prefer that a bit

uh to the other option where it was like we just put all the sizes in like specific place in the header and this just yeah just read some bytes and you know where the things are but there's no really option to extend it easily uh in the future if you want to add So currently you can just add new section type and that will be some kind of somehow like backwards compatible so like they would you can add optional sections in the future and you don't need to know what if the section is about uh yeah but yeah definitely this this way to kind of compress this information more um I'm not sure about putting like

adding this dependency you mentioned that you would need to kind of read one section to know where the other sections are uh maybe it simplifies the parser uh but yeah I would need to look a bit how what does it mean practically and like for example where do we need to access type sections uh seems like we we access it more than we previously imagined I mean like at runtime VM needs to also check types I think in some places so yeah maybe it simplifies the password

and show if if the runtime will be simpler with this way but definitely you should check how it will behave and uh but still kind of we want to keep at least this offsets in the header only uh it might be also like related to the very countries later when like every every like chunk of of access is spread differently so if you can just read the header and then have all the information list to where to go next that may be useful um but I think most to try to explain why we decided it this way definitely we

know it's not like ultimates in terms of I don't know the density of the information or uh yeah we lose a bit bytes on bytes here and there um to keep this ability to add some to extend it for the future without bumping the the dof version does that kind of make sense yeah it makes sense thinking how maybe we could

experiment and try out both um I mean I could probably set some time aside to basically Implement with uh with the design that I proposed in mind and uh I don't know maybe see how they compare but um yeah with other like external things aside from just runtime and parsing then um yeah I'm not aware of like how that affects us so I'd have to look into it more right yeah I mean do you think it's useful to try and have this comparison and be able to take a look at like okay what is the complexity of this algorithm for parsing one versus the other what is the runtime performance of each that's very useful and then to also think a little bit about

how extensible are both of them and I think the note that we sent has some discussion about what the goals are from the perspective of being extensible and you know generally other goals that we had during the container header discussions so if you take a look at that that might catch you up a bit but yeah I think that that's probably the best approach and I took a stab at implementing some of those parsers you can kind of see the go code there as well just to get an idea but yeah always useful to try and look at it from a different perspective okay um just to Circle back really quickly we

talked on the chat about adding Swap and dupin to Mega elf just gonna give people a space for a second in case anyone thinks that should not go in I agree with Alex it's probably the thing that would be first on the chopping block if we need to reduce scope but it seems like a good thing to just go ahead and add right now okay we will assume that it's added yeah okay well uh Dana you had a few other

things you wanted to talk about do you want to move on to here sorry I was muted um okay so a few things I want to talk about before we took the detour on the container format um the first are the three items I mentioned last night or this morning um was reordering the containers so the data segment as last with create three we're adding new sub containers for deployment in the container and those got put on at the end um I would like to ask that those get put on before the data element and the reason is for for consistent hashing when we're adding the auxiliary data from the create three otherwise we would need to rewrite the containers um in some cases to put it in the tree to get it updated in this way all we would have to do is append the data and

update a field to get it correctly and it would reduce things like vertical trees would have more consistent accesses to the various uh deployments if we keep the variable data at the end and the stuff that depends on um and part of the problem is because the the data copy operations if you copy across a seam um you'd either have to have logic to join the two pieces or rewrite it in memory to to get consistent access to this so that's that's one request any thoughts on that guys yeah I think it makes sense to to have it in disorder

uh especially if we're going to append data which means it's much easier to do if it's the end section there's one one thing kind of reminded me that we kind of decided uh in the previous discussion that we already have these three type of sections and we add the fourth one right now that we made all of these mandatory in the header so maybe there's also like option or like make a decision to also make this one mandatory in in a sense there will be indication about it in the header but it

can be of site zero of the account zero whatever so the data can be skipped if there's no data in the header no the it's kind of the other way right so you you now need to kind of indicate the data section but you can put the size 0 there and the same for the subcontainers I mean this is deviation for to require subcontainers not just let them be absent kind of feels like this is not consistent at least um I I'm not sure we need to talk about it right now but uh maybe there's something to consider for the next time um I'm not sure how much bytes we

already put there uh but yeah I think there will be like three additional bytes that's kind of has have to be there so um wow I think we need someone need to to check like what the overhead is but if if one wants to like be more consistent what we presented before I think that's that's the direction yeah but I don't have three problem with the putting data it feels more natural for me as well to put data section as the like the last one foreign

okay I'll add that to the notes what else you got so while implementing call delegate call static call for the eof The Proposal was to change it in place at the same op code so instead of taking six or seven opcos to take two or three op codes depending upon the context and it's this it's the same operation number and that you know with the same op code number having two different call stack items um felt a little weird and I wonder if we should reconsider that and I know one proposal that went out was a Collex operation um where we would combine call delegate call instead of column of single

operation with um one immediate by that would have flags as to whether it's a delegate call whether it's a static we'd have room for other flags um with the with 43 uh 43 37 coming on the uh on the scene um they have a new validation mode that requires rejecting um not evaluating environmental uh op codes like block number and block hash um and so growth in in calls like that where we could add a no-end call and have an OM flag it's where those will be prohibited in the call as context um moving to a Collex type 1 rehab you know these eight Flags we could adopt

does provide room for adding new features and call without having to create a new OP code um you know it still would create you know overhead on the on the frame and the stack operation but that's one option and another option that crossed my mind is if we could just get new um op codes for Call to delegate call to static call 2 that would be the two or three op code version of it um these I think are less you know um these are more annoyances I don't think it's gonna necessarily break things but it increa it introduces more um this is the rule unless it's this situation type sort of thing that comes up in a lot of compilers is this where uh you know F1 is called unless you're in eof in which it's called with only

three yards it's you know my goal to try and reduce these it's this unless that type situations if we were to give them their own op codes or move to a new combined op code any thoughts on that looks like Paul responded that he wasn't convinced on the call X idea I didn't quite understand the call X idea you're saying that

there's a lot more cases that we might want to add flags for to check an example so right now the two flags we would have in college would be whether it's a delegate call or a static call um another flag we might want to add would be no environmental calls because I mean those static is basically blocking out certain op codes from from the column and stack frame that'll cause an exception we could have another one to add that in that would be something that uh that account abstraction would um oh I see collects would either be three op codes um and value just wouldn't be used in the case of delegate caller static call and require those to be zero or if those flags are set we would only accept two which would you know not

necessarily be a good thing to change the number of arguments popped off the stack based on the size of the media but if you view it as a as a two byte op code it's not too awful um you know it's I mean there's lots of things discuss about it it might not be the best solution but the thing that is that bothers me is having you know One op code number have two different uh stack operations basically on the context of the is this code run in eof or is this code run in Legacy and there's significantly different handling that goes on with them in regards to return data and I guess it's just return data

input return data value what are the two I'm missing anyway any thoughts on this guys really table it should we discuss it and at a later point yeah who you're calling the value so actually it'll be three or three or four three three or four because you need the address value might be optional the RX you're passing in the returns

wouldn't come in the memory um but we're chopping off um oh you're also chopping off gas so whether we get those three items or not in there it just feels I don't know maybe we should table it and let people think about it as they implement it I guess one thought I have on that I'm like not so deep in eof right now so I don't know I don't have as much context about how important it is to support these other op codes the only thing that I can say is that I think call X isn't my favorite solution like I think if we were to go down that path I would probably prefer just to have separate op

codes like have a call op code that doesn't allow state access and come up with a name for it we have plenty of Ops available still I don't think that we necessarily have to just put it in um a compound up but that's like a really minor thing and something that I could be convinced otherwise of Fairly easily but how about a new run of call delegate calls data call code allocations for the eof use case where there's three fewer arguments that way you don't have the conflicting auth meaning different things in different contexts yes F1 always means Legacy call semantics and like say E1 would mean uh gas free semantics

I probably need to think about it a little bit more my intuition is a it's not something that worries me a lot but maybe I should be put it out there as we think about it going on so I guess we can table this um my final point is a discussion on EXT data copy um that's one feature that we are losing from from for moving from code copy to data copy is the ability to copy data just the data section from another contract um there are people out there who are using um contracts as data sources um I'm okay if it goes either way but I think we either need explicitly allow EXT data copy or call out in the

rational of whatever property IP that this will make data contracts impossible then we're okay with that any thoughts on this um maybe a question related to it so so as as the eof versions change and these things um you know certain things become disabled another one's not obviously you can always just use Legacy formats or previous versions but um so is is the objective here to get basically

all new contracts move over to the most recent eof version every time or as or is this kind of more of um creating more like specialized contracts that you know maybe like a certain eof number is used for like a specific thing or something like that because I mean like data contracts would still exist right and they can still be read just not from an eof contract right so that's um they can still be read but that's there's another piece that is important for this is that we're not allowing eof to delegate call Legacy contracts to prevent Escape hatches like this um my vision generally speaking um I've heard other people discuss this at an

interop we were at um is that there would be at most one maybe two eof versions live at a same time and if we propose a new backwards incompatible eof version then we would need to have some standard transpilation from say eofv1 to eofv2 and all eofv1 contracts in the system either as part of a single point migration or when we go to the next version our interpreted or transpiled in the eofv2 and operate under efv2 so if we do things like we change like some of the stack orders some of the stacks or we totally redo how all the op code mappings work that there is a standard process we can do to say this eof contract looks like this in eofv2

so that's why we're going through this whole exercise of deprecating entire Concepts like the concept of of code visibility that you can view the code within your concept to make sure that we can maintain this transpilability going into the future um identifying things by code hash is going to be a necessary casualty those will just become identifiers if we ever need to use that sort of a situation so so that's the vision is that these versions show major compatibility things and that we would be able to to transpile from V1 to V2 and V2 to V3 and so that in in your chain you would have Legacy code and you would have eof code of whatever the appropriate Fork version is so I don't think the vision of having

multiple versions of EOS is something that we're really wanting to see because of the maintenance burden that the clients have expressed concern about when they see some of this eof some of the eof proposals that are going around right answer some questions uh answers a few brings up a few others um so I mean in particular you know there's already like a couple of contracts in the wild that kind of abuse mechanics that exist today that um you know maybe won't exist or maybe will change in the future right so I mean if this is the case and and people are writing like low-level eof code which I imagine they will I I don't know like maybe maybe

Transportation won't be as difficult as it sounds but I don't know it seems like if there are things that are being taken advantage of that are specific to an eof version then changing that would cause some kind of undefined behavior in the contract right that would be part of going to a new version is is clarifying what those would translate into the new version I'm making sure that it can be done that's why we're trying to keep eof footprint as small as possible in the amount of undefined as small as possible so that's one of the arguments for saying that there's no external data copy but you're right we could so we could subvert this by not doing a delegate call it's doing a regular call to another contract who then goes into its data gets it copies in the return platform brings it back

um the question is are we okay with those Escape hatches um because I mean that that would actually work with an eof if you have a data contract where you call the data it gets it and it serves it back to you um that's one way that we may not need EXT data copy you just have a standard data copy header in it so we may not even need this and it can still survive with their operations um so I think you know a lot of the bias is is if we can live without it reasonably we would want to consider that that's why we're also doing things like we're breaking the gas rules now um to where you can only ever send the maximum gas with your calls in you know the call delegate calls call status well um so if if we need to we could

reintroduce that but we can't remove it without breaking it so that's why we're biased towards doing all our breaking changes now as well right um well I don't want to take up too much more time on this but um I would definitely argue if we're going with the escape hatch route then I think delegate calls will be important because you know it would be easier for protocols to upgrade right since a lot of people sit behind upgradable proxies anyway I imagine it'd probably be in a legacy format and so if an eof version changes and it would cause some undefined behavior and they would need to update then you know they could do that through uh through the upgradable proxy but of course that only happens with delegate call but uh right delegate calling into eof I think we're allowing delegate calling out of eof we're not

allowing and that's because you can delegate call out into something that'll self-destruct and we're trying to keep self-destruct completely out of the eof right now so delegate calling out of eof to a prior version is not something we're planning on supporting honestly if I don't see a reason why we would want to support it because of risks like that of undoing the restrictions that might be added in a new version right yeah it makes sense I believe with the current implementation of self-destruct that it will only be allowed in um the same transaction that will do create two on the same address then if so basically the old version of self-destruct will disappear

that argument then is invalidated because it is like you if you if we're only like disabling delegate call for that reason then then with the new implementation that will come in Cancun most likely to see a fight for Cancun uh doesn't make sense when we made these decisions we weren't sure what the new version of self-destruct is and I'm not even sure that that version of self-destruct Will Survive once we go to the contract analyzes and see what contracts were breaking because there's a strong bias not to to break existing contracts deployed an existing functionality maybe we'll do that with the sufficient you know notice but when this decision was made to prohibit delegate call that was the first example and there was not enough known about

prior versions um but there's also some other features that we're getting out of um out of it like for example the observability of code um we can't EXT call into Legacy code um and bring it into the system without you know deliberate actions on the part of the code and delegate call there's ways that we could get around that so there's there's you know self-destruct's not the only one it's just the most flagrant one yeah that makes more sense so kind of my my kind of way of thinking is that we it's to like design this eof to be to be withholding like on its own so all of this in interaction with

Legacy is just because we already have it but it's not like we we use it as a feature to to bring some other features to F so I think like you have should be able to to exist in in isolation so you can imagine deploying new new blockchain that way only has UF and that should work and without much disruption so if if we think like data contracts is something really important as a feature then I think that there should be somehow supported uh I'm not sure it is I don't think that mostly to me data context seems as something that happened because of this like gas gas model is not really great

after talking through it on this call I don't think we need the XT call because if you have a data contract you can write a function that will read your own data and serve it up on request so data contracts can opt in to serve the data but the consequence is you can't go in and Snoop random data of other random eof contracts and I think that's actually a good feature you can opt in to serve your data through a call but you can't um just go search the blockchain for random stuff yeah what I mean is that if if you would want to migrate such a system to to a like different blockchain when there is no Legacy evm right so there's no way to extract this data if you need it uh because there will be no Legacy part

of of the system to assist you right I I honestly see eof only l2s is something that's got a very rich vein to mine on for a lot of features okay yeah but it's still kind of I mean the like I think in the position this can be added if if it's like proven to be needed or something like that so okay so the conservative uh option right now I think it's it's better agreed we can always add if we need it later so I I'm comfortable with that

that we're not going to do it and if we really need it but we don't think we need it and we think we have options to get out of it if we need it cool anything else spec related there's actually there's actually one thing um I spent some time on on writing uh what 337 support with UF

and I think we do have like everything needed with one exception um the gas removing gas observability kind of breaks 4337. because that depends on being able to control fast when running as a giant bundle right yes it's one of the things that's baked in how essential is it because the spec also says you're supposed to simulate your executions before you even try but you need to figure out how much to pay

and so to do this trustlessly you have to run you have to get the gas used at back or the gas left back otherwise the bundler just says I use this much gas and there's no way of proving it on chain without a complicated game well it's just a side effect of the contract that you're not proving it on chain you're just making it possible to execute with if if the bundler's behaving properly um to dispatch the gas and that would be in your in your smart contract wallet where you'd limit the gas when you would monitor your gas

I mean basically in the worst case you would have to have enough enough funds prepaid to to cover the total limit of the bundle right in the worst case I mean for each each um each execution included in the bundle don't you kind of already need that well you have the limit so you only need to include up to the Limit quite easy operation I did yeah I guess I'm not saying how that's different than what we were just saying so right now it's limited device that's limited by you know what is the limit

for the given user operation but if you cannot limit the gas anymore in the U.S then what you need to prepay is the total limit of the complete bundle which includes a number of other user operations the user needs to do this or the bundler does this I mean the user needs to have enough funds right good bundle we need to to select such users which have you know funds to cover all of that you know beyond what they specified for for the user limit would this be solved by a user operation being much better about estimating how much gas it's going to need if the

bundler is always going to charge the maximum gas and never give it refunds because I mean that's really what we lose with the gas is the Builder could always charge the user operation the maximum gas they'll allocated that's what I was thinking which and that that goes against what Alex is saying because if that's the case then you only have to have the max your gas limit not the bundle limit and the bundler would be responsible for ensuring they have enough gas too based on the map yeah yeah the bundler would the but the bundler already has to have at least enough gas to pay for the gas limit of the sum gas limit of all of the operations but I think what Alex is saying is that he's saying that each user also has to have that much um well basically for

I mean you know the the sequence the the operations are um are included um I mean the first the first one would need to have the total limit right because you may spend the total limit but as you progress forwards that how can you spend more than what you've how do you spend more than what you've put as your gasoline for your operation because you cannot control the gas limit you know as you do a create or call it's eoa that's being charged for gas so it's the eoa's job to recoup that gas I see so you just need to have in your wallet

logic that'll refuse to pay if they're charging you more for gas in the user operational lab for which would cause the entire transaction the entire bundle to fail at that point or maybe your subfundler depending upon how good the bundler is written I think what happens there is that you end up in this complicated scenario where it makes it reasonably easy for the user to grief the relayer or the bundler because right now if you just use the result of call then this is like the de facto cost of the transaction it doesn't matter what they simulated like that the true cost is going to be paid and so it's totally fair but if you

just rely on the stimulation it's not too hard to construct contracts where you do some crazy thing that makes so that it stimulates one way and executes a different way and then the relayer ends up having to pay more than the user is allowing to be charged even though the realer tried to simulate it I don't necessarily think this is the worst thing in the world but it does change the dynamic between the two parties a little bit I think we might be going on a tangent as well and I do want to talk about testing some but yeah this is I don't know what what else do you think about this Alex is this something that we should like try and look into and figure out how to support

4337 better in eof is it possible I mean it seems like a fundamental disagreement between the two well yeah it's not like in the US this agreement it's more like a disagreement with this goal of removing ads observability um and 4337 just happens to fully depend on it um I haven't really come up with any solution the the closest we have for that is you know the transaction packages we had that's like the really the closest option for um having proper you know gas um rebuilding gas observability but having these kind of features you know neatly

um yeah I I don't know what the solution is basically what this this will boil down to is uh what is more important like you know 4337 style operations and as they work today or removing gas observability that that is I think the final question so you can still run your 433 wallet in legacy mode and have it call it eof contracts that's you know and have your user operation call the eof because the first call in would be a legacy call into an eof and you could limit your gas there but to allow 4337 to stop the progress of eof I think would violate the premise of 433f that it doesn't

require protocol changes if it's going to induce and limit the scope of future protocol changes then it's actually causing protocol changes so that kind of goes against the spirit of what 4337 is claiming as a protocol free um support for user operations I don't know I think it's like a bit of a marketing term they're definitely planning to constrain future operations and they definitely plan to eventually make a protocol change whether or not that's in the marketing material right now and I think that's fine because if the user operations are top level and it's changing in the protocol then we can enforce the gas at the protocol level it's the call level observability that causes all these problems where we had

to put warm stuff when we got the the price on s store and S load that locked a few contracts because people didn't send enough gas if we can't require them to send all their gas then we lose the functionality that when we change the schedule any solution to unstick of transactions to send more gas because that will constrain our design space for fixing gas schedule problems but I think of this it's you know if they're going to come in with protocol changes we'll still be able to support it because it's not being done at a call level these user operations I think we should timebox this and talk about testing is there any last quick things we want to mention this is definitely something that we need to

continue keeping in mind yeah I think my closing uh thought on that is I think this will be like a really um tricky discussion to be had um I could really imagine you know based on this fact like UF would be pushback further uh what people still want to like discuss um observability restriction um so I think we definitely um should have a proper discussion maybe on the next call or the one after and figure out the strategy and and then

good answers and and you know everything around this topic and maybe the final uh agreement gonna be that we either don't support um this or you know push the um push the risk to the the bundlers or we get rid of uh we don't make the changes on the gas um but yeah let's discuss this next time um sorry to take everyone's time here but uh can someone remind me why we want to disallow gas observability because if you can observe the go ahead okay yeah if you can observe the gas and then you change the schedule in a later

Fork then it changes the behavior of the execution and so you might have some execution that relies in some specific uh gas amount being used and if you rely on that and it changes then your contract might be broken in a future upgrade and one goal of uf2 is to be able to just change contracts do transpile contracts from one version to another and being able to observe the gas makes it very difficult to do that right right makes sense thank you yeah okay we got four minutes it would be great if we could talk a little bit about testing that was kind of where we left things about two weeks ago

I think the last thing that we talked about was we're just approaching the point where we really need to have the eof test suite at some level of completeness so that client developmenters can have something that they're targeting does anyone have an update on where those things are I think Paul and Alex mentioned a little bit in the client update but I would love a um yeah North Area update how it's been going yeah as Alice mentioned there are there are um PR's in the in the test in the test repo uh I think most of them are

almost ready the uh these These are still in in draft well there was um there was a pending change or or request to retest it in order to um to check if um when we are checking valid or even validity of code uh we only get if the code is valid or valid but we don't get the reason so we cannot check uh the specific reason why uh a newf this is failing but um yeah I didn't I think

for now we are not going to use this format um and yeah the the PRS as they are right now I I think I are good to to merge into the into the main um to the main branch um at least for for the version one of your awesome is that something we can try and make sure it happens before the next call in two weeks yeah yeah I think so okay great two minutes left

any other comments on testing I'm in okay about testing uh well from our side in Netherland we are having a bit of problems regarding testing because we have some test cases that fail and we we don't know why they fail yet and I have a small question regarding get does get pass passes all the tests all the state tests of UF yeah currently the the tests are filled using get and currently it is it is agreeing with ebm1 as well so yeah both of them

can you link the the main branch or the main PR for of gets eof implementation because there we are we have one here and when we run it when we run the state test with the current uh merged eof tests they we see that some tests fail we're not quite sure we're still double checking but it's weird so here's been working on the yeah sorry you guys been working on uh um death against my branch and I was working on a Defiance and spiritual Outback as well so I think Hugo's branch

is kind of the latest not to the pr that's currently in draft against Geth so if you could share that Branch with them you go um okay that's the top of the hour any final comments can all the clients post where their main work branches so we could do cross-client testing possibly or at least see out and the same testing so just to know what is the latest branch of um fantastic

yeah with someone from Epsilon mind adding that to the mega eof spec or make another um not a hack MD to track these things or at least a place where you can share with client teams to update with their branches and that stuff yeah should we actually keep extending this uf1 checklist or should we do like in a uf2 checklist which I get a new collection of links what would be the best in eof2 checklist for ev2 because I think that they're asking

about the ELP one things the V1 stuff the new check was for Mega elf yeah we can update the old one and then let me start a new one okay that would be excellent one minute over I'm gonna post an update with a couple of the things we talked about from the spec section of the call on the PM issue I'll open an issue for the importers call number 12. and talk to you guys again in two weeks in the meantime feel free to chat on the EVN channel on the

youth r d Discord thanks a lot see you later thank you thank you everyone thanks everyone thank you