EOF Implementers Call #62

Transcript

I'd like to welcome everyone to UF impl call number 62 it is the 27th of November um this is our first meeting since Devcon um so the agenda is a little halfhazard right now um we'll go through it but I think at first want to open the floor to see if anyone has any comments about anything that was discussed at Devcon they want to add anything to the agenda or want to discuss anything make sure that we get through it I'll go ahead and open the floor if anybody wants to say [Music] anything everyone have a good time at Devcon who

went it was it was very good unfortunately I got something terrible on the way back on the plane back okay so um yeah there were lots of good sessions lots of good discussion um so I guess we'll start with um the uh regular updates and the things I remember on the Colin in the in the checklists um I'll go through let me uh me get my notes started um so testing update do we have anyone from the test team on the call not seeing anyone

um so guess one update maybe we should talk about it um I'm getting some work done on the fuzzer and one of the bugs I tripped on my side was I produced inate tests with invalid eofs which lucky for me proved that goavm lab would detect the difference because G and Basu handled that situation differently when there's inv inv valid eof Basu um will set the contract to have no code and gu will happily have the code and run if it parses and the question is how should we handle that or should we do the third option un which the state test as a whole is invalid if there's any invalid eof um

entries um so what are people's uh opinions on that is this with starting with invalid on the chck or deploying invalid deal so this would be running a state test or a block test a block test um you would import the block and you probably I don't know if you reject it that's probably good thing to to question um so the state test would specify in one of the in the allocation sections one of the accounts would have eof code um in this case I didn't rerun the stack height checks so the stack heights were invalid but otherwise it Parts just fine um so uh the question is for state test

I think it's fairly simple you validate all the code if any of the code's wrong um the the test always fail the test can never pass and maybe we send a different signal to say test invalid um I think that's what was suggested on Discord but block tests when you have to try and import a block um I mean how many the blocks even created I mean that's that's uh an interesting question because if it's coming in through a create transaction the create transaction should should reject it for blockchain test is the only issue with the Genesis block because the state right I think right you cannot just plant account code in a block right extra protocol

so say test and I think unless we want to somehow test what happens to to an evm implementation that happens for any reason to run inv valid EF execute inv valid unless we want to do that and Define that and spec this out then I think uh those state test should just abort and block test also should abort and we can follow through with specifying that you know Genesis is invalid if it contains an invalid eof code in an account yeah but that's optional I guess yeah for measure do we validate uh code

that's not that's like a different version than EF I don't understand like what does the other blocks past blocks matter or the what other code matters in this case so it's the same code uh Legacy uh by code has no validation any presentation of code that does not start with ef is accepted in all places and at all um and it's just the execution time that that the behavior changes the E would be if it starts with ef and I guess also for um this is a question for 7702 efo1 yeah good question I don't know

they uh I didn't see this talked about okay so um you to say something Peter I was just going to like reiterate that I think we should uh reject those tests and just say that executing invalid UF code is something that we just do not specify it's invalid it's undefined Behavior okay okay are there any Corner cases we're missing because I think that will cover

all of them um when it comes to imported blocks the only way the eof goes into the block memory is through a create transaction that has the implied validation so I think we're going to be good there another case is if block contains creation transaction with invalid UF that should be rejected right right the transaction will execute it'll notate the invalid eof and the transaction should fail and actually I I just Recall now that in the spec we have a mentioned that EF is only safe to be activated on

chains where EIP 3541 is active and where there are no um I guess not I don't remember the phrasing exactly but the gist is that there are no invalids or or cod stting with ef okay so like assumtion I think I'll actually put this on the uh ACD discussion tomorrow because it impacts 7702 as well yeah 772 is interesting okay um any other testing updates before we go to the next subject um I I don't know if there's been much uh stuff happening on the test

testing uh front there's no one from testing to say this right yeah no one's here so I I I've seen that there's been an initiative kicked off by the testing team to Port the ethereum tests and organize the porting of ethereum tests to East which impacts UF by that it can if if we have those test in East then we have we're in a better position to uh to run them in eof setting as well because East has the flux that allow you to run a test in different evm

versions so there's an issue like a big tracking issue that uh um that I guess organizes it there's some file and well uh we can take a look at this but uh until then until that time there's this opportunistic UF W tool that will make that will wrap existing ethereum tests into eof when it can and those tests will be included in the next release um so that will for example mean that all the op codes will be executed and tested in some way in us

