EOF Implementers Call #39

Transcript

all right welcome everyone back to the UF implementers call today um I don't actually know which number we are because we stopped tracking on uh the PM repo but he must be around like 35ish 36 let's start with the client updates um Deno you're first on this list uh so please go ahead sure so um over the weekend I started implementing TX create um there's a lot of overhead in creating a transaction for this so I want to bring that up as a uh issue um after we go through the client update but it's um there's there's a lot of moving pieces

to bring in a new transaction type um that yeah and I I'm still not done I still don't have it fully implemented the things still wiring things through it's all different locations on the client so that's that's the status of Basu um that's all the changes that happened from last week all right let's discuss the transactions after the round uh dragon do you want to go next yeah uh for my side I was most focused on verification of UF I'm passing a lot around 80 90% of the vector test that are on ethereum tests so yeah I'm mostly doing that I see that some of them are not updated

and some things are missing but yeah yeah going through them that maybe I have one question about that what's the basically the newest spec newest uh spec on the ethereum test I saw that there few PRS but we can cover that later um sounds good I was also um yeah going to was just loading the Readiness Matrix um so wanted to ask first you Dragon if the riness Matrix reflects where you are and then also Deno it should probably be updated some

of the things are working in progress some of the things are there but not well tested but yeah it should be updated that most of the aips are in work VIP some of them are even considered maybe done I update that this after the meeting thank you that sounds good U Daniel um yeah let me finding it again yeah it's correct 7620 is still under construction that's TX create um caveat I you know this is depending upon updates of uh testing so a thumbs up doesn't represent uh fully tested because not all the reference tests are written yeah sounds good um all right

Epsilon who wants to give the update on evm 1 uh please go ahead uh we have merged X calls and we have merged evmc changes required for TX create and so the final things left are you have create and TX create which are already but still not mened still one you that's and is the Readiness Matrix reflecting this so Readiness Matrix says 70 7620 is under construction everything

else it claims to be done yeah I just pushed the update before the meeting it's correct uh awesome um all right Peter do you want to give an update on the spec uh yeah terms of the spec the E update for 7069 the axt calls was merged last week and I think that's all the 3540 and 4750 are still in review and 5450 is U I think it's tail right now and we're sort of I think

preparing to to Pi of working on it and that's it and we have a bunch of discussions on the specs I think today maybe later uh all right um yeah thank you Peter um so we have Alex on the call I'm not sure if you're working with a client but uh feel free to do a very short intro um if you have a working mic uh yeah hello um I'm sorry for joining the call I got a a link from your Vice I just wanted to learn more about the EF uh for the purpose of like how it can be used with our work on

account abstraction sounds good yeah let us know if you have any questions um during the discussion we're GNA have in a second um barab bash do you have any updates from the devop side I think we we have some updates from our side um I'm ready to test whatever you guys have if you have a working Branch I'm happy to se EV for E all right sounds good um well we going to see on this call all right let's start the spec discussions um Peter I believe you do have a list so maybe the

mic is over to you then uh yeah so there's a bunch of of discussions that have been happening on Discord I do have a list uh um maybe I'll just run the list quickly and then we can pick something that's we find most important so there has been a discussion about TX create less eof which I think resulted in not pursuing this idea because TX gr has a valid use case uh and now there's this actually an original discussion that the TX create L one uh spoff of is uh whether we want

the irregular State change for the Creator contract or some um Le Legacy like deployment facilities uh for Eos to appear in the state for the first time because then um then on like the Assumption right now is that only eof can deploy eof next uh we were kind of I think we we had a discussion about status codes uh from EXT calls last time we were supposed to do a write up of the current status of the status codes which I think we don't have right now so maybe that's not a

good time to discuss and um then there was a suggestion that we have more strict init codes transaction validation rules from Dano was specifically that there was supposed to be no empty init codes and no lacking init codes or empty array of init codes in the init code transaction that was Dan suggestion and then there's the ban origin thread as well and then there's the thread that we might want to V validate containers um to split containers during validation into init containers and runtime

containers as we call them and the first of them can only all return contract and and the other kind cannot we we can validate this during validation with some limited um difficulties but I think it's a viable suggestion so any anyone wants to pick a topic maybe I'll just um paste this list into the chat so that you can see it um maybe I would suggest if we set aside like five minutes for the status codes then we can finish that probably a

