EOF Implementers Call #71

Transcript

All right, welcome everyone. This is EF implement call number 71, April 16th, 2025. Um, today's agenda, um, doesn't look too busy, but it actually is. Um, testing update, client updates. I ordered these, um, east got missed, so we'll do them after EthereumJS. Um, spec changes and updates. Um, this is going to be most of the discussion of the topic today, I think, is bootstrapping. Ah, and east just showed up. That's awesome. um that's sinking from the GitHub issue. Um then we'll talk about the current test nets in the next test net and then other comments and resources. If anyone has anything else they want added to today's agenda, please drop it in the chat and we'll try and discuss it in the

appropriate place. Um so first place we will start is testing update. Um and Mario's on the call. Mario, you want to take us off? Hello. Yes. Um so we're planning a release rather soon. Um this is a general uh east release. Uh so it will include petra test test cases but also would include like u the ef version. So my main concern right now is that we I would like for us to have a DevNet one uh non-breaking release because I I I wouldn't want for us to make a release that is neither compatible with uh DevNet zero and it is not compatible

either with uh with DevNet uh one. So what I what I want to like um um get get um finalized today is that we have every breaking change um merged into east um either today or in the following days would be that would be great. So if there's any open that we need to merge to make uh full compatibility with the net one even if there's not uh if there's missing coverage that's still understandable. we we will make another release with more tests, but I don't want for us to to make a release that uh that is incompatible uh with the one. Um so yeah, that's that's the current

state. I think uh Peter uh from IPS already told me about a couple of PRs that I will get to review today and I will prioritize to get the merge and uh yeah, basically if uh everything is in place today, we can we can make the release. Otherwise, tomorrow uh we'll try to make the release. Uh but if there's anything else please just reach out. Um yep that's current east status. Okay. Yeah. Um what's is this correct that the only major change is eX create EF bootstrapping?

Uh well there is a PR the PR that we mentioned is uh one that tests removal of create EF creation transaction and um and uh also it is contingent on the uh substitute which is the legacy DX create which is not the chosen sort of baseline but we will we will be discussing this in later in the call. So if we choose that baseline then yes the PR is uh you know it's main mostly done but needs some polishes but if we decide to pivot then it might not be able to be ready today

or tomorrow right so the changes so the um ext changes are committed um simplify EMF create to new address hashing is committed committed um and this is using the 32 by uh address for ASC for address base expansion correct um change kind data from 04 tof um container size to four bytes and there's some discussion on um discord as to why we need this and this is so we can make contracts bigger than 64k and modify max stack height of all sections be max stack increase in that um I think that was the last PR that went in just

last week yep so it's these two that we're currently um going to get resolution on. Well, the TXre uh is also committed and the legacy TXE uh tests are also committed which is the baseline bootstrap solution. But what is not committed is the removal of um the last line basically and and the removal um has the consequences of changing this these blockchain tests which are generated from UF tests which require some some method to deploy UF code.

Okay. So yeah, so that's the only part that's actually um well undecided yet could say. Yep. And that's on the agenda. Cool. So, if things go well, we'll have um a published set of tests by the end of the week or beginning next week, right? Yep. Okay. Yes. Any other testing notes? Next week, I'll be starting fuzzing. Um once people start getting success on the tests, I'm updating the

fuzzer. Um it surprisingly I had some some dependencies on on the container structure which makes sense because we're fuzzing to the container. I'm currently updating that on my branch and I've also brought it up to date with current um EFT code and the current EES code. So I will get updates on that in two weeks and you'll probably start hearing from me. I'm going to start finding findings. Um I won't be too aggressive in sharing findings until your client is um passing all the published tests. Uh because that's the first thing we do is you run the publish test and the funding that can be instant discoveries. Anything else?

All right, let's go to the compiler and client updates. Never mind. Um, up to the latest DevNet Zero test, um, there was an initial bug with the spec trains around ambiguous contracts, but that's not fixed. Uh so I think it's is it 22 version?

Okay. Um and the devet zero is now merged to our master branch and one that's still being worked on. Okay, EVM1 I don't think we have a lot of updates uh um except the removal of of creation transaction everything I think it merged

