Rodiziet, could you repeat the things you said about Ypsilons progress?

Yes, so we merge the PR regarding the ColF stack validation as the first thing, and the second thing we are working on the on the support of the EOF tests in EVM1.

And the third thing we have still continuing discussion about disallowing callf to non-returning function.

As far as I understood from the recent discussion inside our team, we are leaning towards disallowing this kind of instruction to non-returning function.

As far as I understood this, it's basically, okay, I'm not going to say because I don't know.

So I don't want to make some misunderstanding.

So basically, we should discuss it with Andre or

So yeah, if I had to guess it would be Redf.

I might be wrong, but Redf pops a call, pops a message frame.

All the other options, return, revert, invalid instructions, create, those dispense with the call frame.

Red F doesn't pop a call frame, Red F pops a function frame.

And all those other ones, revert, return, stop, pop a message frame.

And since EOF is operating within a single message frame, the only 1 that would make sense to me would be red F.

Yeah, I mean, it would be a little weird for to require subroutines to call.

But I mean, it's actually kind of an interesting restriction, right, because like you may, I don't know, want to have some kind of thing where you return, sorry, a contract return from a subroutine.

A subroutine that does nothing but revert would be a non-returning.

So you wouldn't call 1 of those, you would jump f into them.

So you wouldn't call f an outline that reverts, you would jump f into an outline that reverts.

And if it could ret f, then you would call f it.

Basically it's a way to introduce dead code, I think, if you can call F into a non-reverting instruction.

It kind of seems like the the duties of call F and jump off are getting pretty clearly delineated.

Yeah, jump F requires, call F requires a return.

You know, it can either tail or curse or return or terminate.

That's a very concise way to phrase it, yeah.

I didn't have the agenda, so I did it out of order.

Are there any clients that have any clients updates?

Do we have Nethermind or Geth or Ethereum.js on the call?

Basu, I keep working on Cray 3, I keep getting distracted with other things.

Status is it just need to write and validate test cases.

Haven't committed it yet to our mega EOF branch, but there's a lot of distractions trying to get Cancun out the door.

So the next traditional agenda item is compiler updates, do we have solidity here we got Viper is there a Solidity representative?

Okay, Charles, do you want to go for Viper?

I was still talking with Pavel about the stack validation, And it sounds like Andre is doing some work on that.

But I think at least me and Pavel are pretty low in bandwidth right now.

Not that many updates but we are working on a rebase, which I will share on the chat.

This branch is basically the work that I did like a month ago, but it's being rebased on top of main because there were so many new changes to the execution spec test which is the Python test repo and Spencer's currently working on fixing all tests and basically just rebasing to main so we can have like a solid base where we can start adding more tests for the latest spec.

Andrei mentioned that he wanted to start contributing.

But he mentioned a couple of comments on our implementation of the create tree functions and methods that we have to dynamically generate code.

So we're going to first rephrase and then work on fix those comments.

But, yeah, mainly I just wanted to share this branch.

This is where the EOF work will land on the next couple of weeks or months to come.

And also invite everyone if he wants to take a peek into the code, into the Python code and wants to contribute, just please let me know.

There's no way to pin just a branch, is there?

Just looking at GitHub, there's no way to like say follow the changes to this branch.

You have to follow the changes to the entire repo.

That's probably 1 I should pay attention to anyway.

That update cover anything you might have to add or to see if I have anything that.

Yeah, my audio was not working before, so I didn't hear anything but yeah, from my side.

Yeah, there is this request that it is changing the existing UF tests in order to change the, for example, the current fork name to BRAC and also the data ID from 03 to 04.

And also there is another new PR, which this PR is changing all the existing tests in order to change the first section, all boot in order to, to market as non-returning function.

Yeah, this is, this is, this is almost ready.

There is only 1, 1 last change that was added to the spec, which this allow using call F for calling non-returning function.

So this is still needs to be added to these

test changes, But yeah, they are almost ready.

I guess We move on to the community updates.

I don't know who maintainer.eth is, but I know who perpat and zane are.

Perpat and zane, do you have any, are you both with the S-Store 2 project or are you on separate projects?

Yeah, when we kind of maintain a library that's like similar to us to start to but separate version of it.

