EOF Implementers Call #27

Transcript

hey everybody Welcome to the EF implementers call number 27 um I think we talked about eof on all Court devs a couple weeks ago for the first time in a while and had a pretty uh good conversation about it there and yeah I'm curious what people have been up to in the last couple weeks on the client side does anybody have an update they wanted to share not everybody all at once please

I hello can you hear me by the way yes okay uh in nether mind we are reimplementing e because it's been stale for our branch has been stale for a while right now and trying to catch up quickly with the mega spec and that's what we're doing right now cool anything on evm one I don't think we have much many

people are off these days uh we are still have several implementations in progress of the uh changes to the spec that were discussed in the last calls uh so like this Al and unreachable sections is one and like uh new design for grade three and four is still also in progress and also they can create four address init codes by hashes instead of indexes so these These are the changes we're working on but still in progress sounds good Dano anything on Bas Su side for updates no I've most been writing

presentations and doing video advocacy to try try and get a eof to happen so um one one question I was looking into possibly doing jump fi and call Fi um just had some questions like what are the op code numbers going to be for these proposed operations so that's that can be discussed later on it's my update thanks Dana I guess that's probably all of the client updates uh let's go through anything on the compiler side and then we can jump into some spec discussion I see we've got Daniel here any updates from

solidity on EF not really uh yeah I mean we've had the implementation of the previous version last year but since then since yeah I'm a bit skeptical about the guarantees that all CS can make for it ever happening was a bit hesitant to spend time reimplementing the new version we may do that but yeah still catching up with the changes we've discussed internally with ipsilon a lot of the changes but yeah from our side we haven't yet updated our implementation to the latest version thanks for that update Daniel um Charles anything to share on

viper side uh no about the same okay uh all the updates are done then shall we jump into spec discussion I don't think I saw anything specific on the agenda what do you guys have on your dockets yeah I think we discussed it in the channel but maybe it never made it into the into the agenda Point uh I think there was basically two points we really wanted to discuss um especially that we have both Daniel and Charles on the call um so the

two questions regarding language implementations and one of them is the the various versions of um the swap dup um so 663 the other point was the stack validation or air jump if um and I think lastly it's just really the call to size or versus gas regressions um I think these are the three topics of which we really need to make a decision on um probably I would suggest to start with the stack validation and because Andre wrote up a a lengthy explainer of that topic and we did share with Daniel I believe charie also read

it so maybe that's like a good one to to start with um I'm not sure Andre do you want to read the discussion since you wrote the document uh sure I can give an intro it was written by Paulo partially too it should be introduction part and uh so in two words there is a problem with the current St validation which makes things difficult for compilers or like leads to code size regressions where they want to um jump into helpers from different St Heights and

current St height validation restricts this to uh uh to any instruction in the code to be reable only from the same stti height and so we've thought about one algorithm that loens this restriction but makes it the algorithm itself becomes a bit more difficult or complicated and there's also an extra requirement for how the code blocks are ordered in the code section uh specifically any uh

uh any block is reachable via a forward jump or a just a flow of instructions so it means that no blocks are reachable only via a backward jump uh and in this way we can go over all instructions in one pass linear pass instead of using a work list and then keep track of like the range of Stack Heights for each instruction and in the end uh like a low a range instead of one specific St for instruction and this seems to solve the problem but like makes it more complicated um and another solution

which is not really solution to the problem but rather approach that compilers would take instead of using functions or Cod for these helpers but just use uh oh rather no this first approach was actually when they don't use code sections for helpers but use uh just regular relative jumps and if they put the helpers into the functions then jumpy might be the solution that like leads to a better code size in the end and makes it acceptable to put this this help us into separate functions so to me it seems that like

yeah on the one side this more complicated algorithm is more complexity but then the question that we have also if it's possible then to drop non returnal functions from this spe and jump F maybe they they are not needed then everything will be using just these jumps and helpers will be just like uh blocks inside the same code section then maybe in the end the entire spec will be simpler even that would be nice I think and yeah so um one difference is that uh jump

