EOF Implementers Call #6

Transcript

hi everybody hi everybody Welcome to the eof implementer's call number six formerly known as the eof breakout room we decided last week to start doing this uh on alternating weeks of all core devs for at least the next couple months to try and get a hold on eof and figure out what the game plan for um you know trying to get a Cancun inclusion is so yeah let's start with some client updates does anybody want to share what they've been up to since awkward devs last week or maybe like a little bit before that

basis been doing mostly cleanup and some um taking time to do some optimizations now we got it correct we can see if we can do it faster so um one of them has to do with the PC of rbh and another one has to do with um Counting dead code so nothing too exciting or groundbreaking cool never mind uh same we've been just doing summary podcasting code and doing something minor optimizations here and there great

uh Aragon is anybody here guess not uh okay on the guest side uh also pretty similar spend some time trying to clean things up uh I haven't really done much performance work on the pr still mostly have been trying that sends the cleanup to improve errors and logging and so that kind of also uh came out through this uh proposal for this reference test format which we'll talk a bit about is testing section but

yeah I think yeah that's most that's mostly it yeah not a ton of new things on the gas implementation foreign foreign Daniel do you want to give some updates from solidity uh yeah can you hear me I hear you okay uh yeah nothing substantial has happened since the new year for us as well I think I mean we did have the uh uh yeah PPR draft of an implementation in the end of last year reported the last dishes we found but yeah that's basically it for us actually uniswap tried to Moody from

uniform try to run testing through them but we yeah I haven't heard from him back now for a few days but yeah he wanted to pass through with 3mjs and had some issues with that but yeah may you have more data soon got it all right let's see any other compiler updates from anyone okay spec updates uh are there any things from ipsilon that you guys wanted to bring up and talk about there's a couple of things that Dano listed that we can chat about

but is there any things that you guys have on your mind okay so I guess the first one here is yeah I know you're interested in removing this PC verbiage right do you want to talk about that quickly yeah so um back before we got rid of the PC operation it made sense to aim to where the PC equals zero is inside of the execution um and that's the beginning of the code section um now that we don't have a PC or a

direct jump there is no way to introspect or interact with the absolute position of the PC inside of the spec so I would like it removed um and you know execution starts at the beginning of a code section without saying the PC um because one of the optimizations I did in basically was I didn't split out the code sections I just set an entry point of where the index is from the beginning of the container and it all works because you know the code never overruns because we already do those checks um so it helped me from having to you know like in the uh degenerate case of 1024 different containers I don't have to slice up the array a thousand times I just use the same array passing it

around so it's helping on a lot of garbage collection in Java which is a bigger issue than in a lot of the other languages Alex has a hand up yeah so EIP 4200 um still have or also refers to PC and had a PC is modified but the internet there um and I think the same applies to uh the other EIP as well the intent isn't about what the the PC opcode is returning it's rather the internal PC representation right um what The Interpreter thinks uh at what position it is currently executing

um right but if it's all relative it doesn't matter what the zero point is does it I mean in the Erp 4200 if you want to eradicate PC as a term entirely then I think we need to come up not as a term just just the PC equals zero designation I mean that's only for stating that execution starts from beginning right and is or we could keep it but either way um you know I could when we need to expose it just you know look up the the entry point index and do some math

but if we're removing PC observability then it doesn't matter because PC equals one or PC equals 42. when you when your code section starts yeah that's an interesting point can can this in this in the future if he yeah if he relaxes if we relax this PC equals zero yeah yeah I mean I didn't send a point um but yeah it I guess it just only matters if PC error becomes something that can be introspected again because right now the way that I understand it is that you have implemented the eof spec it's just

that there is this guiding principle of PC equals zero to states that execution starts should start from the first byte of the code section but the fact that your PC is an absolute value across the container you still get the same outcome yeah I think where you could have issues if some other off codes are described you know that they do something based on the PC and if they don't do it in a relative manner right and right now yeah yeah that sort of start mattering again so we could bring it back in if we need to do absolute positioning but the absolute position becomes problematic

for certain code Transformations anyway so I think it would be hard to bring it back but not impossible okay I I personally don't have a problem either way so if um you guys are okay with removing it I think that that's okay [Music] yeah I I also don't have a problem with this suggestion I I'm not like particularly foreign thought about this back as a kind of

