EOF Implementers Call #40

Transcript

this is e implementers call number 40 um so the we'll start with client updates for Basu I had a busy week uh Easter week in laws and other things getting in my way so I didn't get much progress done I did get that one spec update we'll save it for the spec updates um but as as far as as Basu I should be able to finish all of the um spec by the next meeting for the transaction and for the um uh if we do the changes to allow um type 01 and two calls to allow creation uh transactions um I haven't tried the new test yet but we'll do that later um next is uh evm

one not I don't think we have any significant updates although today I think we've added uh new transaction validity rules to our TX grade Branch uh the ones that we discussed last call were empty init code array is not allowed and empty init code is not allowed so this is a new addition and yeah that's it okay great um ref RM uh from my side I wrap my head around validation and stch checks and I'm passing more most of the I think I

failed just on one test uh and yeah that's most wait um I still need to figure out not figure but Implement return contract and after re reviewing the pr should be up to dat but still pending some fixes and still pending some changes need to be done but most of the work is basic close to f cool uh nethermind uh hi well uh we had to kind of shift Focus for a week to other

projects but uh mostly our implementation is complete cool um come back to this on testing but I think when people are sounds like the client except for we don't have any representation from G um which also would imply participation from Aragon since they use most of g code G's code for their um evm portion um so it sounds like we're getting to where most everyone's implemented so um yeah we'll just loop back to this on testing um next on the agenda is compiler updates um Charles any compiler updates

uh no compil updates okay but you want to discuss something about uh return contract e during the spec section I see that in the notes and we don't have anyone from um from solidity on here do we no okay who who who is the contact from solity basically we are coming to the point where uh youf should be included inside prag or at least Ved on and it would be really great to have both TRS here from the wiper side and somebody for to say hey we check this this is okay and we want this

included yeah I think we're going to get our go no go um not tomorrow but a week tomorrow um they Tim had to get through all the people who wanted to pitch their um Pitch their Wares for Prague and next week's going to be um hopefully next week's going to be the callws in and out and it's not a call that's going to have all the time sucked away because of the um the issuance change proposal that's out there I'm G to I'm going to Lobby Tim to put a time box on that um but we really need to figure out what's in Prague if we're going to ship it by by Dev con southeast Asia um yeah I I think we're in a good position

position um considering how much work we have completed and how much things are being proposed that people haven't even started working on to make a strong argument that you know we should be the uh the headliner for the release um so we'll see how that goes but that being on CFI is an important signal that will unlock a lot of people to say oh we actually have to work on this um so yeah that's that's a pretty important signal yeah in my mind it's like you should be cluded prag but there isn't anything official and until there isn't end official it's still in maybe yeah so yeah we need to figure that out yeah that's that's next week's uh ACD okay I probably not being the next

three weeks I'll be basically out office and getting married next week and congratulations yeah thanks so you got more important things to do for three weeks exactly so I hope this this is going to be pushed yeah um given that your most recent post from The Ref team includes it is as lead accepted um I think that's that's the witness we need yeah so that's why George has basically made that post and it's very impactful because exactly because of that it is in the writing hey we support this and we want this included okay yeah cool

um spec updates and testing updates I think um let's take a quick diversion to the implementation Matrix um I think we need to start um nailing down so we got just a couple more spec issues but I think we need to start looking at testing and being able to identify which tests are valid which tests are invalid and who passes which tests we can um narrow down and these these two items are actually kind of related together um you know if there's a specification statement and a test to prove it um then if there's disagreement on what the spec says um then we can demonstrate it and we can come to a um collaborative decision about what it really means um so yeah let's do spec updates um so we have two items ban origin and

return contract eof um because Charles put his in chat first let's talk about return contract eof Charles yeah this is just a followup to last week uh apparently I missed the discussion um doctor's appointment um but anyways um I think that return contract init code mode should be validated uh instead of at runtime and I'm not sure why it was voted on no last time so you say it it was voted no that init code is not validated what what did