okay but I don't know when their next release is planned for the for the UF of course we can I guess ask for one if you want so this is the big UF tracker you're talking about well wait wait wait wait I I have no that that should be a recent issue I would say if you go to East repo I guess oh maybe that's not an issue I've seen it somewhere sorry uh issue

97 972 open isue okay yeah yeah yeah so there's I guess the plan of the testing team for the porting and I think that uh someone had already started some some contributions and that's all I know that I can um

report okay that's worth noting though all right any other testing updates all right any client updates or compiler updates don't think much has happened uh since it got pushed to Osaka I think all of the main client Engineers have been redispatch on getting Petra out quicker uh correct me if I'm wrong on that I mean I know that solidity support is like an ongoing effort to merge it into main as an experimental

flag yeah don't know the supports we currently on like merging function supports like call F with f jump F it's basic progressing rad is working on it and it's going well okay stable as she goes and my understanding it's cross many PRS right now it's not just one yeah there's a bunch of it's like I can see one two three PRS open now there are three PRS to be to be matched one is under in the review

process and the other two are waiting on the first one will be matched so they all depends on so yeah so we just just match them one by one I think uh this PRS uh so this one which is now in the review and the additional two should be matched this week maybe early early next week yeah and they add that like important intermediate Milestone is for us to be able to run all the semantic tests we have in the compiler and basically with those PRS I we kind of almost there okay it's all of

these no the the the the three the three first PRS are okay the fourth one is on related actually and uh the last one is just the big one p which uh was splitted into many different P by one by one all right that's actually good good compiler update all

right what's next on the agenda spec updates got one from kogan and Rio would want to discuss contracts later should we start with um did I pronounce that right dogen is he on the call yeah don't don't pronounce G okay oh good uh is the next or is this spe updates we're on spec updates so this would be a propos spec update I guess oh okay um spec updates or other yeah okay so um yeah go ahead assuming

this is next next agenda item so uh yeah um I put a tldr on the issue so this so first of all I'm Khan from the sourcify team my teammates Manuel and Marco are also here in in Bangkok we had a meeting and discussion with the Sol team about the metadata hash that the solid compiler places right now it's uh appended to the bite code and I guess with the eof there hasn't been a specific discussion or specific place for this and we believe there is benefits to have

a um separate metadata section in eof basically this is part of the data that is unreachable by the code the one one reason being any change in this field does in fact affect uh the rest of the bite code because if the metadata hash length changes or like the in general this this metadata hash is part of the cabore Au data uh which contains also the solidity version so any change in this data changes the offsets the data needs to be read not like this part won't be read but the other data so

effectively any change in this metadata affects the uh main bite code so we believe it is it is it is um it is a good practice to have a separate met section um did I miss anything Camille or Mar Manu I think that's basically it about like making it easier for verifiers because like if removing metadata changes the code kind of becomes much more complex uh and yeah like there's one other things that kind of we could maybe work around it but like say keeping um zeros instead of metadata

when we the use the request to remove it but there are several down signs to that one is of course the cost of having the bigger bite code but also like this size of this metadata CBR section kind of is dependent on several factors like on the on the code on like parameters and stuff so it's not uh that simple and yeah basically our solution if we don't have separate meta metadata section would be to just omit it and it would shift all those offsets in data load instructions when done which kind of complicates stuff for verify verification yeah I forgot to say uh we are basically coming from a source code

verification standpoint and right now the verification gets quite messy we have a lot of workarounds to locate where this data is and having a dedicated section makes it's really easy for for verifiers and yeah and I guess like solity has this field right now but I presume other languages might want to add other stuff to this field so this would just be like um a field where we give you a length of data and at runtime uh the runtime wouldn't care what's there it would that be a correct understanding yeah yeah exactly like we

don't even need like any instructions to access it because this only really read like offline by verifiers yeah and from from the from the perspective of the compilers uh this this metadata section now as it's implemented now in the in the current solidity you have support it's added at the beginning of the data section of the UF container and uh basically it means that for example uh data which is available from the from the from the runtime so for example uh for example um for example some immutables variables values which are St there have to be all they have to be placed in The

Meta in the in the data section after the the metadata metadata part uh because uh because of the of the reason because they are they are basically initialized the value are is initialized of this IM immutables is initialized during um con uh contract creation uh before return contract call so and and the data is basically appended to the end of the end of the the data section so so that's why it's kind of I think reasonable to have a have a optional met data section for

