 I forgot to start recording this at the beginning of the call. Yeah, if you want to. Yeah, I have also one question regarding the spec that I would like to ask is that I think what we should do with the data section is not clear. In the IPs. And that should be also included in the spec so it is clear what you should do with the data section. What do you mean do with the data section. So, as from my understanding the data section is sometimes used to call the constructor of the newly created contracts. Or is my understanding incorrect. I think it's still an open question of what, how the constructor arguments will be passed into the code. A complaint that this little team was having was that if they are going to generate to the constructor arguments in, you know, the contract that the place that just submits the contract deployment, then they would need to review the contract deployment, then they would need to recalculate the data section size of the container in EVM code before the create is called. And so for that reason they preferred that there was just extra data at the end of the contract for the code. So, as far as we know right now. You're saying data section is useless it's just to submit data to the blockchain. It's not used in the EVM I mean, in any case. No, it can be used with code data load and you can manipulate it within your EVM code. Right. I think the original inspiration for the data section was the people were creating contracts that they were using as data. And we wanted to give developers that functionality natively in a way where that data couldn't potentially be executed. Sorry, just question. Code, did you say code data load? Maybe I got the, the opcode name wrong but there's one where you loaded from your current by code code copy code copy so but code copy. Does that, so does that operate on the whole container or what, what does that operate on? It does. It operates on the entire container. All of the ops in that family that operate on code overall right now are, you know, continue to operate on the container level rather than would it localize per section? Wouldn't that be more useful to have opcodes that operate on the data section only? But then we would have to have new opcodes for that. Yeah, I think that's probably what's going to happen at some point, but. Vitalik wanted that. Vitalik wanted the code copies only to work on data sections to create a potential future where we translate the code in the code section but I think that got brought up too late to be integrated into this current round of spec. You got it. Thank you. Can I add something to this? Please. Yeah, I'm kind of going around this like I think this is the core issue is that's how create works. So create doesn't like when you're creating a contract you don't have like call data as in like regular execution. It's always empty. And like the constructor, the contract gets is taken from just adding the data to the actual code. So it lands, the constructor arguments actually lands in data section in EOF case. And yeah, I think it would be simple if that's kind of separated and there's like separate stream of data for the call data in the create instruction, but it's not the current situation. And because of that like traditionally, you just append this data to the like init code and, and then the code running inside the init code just knows where the data is and so on. But like the kind of ugly, ugly aspect of that is that now the contract that creates another contract needs to kind of reprocess the EOF and usually patched the data size, the data section size in the EOF container. And that means that it needs to manipulate the EOF format somehow. I think it's not super difficult, but there are cases with this is like super, almost impractical I think my understanding, especially when you consider the cases that sometimes, sometimes contracts wants to like pre-compute the return address of some like future creation and then like it's getting complicated. So like, like kind of ugly fix as well. That's my kind of scoring of this approach is to like allow external data or something like that in this init code situation that we kind of discussed a bit. And I'm sure this is great, but maybe it's not worth the trouble and like have this limited availability of doing this like previous, previous like use cases and what else and like kind of I see it like if we kind of redesign the create a bit maybe that's like we can find like better solution but that's definitely not something we can hope to include right now. So what do you think the rights next steps are for resolving this because it seems like there's two main paths for dealing with the construction arguments and one is like as you described manipulating the data size and adding the constructor in the data section and the other, it's, I guess there's three than the other one is appending the constructed in a code and the last one is changing how create works and the last one sort of out because it's too large of a change. And so the question is how do we decide if we want to allow this extra data after, you know, just for the init code purpose. So to my understanding solidity can handle this, this thing right now, it just like this additional code that will do the patching and so on. And that works like in most of the cases. So the things that probably don't work is to pre computing create two addresses with some like not look starting size arguments so for example the constructor of the create to takes an array. It's really complicated or maybe it's impractical to like pre computed but I, I might be wrong about some details. I think I would just keep it as it is. If we don't plan to include new changes of this no time for it. Which I think that's the current status. And we might lose some use cases. So, but I think that's a bit better than trying to kind of quickly patch it. Okay, Dana. I'm afraid those use cases are going to be pretty big and it's going to be a pretty big limitation to require all of your init code to fit inside the container and redefine the size of the container dynamically. This is, I think this is important thing we need to get fixed before we ship it. I think we, my opinion is we should do it. We need to do to get it fixed. Whether we allow create an it code to not have a size limitation, or we change the size limitation to be container must be at least the same or larger than the data section would apply. I think we need to do something we need to do something great would be another way to do it, but that is that that even would even go beyond can tune I don't think I have the time to define that well, and get people on board with it that's like a one two year out solution there. But I don't think that I think we need to get it fixed so that we can have arbitrary array data for a constructor. Um, yeah, I think I don't like for you for view about it. Solidity should be like better team to comment on this. I think the constructor works. What doesn't work if you want to pre compute the address inside some other contract, like, but okay, I think I think I agree this like this like some issues with it. And we might not even know like what exactly kind of issues we will have with that. And one more thing, which is kind of related is also the fact that we now expect the return of the of the unit code execution to be also you have format right. Which means the like returning empty empty code. It's not. It's not valid in this case. And I think someone commented that there's kind of use case when you actually have an Indian code that inside the unit code creates another contracts. And in the end, it just like returns nothing. And then this this contract, like the main one will not be created because empty code means empty account and this account kind of successfully was created but also will not be like reflected in the state. And that's the use case that we also kind of break. Because you need to return empty of which is this has some bites and this bites will be deployed or go there will be pretty useless. I think I've seen that use before where people just want to execute a string of EVM code and not leave a contract around for new transactions so I think it's. I don't know if we need to support it through EOF but if we're going to make features that are EOF only that we might need to start considering how to handle an empty create from that we require EOF or an empty code I think might be a one solution there. I guess this is something that we can later allow empty code to deploy this is backwards compatible with the changes that we have. So I don't think it's something that we need to come to consensus on right now. I think there's enough of a consensus. It's always good to have a novel value in any system like this. So you're saying that you feel we need to allow empty contracts to be deployed from EOF. Yeah, it's something that people already do. It's perfectly logical. It's just the null value for that algebra. Because it deploys with notes zero right. So if there's no money, no storage, no notes, it'll be a wash. No, no, it doesn't. So it deploys with a with a nonce one. No notes one so it doesn't garbage run it okay. Yeah, so it's I mean it's totally useless thing to deploy a contract with the nonce one, leaving it forever unable to you know handle any inputs or. Yeah. Yeah, I thought the idea on one side of it. But I thought the idea was you leave less behind in just running that EVM code that if you're, you know, forced to, to have a bit of actual contract code there. Yeah, I mean, yes, but you still have an imprint on state. Yeah, because reducing. I think the imprint on state of having code zero versus and quote unquote empty EOF container is negligible because we're only going to store one version of the code hash. So as long as most people are deploying empty EOF containers after they run their code, then it's, you know, not really going to be any overhead. With notes one you're going to leave something in the account tree. And that would have been already if we allowed people to deploy you have contracts with size zero. So that behavior doesn't go away. It's just that we're not going to be storing a whole bunch of, you know, 1020 bite EOF containers that do nothing. We're just going to store it once and then we'll have the code hash for them. We're not going to have EOF, but I think we should consider a change that zero code doesn't create account. But that's out of scope for this discussion. I agree with both of those. I think I might have like presented it wrongly, because I think the original use case was using self destruct in the end. So I comment that's like returning captives like equivalent, but I think the hour I missed the nonce, the nonce thing. So mostly the use case was that this init code that creates other contracts or do other stuff. And in the end of that itself the tracks so then the contract is not created. I see. But the effects that were applied on the way. We're still hold. I think we should continue debating this question of if we should allow zero code contracts to be deployed offline. I do want to try and resolve this question about what to do with constructive values for the init code. It doesn't seem like it's very good consensus. I'm like currently leaning towards making no change unless we can present like a really clear example that's going to make things much harder. If we have to put the constructor in the data section, we can always do a change in the future to allow extra data after the init code container, like we were discussing, but we can't easily in the future say that's no longer allowed. So unless there is a good example right now like this is going to not be possible by putting the constructor in the data section I think that we should leave it as is and then decide again in the future. Does anybody oppose that. Okay. I will document that. Oh, I'm in. Yeah, just about the data copy of code. Does anyone feel strongly against adding it into 3540. So what exactly are proposing adding a new code. Another code. So to copy the data section to make it easier to manipulate it exists. Oh, X 35 called it alone. What do you mean cold cold. He wants he wants an opcode like code copy but that operates only on the data section. Got it. I in theory I'm not, I'm not opposed to the idea per se. But yes, I would be opposed to doing like just throwing you new instructions at this point. And because I think we should try to just get your finalized. Yeah, that's how I feel right now. I'm not adding adding it right now is that in the case that we want to add it later. It will be a totally different version. No, I want the newest version. We can apply. Yep. It doesn't change any previous behavior. So we can just add it in a fork. True. True. Okay. So we have a set of invalid code reduces, but we don't take stuff that was in the valid set move. It's the invalid set. So it's a compatible change. If we just add them up. Yep. The only cost is that people who are deploying contracts in that time period between will have to pay to calculate what offset they're going to load. Start loading data from. And I think that's okay. Yeah. So would that be paired with deprecating call data load. Inside of copying the code sections as well. To go with the. Yeah, code copy. Well. Yeah, code, code copy. Yeah. Sorry. 39. I'm looking. It's too early for me. Would that be paired with deprecating code copy inside of EOF. So it can't copy code code, but only data section. I think it could be. That's something that's going to be a larger debate. I think so. Right. Maybe we should put a warning like going out with self-destruct. This may not work in the future when we roll it out on day one. So we don't get surprised saying like, depend on this. Well, the problem is, is that if we're going to have people using the data section to put the constructor. They're constructors and then I think it's going to be difficult to properly deprecate code copy in EOF. In which case we would need to probably do another. Yeah. If they're making a quiet and copied code that exists. We could, we could make a scarier sounding warning and scale it back if we need, but I think if we're going to do Vitalik's vision, we might need to put something in there. Yeah. Yeah, like, I think like. Yeah, code copies have you used. Like one is this like constructor arguments. And secondly, the immutable, immutable variables in Solidity are used this way. So like every contract, you should assume like every context uses this anyway. Right. But is it referencing? Go ahead. Yeah. So warning will like not help at all. So yeah, I'm like, my, I know my view is like, I would like to spend a bit more time on it. Like thinking about how the contracts are created and limit the like observability of the code, which I think the current current situations kind of go a bit into the other direction. So like the fact that Solidity, like the EVM code needs to understand EOF format. I think that's, that's a bit like, yeah, the opposite of what I would like to see somewhere, but this is like, this is the different set of features. So maybe for future, maybe never, I don't know. But yeah, if we're going for Shanghai, definitely we can't touch it at all. But they could put their constants and everything in the data section. And we just warned that code copy may not copy code from a code section. Or the EOF header in the future. Yeah, I guess that could be possible. Yeah, yeah. Like we'll, like we'll end up with like this weird instruction then that kind of only like allows you to access the data about the offsets or something else. But you still need to know what the offsets are, right? So like, even though it only allows you to copy data, it assumes like the const, like the, the structure of the, of the container doesn't change at all because you need to exactly know where the data section is. Right, that's usually the last leaking step of a compiler. Once it lays everything out, it can rewrite the numbers. Yeah, yeah. But that's like, that leaks some information about the code you're having, right? Yeah, I guess ideally like TVN cannot like snip anything out of that. I'll accept data, which, which for, for the other word is just like stream of bytes. And we never assume we'll actually modify data because why would you, but the rest of these you would, yeah, I guess that's like this, this Vitalik idea that you can't expect it. So, yeah, you can modify it somehow, upgrade it externally to something else. And I think that's really interesting, but we don't have a proper design for it. I feel like we should put this conversation on pause for now. I think we're going to talk about these ideas of the Vitalik's proposal a lot on Thursday and maybe in the coming days. And I do want to talk about testing and test nets and stuff. So if there aren't any other, other spec related questions or comments, then we should move on to testing. I know that the epsilon team has been putting a lot of work in and then writing some cross client tests and Ethereum slash test, just someone from the team wants to give an update on what's going on there. Yeah, we have several PRs open to one of the most ready is 3540 tests. I think your client teams can already try it. Others are not so ready, I would say. Yeah, I run the fillers or the fill tests for 3540 on my range of guests and I passed them except for about 14 of them and half of those were ones against Berlin. I'll look into it. So it should be possible for other clients to run those tests. Do we have any idea when we might be able to release those at least 3540 tests just need the review from the testing team, I guess. Okay. Others are mature so in progress. The others being like individual focus test for each of the IPs. Yes, currently there is a PR for 3670 for 4200 and 4752. Okay. By the way, one thing to note about this 3540 tests, 3860 limit on a meter in code is not activated in that. And yeah, we will regenerate these tests as soon as. Get the mergers 3860. So for now it's without 3860. Okay. Thanks for that update. Other tests. Mario has written quite a few of tests, maybe three weeks one month ago. And over the past week, I was trying to get them updated to the latest spec changes and things. Now they are fillable. So I've been able to fill them with the, the geth branch. And yeah, we're going to try and get that merged pretty soon. I don't know, Mario, if you want to comment at all on. Plans for those tests. Not yet. I'm, I'm still going to take a look over the changes and. Yeah, I think I will prioritize that to finish today. Have a, have a review ready for you. Great. So I think it was respect to testing overall. We really need to at least get some tests sweet published and released so that all of the clients can run them. So we need to at least sort of have like a baseline of what everyone is targeting and implemented, et cetera, so that we can try and do a. Test net in the next. You know, a couple of days. I think. We should really have something, some sort of test net before all core devs, because that was part of the stipulation that. We're still going to be working on testing and differential fuzzing and approving all of these things over the next couple of weeks. But as a, like a good faith effort. I think it would be great to. Get a test suite released and. Start a test net. Does that seems like something that is doable to clients. Wait before this. Before the next one. Before this all core devs. So the problem with the test net could be that if we. Didn't run any tests. We will end up with some consensus issues. And so we will spend lots of time on the bugging the issues. Instead of just running. Tests. Yeah, I agree. That's why I'm saying that I think we need to initially have a test suite suite released. We are all on the same page. At least. Do call it. I mean, will clients prefer to. Like focus on doing a test net. Wednesday of next week or something. Rather than trying to do it before all products this week and just focus on. Like solidifying across clients. Before all core devs might be hard because if we notice that something is failing. On this test. We don't have no time to fix issues. But next week sounds better in my opinion. I think we're going to spend most of our time the next few days doing the. The fuzz testing rather than the test net. I think we'll get more signal out of that. Then out then at DevNet. Yeah. That seems fine. I don't know if you have any thoughts on this, but I think if we do come with a test suite. Yeah. I think we're going to have a good idea of clients, you know, are passing 90 X percent of this test suite then. Yeah, I think I would agree. That's the most probably valuable signal. And then also the test net bits, there might be. Why. It might be worth discussing. Do we want to have just one broader test net for client teams to join versus like an EOF only one. And I feel like. Yeah. If we have that conversation on our core devs, that's what we do here. Okay. That sounds good. Let's, let's focus on that. Let's focus on getting a test suite before all core devs. So we can get an idea of like where clients teams are. And then, you know, ourselves right now we can say we're sort of planning on doing a test net next week, but that's going to be pending on the conversation that happens. On Thursday at all core devs. Andrew. Yeah, so I'd like to double check that your F is based on Shanghai core, right? So we are not like doing some weird thing where we don't have some bits of Shanghai core, but we have some bits of your F things like that. Because in, for instance, in guess, I know that. Yeah. Like there is one particular point. I know that. Yeah. So I would like to, I would like to, I would like to finalize the change to if 3860. If 3860 is not merged into guess yet. And there has been recently in change to. If 3860. So. I would like to. Like to finalize the change to 3860. And like enable all, like all Shanghai core reaps in, in Shanghai. And like. So to avoid situations where. Yeah. Some bits of your F are enabled some bits of Shanghai core are not enabled and so on. Yep. I am agreement in agreement with that. Yeah. Yeah. As the 3860 finalized the PR, I think it's not merged yet. Is there any strong proponents to merging it? Merging it into guess or merging the change into the. And to eat. I think everybody is on board with making that. Oh gee. So. Yeah, I think we can just assume that that change is going to be made. Yeah. Yeah. Yeah. I think it's just sweet that is currently the PR that epsilon team right now had prepared does not include that change as far as I know. As far as you guys know. Yeah. The UF tests don't have 3860 is what. Andre said. Paul. So you think it's fine. I merge the change. We just like present on all core depth that the change has been made. Yeah. Yeah. I feel like we can go ahead and make the changes in clients. And. Talk about it on awkward depths and if for some reason. Something comes up where people have a problem with changing it. We can revert. But I think optimistically accepting and just change is probably fine. I mean, I mean, I mean the spec change mostly. Oh, I see. Yeah. I think that's fine. But in terms of client teams, we can just optimistically accept the change and we'll merge it officially after all for those. Okay. Thanks. Hey, I just have a question for the epsilon team. You guys are getting a review on the tests. We are from Dmitry or is there anything that you need from me that I can help with? Yeah, I can take a look. It's just that we have two suites right now for. For tests. So I think ideally I can take a look at. The tests on the, on the Python test for review. And then if Dmitry can take a look on the tests. But I will, I will also take a look if I have some time today left. I also put on the agenda just to mention this EOF parse tool. I think unfortunately Martin has to go, but Martin has been doing some fuzzing with the EOF parse tool on the handful of errors. I think Dan, you've also been doing some differential fuzzing. I don't know if you want to make a comment on how that's been going. So I think it's been going well, but I think it exposes that we might want to add a new type of test to the reference tests. We have the general state tests, the blockchain tests and the transaction tests. The transaction tests, their goal is to say is this transaction valid or not. I think we use similar things to the transaction tests. For the EOF contracts, because the only question we have for, you know, a very large purposes. Is this accepted or not? I think it's not. The only question we have for, you know, a very large corpus is, is this accepted or not? And the alternatives make a very large corpus of blockchain tests or a general state tests, which are very heavy to calculate with the only question we want is, are they getting the stack validation correct? So I wonder if we should use our findings from this emerging to create a new, you know, transaction tests type set that is just for the EOF. I could put together a proposal and put a patch and push it to see if it's needed to show what I'm thinking here. But I'm thinking that's the signal we're getting from EOF parses, very strong and very valuable just in the validation. And we could focus the general state tests on the operators, not on the container format. Yeah, I think that makes sense to me. It seems to fit pretty nicely in line with the new transaction tests that Martin had worked on sometime last year. It does seem like something that would be a pretty good fit. I don't think this is something that we're going to make happen for Shanghai. I think, yeah, it's something that we should aspire to after Shanghai. I don't know if you think differently on that. It's assembling the tests and getting all the clients to use the test is, is the Shanghai part, but I think we could get a corpus together relatively, you know, shortly with him before we head off to Austria, and we could grow it as we find bugs. So I think, yeah, I can, I can get a proposal out by the end of the week. Yeah, if you want to make a proposal, I think that we can definitely get something going. I don't know how like the integration will be with some of the official test repos, but we can definitely do something ad hoc by Austria and then talk about it there and decide how to, you know, merge it officially into like the testing suites that we have. So one question about that is that what do you have in mind? Do you mind? Do you mean that just purifying the container? Exactly. Or also execution? No execution. Just the container. Look at the container. We run code validation. We run stack validation. And the question is, is it valid or is it invalid? Is the real only output? And we might need to put it against different forks. If we change this, we might need to put it against different use cases like, is it a code? We'll want to comment saying why we expect this one to fail. Or what's interesting about it. Right. And this follows very closely to like how the transaction, the T nine and tool works. Basically you give it the transaction by code and an output. So like, was that transaction out or not? But I think that, that makes sense. Yep. That's my model. Yeah, just a comment. So we want to check in the transaction test. That's the EOF container spend it right. Yeah, transaction test, but instead targeting EOF containers, not transactions. Okay. But like if you have containers in valid, then the transaction itself is still valid. No, it's not a transaction. The input is going to be the raw EOF data, not a transaction creating an EOF. Okay. Yeah, sure. It's just a simplified hook into that logic that's doing the container validation. So we have seven minutes left of the call. We're kind of coming to the end of the agenda. Were there any last comments on testing that people wanted to make? I think this is kind of testing like this EOF validation can be very simple. Even you can have like, like one valid directory, one invalid directory and just place the, the byte codes there. Respectfully. Okay. Yeah, that's pretty much everything that was on the agenda. Are there any other questions or comments? We wanted to discuss regarding EOF. Yeah. And I think it's expected on the all core devs from our side, like in general, like the, the group that this involves in EOF. Like should there be like any report or like. I think that we just need to get this, get a testing suite. Released and. And then we can figure out what the client test pass rate is for each of them. So we can basically come on and say, you know, this is how clients are doing with EOF testing. So people will sort of get an idea of what the status of that is. And I'm guessing like the other main thing that people want to talk about is they'll want to talk about the talix proposal. So it might be good to revisit it a bit and think a little bit about the impacts. Great. Do we want to schedule a six EOF breakout room? Or should we wait until after all core dubs? I kind of feel like there's the answer to them. Make the call after our core does sounds good to me. That's it for me. If anyone has less final comments. If not, I think we can just go ahead and call it right here. Thanks a lot, everybody. Happy new year. Let's just keep chatting in the EVM channel. About the. Testing things that we find and yeah, let's get a test we released the next couple of days. Thank you. Thanks. Cheers. Thanks.