master now as indefinite Yep. Okay. Next is wrath. Um we had one bug on definite zero tests that is fixed. Um yeah, we only run state tests and EF validation. I still didn't run blockchain test on deet one. Uh I'm running uh the test suit that Pavl created. Uh I have few failings for most layers totx create. So I'm close to finishing

that. Um anyone from G on the call? Um, EthereumJS. I know from mater ES actually I should have been

eels. Yes. Uh on the E side we've uh got uh we are passing the version 2.3 of the tests and uh we've got PRs up for uh TX create and pay off code of good because a couple of behaviors I think are still not uh determined but we've got PR up for the latest back whatever was updated. Did I miss that? Did you have the rest of CX of Devet one ready?

Uh no uh rest of the net one like DX create is the missing rest of it. Okay. All right. Basu. Um, then yeah, you go. You go then. Okay. So, um, we had the same bug Ref had, but it was fixed in main, so I just merged it into, um, our UFDNet one branch. Um, so we'll be working on that and CX create. There's um some gas differences that we're going to be researching, but again until we get resolution on bootstrapping on final

form um you know that might change dramatically. But those are um those are the the current state. Um also want to bring up the the pay codes. Do we did say we wanted it on devet one, right? No, we going to do two. Oh, okay. Okay, that's not true. But um from what Charles mentioned on it magicians um I I we we have not yet made it available to the legacy legacy VM. Um not sure if we

want to go that way or not. Should we discuss it or not? Um yeah, let's go ahead and add that. Let's do that first. Yeah, but Charles is not here. So, Charles is not here and that's going to be part of what what my ask is going to be. Yeah. Okay. Anyone from Aragon? So there's no one here. Um Racy Techch

did get a hold of me. He has a fork of Aragon that he implemented EOF in. Um but there's some complexity as to Racey Tech's um relationship with Aragon right now that I don't know the details of and I'm okay not knowing. So, we'll just leave that there is a fork that has the info. Um, and Aragon, they'll see where they land with getting support for this in the future. Um, compilers. Did I miss any clients that are on the call before I go to compilers? Good. I got everyone. Uh, compilers. The first is Viper. Anyone from Viper on the call?

Okay, solidity. So basically is proofing the work forward. We have a bunch of pending pull request from him finishing the implementation of the lowle optimizer and you want to get that out in the next release that should go out around the time of spectra. And yeah, this is pretty important so that people actually get like small bite code and like don't complain too much. So we'll be prioritizing that. Other than that there's also his uh PR enabling Elf create in assembly though actually discussed that today and like the issue is that like just enabling it doesn't um solve the problem because

like the use is basically deploying like custom container for example like either custom uh just custom bite code or even like lowle so that will actually require like some more features in the compiler. So we'll like uh merge what's radic implemented but like to for example make like something like a compile properly with all features will require like a bit more work after that. So that's basically it. Um, how are you handling creation salt

end? Uh, I mean we we're not doing any translation. So basically I mean currently in this our prototype is still using the version that still had like the init container half there. But like when we switch to the more current version we basically be relying on user to provide salt and we'll block creation without salt provided and you will use the user provided salt as is.

Uh yeah. Does that correctly summarize it? Um I mean like there won't be default sold but yeah we basically use provided sis right. Any other compiler teams or

questions before we move out of com um client and compiler updates? Uh sorry follow up on the previous question. I was reviewing my notes. Um I just want to confirm. So this uh use of the salt as a result um new full salt right. Oh sorry let me paste this in the chat to be clear. An expression like this um provides different security guarantees depending on legacy target versus eof target.

Um yeah I mean like on legacy you have uh still have the um the init half and argument half on UF you basically on the salt and you have like to on on your own kind of like figure out what you have to go there because like we can't really provide anything that's like really equivalent or I mean even if you could like it be like very expensive. So the decision was basically like to leave that up to DAX. It won't be like dropping replacement anyway. So not necessarily worth trying.