this but yeah but uh yeah so from the co compiler compiler perspective I think it's it makes a lot of sense to to have it separated okay brania yeah I'm not sure I understood yet what so can you explain how the size of the metadata section can change um the metadata section would for example in solidity case that would contain the cabore data the Cabo data is basically some mapping that is encoded in Cabo encoding that

can contain multiple things one the solidity compiler version 081 whatever then the metadata hash which is either an ipfs hash or a swarm hash by default ipfs hash that resolves to the metadata file which contains a bunch of information about the compilation there is also so an experimental flag so if this contract was compiled with an experimental flag this cabore section contains experimental true as well so any change here uh would cause a different metadata section to let the the terminology is quite confusing I I can imagine um any

change in the contents of this section would change the length and in turn with the current setting this would change the offsets of the data read um operations and this would in turn change the code which makes verification quite difficult okay I see yeah yeah to so do you have some sort of circularity there in the sense that is it still possible to uh construct the metadata even if if like with the

current state of things I'm not sure if I get the question so there is multiple metadata one this by code metadata now we are talking about the section to the metadata file which is the solidity contract metadata it is a Json file that contains ABI source files compiler settings and so on does that help yes no no I I think I've answered myself yeah I mean also that like basic problem is not in constructing the metadata but about like the the compiler provides an

option to omit it and that's caus differen so one the metadata CBR can be different lengths and also it can be omitted like when the user requested and it could be stripped right yeah yeah I can stripping post compilation yeah strip post compilation and you reconstitute the contract and have zero impact on the code Shifting the the indices the data indices well if we had a separate section you wouldn't shift the data indices right no but it's yeah you can't can't uh strip it I think you can only zero it out you could you it predeployment

dat you need to update also all the all the data load and uh immediate arguments uh in the code and I assume they this uh to be make much easier just removing this this this metadata section without changing basically the bite code of the contract but this is a decision that happens at at the beginning of compilation right like before you begin to emit any code at all you already know whether you'll have metadata or not so yeah um I'm not sure I see the the the

issue so one thing that bothers me is whether or not you're putting the metadata down or not is it changes the output code it's going to change the indexes for the data so metadata present versus metadata not present does have an impact on the code and it shouldn't if it had its own compiler if it had its own container section then it won't either the metadata is there or it's not and the data section truly belongs to data ex I also I also see like another downside of using the data section for this it is that it the guarantees that that cannot impact the behavior of the code are smaller I mean I guess you can guarantee that no one reads I mean the

code doesn't read that part of of the data section but I guess it's harder and with the metadata se you have 100% guarantee that that will never change the behavior of the contract which is I guess the point of source verification As I understood the Articles you posted I I say it's like more like side benefit because like on Legacy we don't have this guarantee at all someone could craft a code that depends on metadata but having this on UF would be like really a good thing so yeah yeah yeah so that's what I mean it's not only the offsets problem but also it's it's it's kind of cleaner it's

um it's invisible data to the evm okay um quick temperature check uh people like it don't like it should we ask for an EIP be written up for this anyone have problems with it anyone like it or merely okay with it I think it's reasonable okay maybe we should um like what's the best alternative that we can come up to this and if the

alternative sucks then maybe that's a a good indication that the idea is is sound I think the alternative is what we're doing right now which is sorry an alternative alternative like like something else Al together if any ideas I don't know I don't know um we cannot have a I don't know a subc container but that would require require a reference to that just think like that you know maybe um those are hocky and inelegant then this so good another thing that was requested

I I can't remember who it was is a place to put debug symbols um for stuff like remix um and that sounds like something that's more appropriate for a side car um than for putting directly in the contract although apparently it's put in the contract a lot always anyway because like the um uh the the revert reasons that L uses for example are hardcoded in some places on occasion but by side car mean something like with the ipfs file a separate file that goes perer to the class file but I don't know if that that's you know that would totally re that would upend the whole development process because everyone's expecting one

file well we have the metadata from solidity we have the metadata output from solidity in Jon which goes to the ipfs As I understood so the put land there and just you know be transparent to what we are designing here right this just another piece of the metadata that we uh that we are processing the problem with the sidecar metadata is it doesn't go on chain and that's for Source if I needs it to verify it get some identity but yeah it's interesting problem anyway um I think the best way to progress this would if we had an e IP proposing an

addition um so that would be the next the next step to get something tangible to look at um and unless there's some better option coming up I think this solves a lot of problems cool sounds good um what do you think the perception would be in ACD or as an outsider asking this so an outsider with support from the team I think would go well in ACD because an outsider proposing it would show that this is something the community wants not something that we just thought of ourselves and thought