Yeah, no updates on our end just like to follow along on this call.

Okay, that's good to hear that you're following that.

Double click on like, I just I think the last call that I was on in terms of the conversation about exposing an opcode for cross-contract UF storage reading, I think where we left that was like splitting that off into its own EIP.

And is that still the latest kind of state of the world in terms of the consideration there?

Well, we still haven't seen the, we've seen the draft of the data copy ops, but I need to write a draft for that.

So it is kind of a strategy discussion, more to say, coming up to what we get into Prague, is it too big to get the stuff into Prague and putting some of these in separate EIPs will make it easier to sever out pieces if the other core devs think it's too much for their clients or to bring it back in or if it's SELoad or the RISC or whatever, it takes to get it, the elephant through the door into Prague.

And I think the another couple of calls would be on that 1.1 list, I guess, is what it might notionally be called, although it doesn't exist, would be the call fi and jump fi functions.

If those put on there, they're severable, they might add value, they can be discussed on their own.

But it's not essential for the first pass, although it would add value and make things better for the community.

And those, because those are not, I think we want to have 1 thing that just does the bare minimum, that does all the breaking that needs to be broken and still has a complete functional system that may not be the most efficient on first pass but is self-contained.

I think that is what we need to have is the smallest possible bundle and everything that comes off of that can be added.

Because I think that's always been the strategy with EOF back when they were discussing it in Bogota and every other place that they've talked about in Amsterdam.

The more you split out of it and make it, you know, it's, the whole is more valuable than some of the parts, but at some point, you can't have it too big to ship through the door.

Yeah, I think we'll continue to follow along there.

I think like the pragmatically what it means for folks like us is you know that's not included in the the first hard fork supporting uf I think going the approach that's been talked about on this call of like kind of using a pattern of storage contracts exposing a method that allows you to read their contents is probably, yeah, the other path there, which I think is definitely workable.

It's just a little bit, yeah, less efficient, more messy, but not a like heartbreaker or anything like that.

Any other community questions, comments, feedback.

Couple of things I think that are worth mentioning.

Ypsilon is putting together the EVM Summit that's going to be, I think, on Tuesday, the week of DevConnect out in Turkey.

If you go to the EVM Summit.org website, I think it's the .org.

They're asking for attendee lists, they're asking for speakers.

You know, if you're interested, that's something to do that week.

So if you're the type of person that finds this call interesting, it's probably the right place for you.

Also, I'm gonna be giving a talk at ETH Chicago here in about a month on the Ethereum object format.

I should get my slides together in a couple of weeks and fill in those comments to add to that.

Try to do my best to represent the project well and what we're trying to accomplish there.

Ypsilon's done some amazing work on it, and I want to make sure that they get people in North America aware of the stuff that they've been doing.

Any other conferences that people are aware of UF stuff happening in their EVM that they're participating in and want to promote?

All right, Any other discussions before we give everyone 35 minutes back?

If not, I guess we can all check our emails and our Discord threads.


Speaker 0: Okay, recording started. Rodiziet, could you repeat the things you said about Ypsilons progress?

Speaker 1: Yes, so we merge the PR regarding the ColF stack validation as the first thing, and the second thing we are working on the on the support of the EOF tests in EVM1. And the third thing we have still continuing discussion about disallowing callf to non-returning function. As far as I understood from the recent discussion inside our team, we are leaning towards disallowing this kind of instruction to non-returning function.

Speaker 0: Okay. Cool, that's just the Epsilon update.

Speaker 2: Is non-returning the ret f or return?

Speaker 1: As far as I understood this, it's basically, okay, I'm not going to say because I don't know. So I don't want to make some misunderstanding. So basically, we should discuss it with Andre or

Speaker 2: Pavel, maybe you're playing.

Speaker 0: So yeah, if I had to guess it would be Redf. I might be wrong, but Redf pops a call, pops a message frame. All the other options, return, revert, invalid instructions, create, those dispense with the call frame. Red F doesn't pop a call frame, Red F pops a function frame. And all those other ones, revert, return, stop, pop a message frame.

And since EOF is operating within a single message frame, the only 1 that would make sense to me would be red F.