So I I just want to um make it clear I don't think this is a good idea. Um I do think the we we need to preserve the semantics. They shouldn't change depending on the target. And like is proposal what you propose or like some have like some kind of row salt parameter and like that's what I said before. And and the default is like in in this expression when the user passes in a salt in order to preserve the the security guarantees you would need to hash it together with the um the hash of fu. Right? So you would emit a hash um to do

that. and um and the input as well. Right now you you see that it's expensive and it will be a little bit expensive but if you provide this um escape hatch right by using the raw salt anyone that cares about that would be able to escape that. this would be I think the best um decision to make and like maybe I don't know maybe in 0.9 this could be changed but it just seems it doesn't seem like a good idea to to make it be so significantly different in in in 0.8 eight.

But I mean like for example that's not even the only difference like you don't even have have like nons. So even if we do that like deploying things twice would still like give you the same address. So kind of it's kind of like feels like a just half measure. So well but it's very different to say like full full like it's very different to say that new expression without salt doesn't compile in eof target that's fine because the just the code won't compile but if if it does compile and it does something that is not what you expect coming from legacy that is what I find concerning Just a note about the that the T um

sorry the EF create doesn't charge for the hashing anymore. So if you charge for it um it's not uh it should even itself out I guess. So I mean it will be cheaper. Sorry again. So you mean it will be cheaper than the older than the legacy creation? Well, the row salt one will be but the the salt uh the equivalent salt parameter new expression that Franjo suggests would I guess be um uh the same cost as as the legacy one roughly give or take because you know

you need to push some stuff around but u but the hashing itself um of the init code would be done would be charged for once in both cases. I see. I mean like to be honest like opinions are a bit divided because like I personally I wouldn't be like really against like doing something like salt but like Daniel is really strongly against it. So if you're like strongly in favor of that maybe would best like to come out to our team call and like talk to him directly because like I'm not like strongly convinced that this is that

much of a problem but I'm not strongly convinced either way but he like he's the one you have to convince basically I'll try to go to to a call or or open an issue. Okay. Yeah. I mean if you maybe I would think to because like if you do that we'll also I mean also I also bring this myself on the next call like basically we had one today like basically two hours earlier so yeah we have some agenda for next week but I can add it and we'll also discuss it. I mean we discussed it because like like I said like kind of Daniel Duck didn't feel feel convinced. I'm not strongly either way.

So it's and that does. So basically we need someone like who is strongly convinced other way to kind of like have good arguments and like we can figure something out. Well, thank you. Okay. Um any more discussion or we'll just move to the solidity call. All right. Hearing no requests, we'll go on to the next step. Um, we're going to talk about spec changes. We added legacy up code support and eof bootstrapping.

Um, as was mentioned in some of the discussions outside of this, um, Charles was concerned about um, he didn't list any specific op codes. He's concerned about op codes only going into eof and no longer going into legacy. And also um Simon, not Simon Dudley um uh another person on Twitter, Rick Dudley. Rick Dudley. That's what Rick Dudley Rick Dudley was also concerned about um legacy not getting um features that would be fine in legacy like the payout code support. So um should pay go in legacy?

Um and here's my proposal. um it defaults to eof only when we talk about efon op codes until we get someone in the appropriate ETH magicians thread saying hey I think this would be useful in legacy can you please add it and that's going to be the signal that we need um from the outside that if we go through the effort of adding it to legacy that someone's actually going to use it and I think that's my my main reason right now for not wanting to add things into legacy is we could add op codes that'll do nothing more than increase test surface and if nobody's is going to use it. All we're doing is creating extra work. But if we get someone coming in into the ETH magicians thread, which is there's an EIP, they link to a discussion forum, that's the appropriate place we should discuss it

because it creates a permanent record of what decisions were made and why. Um, if it shows up in that ETH magicians thread, then I think we should consider adding it. Um, I haven't seen that yet for anyone do pay and I've explicitly asked Charles to do that and I don't know why it hasn't got in there. Um so that's that's my thinking. Uh weekly held willing to be persuaded against it. Uh what do other people feel? I think that's valid. Um it's not something that can it's not something that's prevented from happening in the future by not adding it now. So I don't think that's a problem.

