EOF Implementers Call #68

Transcript

all right I'd like to welcome everyone to eof implementers call number 68 Wednesday March 5th 2025 um the agenda we have set up uh testing update client and compiler updates um then we're going to go through the Osaka test net plan in priority order for our meeting notes first make sure we have all the changes ready for devet one then look at the devet 2 changes uh Willie Morris is on to talk about payop code um so we can you know get his understanding of it in case we need a explain it to all cord devs um if you have any other things you want added to the agenda please bring it up in the chat and we'll get to it after we get done with we we'll look at it after we do client updates so first up is testing updates Mario do you have

anything for testing for us um not really I've been like focusing on everything that came from peski and now aolia so yeah no that many updates on EF yeah that's totally understandable um it's it's been it's been a circus this week um cool um so so on on testing we're probably going need to start uh this is probably more of a devet one thing U when we start implementing these things we're probably going to need to update some of the tests um to reflect some of the structure changes we're doing so um if everyone could take their current implementations and put like a uh eof devet zero tag on it with Git that would help us be able to recreate

what we have have now so when things go forward we'll be able to get it um client updates uh let's start with um ref um no changes we still de at zero yeah uh I yeah and maybe I'll ask later that's it not changes okay Basu Lewis also no changes here still at definite zero uh as far as I know okay I'm not seeing another mind on the call and I'm not seeing a GU is that correct okay evm

one speak can you now that's great go ahead uh need to mute call Mute go ahead uh so we we've got the TX Creed bringing it back uh in progress and also the you have create hashing change and we've also prototyped the one of the quality of life Improvement improvements which was the of create order of stock arguments I think that's it okay your mic okay cool we're all in the same room so it's kind of a different

experience um and I think that's all the clients that are on we don't have any from Aragon or ethereum js on the call it looks like um how about compilers I'm not seeing what I was expecting for solidity or for Viper um do we have any solidity updates our solidity guys outside no R it yeah Ric was here but I to my understanding there was no really changes to solidity compiler the stuff that has been done before last week are in the main branch and not so much so far

okay all right so any other team updates or compiler updates before we go on to the main discussion the meeting actually there's one testing update that I don't know we were stest on day of implementor call last time and we have a new release 2.2.0 right of the free release test so if you're um um you would like to download this and report back with whether you're passing new release and this is with e DEET

zero uh this is e def zero yes okay just new test onp and Spectra compatibility okay and I expect this will probably be the last release for Zero and the next one will be for one because we're going to be in the middle of working it over the next couple weeks okay we'll see um second call for eof uh client or compiler or testing updates maybe more like a question for de one uh when should we plan those changes to hit the next next testet

devet that's exactly let's start off with that discussion that's probably where I was going to start it yep so um as far as timing for eof goes uh I've I've prioritized our devet plan in such a way that we can have devet one done and after that we can take whatever the most current devet is when Pierz ships um PD is pieras is important enough um that they've made it clear that anything that's not ready when pieras is ready will be left behind it is not just a headliner it is the sole and singular driver of this next release so if we're not ready to ship eof when p is ready we will go to glamsterdam which has a indeterminate ship date which is not a good place to be so um youf Dev Net One changes i' I've

included everything that's a breaking change and it would be great if we could get that finished in the next uh four to six weeks um and tested so I need to get Basu and evm one um ready to do tests here in a couple of weeks so we can get everyone to get weeks and we can start fuzzing and get something ready for a um for an E1 devet ideally when um ships would be the ideal time so if we could get our code and we could start working on these changes and what I want to do on the call today is finalize what needs to change for the clients um there's two outstanding items or three outstanding items um about the Omnibus PR but I've posted a PR that's going to change all

the eips um I have concerns I'm going to have to split it up six ways to get it past EIP editors um if there if they sticklers about the one IP EIP it's it I'd like it to be a coordinated change but we may not get that so um that sounds great so something like four to six week for DEET one uh and that's mostly the major CH that we want for youf are basically there cool and then from that point I think we would probably do like a three or four week cycle for devet 2 we try to figure out what we can scope in and then devet 3 devet 4 based on the priorities and