explanation how it's supposed to work but I wasn't ever connected to this explicit value zero yeah Alex I would suggest if we remove the PC equals zero wording then somewhere we should explain this explicitly that it is implementation defined and every single instruction has to be described as being you know relative um if they change the PC it has to be relative maybe this is under security considerations I'm not sure you know they're maybe that's the best section for it but I think it has to be made clear

so the trace specification on the standard tracing may impact that I'm looking at this now and now here hearing the discussion on it that's the next point that I brought up is how do we in 3d155 our standard output it has a PC value so we would have to do some math to get to PC zero maybe we should just leave it in there and I should just not worry about it then we need to have some agreement on what the PC is for the tracing yeah does anyone have a strong feeling that PC should be absolute for tracing or should it be relative to the code section my intuition is that relative to the

code section is preferable it seems much clearer what's going on when reading the execution I don't think that would cause your optimizations to be thrown out the window because you can still calculate it in some branch that if tracing is on then calculate this yeah so if we keep it relative to the code section when you put the code section in the trace as well yeah and that's what we need to do either all the time or when code section does not equal zero Yeah the code section non-zero definitely needs to be there if we put code section 0 in that could

be something to denote that this is an eof Trace that might be valuable that might be valuable truly because otherwise you don't really know what semantics I mean do you really ever know what semantics the trace is going on because there's not Fork information you know what Block it's coming from so you could Define it from that um but it is also be useful when you call between contracts to know you're calling between an eof and a legacy contract if you see this section up here and disappear right so section always I think that section always is a good

idea but only for eof code only for UFC code okay those are my two questions so um no change on the spec I'm fine with uh but the the tracing spec needs to have some clarity somewhere I don't know how to do that to add it oh it's stagnant so fortunately Martin and Marius can change it yeah yeah okay that's something that we should work on uh I have a couple of those things I just stuck on here I know that a big spec question that we have outstanding

is figuring out how to support net code arguments I don't know if there is any other thinking about how we should deal with this how we should resolve this problem maybe this is something and we don't have to like go into super long debate here but I do have another section I want to talk about like what is our plan going into this interop what is our plan for the interop and maybe that's like something we want to answer during the interrupt Alex yeah so that would be probably the update from Epsilon V we started to work on how to do you know creation we started a document

last week to balance off some ideas internally and we want to share it as soon as possible but there hasn't been too much work on it last week but my hope is that we actually gonna share it um early next week and that could be a discussion Point um especially for the interrupt um but there have been some interesting ideas how to actually support immutables and uh um yeah it seems like a solvable issue you know with the extra time we have now okay great let's talk a little bit more about that when we talk about the interl plans then uh the last spec update I had a bit of a

question here we have some more time now does it make sense to work on some unified Eep at this point or do you think we should just continue forward with the multi-ip approach it's a whole lot easier to read a unified eat um do we go The Meta Heap approach and uh have it copy it or do we deprecate the other Eaves if we go to assembly I would think deprecate the other apes and just say this Eep is the may not say this is the Eep text but like we know that this Eep is the combination of all these other Eeps into a single format and in the event of typos the unified e prevails

do the authors have any feelings on this is that something that you're interested in working towards or probably not do you mean that we're gonna have a like a brand new unified Eep uh with copying that entire spec text or are we saying that for now we're gonna just rely on the unified spec and once everything is is you know 100 um you know clear then we're gonna copy back stuff into the earpiece or you know or luggage for adoption what what is the suggestion uh I'm suggesting that a new Eep is written or has most the pieces copied

from the existing Apes so that there's one Eep that's the source of Truth for the big eof implementation is um one of the reasons the unified Eep is nice because it doesn't need to be concerned by all those other required sections by if you want um you know the demotivation can be quite big the rationale and security and backwards compatibility stuff all those

likely could will double the text but also the current tips have like the python code which we discussed that maybe they obsolete at this point um so they could be even the current ones could be cut back personally I think the the least amount of work for now at least for this month um you know during the interrupt is just using the unified spec I'm not caring about any of the other eips and all that um okay but I'm not sure if every implementer is happy with working of the Unified spec as opposed to the aips