IFI uh has some other good properties which it allows better code sharing so you can always factor out some shared code into uh into a sub routine whereas if two sub routines have the same code um merely relaxing the stack validation rules won't help you outline that code I mean it's two separate things really it's uh code duplication within functions and across functions I mean the stack validation

relaxation allows code D duplication within one function and the jump uh the jump fi approach makes it easier to do a cross function code D duplication the disadvantage is that you need to have had inter sections for the functions that you outline that's the main thing where the stack validation has the advantage if you don't want to uh D duplicate cross functions you save the overhead of the of the function headers uh right yeah ideally we'd have both right right right right ideally we would have both but I'm saying that the D duplication

cross functions is like more General because is you can always D duplicate across functions even at the cost of a function header and call um but if you only have the stack validation uh relaxation then you might be in some situations where you can D duplicate code within a sub routine but not across sub routines the actual code side straight off would be easier to evaluate if we had complete imp mentations of all the options of course but it's significant effort um the code size issue has also

helped a little bit um it's helped a little bit if there's um R Jump N I so a lot of instruction sets have jump if zero and jump if not Z so if evm had both of those instructions then we could save a bunch of is zeros uh which doesn't entirely fix the problem but it makes it more um palatable and it's also really easy

that's getting a lot of jump up codes then um right I mean in general in our sorry go ahead yeah so we could like choose between them or um yeah like you said MO a complete implementation to like really compare all of them but the last indic implementation that we had of the previous version I mean all of this applies to the previous version as well basically uh indicated that actually the dropping of jump tests

already decreased code size costs a lot uh so yeah it's the Cod size increase I was initially more worried about than after I had this initial implementation although that implementation was written against a incomplete evm one implementation that allowed jumping to blocks from different different stack sizes and had code dep replication in it so even though only within functions so that had actually has an Cod size Improvement in the end but yeah it's yeah for Viper actually even with the jump test removal we got a Cod size regression interesting

I mean the main questions and I mean from the compiler side I think it's rather clear that we ideally want to have all of this the question is uh what's the maximal option out of this that we get or can realistically expect so what kind of choices can we have between combinations of what we just discussed that's basically what we need to do I would say yeah we're trying to minimize the

overall complexity and I would say we should have either one of them and I should note also that both of them are forwards compatible so we could theoretically introduce another one as a later upgrade um and I don't know given that jump F if jump F and non return functions are useful by themselves and we can't get rid of them with relaxed stack validation then maybe jumpy is a simple one to add and this is just yeah so the options I would say to having in mind

the goal of minimizing the complexity is less restricted St stack stack validation but no non returning functions and no jump F or restricted stack validation and jump F and uh non return functions and jumpy that's I think how I see it I think I'm okay with jump ify I think it's like a general solution and it seems to me that the implementation is simplest um for the clients I have a concern that it's a little bit more

expensive than uh our jum by and that might add up the problem is it makes it more complicated for us to determine when sharing the code is actually cheaper because you always have to account for the additional overhead the code Tob coion using arumai within the single function is always beneficial so that's a no-brainer but it's not like that's yeah a block yeah it produces a code size versus gas kind of tradeoff which you have to take I would say i' really like to have

the ability to D duplicate within functions but I would tentatively be fine with jump fi as well even though it's from our side I think the more complicated solution I mean one more thing to consider maybe is I mean one can simulate jump fi with uh R jumpi and jump F of course uh that makes it a bit more expensive then and is reliant on having uh the stack height relaxation because it would jump

these outs would jump from different uh different stack Heights but that with a there's a good measurement of how much an improvement jump fi would actually be on top of that if one has Cod duplication within functions without having Cod duplication within functions that sucks but I mean with that not entirely sure yeah so one use case I realized for jump fi is that you can actually perform stack unwinding because you can have like a help you can kind of like emulate R fi which you can also do with r jumps um