based on the appetite we get out of ACD for adding new features um as I mentioned before the call started um we need to be prepared for the risk that ACD may say that all we get is eof devet one um because there's been some scoping discussions and adding in some more writers into eof might cause political problems um try and get them in but we may need to sacrifice them for for political purposes to make sure that other things don't get it as well so that's that's the risk we run um but I think ideally what I would want in um devet 2 is if we decide to do pay we should get it in this release get the metadata section get that nailed down and then the EXT code address and EXT

code types which were necessary for the um erc721 contracts um but the two open questions we have seem sorry cype seems important I would even like want want to push it inside that one it's not that big of the change it's just one op code yes it's not crucial it can be added later but I feel that it can be bundled inside Def One they just my opinion I wouldn't mind if this de two but I feel that um yeah important to add it in first iteration okay probably quote address too I think is another important one

let's try and um let's let's loop back on this in two weeks and see how much progress we get between this and the next call um because yeah I I think the real deadline for e devet one is want to be able to launch it about the time pectra goes up um so that's the signal that that allord de is going to need that we're ready to go um so yeah so we can we can add on if we if we get done early or if pectra slips out even more than we would like it to which is a risk small risk but zero okay so let's do the second one first let's talk about Commit hashes This one should be quicker um let me find the page in the Omnibus new address what is the final

form of the hash is it FF sender salt or just sender salt and is it 32 or 20 bytes I am okay with all of those let's just pick one can you pull up random.org huh can you pull up romg so what I have printed in the in the pr right now is FF which matches create to Sender salt it is the same as create 2 we just get rid of the uh init container part no no this is literally is um create 2 um what's the EIP number for create 2

2015 okay also the container I mean you code create to so that's that's I can type the number in right yeah it has the init code so it would be less like 32 byes less yeah so we get rid in it cach so it's just like create and the concern about collisions are not a problem because the length of the hash is significant so they can't use it to create collisions any more than any other hash could be used to create collisions yeah I think someone commented that

keeping the FF prefix is like the the least change some way okay I think this at least the least number of arguments we have to provide to this to justify the decision I mean if I don't know I mean I Was preparing like removing PRS at the beginning it's the easiest to implement but you also need to put this implementation in some different place but maybe you have to do it anyway so why was it put in create to in first

place the FF because it kind of blindly guarantees no collision with rlp encoding but I think it's strictly not needed because the rlp encoding of the the address hash for create instruction will have always different size as well so it will never Collide but if you put like FF it's really unfeasible to have rpn coding that starts with the same B so it will differ on the thir B but I think K guarantees that even if the length I mean the the input is the same but the length is

different it will not cide on the har so it was a bit too much to my to my taste but uh it was kind of old time so nobody fully analyzed that yeah but that was the that was the motiv right to to to have no collision with the other address schem so we'll retain it for uh consistency all right I don't know all right that's like I said I'm okay with all of them let's just pick

one the next one is kind of a different question um and I think has more of an open-ended decision uh create a contract for E 7873 how feature it should it be it specifically should it include a flag to include the collar in the final salt for non-front runnable deploys um how we put that flag in so that is uh did I get that PR so there was announced that the Creator contract is more feature so uh it not only allow Bo new contracts but also to serve as I understand as a replacement of the to field on transaction

transaction and then like the other on the other hand we would like the cre contract to be as small as possible so it's easier to audit it might eventually just not be used yeah just to summarize what I understand about this is um the Creator contract as is is front runnable um that means that if you see a transaction to the Creator contract you can take it submit it yourself and

you'll get the same resulting address normally when you have this um you want the the caller right the message sender to to somehow be significant to prevent fromont running attacks and um yeah so you would want this here but then we also want at the same time the address to be independent of the Coler whenever that's fine um so it's a bit of a difficult