transaction creation discussion is going to be going going to be a big one um let me fix this I'm fixing this pretty quickly um so regarding the status codes we have four four topics okay and Status Cod actually I just Dro status codes because we we don't have the right up already okay yeah that was my go ahead if anybody wrote it go ahead Alex I I didn't C that is my mic not working no no no I I was I think we talked over each other

yeah I was talking about the status codes and I was going to ask if anybody did the right up not that I'm more aware of I think I think Pavo wanted to start it or kick it off but then uh I think uh he got involved into something else he's not here today all right should we start with this uh Deno suggestion no empty init codes field maybe we time box it to 10 minutes I I want to give like 30 minutes to the Creator contract Legacy stuff because that seems to be the biggest most important

discussion yeah so while implementing the um the init code transaction I was comparing it to some of the things done in the blob transaction some of their validation rules one of the rules they have for validation for the blob transaction is it must contain a blob so people don't try and use a blob transaction to try and sneak regular transactions in that don't have blobs you know that was one of the ACD decisions so to to correspond with that uh the proposal would be to require that in init code transaction have at least one init code section and that each init code um be at least length one or longer so we don't have an array of zero length U an array of one zero link the NIT code would be an invalid transaction um so no no it code

list would be invalid a list of that is empty would be invalid and a list containing an empty init code would be invalid so all the init codes need to contain actual init code and there must be at least one is the short description of how I would think a valid transaction now as far as validation um they specifi there is no concern about validating the exact body of the eof so it could be any random bytes um and we can still validate the transaction and this is a very simple rule that could be implemented um a transaction handlers without knowing anything about the evm or eof so I think that would um improve it without putting UND du validation rules on those who don't care about eof and need to process the

transaction anybody wants to bring up some opposing points uh I I like the consistency argument and and like all the arguments I think are I had this small um issue that uh we we we allow 256 of these init codes and like all but one can be of length one and then the last one is empty is that no way to be a a problem and I don't know if 256 is too small a number for this to be a like a a problem

that this is going to be too much work to do during the transaction validation it shouldn't be a process it should be a problem at all I would think because okay consider the situation of a large call data one you got to read the call data and read through all the btes to the end um here you might be doing 2 56 stream interruptions um and get the length of each stream Interruption and make sure it doesn't exceed the um inet code size and make sure that it is at least one so we're already checking each of the 200 potential 256 ones to make sure that it is not larger than the init code which is already written in there so that's just another check to make sure that it's at least Z it's at least one are we

checking the length of the init code at that point yes it's written in it's an invalid transaction if it exceeds the init code at least I soon recall let me let me double check the text I thought we check it once it's invoked with TX create but I might be wrong we also check it there okay is this in the meas spe yeah it's the first rule of transaction validation inet code transaction is invalid if there is more than Max and N code in the NIT codes or if any one exceeds Max the NIT code size all right okay so the proposal

there would be to say or if link is zero and then another bullet point item saying that there must be at least one entry in the NIT codes okay then in that case my my issue is is void and there's like a meta issue um that's not in the spec that is more operational um clients like get won't gossip transactions larger than 128k although transactions larger than 128k can show up in the chain um so um that might be worth calling out in the spec

but it might not be as a security consideration makes sense sorry what do you mean by this it's it won't pick it from the men pool or won't transmit it in the men pool it won't transmit it to any other men poool other than its own so there's a mode you can switch get in um if you submit it via RPC to its men poool it'll accept it if it's larger than 128k um but it won't gossip it out so this is kind of an issue for some l2s posting l2s are fully aware of it so

they limit their call data so that the entire transaction it's less than 128k but now it's completely moot because everyone's moving to blobs and I think that's where the 128k number for blobs um became attractive is because it's already established in the clients so that means if if we still have well actually the init code limit is is double the um double the the code size limit so it means there there can only be like two and a half contracts before we hit this limit full contracts full contracts sorry Two And A Half full contracts and then you got to consider and a half full unit codes yeah the gas

limit of the block um is also going to provide some realistic limitations on that too because I think uh the initial contract limit um was six uh six Mega uh six Mega Gas um was what the initial 24 4K limit would have done so it wasn't an issue when they first proposed it so um yeah you would quickly you could only do three full contracts in a current block or or five if you're going to you know go into the extra space so there's already ergonomic limits to the maximum size of what you can do in this anyway and I think the 256 size was initially proposed when TX create was going in Via index so that also didn't make any sense to have anything more