you mean by init code mode can you elaborate uh yeah I mean what we discussed in Discord which is um at validation time you um basically check whether a contract is in init code mode or not which means that it's um called by referenced by UF create or return contract and then um there's different rules inside of in code mode versus not and um what were the rules for nit code that they can't have a that you have to have a return contract or a revert yeah I think that's the main thing I need to

go and refresh my memory I think return is made as the invol upload right yeah right exactly and stop so um I think one of the concerns with this is we're introducing another flag to the validation steps um and are we getting the value out of adding that flag in that extra validation step because it's also going to effectively um increase the testing that we're going to have to do the number of test cases we're going to do um no about that because it needs to be tested anyways and there is a flag anyways it's just that run time instead of validation time okay and um philosophically

speaking like EF goes to Great measures to you know uh filter out to reject invalid op codes at validation time and it seems logical to also try to uh reject these also um because this kind of besides the invalid op code I think it's the only place in the spec where invalid op codes are actually allowed okay from my side it it's not great to be honest having init code validation in basically having init code checks inside

validation seems okay but I wouldn't make this change right now because we already like progressing a lot faster and the change is not going to bring a lot of benefits I would if we introduce something like init code check inside validation I would even introduce uh different type of container that's just having in it codes isn't that kind of a good thing because like they are kind of actually different types and um yeah they are treated in the one time yeah we now have like rtime checks that check if if we

have full data or not full data we can additionally have uh different container that's going to just have like init codes basically UF that can act as init but that will require new testing that will require like new test sets rewriting all the test that we already have don't I mean aren't these already kind of tested for but they're tested at different parts of the execution like um for an invalid op Code test um we would just check the output of it versus it being an e validation test they would need to move to different stacks and the uh

container validation checks don't have a flag to say whether it's a nit code we would need to also modify the retest death handling and the TN handling um because these aren't regular it's it's a different style of test for uh container validation and execution validation yeah I mean I guess I've said my piece I think it's uh more it's there's like a correctness landmine hanging around if it um both in terms of testing and also for people emitting EF if there's these invalid op codes that um turn on in different modes but just to brainstorm

idea but if but what if we include new container how how big of the problem would that be not problem but how how how what we would need to change how big work would that be so my thought is it would be one additional header flag it would be a flag saying we expect this container to be an init code container or we expect it to be something that's not in an code container um an execution container and so that we would need no context um from the execution environment and the uh the containers could validate it um yeah they could validate it without any extra context

because that's the other thing we need to drag along is we need to run the validator in one of two modes depending upon how we got it um I think the validator can actually be run um in like agnostic mode and then it just tells you whether it's an AIT code container or not because an a nit code container must have a return contract type code and it cannot have the the other two outcodes the returning stock and it cannot have both uh yes but stop is implicit so you would look for whether return contract is there or not what about revert it's load in

both yeah I think revert is fine because it's um it has the same semantics in both modes I think stop is invalid in a uh in a nit code call you have to end with a return contract or a revert you can't just stop you can't return right it is invalid um I think it's in the spec but also just because it's the same semantic since return z z right right so you couldn't stop and you couldn't return and that would fall in a category if you can't have both can both return contract and a stoper return in the same container yeah so you can have the container header but it's um redundant

with what the container actually the code that the container actually contains I like idea of having additional flag in is in it code yeah that's fine I think it also kind of cleans up the spec too because um it makes a lot of rules really obvious how to implement like you just can't um like youf create must reference in a code Container for instance so is it worth three more bytes for every container or do we presume it's execution mode unless there's an init code flag where would we put the flag or do we do the implicit return

value and just do with the rule that you can't do both and at figures it out during the validation kind thing that we can stuff it in look at the header St are we okay to add additional bite prate container um because the way the headers are written it would be need to be three it need to be a type and then like a link or a description and yeah we don't have flag Fields yet how you mean different type okay A B different kind how