situation um one potential solution is the creater contract should ignore the caller um but then if we do that it's like the default way to deploy contract is insecure in most cases by default so one could say the default weer deploy contract should be another Factory some EO ERC Factory deployed from the Creator contract now the problem with that is that um this needs to be deployed first it's not going to be built into the chain and that makes tooling a little bit harder because you need to deal with that edge case um so I don't see a clear solution

here one of the options was to add an optional flag to to hash the color into the salt um but that adds complexity it does um were we going to add a 4X selector into the calls into this anyway so it's friendlier to solidity or were we just going to take it straight it flat because if we add a selector then it's easy to make two methods and just recommend um one is the safe and one is the unsafe actually put that in the word and it's unsafe and you would need to make sure that there is no state that depends on who called The

Creation um so if you're a deployant because I think there needs to be a method I mean if if that we need one that doesn't have any of the sender addresses in there to get a tow hold contract get a universal tow hold contract so that needs to be available and if we don't have that then we would need to rely on a use you would have to use Nick's method at least once to get a consistent toold contract which has as mentioned before on these calls has problems with the uh with the gas cating in some of these so actually I'm thinking one thing now the caller is not visible inside of the innit container because well

actually that depends on whether you do call or delegate call into the Creator contract but if you do a call into the Creator contract and the Creator contract is the color um so then it the front running in that case would only result in manipulating TX origin and you might use TX origin to set your contract owner too which is something an audit would flag but somebody's going to do it and blame us no in that case I I I think it's it's already kind of widely understood that TX origin is bad um so I'm less concerned about

that but is ising selector the into the original P contact that much better than having like Factory which is comess that is that not also problem is not equally problematic tooling because yeah because we could use the the unsafe one to do an immutable doesn't matter who sends it get the ERC that's the standard safe one um but then people would probably the way I don't I doubt solidity would want

to build it in another compiler I don't know I don't have what the experts not in the room like I think it opens up like configuration issues that we actually seeing on on tests right now yes that you you need to make sure like it shows up on many different Deets and test and like other chains right it's like it's kind of lowers the the guarantees that the contract will be there this one will be there by like Fork definition right so whatever chain has this Fork implemented you know that the address will exist

address if the behavior of the new Factory is same you can expect that the address also be do we want to have the auto deploy of it built in every single solidity produced contract or do we want to have that something like a a library decision Ben's got his hand up do you got something to add Ben I mean you could have one that's only in it code and then if you're front run it doesn't really matter because you know they're deploying the same contract oh I suppose unless unless it's taking sender in the contract but right it would it would right the contract be need TX origin or sender cuz you both

well not necessarily not necessarily either if you're just sending a a neutral contract contract that has no owner um you know like a utility contract then if your front run who cares because it just means somebody else paid the gas right if it's if if there's only one way for that contractor result but there's cases where you might want to use like TX origin or um if you could get the sender in to set the owner of the contract um because that's something you would want to do the in the init code but there's also no way to do a delegate call from a transaction yet so you're always going to be in well you're going to be in context of whoever you're

calling so you will be in Center big yeah so who's got the strong opinion on this because this this contract needs to be audited that was established last week and once we get um devet up and running we can start the audit cycle once we're fairly certain we're not going to change it anymore so if we we don't have to be you know beyond certain that we're right there's room for us to be wrong on it but the Auditors will be the ones uh telling us to fix it so we should make the job easier but yeah who's got the strongest opinion on

this they get to make the decision should we apply the circus method how about we we go with the simplest version and we have the not somewhere that does this is concerning and I don't know I mean I'm not sure who should have the final word on this yeah but if if we don't have if we don't have like specific solution right now maybe we should pick the simplest to like move it on and and already keep this note

that yeah it shouldn't be like secret and we waiting someone to find it I think it's it's better to have it written somewhere that we kind of have some concern but yeah also don't feel expert on on contract auditing so yeah Ben I'm just following up with the simplest probably the simplest that allows us to deploy the next more complicated if you know what I mean does the does the simplest version enable uh like a a trustless deployment of a more advanced version if that makes sense