There's one caveat which I I think raised in one of the PRs to the pay op code EIP is that the pay specifically the pay op code um has a problem of the return code. If it has a return code then it must either align with eof conventions or with uh for ext with legacy conventions for call or it should it would have a different behavior in eof and different behavior in legacy. So this is uh something that always we need to keep in mind that some opos if they are introduced in both they might have different behavior. That sounds like a bad idea.

Which one? Um to to to have them behave differently in legacy and and eof. I would just say like if it should behave like eof and you just need to invert it in in legacy code, right? Yeah, that's that's fine. I mean, just just need to keep it at the back of your head. It seems to be uh missed it uh quite often. Is the overhead only in terms of testing or like what what is what are the reasons not to add these things to legacy?

So at least for a client like Basu um the way we implement it it's just updating a table to allow the op code to go in in a certain place or not um as part of the fork. Um and actually actually basic has one table for eof and EVM and in the op codes we we check the version if it's version dependent. So it's either you know if it's like get has the two table solution would just be adding a row in a table and when basu has the one table solution um it would just be finding a particular op code and taking out the check that says hey I'm only valid if we're running an ef op code otherwise act like we're an invalid instruction. Um so that's the client impact. It's not that much of a change.

There might be some uh unit tests that they would update um depending upon how many unit tests each client writes, but we would also need to write uh uh EST tests, ETH tests um to cover all of the possible permutations of how that might get used. So that's where the real burden in a lot of these um changes are is we'll need to write the uh the the good coverage on EET, make sure all the clients pass it and make sure we manage it. So that's you know most of the burden is felt by east on this. I I don't like the concept

of waiting for a request to be made, particularly because, you know, there's always complaints about like how hard it is to to stay up to date on on EIPs and like all core devs, especially for quote unquote outsiders. So, that's the reason why I don't like this. um like it would be very easy um for there to be someone that would want it but just won't see it in time to request it. That said, I think it's also a valid argument to say that we want to reduce the testing effort. So, I'm not sure where where to stand.

Um, and that gets into the question, how much do we do outreach and and query people versus how much do we expect them to uh voice their opinion? And I my thought is logging into a discussion forum and just saying, "Hey, I'd like this." My thought is that's a low barrier. Um, and yes, there are people that are quote outsiders to the process, but I think this is a way to bring the outsiders into the process and get them participating and get their voices heard. Um, I mean, it's tricky. Do we do we do we do outreach only or do we wait for people to come to us? And I think it's kind of a mix of both we should do.

We should, you know, find ways to ask people, hey, do you want pay in legacy? Um, please post your findings to this forum if you think it should. Um, because I don't think we can design stuff on Twitter. I don't think we can design stuff on one of the many Telegram groups that go around. Um, just because request is made somewhere. At some point, we need to formalize that in there. If someone makes a request in Twitter and someone champions it and brings it in, I think that's fine too. Um but yeah, so the question is um for all of these op codes that we currently have in um eof, which ones do we bring in? Pays, I think, the highest value one. Um do we bring in um some of the other ones like

the data doesn't make sense? Anything with the medius doesn't make sense. Um, but feel like there are some others that might make sense that aren't immediate driven. They're escaping my mind right now. Ben, yeah, I just like to to repeat that not including it isn't an irrevocable decision. So if if it was desired after you know Tusaka it could be brought in the legacy in um Glancham for instance you know it's not it's not like um it wouldn't be too hard to bring back they'll bring

The the other ones that could make sense as far as I can tell are return data load. Honestly, they should be completely decoupled from eof my opinion and also the extra data load. That was the one I was thinking of. and ext that also brings in the thing where we bring be bringing in eof [Music] um yeah and this is something we could do in eof devet 2 to be honest so we don't have to do this in devet one okay I don't think we're going to reach a decision on this today and we need to spend a lot of time

talking about bootstrapping so I am going to time box and encourage people to come back with opinions in the next call and Camille's chat message I will read later but let's move on to UF bootstrapping this is the big decision we probably need to come to a resolutions today um to set the table right Now there are six ways. So so the question of bootstrapping is how do we get an EF contract into the current system.