Speaker 2: Yeah, I mean, it would be a little weird for to require subroutines to call. But I mean, it's actually kind of an interesting restriction, right, because like you may, I don't know, want to have some kind of thing where you return, sorry, a contract return from a subroutine. So,

Speaker 0: that I would consider non-returning. A subroutine that does nothing but revert would be a non-returning. So you wouldn't call 1 of those, you would jump f into them. So you wouldn't call f an outline that reverts, you would jump f into an outline that reverts. And if it could ret f, then you would call f it.

Basically it's a way to introduce dead code, I think, if you can call F into a non-reverting instruction. Yeah. Into a non-returning instruction.

Speaker 2: Yeah I mean yeah yeah I get it. It kind of seems like the the duties of call F and jump off are getting pretty clearly delineated.

Speaker 0: Yeah, jump F requires, call F requires a return. Jump F prohibits a return?

Speaker 2: Call F requires a possible return. But jump F is very restricted, right? You know, it can either tail or curse or return or terminate.

Speaker 0: Right, right. Tail, recurse, or terminate. That's a very concise way to phrase it, yeah.

Speaker 2: OK. Yeah, OK.

Speaker 0: I didn't have the agenda, so I did it out of order. Are there any clients that have any clients updates? We got the update from Ipsilon kind of. It's also a spec update. Do we have Nethermind or Geth or Ethereum.js on the call?

Doesn't look like it. Basu, I keep working on Cray 3, I keep getting distracted with other things. Status is it just need to write and validate test cases. Haven't committed it yet to our mega EOF branch, but there's a lot of distractions trying to get Cancun out the door. So that's the update from BASU.

So the next traditional agenda item is compiler updates, do we have solidity here we got Viper is there a Solidity representative? Okay, Charles, do you want to go for Viper?

Speaker 2: Yeah, no Viper updates. I was still talking with Pavel about the stack validation, And it sounds like Andre is doing some work on that. But I think at least me and Pavel are pretty low in bandwidth right now. So no material updates.

Speaker 0: OK. Testing updates. I guess that's Hugo and Mario.

Speaker 3: Yep. I go first. So yeah, basically no. Not that many updates but we are working on a rebase, which I will share on the chat. This branch is basically the work that I did like a month ago, but it's being rebased on top of main because there were so many new changes to the execution spec test which is the Python test repo and Spencer's currently working on fixing all tests and basically just rebasing to main so we can have like a solid base where we can start adding more tests for the latest spec.

Andrei mentioned that he wanted to start contributing. At least that's what I understood. But he mentioned a couple of comments on our implementation of the create tree functions and methods that we have to dynamically generate code. So we're going to first rephrase and then work on fix those comments. But, yeah, mainly I just wanted to share this branch.

This is where the EOF work will land on the next couple of weeks or months to come. And also invite everyone if he wants to take a peek into the code, into the Python code and wants to contribute, just please let me know. I can help out in any way I can.

Speaker 0: There's no way to pin just a branch, is there?

Speaker 3: There's no way to, sorry, what?

Speaker 0: Just looking at GitHub, there's no way to like say follow the changes to this branch. You have to follow the changes to the entire repo.

Speaker 3: Oh, I see. OK. I don't think so. I'm not sure.

Speaker 0: I'll just follow the whole repo. That's probably 1 I should pay attention to anyway.

Speaker 3: OK, OK. Sounds good. Does

Speaker 0: That update cover anything you might have to add or to see if I have anything that.

Speaker 4: Sorry, my. Can you hear me.

Speaker 0: Yes, we can hear you. Yes.

Speaker 4: Yeah, my audio was not working before, so I didn't hear anything but yeah, from my side. The. Yeah, there is this request that it is changing the existing UF tests in order to change the, for example, the current fork name to BRAC and also the data ID from 03 to 04. This is already ready for review. And also there is another new PR, which this PR is changing all the existing tests in order to change the first section, all boot in order to, to market as non-returning function.

Speaker 5: Yeah, this is, this is, this is almost ready. There is only 1, 1 last change that was added to the spec, which this allow using call F for calling non-returning function. So this is still needs to be added to these

Speaker 4: test changes, But yeah, they are almost ready.