yeah I was getting the feeling that people preferred working off the eaps and to be fair the eips are more concise like I've realized that there are some small things that are overlooked in the unified spec the contract creation aspects I think are under specified and like of course we can specify these things and the unified spec in a good way it's just that it's not quite as clear as the eaps and everybody tends to just fall back to the eaps and look and say okay well what does the EIP have to say about this and so in that case then we're kind of losing the advantage of the unified spec rather than because I think that the

behavior should be if the unified spec is not clear then we should update it to be clear rather than falling back to the Eeps and then at some point in the future try and Port all of the changes in the unifies back to the appropriate heaps I don't think it's the flow we followed yet anyways we don't have to make a decision on this I just think that as things continue to change it is better to have all the changes in a single place and

this is something that has been difficult over the last two months for implementers trying to make sure the end testers to make sure that everybody is agreeing on the exact same things so something that we can consider uh okay testing updates Epsilon guys do you have anything to share um I have some some stuff so maybe quickly about the spec updates I didn't say before um there were two there were two changes from my side one was just to rename the data stack to operand stack that was a prequest to the some of the APS and that

this has been merged and there is follow-up that um that is listed in the in the in the agenda uh issue for for this call that um that kind of changes some of the runtime checks uh to to asserts because they the conditions are already guaranteed by the the the or the stack validation so there's a request for that it hasn't been marked yet um and on the testing side so uh we were focusing on the

uh yeah like comparing mostly the the Gap implementation with vvm1 implementation using uh State tests and at as of today uh I think there's only one issue remaining and the rest kind of like the implementations agree on their rest of that uh so the the issue is um in the create as usual so um I think what the text test expects and what uh graph implementation is doing in case init code is invalid uh

it's uh the color notes bump remains uh so the the creation fails but the nose is increased by one um I think that has been discussed somewhere before but uh I think intuitively uh the the check should be before that and the nouns should not be updated but somehow the test explicitly expects this so maybe there's some decision made I'm not really aware of uh but I think I'm still in the position that that should be the other way um so that's the difference between two

implementations yeah so if that is resolved I think we we kind of went a good position right now and uh um yeah I think more tests are coming this week or next week for other test cases but uh like two big chunks of the existing tests are pretty good right now okay awesome that's good that's good news any comments on that stuff okay uh

there's been some talk about having a reference format for UF tests a lot of the tests that we've been writing are really focused on just the parsing and the validation of eof by and so there's an idea of what if we had a way to just run the parsing invalidation without having to generate blocks and import them into the chain and then check storage elements and these types of things so there's been some proposals there's basically two proposals I think that Dimitri started writing one in the ethereum test repo

and then I made some suggestions for a slightly different format and I wrote a hack MD with that I'll post so this is about as Bare Bones as you can have for a filled test fixture it really just has the code and then the results for each Forks that we would expect the results for the maybe big question here is there was this idea of maybe standardizing the the error errors that we that we have from the parsing and validation code this kind of puts some maybe unnecessary constraints on implementations because

certain checks need to be done in certain ways to be in conformance and maybe that is overbearing for implementers but I do think that having the ability is a a as a tester to say I am writing a test and this is the error that I'm writing this test to cover is useful because generally this binary output of pass fail we don't know if the right if like the right thing is getting tested in the clients and so maybe we're hitting another section and we're not having like full coverage over what we want and so that was sort of the idea behind this I don't know if any other people have strong feelings about this so I like enumerating the expected

exception in there um I would prefer to see a texturing instead of a number so I don't have to look up a table so I can tell it from the test directly but what basic does there's a couple of other tests uh scripts inside of the reference tests that specify the exception we don't map the exceptions right now we just verify that the exception occurred we use that as a plugin as a failure but we could easily you know do the mapping and make sure we get the same fails I do like the idea of trying to say what should fail and try to make a test fail in only one way because there was a several years ago one of the LPN tests had two ways to fail um and basically was only getting one of them correct and wasn't checking the other way and that was the only test

case that checked for um LPN pairing or something and because none of us are crypto Masters and know what this checks are we didn't know that the check was invalid so enumerating in the test how we expected to fail I think is valuable um to those who aren't you know like say you know phds and cryptography it can tell you what all the failure cases of a b Edgar are so I see value in enumerating them even if they're not directly used yeah I guess I can I can update it to you strings my initial hesitation was that there you know each language has its kind of like own way that they like writing what errors are and each code