our Jump by but uh it's kind of interesting because you can have like a shared stack unwinding routine so it gives you different ways of ter like kind of terminating execution of the subroutine mean sharing that between multiple subroutines yeah I mean but why does it need to be conditional I mean you can still do that with an not jump I and a jump F I mean it's just minor optimization there of that becoming a bit cheaper I mean that only works if we have the stack uh H relaxation because all these

cases where you share stuff like that I mean stack and weding maybe not but a lot of cases are from different stack Hees so and I'm a bit worried that the stack the strict stack validation will bite Us in the back in the end because yeah it's very um it's very kind of yeah it's restrictive and I see what the the the the want for from the B code analysis side but it does make the compiler job like a lot um maybe there's like

one reason for it um is it if we are unsure you know what is the good version if you do start with a much more restricted version then it can always be relaxed but going the other way around is um going to be way harder if not impossible but I don't think that there's really any reason to go from the relax validation rules to more stricter validation rules like I don't think there's any benefit to analysis um the only con is like it's a more complicated

algorithm but there's no like semantics reason that I see that we would ever want to get more restrictive on the stack validation it's true could even imagine that it's eventually maybe with an different algorithm even possible to get around the ordering requirement Happ planned to think through that but never got around to but do you mean the forwards versus backward requirement yeah yeah I agree I think and I think I suspect that it can be completely relaxed but I don't yeah so I haven't gotten around to the

through but yeah I mean the Restriction is something we can deal with in the compiler that's not too much of a hassle I think you mean the ordering restriction yeah yeah yeah yeah it's fine I I the ordering restriction basically says that you can't have like these unbounded Loops which uh from the compiler perspective is totally fine but yeah that kind of didn't bring us further now well it did because

like like you said you can uh so in the in the in this document um where we go through jump fi it doesn't at the very end of the document there's no um um should I share my screen hello yeah yeah yeah yeah so it uh this is with current e this is with jump fi but there's no example of what it would be like with relax stack validation and what that

would look like is I don't know if I can leave a comment or how do I leave a comment it would basically look like push condition um or by at end of the sub routine and there you have the choice

whether it occurs in multiple functions and the jump F in the helper code or if it only occurs in one function to just inline it there I think that's actually nice and I'm not sure whether the jump uh jump fi really improves that much across that right right um and addition sorry go ahead okay uh I mean the additional code size involved in that pattern is

probably I mean yeah maybe even alleviated by being able to inline some of the helpers if they not use the cross function yes you can take the choice whether to inline the helper or jump F out but the the it's obvious here that the the gas the the gas performance is better is best what you mean that uh jum fi is cheaper sorry it's best in the happy path yeah and you usually these kinds of

things are used with something that's very likely or unlikely so you can kind of optimize around that yeah I mean this discussion now so far leaves me to conclude that actually the stack height validation relaxation helps equally or even more than jump F and I'm completely fine with what you have in the comment there as as a pattern yeah I think that only works with the stack validation relaxation otherwise it can only happen in very few cases in comparison yeah so I mean my initial um

take was to do the relaxation on the validation and then you know at some point jump if I was suggested but um and I think that kind of I think like we've been saying it kind of solves the problem but the stack validation is kind of I think it's more elegant from the compiler perspective that a workable conclusion for For the Rest yeah I would agree from my

perspective it's also more elegant so solution jumpy feels like a hack like it's something that solves one specific use case for compilers but I see that I understand that you ideally want both St heide relaxation and to keep jump F because it's also useful for duplicating it across functions yeah jump if is very important in that sense uh hang on if uh we don't if we have this stack validation relaxation do we still need jump off yeah that's one of

the questions I mean you just had it in the uh pattern replacing jump IFI so I would say yes but you could use callif there uh what is the latest restrictions on stack Heights and stuff for call F and all that does that work in all cases and then you need call F red f potentially I mean jump f is nice in any case yeah you would need call F and red f to make it not fall off the code section without jumping oh because you can't