Speaker 0: Cool. That's good. Getting tests, that's really positive. I guess We move on to the community updates. I don't know who maintainer.eth is, but I know who perpat and zane are.

Perpat and zane, do you have any, are you both with the S-Store 2 project or are you on separate projects?

Speaker 6: No, we're from separate groups. I work

Speaker 0: at Rblocks.

Speaker 6: Yeah, when we kind of maintain a library that's like similar to us to start to but separate version of it. Yeah, no updates on our end just like to follow along on this call.

Speaker 4: Yeah, just following along. I work for 1 on one.org. That's, yeah. Just like in the same 1 chain groups.

Speaker 0: Okay, that's good to hear that you're following that. That's good signal. So, so probably a quick meeting if

Speaker 6: maybe just 1 thing

Speaker 0: to discuss. Go ahead.

Speaker 6: Double click on like, I just I think the last call that I was on in terms of the conversation about exposing an opcode for cross-contract UF storage reading, I think where we left that was like splitting that off into its own EIP. And is that still the latest kind of state of the world in terms of the consideration there? Or is there a better pattern that?

Speaker 0: I was going to write the EIP for that. Well, we still haven't seen the, we've seen the draft of the data copy ops, but I need to write a draft for that. So that is kind of a meta discussion. Let me write that out to myself. NXT data copy EIP.

So it is kind of a strategy discussion, more to say, coming up to what we get into Prague, is it too big to get the stuff into Prague and putting some of these in separate EIPs will make it easier to sever out pieces if the other core devs think it's too much for their clients or to bring it back in or if it's SELoad or the RISC or whatever, it takes to get it, the elephant through the door into Prague. So I think that's why we're going there. And I think the another couple of calls would be on that 1.1 list, I guess, is what it might notionally be called, although it doesn't exist, would be the call fi and jump fi functions. If those put on there, they're severable, they might add value, they can be discussed on their own. But it's not essential for the first pass, although it would add value and make things better for the community.

And those, because those are not, I think we want to have 1 thing that just does the bare minimum, that does all the breaking that needs to be broken and still has a complete functional system that may not be the most efficient on first pass but is self-contained. I think that is what we need to have is the smallest possible bundle and everything that comes off of that can be added. Because I think that's always been the strategy with EOF back when they were discussing it in Bogota and every other place that they've talked about in Amsterdam. The more you split out of it and make it, you know, it's, the whole is more valuable than some of the parts, but at some point, you can't have it too big to ship through the door. So it's kind of a tricky process.

Speaker 6: Yeah, that makes sense. Okay. Yeah, I think we'll continue to follow along there. I think like the pragmatically what it means for folks like us is you know that's not included in the the first hard fork supporting uf I think going the approach that's been talked about on this call of like kind of using a pattern of storage contracts exposing a method that allows you to read their contents is probably, yeah, the other path there, which I think is definitely workable. It's just a little bit, yeah, less efficient, more messy, but not a like heartbreaker or anything like that.

Speaker 0: Cool. Any other community questions, comments, feedback. Couple of things I think that are worth mentioning. Ypsilon is putting together the EVM Summit that's going to be, I think, on Tuesday, the week of DevConnect out in Turkey. If you go to the EVM Summit.org website, I think it's the .org.

Follow my Twitter, EVM. EVMSummit.org. Yeah, check the link. They're asking for attendee lists, they're asking for speakers. You know, if you're interested, that's something to do that week.

It's tagged as advanced. So if you're the type of person that finds this call interesting, it's probably the right place for you. Also, I'm gonna be giving a talk at ETH Chicago here in about a month on the Ethereum object format. I should get my slides together in a couple of weeks and fill in those comments to add to that. Try to do my best to represent the project well and what we're trying to accomplish there.

Ypsilon's done some amazing work on it, and I want to make sure that they get people in North America aware of the stuff that they've been doing. Any other conferences that people are aware of UF stuff happening in their EVM that they're participating in and want to promote? All right, Any other discussions before we give everyone 35 minutes back? All right. If not, I guess we can all check our emails and our Discord threads.

Speaker 6: Awesome. Thanks all.

Speaker 3: Thank you.

See all Ethereum transcripts on Youtube

EOF Implementers Call 21