um just for my understanding the problem here is if somebody front runs your creation contract and what exactly is front TR basically the the address that is going to be created so they would see your transaction in the memory pool and they' see that your contract sets the contract sender as the owner of it so they run it themselves and now they're the owner of your fancy nft that just just don't do that yeah don't set center with with yeah but I mean if you do other things like if you do things like set the center in the in in arguments arguments that you pass in can similarly be front run and modified

would need to be immutable either way you can redeploy your transaction with the different so we're not you need to create new transaction and sign it all over so because it it was front TR and you cannot generate that NFD whatever it is I'm surprised in it code hash isn't part of the address um the TX hash is oh yeah the in the first Creator contract yeah the TX creat is and we're not including the under hash to guarantee total

contracts yes in the cre contract have fin and that final is combined with sender but sender is already the address of the I mean you do have uh really odd things where people try and work around the fact that in it had init code is included where you have like I think it's is it create 3 where it creates a a contract that deploys a contract and then like self-destruct so that it

you're doing a create to to do a regular create of the nons to get rid of the fact that uses in a code in create three yeah I think we're trying to get rid of those hokey steps so we can optimize some of the create three operations so we don't have because we can't self-d distract we can't self-d distract any o yeah I think that's just more cleaning up yeah and people spend like weeks trying to generate the perfect address not based on um you know GPU

mining so this is once we get this nailed down I want to write a blog post about how we're handling deplo and I think this is a feature because they can mine the data and it's not tied to a specific account it's tied to the argument data of the call anyone can pay for it on any chain so that's when I say we get rid of Nyx method we solve this problem and you can use um they can use market rate gases and so you get to some of these chains that have default High is like well I don't know if monad is going to do e immediately but monad starts at 50u for their TOA now test net and that's a pretty high number hadera was at like a thousand at one point so this would solve a lot of those problems and I think um is it the cas syn they they

don't allow the anonymous transactions pre-signed ones so that breaks X frenia cranio you have your hand raised and you're on mute is he trying to chat um all right so so frano uh come

off mute whenever you want to talk so I think we'll just go with the simplest for now um that might change we'll get feedback in the next two weeks we should get feedback side things yes trying to mention that they will not be happy with having to have a default deployment but use any Source address I guess which is Les certain to be specific value single value cont right the question is would they want to require people to put it in

their solidity and have that predeployment um who else Foundry who's still in business con put brownie still a thing no okay web 3js is not a thing and they full on archive their node

they're they're full on archive their their GitHub repo now all right have we said enough about the dev n one changes does anyone have any questions I posted the pr for review darn um this should reflect all the changes if everyone could review it um if there's anything I missed in the things we talked about bring it up in comments I tried to fix it at first um this if this gets approval from everyone in there it might it'll autoc commit but we can always go back and change things we missed later uh but most of this is return contract return code changes and um some other motivation

section changes 7873 this is an old build anyway yeah and I'll review some of these changes in here so thanks for putting this in I'll review them and get them in it won't Auto commit until I fix this lint issue anyway assuming I get approval and this might split up into multiple PRS um we'll see fro can you hear me now yes we can hear you now okay yeah so I am I'm not feeling very well about the whole front running thing um to me

having like such a core thing be front runnable um is is is a real problem I and and it's not only about TX origin like anything from the transaction context could change like I don't know what could happen if like you include some blob in the transaction right does that affect the contract deployment in any way um or any any future transaction parameter that could be readable within the NIT container could could result in a in a problem um so to me the the simplest safe um path forward would just be to

like include a single bite at the start of the Creator contract call data that just says do you include the caller in the in the hash or not um and that's it like it's it's it's not selectors there there are no selectors currently just a single bite to to configure that and that gives you the option to do cross chain the terministic deployments but also a safe default that that doesn't have foot guns what we kind of reverse the the the chain of action that we always include