terminate yeah I mean I was under the impression that jump F and stack height validation relaxation together is an option and I would choose that option uh so you're saying that if we go for uh stack height validation relaxation jump F would be too much on top of that not yeah it's just my view that it's I don't like jump F complications by itself it makes like ation tricky around it with the non- returned

functions uh it's a bit messy the spec of jump F I would say and ideally if we could get rid of it that would be really nice but I guess if it's really useful then uh I don't know we can keep it I guess it's hard to evaluate the entire the entirety of complexity of this spe at this point it's just enormous in any case to me it seems yeah I'm also not entirely sure out of my head now whether we the stack height validation without jump F would still be

fine I remember that I had a lot of good reasons for asking for jump F in the last version but yeah I need to revisit that but in any case it seems like the relaxed jump uh uh this relaxed stack hiide validation is generally agreed upon as a nice solution so that's something to Target anyways and then jump F and jump fi potentially wait they can still be introduced

used I guess yeah I'm not sure if jump if is still needed actually I'm looking at the stack validation rules and it's like um uh I think it takes some time to think through because there's the no returning case versus The non- Returning for the returning versus non- returning cases yeah it also need to think it through but we can say that with the uh

relax deide validation uh yeah jump fi is unnecessary definitely and jump F may be unnecessary which in general seems to point towards going for the relax de validation yeah I agree I think that's as far as we'd get in this call about that yeah I think I'm fine with this conclusion so we include both relax St validation and

jump F but not jump fi that's the tentative Direction yeah and jump F we can still evaluate whether we can actually drop or not yeah agreed maybe let's try to move to the swap and stuff yeah that's fine by

me yeah not sure how to do that I mean do you see my point that it's very twoo orthogonal things we're addressing there and I mean I see that for you it's more important than one thing and for us um I was saying oh yeah I think I said on the last call that it's probably easiest just to have both instructions I mean they're both I mean there's like actually obviously quite a lot of variant of you know swap stack manipulation instructions which are useful um but I think for our use cases I think that just having both swap in and exchange um

um is the easiest thing to do if that's fine in sense of up code space that's definitely the best solution I mean we really need swapn if we get swapn I mean exchange is nice to have we don't need that but I would also be happy to have it so I guess for you it's rather the opposite but yeah it's the opposite I mean kind of kind of for us it's easier to spill to memory uh than and then you know stack [Music] scheduling um is a little bit like intractable

unless you have you know this exchange op code because I mean in the general case because you can never guarantee that things are going to line up are going to end up on the stack in the order that you want I mean in intractable is yeah the question I mean it's still like I you can still emulate exchange with three up codes I mean that's annoying but it works whereas Swap and you can't emulate but uh but yeah I mean exchange is a nice thing and I mean any mathematical uh treatment of permutations assumes an exchange operation it's much easier to to build algorithm around it it's not as efficient since you always for the case that you produce something on stack top

which is a common case you always produce everything on stack toop but but yeah but yeah I mean I would say for that the best conclusion would be just to key BP 663 as is and we add a new one for exchange I think the best outcome is to add it to the to the EIP 663 otherwise we have too many eips floating around I mean fine either way I mean yeah as I said I I really need swap an around that simplifies our compiler complexity by extreme amounts I mean yeah spilling from memory for us is is a nightmare if you have

Dynamic types in memory but uh but yeah question is whether there's any objections from clients and whatnot to introduce three up codes in that e instead of two but yeah the feedback I got and the reason I I replaced the op code in the pull request is because the feedback I got was like op code space extremely extremely limited and so we need to like choose exactly one op code maybe just save jump fi so that's one good maybe right and maybe jump

f yeah not sure what more to discuss I mean for us any solution that preserves swapn is fine that's about it uh so I think the question is like is it okay to add an off code slot for one of the exchange or two of the exchanges um the single bite or the two bite immediate or