said uh could we just add it like one bite inside the container sizes um does a new kind not work well it be a new kind but the kinds are always followed by two bytes right now and so we want to have a uh it would be three bytes because it' be like you know the kind it would be like 05 would be the next kind in the list um yeah yeah but there's no extra bites because it has to have a kind anyways right oh you're saying um because the oh because the containers are sections are

like split up right yeah I fine with both it's not that big of the difference it's big differ but in the end it's like how we where do we want to put data in the end it's going to be inside an evm it's going to be decoded and used in form so yeah I think if we do do this I think the easiest method is the one or the other flag we we just need a track um if return contracts are used because we also talked about

um adding another rule that subcontainers can either be the target of return contract or they can be the target of um of eof create they can't be the target of both so there is that would fall in line with that rule that it's you know one or the other um and we could add it another that the subc container validation must match for an init container um it must be eof create and for um return contract it must be execute mode yeah I was just looking at the the

header spec and maybe there's the line where you have like unlimited containers so we could swap out the bite instead of having it be 01 it could be like 81 or something so we could use that as a flag or maybe not 81 um 11 that would be yeah I don't know how we could do that that's that's where we could do it we could have a different instead of type one it could be like type seven or I don't know how we want to go about that but that is another way we could do

it my opinion is that even if this might be like the proper way to to solve this if we want this then it sounds like this is a big change and it will push UF out of PR definitely my opinion I think because this changes all the tests and uh and uh and two eaps at least and I think uh there's been this um only minor updates stage for the uh considered for inclusion eaps had this uh impression yeah because I mean it sounds

like they're small changes but they're not actually small changes it's I think if we change the header format then it's it's a big change both you know um I know semantically Wise and also just it's a huge huge amount of of a big diff to to the spec and and to the tests and to the implementations so who got the action item last week to write up the um the change for um subcontainers can only contain certain references well was there an action like

this we talked about it and I thought there was going to be a proposed change but maybe uh looking through the PRS there's none open no no I don't recall something like this okay so I think if we' want it we would need to have some proposed text for probably the solution of the one or the other and it would need to also include the change it would be on the container validation and that would give us a gauge for how much we're getting into what would be easiest way to change

tests I think we would change the validation rules to to Encompass both the subc container can only be the target of a return contract or an eof create and then that within your container code sections you can only have return contract or stop and return and that those must match up for subcontainers as well hold on with the header change or without because we have without the header change without the header change yeah that will crease a little bit complex to how we verified the bite code but it's

possible I mean we have to change the bite code verification anyway even with header yeah yeah yeah yeah yeah and it's also I think there's there's been this main at least my hch that the biggest issue with this validation rule is that it um crosses the boundary between validating code and validating the subcontainers so we need so I need to know uh the code of the subc container and the parent container uh to see if if if the modes mat like to have the full validation routine so that you know e cre can only

call a subc container that has returned contract so that was I think the main valid I think validation is is already aware of like what it is validating uh but not to this extent I don't remember the argument exactly Andre maybe yeah I mean currently yeah validation is independent like each subc container is validated exactly the same as any other container um so and with this proposal subc container validity will depend on how it is uh used with return contract or with the of crate which I don't like this like

this uh validity of subc container depends on alter container I think the point I'm trying to make is that the semantics are different depending on how it's referenced so it makes sense for the validation rules to be different without the rule we could create invalid containers that would fail at runtime and the only thing that ever could do is fail Bas could mix and match the two types of The Bu code that we have and that's bad yeah because I think we discussed it last week that there's

no viable use case where you'd want to have a code section in some cases might return an init container in some cases might return um an actual execution return um that's the only thing thing that would serve is to obscure things um unless you're writing it by hand um and then that yeah that's because you're going to have to deploy what you youit and what you deploy are always going to be from two separate sets so um there anywhere else we can sneak in