the Senter and then you can deploy the factory that actually on that so it's kind of stripped out version of this but the tow hold it would need to have the same Center in all chains yeah including all feature chains that don't exist so it's a feature but has back in [Music] it yeah and I think we actually called the flag unsafe deployment to discourage people from just casually turning it on so if you know what you're doing you're fine if you don't know what you're doing we told you it was unsafe okay I'll include that to the

notes when I talk to the developers on that probably need to think about it for two weeks um let's move on to P code uh we you want to Le us do you need the yeah I'm going to try to prevent present uh my screen let me me stop sharing um there we go you're sharing now awesome okay uh cool so I'm here to present pay as an important part of eof security uh e F uh one of its goals is to abstract gas uh

thereby the gas op code has been disabled uh four op codes with gas parameters are disabled in eof uh so there's this rationale for the G call stipend uh and that's how much gas is provided to a call when you supply zero gas in those OP codes currently uh if there's a value uh so solidity they pass zero gas and transfer incent these are kind of uh basic ways to transfer ether uh if you don't want them to gain full control of the execution context uh so this stiens is enough for log and T store but it's not enough for sore or G

call Value so the expectation is they can't make uh uh changes and they can't uh call back into you if you supply zero gas uh but they are do have enough material to log the change uh and do some basic minimalist operations uh so uh these gas restricted transfers uh they're safe against uh gas griefing uh and re-entries uh so there's uh a problem in eof right now and that's that the only way you can transfer eth is with ext call uh and so EXT call forwards all of the gas minus tiny tin Le less than uh even call right

now is Left Behind uh and uh there's no other way to do it and so thereby anyone that you want to send ether to uh they might uh be able to grief you for example minting gas tokens with your extra gas using the Legacy gas op code uh they can keep looping until you have a like 90% of your gas gone to for them uh and this is I've seen gas griefing in production put it in erc20 tokens uh there's even a scam where they do erc20 approve and they trick wallets into remove revoking that approval uh and then they uh mint gas tokens for the scammer um there's a workaround for eof

so eof can still have a gas restricted uh ether transfer they just need this proxy contract I have here uh it starts with 5f uh that proxy contract would then transfer the remaining gas was zero and so you could use this proxy contract to deliver ether in a safe way as before uh but this is uh not ideal because there's an extra ether transfer uh and you have to go through this proxy um so I'd prefer that that not be how it's done uh instead I want the payop code um to keep these ether transfers um so uh pay is quite like eof there's no gas parameter uh the um ether

transfer uh is uh it it it the recipients works for adura space extension as the other eof op codes uh the uh pay uh works like call with zero gas and so there's no need to preserve zero gas uh to maintain feature parity uh for the most common use case of call with zero gas um the only case where I use it and when solidity uses it is for payment um everything else you need gas because you're expecting them to execute um and I'm almost done uh but uh the uh hopefully solidity uh can Implement

transfer and send uh with pay um and there's also this idea of a right to reject that's commonly brought up in objection to the payop code um but there's already three other ways to pay and so I don't think this is a great reason to uh prevent re-entry and griefing um on payments um so that's all um there's a question from Ben um doesn't um when you when you cut the gas in a transfer so like the current recommended way is not to use um transfer because if you send it to a multi-c then you know

which is say multisig which is a proxy to another address then there's not enough gas and generally it will fail well if it's aoxy and then it does have enough gas to do delegate call then that delegate call can emit a log and I think there's enough gas for both of those operations um but not if the uh recipient is a uh uh cold account access uh for example uh the if the proxy implementation in that case is a cold access account then 2300 is not enough so pay would work in that case but not uh transfer and

send okay Dan um Alex has a question just some feedback on the on the stipend we actually try to get kind of rid of it um and the reason being it has been an issue making changes to gas for the ex reason you described the point of the typen was to try to limit what you can do on an eer transfer and the goal of that limitation was to avoid rights and nothing else so like State changes excluding logs and the way this was achieved with the typen which caused issues in repricings because you always had to make sure that nothing breaks there