base kind of has the same thing and I felt it was kind of maybe overbearing to say your text needs to look like this but the way that I ended up implementing it is it's actually outside the main code base for Geth it's really just a table of these uh air integer or these like GO error types to integer and so really I can just update that to some standardized text output that's totally fine okay yeah I can go ahead and do that I'll probably just use what is in the name field right now for the specification and we can go from there sounds great uh this is a highly tough topic but for

a long while I was kind of interested if you could introduce uh error codes or execution um stopped um because that could help comparing the different deviant implementations and could help in establishing like better coverage or at least understanding the coverage of the test but one big downside is if we do that then a lot of these different conditions something can abort has to be way more precisely described than it is today and one good example is like these discussions around the ip3860 the init code and of course then that would be more

prone to consensus bugs I wonder you know if this step is like a step towards that so it depends how much we were driving the standardization if it's a name used in test in this advisory might say we just go ahead and do it and clients can use it or not the tricky part comes in if we need a fail in a specific way in a failure to fail with the right failure becomes a failure that's where you know you know the spec allows for multiple failure paths that's where it gets tricky because if five things fail um I don't want to have to say that we

need to check them in a certain order I just care that one of the five is returned so it's there there's because you know if we just put in the test and say we expected to fail this way I I have no problem with that it's moving it up the stack into the spec and things start getting tricky right I I mean I do think this is just going to be a good learning experience for understanding if that is a path that we can go towards is having more clarity why things are failing in the evm it may turn out that it's pretty straightforward for us to do this error propagation and degree on certain errors and so maybe that is like a signal that we should look more into doing this at

the evm level it could also go the other way too where we realize that this is hard and maybe the binary pass fail is preferred so one thing that I think should be pushed up as part of the spec is the revert bytes if you revert at the base of the thing that could be brought in right now it's totally optional Mario yeah so I uh seen at least a couple of uh desk pieces that I've written I I've seen cases where it's yeah it's totally possible to have two different errors from the ones that you listed so maybe

if we have um that scenario or it's impossible to just uh narrow down to a single error because writing test is just not possible and it depends on the client where the check in the order of the checks they are doing so maybe we can have uh an either error for very special test scenario so if you have wanted scenario that simply cannot be narrowed down you can have either this level or this error and that's okay I think but yeah it opens the door for Less less ideal test cases or less yeah yes it's it's not ideal either I think

I know what you guys think so should I extend the field test format to include a array of exceptions where we just interpret that array of exceptions as like the output of this test must be one of the exceptions listed yeah I mean that that could be one suggestion um but I'm not sure if we are just uh lowering the uh yeah the the the the coverage of of the of the of these disk is just by doing that it's it I I know it's not ideal but I've seen at least one test case where it's impossible to determine the exact error because you would need to know the

implementation to see what check goes in first um I could give an example but I don't quite remember now I I just know there there is at least one test case where it's impossible to know which exact error are you gonna get yeah well right now there is this like kind of confusing error unexpected into file and this is something that probably needs to change but it kind of overlaps with other errors like you might have a magic that's invalid because you the by you only have the EF byte and some might say that that's an invalid magic depending on how you check it others might have said that I was trying to read something and I ran out

of things to read and so it was you know an unexpected end of file that's a case where maybe the the errors they're just bad there but that would be a case where you could have two different outputs Ahmed yeah but uh in this particular case I think that if you have EF without the zero zero then you shouldn't be running the eof checks in the first place because this is not eof code and should be just treated like normal code and feel like the normal code fails when it gets an AF oh

yeah okay I think you're right okay so say you have ef-o-o and you don't have a version yeah this example makes more sense Dana so there's another way we might have multiple errors let's say there's five ways that the code section can fail let me have a test case it has five code sections in each code section failing in a unique way do we then mandate the chat to evaluate the errors in in byte order in linear order um so there's I think it's gonna be impossible to say that you know there's always going to be with one particular um EF there is only one area from it so that's you know I don't think we want to

get to that level of specification Mario yeah I would argue that that's not a good test case because yeah you want to own this one section one particular at the time but it was more like uh for example I I thought of an example I wanted to make an a test case where you overflow the stack so we have a stack Overflow error in the list but we for to do that we would have to list too many um uh the the two large Max stack height for example so um which one of the two errors would you list because if you want to overflow the stack you have to have a high maxed