this um flag maybe in kind types or something like that not really kind times is for code sections not sub containers so that would that would break the abstraction and it's a code it's a header change as well so it's also a huge change so I think the thing we need to

do we need to probably time box this so we can talk about origin um I'll take an action item to write up what I think spec changes in the validation code might look like and if time is available I might even prototype it in Basu but I think getting a vision of what it looks like in the specification I think to help us get better Clarity on whether it's achievable in the time we have available um but as a as a practical engineering concern um if it doesn't look good we're going to need a table it I know it's as a correctness issue um it's something that we can't go back and undo um and I also have a third spec item I want to discuss about address space expansion um but first let's go to Cyrus and talk about ban

origin um cus do you want to talk about ban origin a little bit sure can you hear me okay this time yes okay I'll make this really quick so number one origin is bad it's been advised against since 2016 every time a developer uses it that de developer can and should be doing something better uh number two this origin Tech debt is necessarily a problem for account abstraction uh and will have to be dealt with one way the other one proposal is 7645 uh which is to alias origin to Cinder that's out of scope for discussion here I guess um number three Banning origin in eof which is what

we're going to discuss here will curb continuing origin misuse and might make it easier to deal with origin later with regards to account abstraction uh and then there's the issue of Legacy deployment still being available and potentially maybe a gas cost bump but again that's sort of out of scope for this discussion um was hoping you guys could uh offer your opinions on on Banning origin and eof so one question I have um what do smart contract developers think they're getting by using origin and what are the better solutions they should be using uh TX origin equals message sender is supposed to check for um non-smart

contract making sure that it's not a smart contract that you're dealing with uh um and what they should be doing otherwise why why exactly that's bad um is a little bit beyond my knowledge range but um there are certain attacks or vulnerabilities to it I don't know could someone else chime in on that I don't think there's many smart contract devs on this call I think we're mostly uh evm implementers okay uh I mean I could call up what Micah was saying in the um future e a channel um but yeah generally speaking it's just known to be bad uh for that for that chick what they should be doing

otherwise is you know handling situations where they are talking with a smart contract and and instead of just blindly uh believing it I mean um just tring my understanding is that like message sender is like the recommended way to do authentic unication um there's like fishing things or something but um if you do want to check that the sender is an eway then TX origin equals message sender like is the right way to do it um and I'm not sure of what the work runs are there well that's I think what

we're what we're saying is that it's not the right way to do it um I'm trying to scroll back up to this yeah it's it's complained about TX origin use is complained about by um compilers and Auditors and has been since 2016 or a little bit after that um I'm reading Micah's thing right here I'll link it in the chat so we don't have to waste time so I think to address Charles it is the correct way to check if a caller is an EA but with account abstraction um you want to allow you you want we want to eliminate the distinction between an EA and a Nona we're trying to actively get rid of the

eoa distinction as an end game goal for account abstraction yeah I mean uh I get that but why is it related to EF because eof offers a way to start discouraging developer use of TX origin in ways that introduce security problems and get us move us further and further away with each use from account abstraction with eof we have the opportunity also to ban it from the op code list rather than aliasing it which it a would send a signal but B in future chains um layer twos that are eof only um that they won't have origin as an

option um I guess my concern is like this is something that uh sometimes maybe not always but sometimes still needs to be done since we don't have out counter abstraction and then by Banning origin um we're like removing that tool there are my understanding is that there are no legitimate uses of TX origin that can't be done and shouldn't be done in some other way and so Banning it starts the discouragement of these misuses if that were the case then I would just remove TX origin from Viper but people aren't like coming to me and being like hey we need to get rid of T from Viper

remove um removing it from solidity or Viper is the the python like solidity language right yeah okay so removing it from language is a very different issue than removing it from the evm because you can still work around it you can still use assembler assembly uh inside it so it really needs to be removed at the evm level um I'm still looking for that that uh link sorry in Viper it can't be accessed in assembly um but I mean are people requesting that it be