than 256 yeah so my question is do we do you want to stick with the two 256 limit or it's kind of pointless and we want the lower limit or we can just ignore it as long as we document this uh this effect um if we do a limit I think we should limit the size of the entire transaction body so maybe we say the transaction body can be no more than four times the maximum code size or 128k I'm I'm not sure which um right because if we use 256 as

the max you can make a transaction as large as 12 megabytes which is gigantic yeah it does seem like it's kind of pointless if it you know it won't be gossiped well conscious about time I wonder if the next best step is um since you're working on this if you would um maybe come up with a proposed spec change for next week and then we can agree on yeah I'll post it awesome um all right should we any other comments before we move on okay um should we try to discuss the

validation question regarding return contract um but we can we have to time boook it to like eight minutes so whoever proposed that I don't remember who proposed that I can say that I I think I'm more in favor of this uh I'm sorry my head went out what was the what was the question again the return contract validation during UF validation so that you cannot return contract from a container which is not used as an init container that was

Charles that was Charles but I think this this this idea also floated during Istanbul or somewhere I think I'm supportive of this is it in the vein of [Music]

um without getting any real return value um I think a simpler one that containers can only be referenced by a return contract or a eof create and not both I think is a much uh more sustainable approach to get this gold that you can't mix them up but also there's a functional thing that you can't really do both I mean I there's a lot of effort for for a harm that I'm not even sure is well articulated this was this was Charles pushing for it and I you know he's not here today give a full defense on it but like I I I don't want to upend the validation process for

harm that we're not even sure exists but I didn't quite follow you would you would have a simpler validation rule or just not have it at all I would have a if we have a either either no validation rule or a simpler validation rule such that um a subc container um all subcontainers must be referenced by either return contract or eof create and a subcontract um can only be referenced by one kind of instructions it can only be accessed by E create or it can only be accessed by return contract so you can't mix them and everyone has to be referenced but then you don't go inside these containers to see whether they use or

not no okay no okay got it oh that works as well um yeah I think that works the me also seems like a complication of validation we'll have to have this Global list of like which instructions reference which subc container like Global across sections validation MH right so it's going to be one array yeah for the entire code validation for the whole subc container um it takes one of three values unreferenced um eof referenced or return contract

referenced so yeah it does require a new Global state but I don't think the overhead is terribly high and I'm also okay not putting it in if if people feel it's too much validation overhead too but if we need to if we want to verify that subcontainers are used we're going to have to track this somehow so in addition to making sure that the subcontainers are accessed only one way this is also a way we can guarantee that there are no dead subcontainers yeah this makes sense it seems like

we're kind of um against introducing these rules main reason being simp just not complicating it that's the conclusion I'm cool with it yeah I think if we don't get rid of these uh runtime checks for return contract and return and stop then like I think it's not worth it to complicate the validation if we do have these checks then what I don't like is that like sub container validity depends on the outer container instructions so validation of sub

container is not isolated yeah that's that's his smell yeah okay I'll make a note of this and uh and then there's going to be some updates to the rational section in the create EIP and I'll just post it there and if there are no more comments I think we can proceed Al yes uh I think we do have the 30 minutes for the

either contract L CF um yeah I'm not sure who wants to lead the discussion but um yeah Peter Deno but please uh get started I'm making notes right now so maybe some I'll go ahead and start so this was something the thinking that came to my mind is I was implementing some of the TX uh to create and trying to go through the final flow of how uh stood up test that would work and um what I realized is that none of the tooling supports getting eof contracts as specified um because when you do a create contract in like Foundry or hard hat they don't know where this they'd have to write an

entirely different flow to do a um a contract call to deploy an eof um which seems kind of counterintuitive that you have to send it to a magic address um it's definitely away from the current standard of how you deploy Legacy contracts um but I think the reason we got to this place um was because the the desire to get rid of um code introspection we wanted to make sure that none of the eof code ever hit like call data or memory or return data we were trying to pull that completely out and so we swept all the places that include at the time um the Legacy create um the the not legacy the existing create transaction the create modes of transaction type 0 1 and two um I think

three's got great no three can't do a create mode um but my my concern here is that because the tooling um doesn't support it that we're going to possibly meet with Market rejection with this if we change something unnecessarily and I think the engineering compromise to use the existing create mechanism isn't as odious as it might seem so so my proposal would be to allow for eof to be added in a create transaction for type one two and three transactions you just put the entire create and the call data and so that starts up um when it detects the EF right now um the contract create transactions when they see something start with an EF they just shut down the whole transaction that's invalid that's per the uh 3 3451 rule um I think that's