height so it's those kind of things those very specific things not not uh yeah yeah oh man yeah so I just want to like a note here something that probably with this expected error exception that we will face is that for example never mind we check uh that the code the eof code so basically any code that starts with ef-00 that it has a minimum of like 20 bytes or 19 bytes or whatever the minimum valid eof code could be right and this is the first thing that we do

to validate the the code because it does not make sense to go through parsing the code if we know that it is smaller than any valid eof code out there and yeah this probably is not the same way it is implemented in other clients for example for example other clients would go through things and they might have an error that is different than this one so we would say oh this is not eof valid code because its size is smaller than uh the minimum uof valid code but the other client failed because for example the Virgin is uh zero two instead of zero one and zero two is not for example uh

valid version for Eos so like I see what you're trying to do with these expected exceptions but I think that they introduce a lot of conflicts so not sure if they're a good idea to go through with Simon uh in my opinion like if we if we are gonna do this we need to be extremely sure that each that case is isolated but it doesn't touch any other test case so if we have truncated code or very small code we should make sure that at least the prefix or what is included in data

spaces correct and the only invalid thing is in that let's say the example I said in that test case is the code being incomplete so if we have multiple stuff happening in the same test case that leads to some confusion also we can restrict sure order of checks we can make it explicit to do this then do this then do this so something like this in the EIP sometimes I would prefer not doing that yeah that makes sense so I mean one way that we can use this we kind of use this as a tool to help us understand if the tests we're writing or testing like the

things that we expect and the like thing that we really care about when we look at okay are clients passing these tests we look at the binary output is there an exception and did the client though an exception that way we don't get stuck on this whole our clients doing things in the right order but as like a test writer still like saying like I am expecting this test to fail this way having that in the field test maybe as a client runs those tests and the test says it should fail because of stack Overflow but instead it fails because there were not enough code sections or something this can be a signal to implementers that you know maybe there is something to look for more deeply it could be a

signal for test writers that maybe the test that they wrote is not testing exactly what they think uh I this is I don't think gonna be like a perfect system it's not going to be something where like one side either the client or the like test filler format um proposal is going to like be perfect in a vacuum it's something that's going to have to go back and forth a little bit uh but if people are like okay with this then I think that we should just like move forward with having these enumerated errors see how it goes but not get too hung up if the error that test is requesting is different than what the client is throwing does that seem like an okay way to move forward yeah I would be in favor of um giving

this trick torsion a try um but quickly able to iterate and and roll back I don't know if you get confirmation that I think it's completely assessing too much um yeah I think in an ideal case it would be nice to actually have all of the air conditions for the evm properly specified and and test the order of everything um but yeah I mean that's that's a really long-term goal I think it's an interesting goal though and I think yeah we should keep thinking about it and use this sort of experiment as a way of understanding is it how feasible is it I'm in

also there's this one thing like there are three aspects in the code that we should test there is the parsing of the header and POI code itself there's the execution of the of code and there's the deployment of UF uofco the parsing itself we can do stuff in different order and we we can have different errors but the result should be the same like a valid you have rather a quality of code is a valid code no matter what the implementation says but for deployments and for execution those who should be strict about the error messages for the parts and we can be

lose a bit but for execution and deployment who should be straight from this there's no other cases they are consensus software they're not just passing and that's right but the error output is still a binary even in consensus so like if the output is not to deploy the contract and spend this amount of gas like these are pretty binary things versus the having the error codes this provides like a lot more granularity into understanding the failure oh yeah I think we should talk about the interop

sum we can keep talking about this testing formats more uh in the evm channel there are these filled tests if people want to start looking at implementing this implementing some sort of test runner in your clients it should be really similar to how the UF parse tool that you guys mostly have already implemented would look oh I guess like one other thing I wrote on here are people okay with this format of Shanghai plus EF going forward is the plus eof something that all clients support and input can implement or should we change it to Cancun when I asked what I should put it in for

the other basic devs that were involved in the eof they said put in Cancun so we I put mine in Cancun but I can Alias the test to Shanghai plus eof and have that go to Cancun because right now the you know in the basic code that's the only thing they can code so I'm flexible but that's why where we're at we're also finding their way okay uh let's just put it in Cancun I can rebuild the tests and they will be yeah forked by Cancun so let's do that um just one thing are we sure that the ethereum tests uh names reflect the