removed from solidity 2 they have been since 2016 and the thread which I can find that ban DX origin the thread from that there's a lot of people saying no we don't want to remove it from solidity but that's a different issue than removing it from the evm here's the link to that discussion okay here here's the link to the other one it's a link to my comment but you can see what Micah says in in respon

resp to that with more information about why TX origin is bad and what problems it causes so from a technical standpoint it's a fairly easy change um you um just add another entry into the band op code list and we change a test or two we don't have to introduce new tests unlike adding um a new init code mode so technically it's easy my concern is just the politics now on the other hand um Banning a code and then unbanning it

later is something that can be done we can always say um in in Osaka or in Amsterdam we made a mistake the soft code is now valid and we just return it with the same existing semantics because that's the backup plan we have for the extended call in gas if it's determined that gas introspection is actually essential um which might be for um if we can't find a good alternate solution to bring full account abstraction into um eof um so that's the uh there there there's two things for it the question is politically is it the right thing to do and it's beyond an engineering question I think it's easy but that's you know that's a an a discussion for the rest of the people on the call what they

think of it um as Danos said as evm implementers this this very easy to do but it's like should we do it my question would be uh who who is the basically who needs to make decision or basically Express the opinion should we remove this or not Charli is for the wiper M the guys need to come and say hey we don't have like like use for this Charles doesn't have like stance of it for example should some uh I know should we ask some uh security Auditors what they

think about it we don't have a lot like um it's easy to remove it from evm but the question was is is should be removed um the ddob Auditors did did a 3074 impact study and did address uh TX origin inside of that I'll link that as well so you know it's generally accepted and and we can get expert opinions on that that that origin should not really be exposed um eof offers us the first opportunity to Halt we can't retroactively yet without you know some other aling

solution but um you know halt from this point forward continued misuse of an OP code that shouldn't be exposed that's what we're talking about okay so yeah Charles is go ahead Charles uh yeah I think that um dragon is right uh I don't have a stance particular on this um but it's not and as Dan and dragon said you know it's not particular really hard from an engineering perspective it can be done but I don't think it's within the scope of the UF you know working group to ban it or not like if somebody from all cord Dev says to us you should ban origin

then like okay we'll do it right or if like uh forg everybody's like we need to ban origin and then okay then euf can be the the the instrument for doing that but it's not uh I don't think this is the right place to make a decision one way or another yep I agree that it can be I agree with that so I think what we would need to see is we would need to see some bigname auditing firm saying please ban it um please stop using it and within the next month and before we fully lock down Prague we would need to have no outcry from people saying oh but we need origin um because if we get a if we get people ban saying ban if we get um an auditing firm say ban it but we

get legitimate users saying you know I think this is you know this is going to be hard for us and cause problems then that's where it becomes problematic but if we don't get that so I think we need to get a statement to please ban it and do a call for um challenge us you know challenge say prove prove me wrong that it needs to be that we should keep it so I think that's yeah it would need to come from ACD or other routine so yeah technically Banning in in eof easy if you if you read that link um this is obviously not an auditing firm but if you read the Discord link I link there you'll see that vitalic lend his support to yep uh the Banning so there's you know one feather in the cap um but yes I agree that it's this needs to be brought

up in a different Forum U but I guess this group can say which we've already said it's a fairly trivial change yeah and who would want to hear it from is not just metallic but I want to hear it from somebody whose business is um smart contract security okay thank you all right um one other item something I always keep forgetting to mention um and write a a a EIP for this but I want to if if it's acceptable um write an EIP that would finalize the address space expansion um reservation what that would involve is

changing the balance and I think one other op code EXT balance op no it's there's no EXT balance just balance there's balance in One op code that uses an address as a parameter and everything else that uses an address as a parameter we've either banned or reformed like the calls um um so what I would want to propose is that right now for when you do like a balance call or a call call and one of the fields is address the top 12 bytes are trimmed off no matter what they are and only the bottom 20 bytes of the call are used um I would want to get rid of that rule and say that if you don't if your top 12 bytes are not zeros um then it's an invalid address until such a time as we decide what a dress