um so my suggestion is I think if we introduce a pay up code it shouldn't follow this old broken metric it rather Ian go ahead you said it still has the stipend no no we get rid of that uh it just transfers The Ether uh it's been the specification of the payoff code uh to not to not give them an execution context at all uh that solves this entirely okay it's unclear to me what it what it exactly means to be honest oh

it's similar to how self-destruct the parameter just receives The Ether uh this payop code the recipient just receives The Ether which is why I discussed the right of refusal there's no way to refuse this ether um just as with self-destruct priority fees or Beacon withdrawals what is the gas limit they have uh the gas what what is the gas limit they receive uh they don't receive any execution context then they cannot do logs and kind of do right exactly that's the point of it yeah yeah yeah it's it's more like self-destruct not like a call with gas zero yes it's also like priority fees the coinbase transfer

that happens implicitly in the block also behaves this way and Beacon withdrawal also behaves this way so it's always been possible to receive ether without getting a call B I mean there was always a debate between this and some people really wanted the non-execution approach others wanted the execution approach with no rights and maybe the the people with the no execution approach have won because of the withraw stuff um this delightfully gets rid of that call stiens that needs to be tweaked anytime the gas gets tweaked done the whole time you know what I was going to suggest that I think at least in my word ideal pay up code would do execution but would restrict

all the op codes doing rights so it could do reads but no rights because that makes it work with multis and contracts um you don't need to like scan the chain afterward um but yeah that's my two sense well yes uh but this can't simply be the same as uh static call and so it'd be yet another kind of permissions execution because they want to be able to do log uh and you log in a static call context uh so that does add quite a lot of complexity uh and so I'm opposed to it um the also uh the uh I do like that it doesn't have any ability to

make changes that does remove a lot of the incentive for griefing but griefing can still be done maliciously uh there's if you're paying with priority fee for example uh the block Builder can get more fees by having you execute more gas and so they'll use up to your limit uh in order to extract priority fees from you yes frano um I I don't really think that this is a a good way to protect or get security um I think there are better ways to like prevent reentrancy

um so I don't really think this is necessary and I wouldn't include it in at least in eos's initial release um that said one alternative proposal just we could consider is to add a value parameter to ex static call it's a little unintuitive but um I guess the value transfer happens before entering the static call so it doesn't violate that and it still provides this protection of like no no modifications that the gas typen initially wanted to achieve uh but again I don't really think um this is necessary personally oh so

again with the static call um the most common thing I've seen done in with the gas diens is is to log and you can't log in static call and so you wouldn't be able to transfer to entire categories of accounts for example the uh there's a uh block Builder I want to say it's uh steth uh they have uh they receive uh ether in the coinbase transaction and they emit a log and so if you don't Supply them with enough gas they revert uh and then they don't receive the coinbase payment um but I'm sure there's other s uh but that's the only one I'm familiar with so you wouldn't be able to use that to pay them um and these

limitations would prevent me from using eof uh because I worry about gas griefing and reury um I understand there's other ways to defend against re-cy but not gas griefing um well what about setting a a a gas limit why isn't that not a protection against gas griefing uh you can't set a gas limit for at the transaction level oh yes um um the uh transaction level gas limits uh is also a way to do this uh yes um you would have to model for that but in the case of uh the uh gas token exploit I mentioned uh where people trick users into minting gas tokens they just do eth

estimate gas and then approve that transaction um anyway so they're they think they're revoking approval to some malicious contract for a token also called usdt uh but then turns out uh they uh they're minting gas tokens for a scammer um so it's they uh will just approve whatever gas limits uh they don't know that it's unreasonable for 30 million gas to be used to revoke approval is is this attack still viable I thought that some Network upgrade had made gas tokens not any more viable gas tokens still have monetary value and so scammers still use that mechanism uh to