both at least the single bite immediate that should be fine I mean we're going to have to probably spill out of the E block anyway I mean if we have like a budget for swap op codes I can like prioritize which on can like start adding until we fill up the the budgeted space because there's always like I said there's there's always more stack useful but yeah I mean a single bite exchange version s reasonable I mean the two bite one could be emulated by a lot of Swap and uh uh instructions then

which is not nice but workable so yes usually you don't end up with that kind of stuff too deep in the stock yeah well sure I agree to that but that's fine yeah and like you said you can do a three instruction thing so it's things are more deep in this time what if we did the two bite instruction first because we can always add a one bite instruction later and adding the two bite instruction gives us the coverage and the one bite would just be um size reduction that we could quantify uh let me think about

that yeah I mean I'd leave that up to Charles but I mean the disadvantage is of course that code size increases if you want to use exchange a lot that's a significant effect I would say a lot of that is small stack uh depth and you still need two bites but so would save one bite you know do a do a swap five and a swap three um that gets you back to you know get an effect of five and three swap you would do a swap 53 that would save one bite from the two if you're doing the swaps a lot yeah and this is an extremely common operation so it's like a yeah two versus 3 byes it's a big difference yeah okay true that actually

that sense even already saves I mean for us it's not that common actually but but yeah either way fine with me actually be a three by swap because you'd have to swap five to one one to three and then do a one to five swap back to put one back where it was so the exchange one or two by version saves no matter how we would consider it yeah it saves uh two instructions um but not necessarily on code

size so there's instructions it would save three or four bytes per um not necessarily because like swap five swap Three swap five is three bytes and nine gas whereas exchange with one bite immediate is three gas and two bytes but exchange with two by immediate is three bytes and three gas but you would need the third swap to restore the number one position on the stack yeah that's still three

buds it's three swaps versus One exchange The Exchange is two or three bites depending on how many immediates yeah it's it's one instruction and two or three bytes depending on the number of immediates so we're talking both about bytes and number of instructions in any case I mean i' but I myself find an exchange with two immediates that then covers the entire space nicer for us because we're more likely into running into deep stack but

I'm also fine if um Viper Says they don't run into deep stack and want to save even more even another bite in it that would be also fine the issue is usually you want to do exchange at um like the worst case you are kind of trying to do exchange at the last step before executing an instruction and um by definition those things aren't going to be I mean the largest instruction is probably like call which I think has seven arguments on this deack so like you can always like kind of preemptively schedule something really deep in the stack but I think you kind of

get yeah maybe I can think about this more but I think I think that mostly you're trying to reorder things in the stack that are kind of close to the top I mean for us things work differently and we schedule within blocks uh two optimal stack locations I that before they actually instruction we don't need to shuffle anything though for us shuffling only it takes place in uh interblock scheduling across jumps and there it's the entire space but yeah that's different implementations in the end so even if it's a wash with three swap instructions one bite and a two bite exchange that's one op code and a save

six gas and it's in the evm loops it's one it's two less trips through the loop which I think the trip through the loop is probably a bit higher cost than parsing the immediates so implementation wise it is faster even if it is a wash on bite size and it's a gas savings to end users yep yeah I mean I think I'm leaning towards uh the the one bite immediate so one bite exchange and a one bite swap that goes deep yes

exactly live with so I wonder if we should make exchange a separate um EIP then um the argument is there's tooo many eips but when you look at the unified spec I think we can demonstrate that's as much of a red herring as we're doing

these separations to be able to um package it up in different you know finally grade specifications of the very specific thing um so I don't think too many eips is necessarily I think it's something that could be defended against and argued against people try and bring there's to many eips but we can point them to a unified meas spec that is actually short than the merge spec and shorter than the bural tree spec so I think I'm not as concerned about that that is a legitimate concern but I think that's when they can be mitigated uh one concern I have about multiple eips is that uh they won't go in together so like it is more likely that one will be slashed