the one that comes after the initial eof container but where we were reserving the EF for eof transactions so when you see the EF you go to the same creation flow that you would do You' start up an eof um you'd validate the container um you'd start a frame with eof and nit create um but you would not put any of the code in the call data you would just execute it all as a nit code and so that would require um a couple of other changes in that we accept any added data on the end to also be considered part of the container so then we would need to rewrite the container as though that was added on in Ox data um implicitly um so whatever you paste on you paste on a code like a um code that would be the uh be the pair contract and

then you would append your two addresses for the pairs there with and so we would see it's an EF start with the process um we would create the same message frame as though we were doing an eof create at the root level that just would be apparent this is this is very typical for the way the evm would work um and then we would just set no values for call data and the call data would be the init code and we would rewrite it so that it's valid so that the data that was added on it the end was added on as though it was Ox data and we just update the data header size and then would execute it from there um so they could take that extra data and they could use that um or we could have the extra data at the end of it be call data is another

approach that we could do they could access it via call data in there so Peter uh yeah I I I think the the way to supply data into this init code execution frame is it can be much can be simpler because the init container has the data section and this right in it code can just do data load right so yeah so yeah we could just do that I mean the compilers would need to be aware of that and know that it's going to be added on AO data but they're going to need to be aware of that anyway for eof creates as well so it's it's code you're going to have it's not even a data because you don't need a special

rule for validation and like the structure of the container is just the what we call like I think this static not even static like the the the the data section that is always in the container and it's in sync with the data section size field in the header so it's it's just a place to put data in and you can use it it may not be fixed sized imagine you're creating a dow contract you're having a list of people who are authorized to be admins um that's a dynamic array so you won't know when you compile it how long your data section needs to be but that's the deploy container and that can do all these Oaks data

anything but when you send the init code you can you know you that's the moment when when the compiler produces the init container it will know how much space It should uh you know Reserve in the data section and put their data there right right it would it would update the data section and execute it with that or we could have a valid Ro to accept it afterwards so yeah that's it can it can be done without much it can be done in code without having much disruption to existing tooling so that's my main motivation for wanting to make this um engineering

change to the way that the um create transactions work because I'm I'm really concerned that you know having to change to create flow is going toate result in huge Market rejection it's the very first way that they interact with eof and if they have to hop through new Hoops they're just not going to do it I don't think um unless we can demonstrate 20% code reduction it's not going to happen

it does make a lot of sense to to have previous or Legacy flow of creating new B code this would basically remove that contract that we have about youf create not youf create but hardcoded contract yeah just great yeah it would be optional like if you want to deploy many many many contracts in one swap two and a half contracts in one swap use it and also when you want to I guess I guess um have the smart contract wallet deploy

thing yeah so that's yeah the smart the the deploy contract is another thing that that has been tickling an allergy for The Irregular State change um since the Dow and seeing the problems it created I really don't like the idea of just randomly dropping State into the code as part of a heart Fork um part of it's because it's social political and part of it is because of practical um in that how do we coordinate this with layer 2s and um other ethereum equivalent systems they run all alt L ones um it presents uh a way for them to screw it up I've seen ethereum Classics screw up their Forks um so I I guarantee you that other people are going to script their Forks if we add more complicated steps in it um then just

activate a new set of rules adding new data people are always going to get that wrong as an irregular State change um and so you look at the contract you could say well maybe we could just do a type zero transaction and deploy it the problem is that contract invokes the eof create op code which means it's not valid under Legacy um which then maybe we would need to compile it under eof but then the first bite is EF which means it's going to be rejected so there's no way to get it on there of an irregular State change unless we again change this spec and change the rule on the uh 3541 rule it says anything that begins with an EF except for this specific contract needs to be rejected and there's you know just to get this on

there there's still a lot of special cases um and it's we have to make a compromise somewhere um either we have to make the make this contract allowable as a type zero we have to do illegal State change not an illegal an irregular State change or we have to have a different approach the way we do the Legacy um contract creation codes um and so that's it however we shake it we're gonna have to make a compromise it's going to be weird and my vote is we do the one that has the best user experience what our negative side of reusing Legacy create Legacy Creator section or maybe better question what