Um we are on probably our third step of figuring out what the best way to do this is. The original idea was to use a creator contract predeploy. And the reason we're even having this discussion is because we were going to write in the cotales of EIP766 which was going to pre-eploy an identity contract replacement for the pre-ompile at slot number four. and to bring that in and all the heavy work for getting three deploys done was going to be done by that contract. Um that has been moved out of scope for PCRA so we can't do that. Another piece of the puzzle we had was something that we added into PCRA um when when EOF was still in PCRA to deal with the absence of the TXRE and the creator contract EIP7698. Basically we took the old

legacy create transactions um of type zero one and two and we created a semantics where we had ef container and after the ef container you had call data um both of these are intended to be uh sunset um and uh so we need to figure out how we're going to do this um 7698's not it crosses too many lines and creative contract we can't do currently in the spec our solution is at CX created to legacy EVMs. So, we're opening that door of putting um stuff that's not mandatory requiring container into the to legacy contracts and then that allows us to do a creator contract in the current

invogue method which is to do use next method to deploy it in a certain location and use that. So, we have a creator contract just not in a nice pre-ompile location. Um there have been some questions on discord which brings us to steps four five and six which is says maybe we create keep crazy legacy maybe we don't but what what what the people asking for this really want is to have the same 2.ill handling in the nit code transactions and options four five and six outline three different ways to do this with different implications on the address creation logic. So that sets the table um for some of these for the pre-eread. And having set the table, I will open it to anyone who wants to discuss and express their

opinions. Can can we what is the reason for uh limiting the length of init? Um the option four and six I presume right this is to avoid the the the logic to choose which init code is meant to run because there's because the you know it it could be the first one but but um I mean it's kind of cleaner to just restrict it's not really mandatory I guess. Yeah.

Um but it's it seems to be like I mean one could invoke a second TX create like a you know invoke invoke a TX create inside that that first init code and try to deploy some other init code. I'm not sure if that that's a valid use case, but it just originally it felt cleaner to just restrict it uh to one, but it's not it's not set in stone. And in option four, what would be the the resulting address? Oh, I see. It's like um like a creation transaction nonspaced. Okay.

Or four. Yes, that would be uh because there's in in the option four there's no no way to um specify the salt which you would like to use. Yeah. Um there's there's an opinion that um I mean while the options four, five and six mainly five and six I guess um four has some problems. So so options five and six allow uh two features which I think were asked for. One is uh that the what the creator contract

offered which is the multi-chain deployment support which sort of as a byproduct got better because we had the the creator contract deployed at a um specific address um predeployed uh to a specific address uh and then um that could be used for for for convenient multi-chain uh deployments without the next method and um so so option three doesn't support this and uh and the other the other feature is that was asked for is that with option three we don't have a default

deployment method that we just work uh from block from the first block of of Osaka uh because with the legacy TX create trick which as D said we need to deploy the factory first. So five and six they don't include the calling targets address in the deployment do they? Sorry I'm sorry very much can you repeat? So option four includes the the the sender address and the notes um RLP encoded create the address. Options five and six do not include the sender address. They only include the content

of the contract. Is that intentional? Yes, although it is it is it might not be well thought through yet. It is uh quite fresh. The reason is because if you include the vendor then um if you would like to have a stable factory deployed um using this uh method then you need to have a a particular address or a private key. uh you either use the next method or or you use a particular private key that you need to keep around uh to make

deployments on other chains and I just realized this getting rid of the sender allows you to at least u liberate yourself from that from that particular address. So I realized this just now rather than last week when we first discussed it but five and six can be frontr run and if your contract depends on sender for security they front run you and steal the contract. Yes, I mean this is this is the discussion we had while while we were discussing the creator contract whether frontr runnable um whe whether this you know multi-chain support is more important than the frontability or front running protection so to speak. Uh but in the creator

contract we had the we were able to solve this by having a flag while here adding a flag uh that would I mean that's still an option but that would complicate the logic even more. So I personally don't like that very much. At the same time you still can and you know it is expected that with this method five and six you could deploy a factory which does protect against running. So if we're talking about bootstrapping then also you know there's this assumption that this is not going to be