from the final spec and unfortunately I think that's the horse trading we're going to be in in a couple weeks if uh we can't trade horses it just might not happen I mean I would say conceptually it's really to quite different things that solve quite different problems so conceptually I would say it would make sense to make it separate dips but I don't it doesn't matter to me at all I mean fine either way I think they actually makes sense to go together because they're both like new stack they're all just stack manipulation instructions with

immediates uh because like the new Swap and dupe instructions aren't even like unlimited they only address 256 slots so they're really just new ways of manipulating the stack in that sense that's the Common Ground yeah yeah initially they were unlimited but we reduce them to a single bite immediate yeah I'm fine having it the semi IP or multiple IPS um but I guess the agreement is that we do want to keep the swap

in uh as it was and we introduce a new exchange is that correct yeah I think the agreement is want to have both yeah oh well W wants to have exchange and we want to have swap in so yeah I mean since you do have the pr open to change the existing AIP I mean if you want to change that to add the new instruction I guess it would be simple to merge um that being said what Dano mentioned that we we maybe need to have some some cards to trade I mean even if it's a semi IP

we can we can make that U we can make that statement right that exchange could be moved out so on the subject of cage to trade one of the the breaking lines I'm thinking of is we put all of the restrictions in the first release and we add the crazier replacement stuff like getting rid of um EXT code copy and replacing it with code visibility and replacing the call stuff do some higher level stuff in the second one so the first one doesn't change too much other than the packaging and the things that are needed to make it um useful for I think I mentioned some of this in the uh EO in the eth magist thread and to make put put the features that the compilers need in the first

revision and then do the higher meta changes in the second revision which would be the code visibility and the um gas visibility changes so that's as far as you know horse trading that's what my initial offer would be if if they say no to Mega and of course my first position is if we can get mega let's do Mega I'm all in for the big change at once but it's not my decision isn't the problem with that approach though that that's basically what we were at last year that didn't work I mean that had already most of the compiler relevant changes and all that yeah I totally agree um but now I mean

the problem is we're getting contradictory requests from opposite sides of ACD and we just need to get them in the room together and say look this coordination failure is going to kill this and it's going to drain the out around the evm chain if we can't update the EVMS um so this I think we just need to get them together and have them say you know one of you has to relent on your position that either needs to go in only once or that needs to be in smaller bits otherwise you know eof is evm is aifi and we're losing a keyote yeah assuming people show up to Istanbul to get in the same room yeah don't don't jinx that um all

right we only have like five minutes left and there was one last topic um which would be nice to discuss um the call to changes and the open it up um yeah I think with call 2 that the return data is removed um Charles you brought up some concerns that this may uh cause some regressions in terms of gas usage or code size and wiper um do you want to maybe like very quickly expand on that and I would be curious to hear Daniel's um view on call too

yeah basically when you already have a buffer that is bounded that you want to um have the call insert the return data into right now you just add the output buffer as the call arguments but with call two as it currently stands you would have to do some calculation to calculate which is smaller the allocated size of your return buffer and um return data science so you need to add extra instructions around every call to and return data load solves this because then you can adjust Aid code

directly out of the return dat a buffer I honestly didn't have the time to review this stuff but return data load is nice in in general that's the question I mean the return buffer yeah it's fine from my side not to have and to have but yeah sorry I'm not up to speed on the latest versions of that stuff yeah I think the so maybe they

like to simp questions to answer here so what call 2 is is doing um um I mean it removes the gas argument and it also removes the output um data area argument so it won't copy anything to the output um and it also returns three different states um success failure or revert and question number one is um are we okay with removing the output data arguments or would that on it on C some some issues for solidity no unsolvable issues the tradeoff and cost would need

that's difficult to anticipate but I wouldn't expect it to be bad either way it's fine in that regard I mean we also do use the arguments for static return sizes like which is probably the more common case in Viper even I would imagine but uh I think the cost of always using return data copy is not bad for how we implemented things currently too bad okay yeah asking for for the output area the base the base argument is says unless