you wouldn't that be neat and it shows that customers want it and it shows customer value and I think that would resonate um and I think one of the things that's going to be helpful is since we've been moved to Osaka we got room to change stuff if this was for pectra there's no way it would get in um but yeah Prett good nice yeah yeah I second that it would be great if if uh that would be an outside EIP um that I mean of course the this new section is optional right that's I U uh we on the same page with this so This CIP could also be an optional

addition and you know the aips that we have right now would spec out in full the container format without that section right that would be all all those containers would be correct and then there would be new I suppose that's the next question would be um do we change the section numbers so they sort nicely or do we just Define a sort order that is not the natural order um so we would have the section come between like section four and five and it'll be section six and then it would just be order differently I mean that's the next question do we want to have a nice pretty section numbering or do we just go with next available section and we put it in the header where it's appropriate and we

just deal with the out of order handling I mean like the first guess would be to pick a new number like that would be five but put it before the data section because we are we have this upending mechanism as someone acutely pointed out so it needs to the head is the header always in order and the body is out of order would that be appropriate would that be fine I don't know I don't know I guess the same order is makes sense just not just remain s and also we have we have I guess some uh thing I don't know muscle memory with

what does section numbers mean so it's also maybe a good idea to not change the numbering right now we have the issue with exil data would we then move it in the middle and move this stuff around I guess this is blocking and tackling stuff when we get to EIP we can look at yeah yeah yeah I also wouldn't change current current numbers of current sections and just add the new one which is not the in the in the exact order but it doesn't matter because anytime we will be adding the new section and it looks that we will be adding soon maybe not inaka but later we will have to add just next number but not in proper ORD you can test this scenario in C AP already okay so I think we need to keep the data at

the end yeah but maybe that's the only exception everything's in order except for the data section and reasonable so yeah I actually like the idea of giving data section number like FF I was going to say that I think this is I I don't know not a bad idea it seems if we are changing the format anyway this will change all the tests again but like yeah if the format is changed this fine and maybe to have it the problem I have with this is that it requires the change to the existing GPS right which is kind of um I don't know it put it it Paints the spec in

maybe worse of but it might make sense to change it regardless of metad dat yeah I know yeah I know I know know um on the other hand I feel like the order will be broken anyway at some point in the future with this account abstraction sections for example which they want to put in front I think okay let's think about that we're not going to solve it today but that's I think probably the biggest issue and this will be one last big change for the 1.0 before he freeze it yeah so that's some things to consider right um what else was next

Rio I think Fran um no probably e create yeah yeah EF create right let's go to EF create okay so there's this uh issue that you're I guess going to and this is the proposal from Charles uh I mean the the background is that we would like to not hash the init container but then this proposal not only gets rid of the container the init container hash in the new address um derivation formula but also basically anything related to The Container so also no subc container index no code address and it puts all the

responsibility of getting that right on the the user or the the author of the contract I guess or on the compiler to provide some sensible defaults which uh would be included in the salt and and as such would make um collisions between addresses um impossible or limited it would be entirely under the control of the contract it would be entirely under the control of the contract slash I mean that would be up to the contract design you know you you could you could hard code stuff into the

contract if you like but you you could also uh have it delivered through through call data for for I don't know generic factories or stuff like that I haven't had time to read and review this because I was asleep um my first instinct is we need some sort of a salt itself like an EF z00 somewhere in this so this is the hash just for EF but I think we moving the the hash of the contract should be fine um because we got rid of self-destruct we don't have to worry about polymorphic addresses anymore but I mean they could do games with revers but that's you know there's

nothing will be side effect um but the one concern is if people rely on this for for um uh what's the counterfactual contracts um I think if we just notate that that this is a bad scheme for counterfactuals um then that should be fine um yeah is it though like full contractuals are were punted to TX create because this is the only one where the code doesn't exist on chain right right so we would need to I mean probably re approach the design of TX grade but we we are in a good position

to that because we don't have it in the current spec so it's limited counterfactual um I mean I guess you could prove the execution but you could there's ways to mess it up because you could create off of any of your subc container objects you could have like five contracts you would deploy based on arbitrary call data and that's how it would defeat counterfactual but you would still be limited to 5 contracts but it's not you're right it's not a true counterfactual and so we have TX create yeah my my personal opinion is that it's this has some pros but I'm quite worried about