space expansion looks like right now we can't do exress address bace expansion because the evm trims off those top bites and I think we can point to contracts and gas golfing it takes advantage of the evm trimming those 12 bytes off um the way they bring in some of the stuff from call data and do packing um it's it's uh it's a way that you can save a few a few points of gas um so I think now evm would be the right time to say that in evm instructions we don't do that trimming you'll need to do that trimming yourself when you're bring it off of your ABI it's just you know uh a push you know there's gas golfing to to bring it in to to do it effectively to trim it yourself before you call it and pack it in there um so that would

involve changes to the call instructions and a few others um and also a separate dip to alter the balance operation and I think one other I can't remember the exact one right now um so Charles is this about gas base expansion in the chat yeah um there's rules in the ABI V2 uh which um checks that the upper 12 bytes are clean um so those rules would need to be changed and um so

requires the ABI requires this right the current version of the ABI requires this okay and there's no versioning for the API either uh which is right something I've been working on for some time but it's not really a priority yeah you need to put the versioning in the Stream which is more bytes um so that's actually somewhat encouraging because it's going to be less of an impact in ready starting to be normalized um we would just this would allow us um to have things like call operations and S stor and S loads um actually that ex EXT stores and EXT loads um but but operations that

would necessarily I mean one example was to try and encode which Epoch your smart contract came from and I don't know what other options are maybe just a flat opening up um but that would only be available in eof and the reason a lot of these address base expansion things got shut down was because of the trimming and the op codes um yeah Andre just said that euf and Legacy contracts can call each other so like that yes may be problematic like if an euf contract has a 32 byte address and then it tries to pass it to um a legacy contract then that would just um break right but I said that's a problem

for the address Bas expansion how they would hand handle that um because they would need a support I mean maybe the rule would be you could only call address based expansion contracts from eof and that would be another thing to push people to e so I mean we're not specifying how it's going to be used what the semantics are this would just be to have the op codes and the trimming so that we can figure that out later uh that makes sense to me uh in that case I don't if if you're leaving the semantics unspecified um I don't see any issues on the from the compiler Point okay so I'll write a EIP at least for the balance and

propose changes to the other e eips then we can get a full look at it next week any other spec questions just say that this can be very impactful MH basically EF enables like uh address expansion I like a doal okay it's on my to-do list and I have a lot of time um cool testing Hugo are you from no Hugo you're from EO evm one do we have anyone from the testing team nope anyone want to speak about

testing okay I'll have a better handle on testing next week I saw that there were some um changes that went into some of the PRS for eof um I hope with my time that I now have available I'll be able to um once I go ahead Hugo you coming off mute yeah just um there is an update in in um yeah one of the one of the EF uh PR um it is yeah it is now the most up toate um po request which is currently uh being uh what it is ready

for review so yeah it is it is containing yeah this latest changes in evm one and yeah it contains many of the changes made by Peter as well okay are there any known unimplemented features in this set that's out there I think the data op codes are somewhat uh um less somewhat less coverage okay um but the uh the um EXT calls are correct between uh Legacy and non- Legacy Legacy and E

um they the EXT calls are mainly covered by test that we are exporting from E1 I think okay and the tests that in the branch that ugle mentioned are um have just been updated uh for you have to use EXT call versions only okay so if we have differences with the test that we think we're right this is the right time to say this is a difference hash it out so this is the right set of tests to do this against I I have one request I see that there is a lot of PRS open on the ethereum test

and should they they be merged or closed or worked on it's a little bit like I don't know what should i r what should I run or not I use mostly the link from P request 1339 and those are verification test that I use for ver yeah verifying e by code but merging all of this inside the the master or develop Branch should clean up a lot of things okay yeah I think 1339 is just validation I don't see any execution tests and I think that's where I have most of the issues with