u the only uh deployment method that is used uh in the wild. But this will be the default one that will be accessed by people using native facilities. So I kind of think we have an obligation to have the most secure with default mechanisms. Yes. But if you include the sender then sort of you cannot unincclude it later. So whatever factory you deploy with this will have the address dependent on on sender and u that is kind of problematic and I mean like the overarching comment I would like to make is that those ideas four five and six are pretty fresh and um there is the sentiment that

free is somewhat a safe u safe option because you we don't really commit to any behavior of the two nil transactions initial transactions at this point and if there's need this these still can be um uh introduced later like for example even today I think we had two more ideas of how we can bootstrap or you know do this like alternatives to six which is we can have a new we need code type two type whatever we it which would just be a nice version of six uh with proper fields and no no um no

parsing of the TX data and also there was another one which I actually forgot now oh that we could have it a default field uh in the init code transaction which is sometimes used sometimes not which is also maybe a bit cleaner but not really so I mean the gist of this what I'm saying is that we have I mean this is maybe too early to commit to any of these solutions and free is the is the safe option for completeness. I also sent another option in the chat which I gather is that nobody likes it but I also think it's quite simple.

Um it's just uh in code transactions with two nil uh run the data as legacy code and then you can use that to create uh to to trigger tx create. Yeah, we I think we were we had this on the list but we dropped it. Um the reason being that it it seemed to be the worst of of all these strictly because u if you run this as a creation transaction you need to somehow um end that and presumably would you would end it with

self-destruct which is ugly and you lock yourself lock the use case into self-destruct being there in legacy. And it also locks into locks you into legacy VM in general. U can you clarify the the the asterisks in in multi- chain support in four? I I don't understand that yet. So it's it's uh explained maybe not in full in the features section just below. Um so I think and someone will correct me. So if we have four that means that we have a in it codes transaction with

a2 nil field. Um but uh and that would be the way say we let's assume that we want to use that kind of a transaction together with the next method to deploy our factories. Mhm. However, as far as I know, next method doesn't work for type u other types other than zero crosschain of course. Oh, so and the initial transaction as it stands now it's inherits from type 15 59 or type two I guess type one I don't know. So I think unless I'm mistaken somewhere

here, you cannot really u use mix meth method uh across chains. Yeah. Yeah. The problem is the chain ID. Yeah. Yeah. Exactly. But how would the other ones be better? I mean none of these none of these uh solve that, right? I mean, no, no, no. They solve it because you don't use nick method because you don't include the sender, but then it's front running. Exactly.

Exactly. Front running vulnerable, right? Yeah. Yeah. I only now understand the whole spectrum, so I'm going to need to think about this. But it does seem like none of these are nice. Exactly. That's that's kind of the the big point. regard this front running issue like is it only about like someone front running and deploying the contract or like actually being able to overwrite your contract that you deployed because like it doesn't have sender then kind of like anyone could just redeploy it

from trying is just I think if your init code doesn't depend on the sender or the value that you the endowment value that you send in or some other maybe fields of the transaction then the front runninging is just a weird surprise because you know you but I mean like you you need code to like make external calls or like do something that to deploy like something even if it's the same it could deploy something different I guess Yeah, it could but that would need to I mean the front if the init code is uh doesn't depend on externalities that can

be manipulated then I guess the front running doesn't change anything so you get the same result at the same address end but if if you call something that will check tx origin or you will it will check the value and um somehow alter the behavior of the init then then yes that could be u that could be bad. Okay. So basically I mean like it's up to you to like make sure that's the case and if not like uh I mean that that there are like some valid use cases where you kind of it wasn't meaningfully overwritten.

Uh there are use cases. Yes. Like for example, if we were to deploy the creator contract using this, the creator contract just you know deploys very simple bite code. Uh so anyone can do this and the result is always the same. Okay, I think I get it now. Thanks. Ben, you have your hand up. You're muted. My t-shirt is getting

outside. There's got to be some sort of birthday paradox of mic issues in Zoom calls. Like the more people you have the more likely it is, right? So, uh maybe while Ben resolves the mic issue, the question I think is whether we can allow ourselves to just stick with three and not have the these two features um in Osaka or at least in DevNet one. um how would that adoption of UF and whether it's it's a big issue or or or we can we can live with it.