actual uh scenario so when the test name says valid does that mean actually it's valid and should pass or how are these test names actually reflective of the result uh Powell Alex do you know um yeah I think they should unless there's some mistake so uh so so the tests are how they are written you also put some expectations section that are not visible to the the final file uh but it's in the source file of the test so

yeah I think it's it's rather don't happen that like uh that the test case kind of so I think the tests are not like 100 blind so you put some code and then just execute and whatever the the evm returns it's your test so there are some expectations that I've checked against so uh so yeah I would if there's something that you think is wrong that might be a mistake in the test or something like that but yeah they usually should reflect what's what are actually testing can can you point me to the place where this expectation is low uh laid out or mentioned yes yes

I'll find some example in a second thank you okay any lastings on testing um yeah it's kind of missed like the decision on the Cancun so like this is easier for some people yeah I think it's like not a huge difference either way and some people have already started using Cancun so we might as well just fill the tests

okay it's fine I think it's good marketing to say we intend to ship in Cancun as well the euf director of marketing has made the decision okay let's talk about this interop where some of us will be in person in a week and a half can I bring up something yeah for that yeah go for it speaking of Cancun there has been a yeah there have been some proposals for Cancun and related to EOS which have been proposed

for Cancun uh because they were proposed late um good example is the unlimited swap dupe uh which would be quite beneficial for solidity and likely Viper and other languages too now given that this we hope to ship in Cancun should we consider like the sound limited swap dupe in any shape or form or we shouldn't I mean it was proposed for Cancun already but you know given we moved like quite a big chunk from Shanghai on their headed effects oh

uh I guess you know from my point of view I'm a bit apprehensive about it because it does feel that we're starting to reach the edge of what we can comfortably do in a single Fork we have a lot more time now and maybe that affords us a greater ability and range of changes but yeah not really sure Paul yeah press wrong button uh yes how I feel I think about it is like the con spec and the current tests Suite is like

um eof 1.0 um and there are some additions that I think we can consider later mostly for testing so think once everyone is kind of on the same same level about testing and we kind of confident I think there are three or four additions that can be added to yeah to current EOS that are backwards they're kind of compatible with the clients back so examples are um this like swap dupe unlimited version this jumper instruction that we removed

there is this no return uh the notion of no returning function that has some affects the stack validation and can enable some optimizations on the compiler side I think and yeah the fourth one that is that what someone suggested I think yesterday or two days ago about the delegate call issue so we can also add this one in um I'm not sure this is like this should be commit commitment to to like ship it but if we have some basic like uh

like revert ability to like like revert implementations to the stable 1.0 version without so much issues and we can always kind of revert the snapshot of tests and so on so if we have time I would go this way and also work on the eof 2.0 whatever spec with some additional changes so we can decide on the way what Milestone we want to test right now and if it's if it's good candidate for shipping all together I'm not sure but at least at this point I would do it this way

Andrew Daniel um yeah I think during the last ACD call it was mentioned that there are some hacks with the eof required in solidity so to my mind that the the priority we need to address like is it due to construct arguments or something else I don't remember exactly but uh yeah I would prioritize solidity implementation and author eof so that there are no hacks or like minor only minor hacks in solidity uh any kind of extra features I agree that

uh it's it's already big enough so that it's on the edge what we can comfortably deliver so I would rather fix bugs rather than add new features Daniel yeah I mean I can speak about the issues in solidity contract creation is maybe the most annoying one there's also another thing what I want to hear some opinions about whether it's feasible to still address which I'm not entirely sure about that's why I didn't bring it up earlier but which would be uh relaxing the stack validation because currently it prevents code D duplication in cases where I think it doesn't have to if we make this algorithm more

complicated but still in linear land runtime in the number of uh of op codes I haven't thought it through but I may be able to suggest a change there which would allow for more code application for us to do for example to jump to through to rewards from uh positions with different stack Heights that's the issue uh but yeah not sure how the general idea is there that's something that it's really a change and can't be added later whereas we really like these swapped up stuff but I agree that it can be added later with less effort so yeah we definitely want to understand what is important useful for you guys because we need yeah we want to be able