that um that's a lot of responsibility for the for the smart contract and and that could lead to errors which will then cause people to have their contract pricked and unable to to I don't know do something that's that's important because they cannot create right uh which I don't know it's like maybe paranoid but oh don't forget delegate call you can delegate call to another contract and have them create because it's going to be the sender address I mean that is that is covered I think this is where my understanding

gets kind of blurry but the sender address would be the the the the contract that does the delegate call so it's just moving the witness to another contract which you know also you you know what it does right so we can design it in a way that it um passes the right s for example yeah um uh so I'd like to add some perspect from the solidity side because like we

discussed this today I want actually to post an update in the thread but didn't me to be for the the call but we kind of also like concerned about like making this like too generic because it moves a lot of responsibity to the uh user of the the user of the contct like especially having to mix stuff into this salt like we probably wouldn't want to like hide this thing like under the syntax with some compatibility uh C out by the compiler so we probably would end up with user being responsible for always calculating this s

manually in on EF and that would create a bit of complexity and it also would probably be more costly so yeah from our perspective the uh Proposal with uh still keeping the container index in there was a bit better because it's still hides some of it uh yeah and like another concern from our perspective that uh uh for example let's say someone wants to deploy uh the same contract twice it might not be like obvious at all that they have to like I mean becomes like much more complex than now

because now you basically use new multiple times and like you get different contact deployed now you have to like to disambiguate it with salt um this is already broken with current scheme we discussed it a bit before like uh so so now you have to provide different Sal if you create the same thing twice otherwise it's a conflict uh yeah but I mean still it makes like I mean this is basically F this things to the user so kind of we kind of go with it with it's strange but yeah I mean you still like more complexity yeah so so we're con

concerned about this then that should also extend to Ox data is kind of what I'm hearing what do you mean how is O data related the fact that the arguments are not included in the address computation so if you want to do that you need to manually put them in the salt and that's already a risk of getting collisions on the other hand it's the flexibility of hasing not hasing the input

arguments and then that some cases maybe it's beneficial not to that's what I got like from discussion today yeah so the flexibility can be good but it also introduces some risk but what if what if isn't like a big problem for cross chain U deployments which I don't really know a lot of know a lot of about sorry but the more the more you include mandatorily in in that hashing scheme the the less chance of having the same address on different chains you have and a sta it seems like a first

candidate to to throw out because it's I don't know I would expect different change to might come with different o data um does AUX data what are we what are we referring to with au data here because another issue related might be with the metadata section that there's there's a like people commonly complain about the metadata hash and they leave it out because it affects create two um could it be could we also explode the metadata field here I'm not fully yeah I don't fully know the spec here but oh that's that's a good question

actually we should we should remember to uh to be worried that these two propositions interact with each other I guess so we would say that the metadata should be excluded from the uh address derivation right yes that would uh solve a bunch of problems that current okay okay oops I mean that's actually another argument for having separate section because C currently it being in data section can affect execution and having separate section wouldn't be able so it be like much bigger argument for excluding it yeah yeah I mean this is a good argument for also not hashing the need

container as a whole so for for this proposal particularly in any form yeah I mean I think is probably fine but still like there should be something that like uni indicates the container like the Sub sub container ID and I guess this code address so I heard the word probably fine that kind of gives me the the chills um can we think of this from the perspective of how might someone exploit this if we just have the address in the hash and maybe that will direct us as to what we should do I don't know yeah suppose there's a contract where

um to claim something you need to trigger a deployment um maybe it's like a contract that disperses vesting wall wallets and so it does create of sorry eof create of the wallet and then it transfers funds to it but the contract implemented the salt uh formula in a way that like it's not correctly binding the created contract to the intended recipient of the funds and maybe this opens up a some sort of

vulnerability it's just kind of one thing that I came up with but the point here is depend on the code it would be that the developer accidentally introduced something right and we could say like in the current in Legacy because the arguments are automatically included in the address computation they sort of carried over that mental model and forgot to to make the necessary adjustments in eof to get the same guarantees does that does this make sense yeah it makes sense and I think

the it I would say that it would be it would be on the compiler to provide the good defaults so if someone doesn't nominate any salt then the compiler should should the ordinal are like the the nons let's call it the nons problem so that when someone does the same thing a couple of times is one thing that's a bit worrisome to me and also the code address which I think uh is not available to the APM um I commented on that on the on the issue yeah I've seen but you I mean not the address the code address so if you