there's going to be a strong argument uh for keeping it then we probably want to just remove it in order to simplify the op codes um so this is something to to probably follow for the next few weeks and the second question is the return data load instruction which I guess the answer is yes that um both compilers would love to have this instruction mean the thing to the thing about there is that of course compil just want to have all sorts of instructions all the time because it makes everything easier but return data load is very nice that's that's definitely the case yeah I think the issue here kind of is like if called 2 is going to force us to use the return data buffer then the

feature set should be on par with memory um because like previously we could use memory and no we can't so we need return data load if here like a difficult question regarding return data load on the semantics um so return data copy currently aborts if you go out of bounds um but M load and call data load just return zeros so what would be the semantics of return data load would it be uh ping with zeros or would it uh a board and we please change the semantics of return data copy to not revert in the

first place that would be ideal and then also do that for return to a load just make it exactly behave like call it a copy and C it a load yeah the only issue with I I'm okay with either the issue with the only issue with return data load uh reverting uh if it if it gets too many bytes is that if somebody ever wants to return pack data like one bite of data then you have no way of access accessing that with return data load um which is more Which is less of a problem actually than call data load so like call data load there's more incentive to pack it but

return data load is priced so that there's no incentive really to not pack with zeros I mean from the returner side so there could just be a convention that return data is always at least 32 bites General the Divergence between behavior in call that a copy and return return that a copy is quite horrible in general I would still argue I mean I would love to see that unified and I would if I had the choice UniFi it and not reverting and there

zero pading but one nice thing about uh return data reverting is that uh it simplifies ABI decoding checks so when you're doing ABI decoding you can just rely on the return data reverting on out of bounds uh and you don't have to do them manually so if we got rid of the revert um on return data copy um would solidity and Viper need to write two separate subes to handle the new revert free logic or would it just be if we're in the reverting logic here's some extra steps otherwise skip these steps I'm not quite sure I understood

but I mean we never rely on return data copy reverting we just have to avoid running into it so for us it's a pure simplification to not hope have it reverse right so the code that you would write that would make sure it doesn't revert and do the verification you would just turn that code off when you're generating eof you wouldn't have to write different code to replace it you would just not generate it basically yeah for Viper that's the case so like whenever you do ABI decoding there's some checks um like that it's a certain size and so on and you would just skip those checks if the if the return data is reverting if it's not reverting then you just add those checks the same as you do

for call data okay that makes me more comfortable because if we were going to have to write two separate sections of code whether it was eof for a legacy then know it brings a security complexity risk but if we're literally just turning a code section off when we're in O that's the same surface mostly um we might have to Mt we might maintain two different code paths depending on the output Target and that's the concern is way be increasing the surface but if the returns are big enough that it might be worth the risk um yeah let me think about that

it uh I actually haven't considered what would happen if return data is is not reverting uh so it might be um this we might be able to get it to be like basically the same code in either case I'm not sure I think the ideal would be that the difference between Legacy and thef code is here's some code that checks revert and it's just absent but I'll let your comp other guys um make the best decision there I mean for us it's not a problem

we could live with the change either way and have unified code if I'm not misremembering that wrapped extremely at the moment I think it's you basically avoid the situation from happening anyways like oh I see I mean Dan if you're asking do we depend on return data reverting right now the answer is no right so so that's fine we don't depend on it now and uh we might be able to depend on it in the future with call 2 but otherwise we would maintain the same code yeah the big upside is whenever there's a solidity tricks in troubles API um conference talk they always mention this so this would be nice to get this off their

list um yeah I wanted to mention one last thing um you know I mean we're like six minutes over the lot of time frame I'm not sure how much time people have um but in two weeks when we would have the next UF call we have death connect and I think most of us are going to be able um and I think in fact two weeks exactly from now is going to be the evm summit day uh so I wonder if he could maybe allocate um some time to meet up there and maybe discuss some of these points more in depth uh or should we consider getting some inperson meeting