yeah I don't think we are going merge going to merge this these are the tests that don't have like regular fer tests so these were generated from ev1 unit tests and I'm not sure where this will end up in the end yet maybe you know fork or something but like test repo I don't think they will accept this they don't have any test other test like this and uh regarding other PR so we closed three PRS today because they were redundant So currently there's this one hugos PR which is going to be hopefully merged soon and this is just the fixes to the tests that are on develop branch and tests like the normal ones that have

fillers and uh uh like the ones that mostly were written a while ago and then we'll have just two PRS this one that you linked the validation tests and and another next to it is execution tests also generated from evm one this one and this is another one that probably not going to be merged so I could like combine these two into one but not sure they are different kinds of tests so um it also makes sense to keep them in two I don't know what's the problem what's the issue with not merging

them I'm yeah I'm not sure like exactly what the tests maintainers position on this with but like these tests are so normally tests are being written as yaml and then run through R Steve and then that generates Jason tests and then both of the generated Jason tests and and Source yl are being committed into ethereum tests report and these ones we generated in a different Way by taking the unit test from even1 and like running our C+ plus utility that generates the final Json ones so that's kind of that could be a problem but in

general they are very help helpful we can have some procedure to say hey when whenever somebody updates makes PR on that type of the test at least one additional clients need to run it so we have some validity that the the test that got merged are correct uh who is the best person to talk about that because it's like those tests are very valuable and having them in theum test makes sense yeah a bit unclear because like also tests are been a bit in flux because this the r Ste is being deprecated in the next Fork supposedly

and then there's this python test tests separately in the separate PR I'm not sure what's the relation of ethereum tests repo to ethereum execution tests which is a separate PR but they are somehow related but not sure if that the second one text them from first one and who is exactly like the one to talk to about our tests it's a bit not clear do they have a testing call they probably don't I I don't think there there is anything like that because I I do remember that I think it was Marius from the GU team he

wrote a script that took all of the retest tests and made um execution spec test format for those I don't know if that got merged or not I know they talked about that in um at Istanbul at Dev connect um and try and get things working through t but maybe we need a instead of making these available and retest death we need to figure out how to get these container format tests into the execution spec tests it's a ptic model read Chang this 479 I think is the entertaining

one they'll read the spec tests anyway um so I guess the short answer is we should make sure we pass 339 349 [Music] and there's one other uh um but yeah let's let's Workshop this on the um the Discord as we get things fixed all right any other issues that

need to come up and be discussed um I was just thinking about this address thing and um does it make sense for the op codes to fail uh with next Cal if there's dirty bits instead of just accepting stuff that's what I was leing towards um and then we can like relax it in the future exactly exactly rather than trimming it because that's the problem right now is is is balance and the others are specified if you put garbage in the upper 12 bytes it will strip them and there's actually tests that validate that's what happens in Legacy codee so

we would just remove the stripping and if you have have anything other than zeros we fail or or we return as if the address doesn't exist I think rather than exceptional halting I was going to treat it as though it's an empty account um and if we could explore that once I get the pr written we could explore it and see what other people think of it but my my initial thought is it's an empty account and can't be updated so you can't send you can't so oh we will have to have exceptional faults um because if you if you do a call with value to one of those we will need to exceptional halt so that's an argument for

exceptional halt yeah um I I just think there's like a some kind of land mine uh if the you know everything else in the stack expects addresses to be 20 bytes but then like the balance up code is like cool that can be extra right so yeah I'll start off with um exceptional Halt and I'll put in the Alternatives considered that we treated as a empty accounts and mention the um the pay operations from call as being the problem why we just set it against it I think it has the added benefit of like you can relax it like one bite at a

time if you want to be that fine like at a bik for some flag and so yep that's what I think we'll do right any other going once going twice go drink some coffee before your next meeting thanks see you all next week thanks bye bye thank you bye