So the idea would keep TXre forever in legacy and consider for DevNet 2 or a future fork four, five or six. Is that what the question is? Well, four, five or six as we said, nobody really likes them too much. So any any either a two nil design or a new transaction type maybe u would uh would deliver these two desired features and that could be the net to or or the next upgrade and now the question is whether we can wait or not. So we would add two new transaction types or would we change the transaction type?

So I mean the other like the new new transaction type is um maybe justified because it would it would avoid all the overloads that we are now discussing in options four, five and six and uh you would just have one init code uh field. But coming from the testing implementation perspective, a second transaction type is not good. I know but I mean you have a lot of testing surface in options for four, five and six as well. So there's there's more testing

surface in the variance, but there's also two different transaction types to be fuzzed and to have code paths to decode. It's not a low lift to add a new transaction type. No, that's understood. But if if you have like some for example take five for example or maybe six uh interpreting TX data like dividing it and then um that's like a whole new abstraction that none of the transactions do right now.

I mean the UF creation transaction did that but it also was um ditched for among others for for that reason right. So avoiding having to parse the TX data and have some custom behavior based on that is is also a a good thing. I mean based on this discussion it almost sounds like two is better than four, five and six just leaving two in. But two also has the problem of non being nonspaced. It has the problem of this TX

data hacking and it has all of the um same security features of existing transaction types too. All security problems and security features. So the advantage there is not much changes. I mean, if we're picking if we're picking which pain point we're going to feel, it's almost tempting to say the pain we're feeling now is pain we're familiar with and we know how to deal with rather than introducing two types of pain. Ben, is your mic working?

We cannot hear anything. Okay. I I agree that two sounds better and you would be able to use Nick's method at least. So, I don't think we're going to come to convergence in 3 minutes. Uh, and I'm not sure running overtime is going to bring us to convergence either. We I mean I mean just just just to make it clear because you have sort of took me by surprise with the option two now.

Would you say that what you what you're saying is that to have al both tx create and the creation transaction we are having tx create and initial transaction for also a different set of reasons which we discussed a couple of calls before. And if we have that code, if we have that then having I would argue that having legacy TX create is much less uh painful than a whole um behavior on the which is UF creation transaction number two, right? because you could you could deploy a legacy tx create from the existing create two stuff that's on most chains with which has a known to hold

right so but I guess back to the point I was making I don't think we're going to get a good answer in the next two minutes should we schedule another meeting in a week do an off meeting week focus just on resolving the eof bootstrap issue and our action right now is to keep three as is pull two and next week we could adopt four, five or six or change two. But for the purposes of getting tests ready, um we keep three, pull two and discuss next week if we change from these in two weeks. In two in one week, we discuss it next Wednesday. Sorry to to

pull to Does that mean to to um Can you clarify what it means? So right now 7698 is in there. You can do a create a new contract from a type 01 or two transaction. We would get rid of that feature and we would require people to go through a CX create transaction which we have a test ready to go. So we could kind of get a feel in the next week for how it would be whether we need to add a replacement for two or keep two and three. I mean, I guess what I'm saying is we don't have enough data, but we need to do something to get tests out to get clients moving forward. And three and three alone sounds like the best way to get people moving forward.

Sounds good to me. Hey Dana, could could you put all of those comments that you just said in the in this uh in this note just so we know what we are trying to resolve and come to conclusion next week? Yeah, I'll save the transcript and sign and synthesize it. I have um some notes in here that I've been taking, but I've been participating more than taking notes. Um but yeah and I'll add this to the notes for the discussion we'll have um next week but to get these the the beta of the DevNet one tests out we'll assume the answer is three and that's subject to revision but we can get tests

out all the other breaking changes are fine it's just the um contract creation bootstrapping is going to be impacted on the tests and I think that's not the best place to be in but it's better than waiting a week for tests, I think. Okay, we're over time, so I'll send a update um to schedule the call in a week, same time, same place. Um uh thanks for everyone calling in and we'll see you in a week and let's continue this discussion on the Discord um and in um the TXrees ETH magicians thread. I'll also post that here. There. Um, all right.

Thanks,