were the benefits of using hardcoded contract because I I don't see a lot of benefits by using current like car Cod Contra that we want to use for DS create so I don't think I'm the best one to advocate for the hardcoded contract since I don't think it's the best solution yeah I can speak to some of the positive things about it I'm not sure I'm the best Advocate

okay please continue did just discussion so yeah I mean one of the denefits of a hard-coded contract um would be we keep the existing rules in the transaction code um and it also makes it obvious which systems support eof because you can just search for that contract um that's also a nice signal but you know that gets in a fork introspection which is something that is also problematic on chain um it's useful to figure out if you support things like push zero or whether you support blob transactions um by executing those instructions and seeing if they fail but um you should know that before you

deploy unless you're using like viral style code being deployed out there that's the only reason I would see the need for um chain introspection yeah this we can still check that if the init code is like EF or not maybe it's not like it's different that having different type of transaction but it still can be checked yeah and uh this this whole getting extra data in is is where I was willing to pull the plug on big eof back in Shanghai because that's when solidity came to us and said um how do we write

these codes so that we can add arbitrary data as part of the Constructor arguments um fixed data sizes were fine if you say you have a pair contract with two pairs you just Supply a short eof contract and let the tooling just depend it like it always does um to to the calls um but as far as um a cleaner solution you know and that throws in problems we need do things like you have an array in the Constructor you have an array of contract owners or an array of initial nft recipients um so that doesn't scale up to more typical use cases um so that's you know we we uh in Austria we uh

discussed um you know some of the some of the options um this seem to be one solution but I'm still I I think it could work but I think it would be a better solution to go with Legacy transaction how would agree we probably still need TX create though yeah go ahead Dragon I'll let you finish yeah it's a lot easier to embed everything inside section pool uh P2P you don't need to have additional type additional restriction additional like um complexity that can be problematic it's a lot easier to reuse

whatever it is there and I don't see a lot of downsides of reusing I think the main benefit is that we all the band that bite that represent UF and that allows us to do something like but just to be clear that we're not considering at this point dropping TX create and init code transactions because they have a valid use case which is for the smart contract wallets to deploy arbitrary UF code correct I was about to say that yeah so that's that's we still need TX create so right now the battle is

between the irregular State change Creator contract solution versus is allowing Legacy transactions to e or Legacy like because they're not really exactly they they do not copy you know they don't they do not have code introspection this can be done like that but uh yeah Alex you had some can you reiterate the arguments you had against this what Dano is proposing CU I didn't quite on Discord yeah not fully sure what what

Solutions are being uh proposed the I mean the initial design faor having their create their contract uh also for the reason I mean assuming you know it would have a fixed address um that this would have been used across um different chains and that you could just send a transaction to it um but this was before the beacon block root contract uh was deployed which in the

end didn't happen to to be at the a like pre-compile style address and somewhat related but not exactly related to UF are discussions around pre- compiles um where there's a proposal to have evx and one proposal is that we can merge Rec compiles now and they can be later replaced by you know contracts potentially U using GMX instructions if we are not willing to make these kind of changes uh like

inserting pre-compile style fixed code that fixed addresses then that argument also kind of won't really stand um and definitely there is uh an example with the Bon block rout contract that it didn't happen at a precompile style address um I think this is the the guest of it I'm not sure what what is the proposed solution uh if you're not having this fixed address I mean the there's always the option what the beacon block route took that one would mine an address and that could also be technically you could try to deploy it on multiple chains uh with

the same transaction as long as you fund the sender um that's that's an option just the address wouldn't be you know pre Compass Ty um I'm not sure what other options are are proposed the option is not to to deploy the Creator contract at all and use this Legacy creation transaction with UF to to be an entry point that originally deploys any so for me the the question is how do we

get the Creator contract on there without um special rules um as written it's using op code Ed um which is the eof create and that implies that it's going to have to be an eof contract and if there is no way to get a contract if we can't use if we can't deploy that Thea Thea the existing uh create contract transactions um then there's no way to get it on there other than an irregular State change to say when the fork activates dropped this in a particular address um because we can't create a type zero transaction um that is chain independent to get the address out of that because it doesn't have the proper um address we can't use like micas or um