if most of us are going to be there um or otherwise just probably set up the next UF call to be the week after death connect I'll be there Sunday through Thursday Monday through Thursday at least um debating whether to trim my travels or keep it but those core days I'll be there uh I'm still deciding whether to go but it would be Friday through Friday and I could meet for the UF stuff might be there uh let's be at the

evm summit okay so probably skip the next one and pick back up one month from now skip the next call but meet and Dev connect sometime if there's a meeting being planned at Dev connect it might be um good to have it be like dual attendance so people can attend remotely if they want yeah sounds good I mean yeah let us know if if you're not going to make it then we can accommodate you or if there

was someone else that said um right yeah I think we made a really good progress today in closing out these um last questions uh hopefully we can close them out um during that meeting um but then you mentioned that you know we may want to think about how to actually deliver this and how to split it up if there's um you know more push back on some aspects um so what do you think what what you know regarding I mean propos this for prct so what kind of timelines are we looking forwards to um in terms terms of like ACD discussions do you think uh assuming we

make like most of the decisions during death connect then probably we can Implement those in the specs like in a week or two after um when are we going to bring this up on allord devs again so I was hoping that we would be able to have more allore devs meeting together in stemble but um looks like some people may not be there um I think we should try and have these talks in parallel and assemble if we can pull them off if we can get the right people in the same room um otherwise um because because I think we need to get a clear signal from the people who are raising the objections as to whether um a two-step solution would work or if they just object to eof in principle and I'm I'm secretly concerned that there

are people who just object eof and principle and want to see the current evm Frozen and that's the biggest concern um but if they're just concerned about the size and another concern that was brought up in bogat talk was we don't want multiple versions of eof live but I'm thinking um this goes into my my thread that I was posting on ethereum magicians if there are still two versions but they only differ in op code set available if all of the validation is exactly the same it's just a function of which op codes we push into the op code validation Loop then I think it's it's easier to say that you know to have three three different instruction sets available Legacy eof1 and E2 if that's what's going to take and have UF be the

main recommended one um but the eof1 just doesn't have the uh the visibility uh the observability stuff removed and you know we just change which op codes we put in we put all of the restrictions in eof B1 and B2 and we use the same validation core logic to verify them that's you know what I think the two most viable approaches are and of course you know my favorite one is just to do just do everything at one time and see what concerns are and see if we could address their complexity concerns if the issue is just amount of testing if the issue is about um utility if you know whatever their issues are make sure that we can get them and make sure that the objections just are I don't like this and don't want to see it done you know if there's technical issues if we can

address them um you know if the issue is it's too large I mean it's sometimes that's intractable but that's what I would want to see is if we can gather this together while we're in a stul um but I don't think we should go back to all devs before you know the second call in January with this unless we have a concrete plan that everyone's on board with um I think we need a probably after they split the uh establish the Gorly Fork so we could do it in between the gorle and whatever the next Fork would be but I'm open to negot I'm open to other alternative ideas I'm not you know it's not that plan or nothing but that's you know an initial plan to go

all right yeah I mean I mean let's see what we end up doing the def connect um I think the only question I had left whether we should tentatively schedule the um the online call the week after death connect or as Matt said two weeks after um yeah and I think I'm tentatively towards the week after death connect um just so you know we we can get um oh but that yeah it would be out of cadence yeah I guess we can do it like one month from now and then let's hope that week Cadence would be the 29th Dev connect would be the 15th so for the fifth week the fifth

Wednesday in November we got five Wednesdays I mean it's two weeks from now and we have it every two weeks so like four weeks from now yeah um would be the the ideal one let's I like that idea Keep It In Cadence right awesome um yeah we went uh slightly over with I think this was super useful I'm not to mat your um you're the moderator do you do you have any closing instructions to say no uh great call um thanks a lot for

the discussion appreciate you being on here also Daniel it's pretty helpful sometimes to just sit down synchronously and discuss these things um hopefully I'll see a lot of you guys at Dev connect safe travels and we'll pick this call back up in the near future thanks see you guys bye you thanks byebye bye