to do the things that we can't do later now obviously so any more information on that is helpful Danno um so we need to tread carefully on the stack validation because that is critical to some um transpilation issues if we could if we can enforce the swap Duke but like the case that you outline where it's you jump into something terminal and only the top X components matter but there's you know mappings like color mapping register swaps that can be done that we would lose if we get rid of Stack validation but if we're taking what would be invalid and moving it to something that would be valid that's like a soft pork fix and that is something that can't be added later um is that we take something that was valid and then making it invalid that's

where we have to bump major versions so adding things like uh swap dupe um to if the slop do those can be soft work added into 1.1 and don't have to be done on the first thing because it's just adding it's increasing the scope of what's valid rather than moving stuff from valid to invalid yeah okay I want to switch gears and talk a bit about this time that we're going to have in person in a couple in a week and a half or so uh what are clients teams plans for interop in general like I've been talking to Tim a bit and it seems like it would be really ideal if we had this separate track where we just saw it

together and we were just really worked through some of these eof things is that like do we have enough things to work on are people going to be able to work on eof do you have like other responsibilities you're going to need to be working on with respect to 444 in I'm not sure what what are people's I am like personally able to work only on eof that week but I don't know what other people's um responsibility load is is anybody actively working on eof right now for a client team that won't be or won't be able to work on hey man okay

I will be there to delete uh but I will be also working on making sure timestamp working works correctly probably that's mostly it devnet stuff but that's mostly okay sounds good okay yeah Tim was all starting about this Daniel I think it would be great to have you at some point I think we should spend some time and figure out like what we want to do with eof that week to know when the best days for you to

come would be I don't know if they're like certain days yeah we can talk about offline but if there are like certain days that work better for you obviously let us know so Tuesday probably would be better if anything okay that sounds good um I talked to Tim also a little bit and he wants to do a session where we talk about eof2 or this you know you know mainly about these ideas that vitalik is having yeah so that will definitely be something we probably want to do it later in the week so we can spend some time together and flush some ideas out beforehand we could continue talking about this like async I think the biggest thing I want to talk about before we go from this call is like what types of things

do people want to have ready when we show up there like we already sort of have pretty good interoperability of clients are there any things that we can prepare in the next um week and a half that will put us in a good place for uh getting a lot of work done at the workshop so can we say that the tests the ethereum tests are finalized for baby UF because if that's if they are then clients should be working on making sure they pass all the tests so we can have some type of a divnet I believe this is

one of the best ways we can go with that week I I just feel like we're pretty early in a cycle now that we've reset on devdets because we have outstanding spec problems that we need to resolve mainly this like Constructor problem and so until we solve that it seems like building devnets is not as much signal yeah lots of tests uh I think they're not final yet so there's still like uh tests being in preparation in like mostly to add new test cases uh which hasn't landed yet and as I mentioned this one I think

there's one issue with the tests and one of the implementations that we have to also correct so yeah still still do some some moving components all right tests are some of these tests merged now to uh East Taskmaster yeah yeah I I mean about this the main branch so yeah not everything landed there and I think at least one issue that we have to check if I can make a proposal for a game plan until we arrive there maybe first we come up with a list of the

tests that are released and make sure that clients are passing those tests that would be a good place to start from just knowing that we're all employing the same things and then maybe I would make the request that we would also implement the reference test tool that could be like a good place to expand upon in person figuring out like how to deal with these error codes if we're going to deal with them maybe trying to do some fuzzing based on that I think that if we came with those two things that could be a pretty good place to start does anybody disagree or have other things I would like to add to the list does sound reasonable

um we also need to have discussions on things like the delegate call um basically circum uh circumventing suppressions uh we didn't have time for that on this call but I think that's also on the critical mass effects for eofv-1 or we can also get called to other EFS EOS all right yeah so I guess yeah I'll write a document and I'll share with everybody about some like milestones we want to have before we get there but I think maybe one other thing I would also add is just expensive time and think about what are the things that need to be solved for ef1 and then we can just kind of start out the week and sit down and talk about those things and like really Hammer through any kind of spec issues that still exist we're one minute over any final comments

on the interop anything we discussed I would just say that I would push for that delegate call thing for Eos one instead of pushing it to aof2 sounds good let's yeah let's keep discussing it thanks a lot everybody for taking the time to join this breakout and I will send some more information about these Milestones that we talked about and we'll see a lot of you people here in a week and a half thanks

bye I'll