grief people and make money um it's gas tokens aren't as valuable as they used to be but there's still a way to convert gas into value I mean if you're if you're getting them for free um yes there's a there's a differential yes well thank you for your consideration um I may not be able to present this uh during the next so please discuss uh with your team I think this is an important part because I wouldn't be able to use eof without this for my own use cases um thank you for your time all right um yeah we'll keep that

under consideration if if you're not at ACD we'll we'll figure out how to best Advocate it there probably use your presentation um yes I can add any of you as owners if you would like to modify it or add anything I think I just present it straight I wouldn't I wouldn't change it at all I want to make sure you're represented the way you want it to be um but my concern based on just the discussions today is there's not enough consensus to add it and I'm not sure that going to allore devs will improve that just to manage expectations um there's a chance that they they could change their mind and change people's minds but if I had a a project what would happen here I probably would not be in devet one and probably would not be in Osaka um but presented in allore devs um

and um willing to take direction from them to add it if they tell us to I would I would add I think it's going in the right direction um that makes sense I'm not I'm not 100% sure on it but I think it's it's definitely covering a needed angle that's that's not Pro and again we may come to consensus but just today I'm not seeing the consensus right now consensus changes over time um but yeah definitely bring it up next week assuming it's also not Chuck full of what went wrong with the test Nets another thing we need to

manage um so what else is left on the agenda um metadata section EXT code Kanan do you want to talk about do we have could you do metadata section in six minutes uh con like like a recap or well um I mean one thing one thing I brought up when discussing with you and maybe also here I don't have much time though but it would be ideal if we could exclude the metadata section from the it hash uh part when when creating the contract that way like any metadata

would not affect the contract codes contract address which is currently a problem that's why a lot of projects like Unis swap are opting out of the C encoding completely or like the Met hash completely but I don't know if that's possible okay yeah I'll write that down um yeah we'll we'll have time to go over this in two weeks but yeah I wanted you to state that that's the big concern you have with metadata um I think so that's something for us to to consider and contemplate on um EXT code address and EXT code Type I think don't have any

outstanding questions and whose hand went up and down I missed it uh had small comment about the metadata but leave it till the end if you one I think we're at the end we're going to get kicked out of here in about three minutes so um go ahead and share what you can um yeah so I think the the the the reason why people have not liked metadata in the past was because of the difficulty of getting verification to work on ether scan um for solidity but as far as I know this has been solved for a while now um unless you're you're like really not I

don't know not not doing proper Version Control or like managing your deployments but the tools to to do that properly are all there I don't think um making the address inep independent of metadata uh makes sense and you get similar problems about like front running that we had been discussing right so um I I would like to to hear more if I'm wrong about that but I I don't think um anyone would really want to emit metadata for any um good reason

the yeah the problem I was referring to more uh so like the verification part is one problem and metata section helps with that by having a uh having a separate section for that and you can look at the metadata section and omit that section when verifying and the other problem is the was has been the create two problem where people want to have like deterministic deployments and when the metadata hash is sensitive instead of like using that they completely opt that out that's why like yeah if you recompile and get any Chang to the code the TX hash is going to change anyway regardless of the

metadata yeah but the problem was the metadata hash changing not the code changing am I getting it wrong so but if you're if you're doing a truly reproducible build the metadata hash will be the same unless you put like dat in it if it's a fully reproducible build you'll get the exact same metadata hash exactly yeah but then people were not being able to do that so I don't know maybe we can discuss this later I don't have strong opinions on this but this would this was a small problem that I could see but it's not a huge problem okay well we're about to get kicked out so I think we should end it here as open questions and we'll discuss it we'll see

how far we get next week um again the first priority is to make sure we get the Creator contract down um and then probably a recap of pay and then we'll come to metadata so I think that's where we'll be in two weeks all right I'd like to thank everyone for coming thank everyone for their contributions uh youall have been a great help thanks