arachnids um uh create two deployment because the contract's going to go through a create 2 validation which is going to reject the EF beginning at the beginning of it so as's a chicken and egg if we could get that contract out there then we could use it but anything that we would do to get that contract out there would probably leave the door open would need to leave the door open for other people coming in or we need a specify that that door is only acceptable for the Creator contract um it just it it feels like unnecessary contortions to not just open it up to everyone so for using the Legacy create we had a proposal I don't totally remember the

specifics we do have an HD about this uh but it was kind of complicated and and weird to because basically in um in the the Creator contract and ORF we had well I think this was before the init code so maybe we could make it work uh this was before the um init code list in the transaction um but it was some weird um ways to um okay just one step back so what we have in in E we have um with the proper transactions we have a separation of call data and init

code and we really don't have that with the the Legacy create option but in the he we did describe some ways to to make it work um but it was still hacky I can try to dig it up I would be very interested in reading this but I mean I think the approach that is kind of floating it's not yet fully speced out is for the call data to contain just the init code and not be available during execution and then the call data would be substituted by the possibility to and uh whatever data is needed within the

data section of the init container oh I remember one other reason we really hated it because this basically me makes um code observable because once you no it doesn't I think I mean this was before the TX creat so if you still have TX create right this is the case yep the code is not observable because it the the call data is is just treated as as

if there was a like a magical TX create that pointed instead of the in it code uh field of an init code transaction it would point to the call data and then the call data just punishes at that point except you know that it runs the init code there's no way to access the call anymore how you canot choose SC data Lo well it's just that's what would need to happen for this solution um P mentioned that in in Legacy three oh wait maybe I miss understood what he

but we I think we can we can just erase this call data once the execution frame starts and if you call call data then it's just as if the call data wasn't there does it make sense I mean another option would be to treat treat the ox data as call data and append the ox data and also make the ox data into the call data but that might be too much we could just set call data to zero and require them to get everything from their data section and I think that's reasonable y Andre you are going to say

something yeah I think that works much sure um stepping back a bit I would say like this so the benefits of regular State change as I see it in deploying this Creator contract is so given that we anyway need TX create transactions so with this irregular State change we wouldn't need these Legacy creation transactions supporting eof so it's not we won't need to to transaction kinds that will deploy EF so it's like simpler in a way and in general just general argument it's we are not mixing Two Worlds we

don't deploy from some Legacy thing it only it's only EF can can deploy EF right so that was the goal of deploying this regularly and then like only using um why is that disallowed sorry we but should we just allow create and create to to create UF and just require validation to be done of that bite code that's created this will allow any Legacy or even Legacy section to create UF I mean that would mean code

observability right yep if you mean that uh cre create or cre to's init code does return to deploy yeah and that's what we want to avoid is people crafting an eof contract in their legacy code and deploying that eof contract um we only want um and this is for systems that use pre-compiled that would do ahead of time compilation or ZK compilation of this we want to make sure that when a when a contract comes in a system that it's gated by a trans action or it's already been known as part of a transaction so if we allow create or create two to create it then at runtime they might have an e contract created at runtime versus with allowing it either the

Legacy transaction or the NIT code transaction um then before the blockchain decides to accept that transaction into the system it can know whether or not it's prepared for that particular contract code and rejected at the time of the transaction versus rejecting it at runtime yeah and if inside the Legacy contract that means that some code are basically hardcoded okay that makes sense I wouldn't also say that what we are proposing is mixing Legacy and UF because such a such a transaction with empty2 and EF

init code sitting in the C no it's pure eof in terms of what it's being executed and it's validated as it's it's almost the same as uh if there was a contract with a TX create referring to a zero uh element of the init codes array you know just like a hardcoded very very rigid deployer contract that only instead of looking into the init codes array it looks into the it looks into the call data and erases it afterwards like would be a new

transaction kind then this because it is reality something very new could also be just to make it very explicit yeah but um it's like I don't know it's more psychological I think than it would still be the same stay maybe yeah simpler for tuling I think that's what mentioned if it it stays Legacy creation but I'm not very convinced they will have to adapt anyway with all the EF rules yeah I'm so I think the approach

with a type five so to speak which is which but but then what would be the two field of this transaction it would not exist at all yeah no because it's not needed yeah so it's also like a funny transaction kind and that adapting tooling to this would be would probably be a more problematic part Maybe so it looks like it's either a new

transaction C or uh irregular State change that's the dilemma and irregular State change happens once another transaction kind needs to be supported always I'm on defense about this I don't know as I okay go ahead as I got more information what's going on I seems regular State change is better way slight better I can't support any regular State change it's I I saw the M called caus last time