delegate code that will be the code of the cont that this execu no but what you ah okay there is a way to get the code address yeah with anable or so so you okay so self is like your your name for the would be code address yeah yes yes okay yeah you're right you're right yeah but okay oh that's good sure I understand that first go ahead I don't think we can even provide like good default because like we discuss it like there's I mean basically shifting to the user so uh that's like similar problem like non we don't have like for non so kind of

like breaks culted cre in a way that we probably have to require user to provide salt and probably here we will to the user as well so I mean buying that it's expensive can you not just have a counter of uh like I mean but where do you store the counter probably like in stor kind of like depend Cas but that's you considered expensive I guess I know I mean that's a safe but expensive default I guess it also doesn't seem like something that we would do automatically

because like it needs to have this counter somewhere somewhere in the layout so we probably would prefer to have it allocated explicitly so that wouldn't be like just fire and forget I would have to like change the syntax way ACC instead of a counter what I would expect as a default would be to recover the Legacy guarantees by getting a salt by hashing a user provided salt with the and the hash of the in it subc container or something like that so there will be no commentary there and you would just get

back that create two guarantees I mean but so I mean we discussed it today on the meeting so kind of like Daniel was really skeptical whether it's like viable I'm not for myself but it still does at some cost so we should probably let this do for a while and think about it and come back to the uh comment Linked In the issue and at our comments there um we're not going to get resolution today um we've only got four minutes left um fanio is that enough time to at least pitch what you're talking about it

so we can think about it in two weeks or do you want to just take the entire question about um generic contracts out out the next meeting no I'm I'm happy to just talk about that next meeting I don't have any concrete proposal I just wanted to sort of get your thoughts on something um okay I don't know if you have any other topics I feel that maybe it's useful to do a little bit of a summary on this eof create okay um so yeah it's kind of hard to to follow all the all the concerns about the U great one of what started this

discussion as quick summary um was concerned about having to hatch the container multiple times try to improve the performance and hashing the container U my understanding is that's also um kind of a ZK issue as well that hashing the container is more expensive in a ZK context than it would be in a regular execution context so the desire to remove as many of these container hashing as possible um would be very beneficial to ZK on creates and make crates not as expensive um oh so the first yeah so that's probably the second reason but the first reason is it violates the contract uh the uh non- introspection because if you have to hatch the container um what if

the container's been restated into some different code format by getting a hash over the container we have to have the bite code of the container which is a way to um address the non- introspection um you don't get the specific code but you get it in accurate an aggregate which is of oh we didn't even get time to get into the E EXT create um uh the ex EXT code hash and EXT code size discussion um we should probably start off the next meeting with that um but yeah the concern is by by including hashes of the O code um we have to keep certain even if it's just the hash of the old original data you have to keep it around and then there would be concerns about how would you prove it if we restate it into different formats

like if there's an eof2 or if if a uh Z chain uh restates it into their Z KVM format um they would still have to keep some reference in that old code around um so by getting rid of the hash we would get rid of the the introspection concerns um so that's where it starts in we're trying to figure out ways to running into other issues um such as polymorphic and uh counterfactual um since we got R of self-destruct the issue of polymorphic address is gone because people would use a create two Factory use some various uh techniques have to create two Factory create different contracts at the same address and they self-destruct them in between then self-destruct is gone in eof that's

not an issue but um the issue of uh counterfactuals doesn't quite exist yet in eof because those really dependent upon like a a create transaction or a create 2 or TX create counterfactual I mean you can still have counterfactuals with the planal create um but by taking the init code out the init code hash um it makes more ways to to make counterfactuals less factual um so that's that's kind of the summary and the thing we need to figure out is if taking out any reference to the existing code um and the paths within the code I mean I would argue even referencing which code section which

subc container section ID um feels like it's still getting into code introspection because it matters what order your subcontainers are in and it leaks one piece of data out of it I don't know if that's necessarily a bad thing or not um but it prevents us from reordering the subc container sections I don't know that's kind of the kind of the summary of where we're going with this um so please leave your comments to this thread up ahead if you have some security concerns drop them in um we'll have another call again in two weeks we need to discuss um has code or account type or ex code create didn't get time to discuss that today um but I'll uh update my ideas into a potential PR

change to the the EIP um any other questions before we close the meeting all right seeing none I'd like to thank everyone for calling in I know for the Americans it's kind of a fun time to call in because of the holidays but everyone else have a good week and enjoy Black Friday shopping thank you very much Happy Holidays