it's not something I can advocate for yeah but it's something already happened it's not out of scope it's very like sensitive topic because you can have very different like outcomes but I would look at this as deploying a pre-compile something in that sense if it's literally written as a pre-compile that's one thing um putting code in a specific address that's an ISC maybe then we could think about that in pre- compile and again pre-compile changes

the hard hat and Foundry workflow and that's where we're going to meet with Market rejection yeah but preop is going to be embedded inside the RM and they will just use it without knowing what what's weide so how is a a promine not an irre State change because you're not changing the state you're changing the rules of the system we already have set up these special addresses that are in the low numbers go to separate code there's no State set in there's just different rules for transaction processing putting in the the the code is written would be at a specific address um and it would

you know be executed as though it was evm code but if you specified it outside of the context of evm code and say it does this then that would be a pre-compile without specifying an evm code I mean we would need to approach it as nothing more than a pre-compile and by the way here is what the equivalent evm might be like um for it for it to be successful um but then they would want to have it at a hardcoded address it's and the appetite on ACD for pre- compiles is low I mean there's the only reason we're getting these 10 pre- compiles BS B BLS is because it's absolutely required to validate effectively the consensus client stuff and they don't view eof with the same level of urgencies they do validating

the CL uh the CL blocks um it's we put more Hoops to jump through to use this and we're not going to ship it in Prague we need to be able to ship it with existing Foundry tools and with existing hard hat tools or it's it's not going to get the acceptance it needs to get pushed into Prague and it's going to be another two years of work so I mean allev practically is aside which I think a lot of what you said is is is true uh I think generally what regular State

change means yes from like a the textbook side yes you change the state um and from the textbook yeah maybe the pre isn't but what you know people were really freaking out prior to the beacon block route is modifying any state where you would never expect to have any modifications and the pre-compile addresses are kind of implicitly expected to be populated over time that's why I really don't get I'm not talking specifically you know about the UF case but that's why I don't get why why there was no appetite to insert the

beacon block route at that address because those addresses are expected to change semantics and behavior and whether you change that through an external specification or insert a code it doesn't seem to make any difference but it's beyond you know this discussion I think one unique thing is it was also very specific to layer one layer two and ALT VMS don't have that um so having a be code that was dropped in and a system transaction handling it um it's ethereum doing it it's layer one mainnet doing mainnet things that none of the other networks need to worry about so I think that's why it was more palatable and people dropped resistance

when that solution came available yeah we also over time what I would suggest is um I think we need to to see like a some rough spec you know what alternative we could have because otherwise it's really hard to to discuss um and agree on anything so I think for next week we need to come up with at least one alternative alternative solution if we if you want to to pursue this change I can I

can yeah what I posted against the the spec is kind of almost ready because this is the TX creat less proposal which was a PR to efmd you just need to not remove TX create basically it probably has some row edges but uh um but I think that's that's what I at least hope had in mind for this because the TX cre plus e was exactly doing all deployments like that yeah that would be the NIT code transaction so the way we would handle contract create transactions the type 1

123 you think 7620 is the right place for that or should we put it in the definition right now it's to to the meas spec still in the meas spec I would say just to Mega spec because that's comprehensive and we see the yeah yeah I agree let's let like it's more it's easier to detect some conflict with some other part of the spec when you're working on the meas spec even more so that some of the eips are not up to dat yet so my concern with not putting it in

EIP is that ACC only considers eips right now they don't like the extra meas specs to for reference so at some point it's going to need land in this this is we yeah disc only for for our for our here uh discussions here okay and then this we can make it up PR to the EAP 7620 will be like just just a chore to to translate it to that form or we can make it a new new IP alog together but but I would start with the

meas speec here just just for our our discussion sake okay so I have two items I'll do the meas speec update for the Legacy create and the validation for empty the this this update to the meas speec is almost it's it's done it's done it's it's the it just needs to get the TX create less PR to to be stripped down of of removing TX create so it's like like five minutes work I just get it done after the call or tomorrow ear

all right we we are almost five minutes over um yeah let's try to settle these uh uh questions next week and hopefully we can start discussing it well there's going to be Easter holidays in most of Europe starting this weekend so probably response rate going to be low this week um but hopefully early next week we can start discussing this properly y all right thank you everyone and see you next week byebye thank you very much bye bye by recording stopped