Date: March 22, 2023
Agenda: https://github.com/ethereum/pm/issues/746
Recording: https://www.youtube.com/watch?v=dN4tDo7Cm4k
Playlist - EOF Breakout Room Meetings: https://www.youtube.com/playlist?list=PL4cwHXAawZxpxjx7t3Aqo01pZYfHjaqG0
Links shared in chat
Matt welcomed!
Matt: Just to get started today let's go through some client updates see what people have been up to since we last spoke does anybody want to get started?
Danno
Matt: Any update on GoEthereum
Axic - Hugo worked on that
Radoslaw
Matt: Any other clients update?
(None)
Axic
Axic
Matt
Danno
Matt
Axic
Matt
Axic
Matt:
Axic
Matt
Axic
Matt
Danno
(at 18 mins)
Axic
Danno
Axic
Matt
Danno
Axic
Danno
Matt
Axic
Ayman
Danno
Matt
Danno
Matt
Mario
Matt
Axic
Greg
Danno
(at 36 min)
Matt
Matt
Ahmad
Matt
Axic
Chat qn - Do clients need to keep big eof in place while working on mega, or can we "ruin" the current big eof to make mega work?
Axic
Matt
Axic
Danno
Axic
Danno
Matt
Axic
Matt
Mario
Andrei
Mario
Matt
Thanks!
Awesome work on Mega EOF.
Date: March 08, 2023
Agenda: https://github.com/ethereum/pm/issues/728
Recording: https://www.youtube.com/watch?v=avNum0JDdOE
Playlist - EOF Breakout Room Meetings: https://www.youtube.com/playlist?list=PL4cwHXAawZxpxjx7t3Aqo01pZYfHjaqG0
Links shared in chat
Matt welcomed everyone.
Besu
(Danno)
Matt
EVM 1 (Axic)
Matt
Nethermind (Marek)
Ayman mostly covered that, so.
Matt
Axic
Matt
Danno
Matt
Justin
Matt
Justin
Axic
Danno
Axic
Specs update
Matt
Danno
Axic
Matt
Axic
Nonce behaviour
Axic
Ayman
Axic
Ayman
Axic
Greg C
Axic: shared number of changes
Pawel
Danno
Axic
Pawel
Axic
Pawel
Matt
Danno
Axic
Danno
Axic
Danno
Axic
Danno
Axic
Danno
Axic
Danno
Axic:
Matt: Anything more on CREATE 3?
Danno
Axic:
Links are stored on EOF hackmd
Specification section we can put 1.0 & 2.0 ?
Axic
Flags
Matt
Any objections? Is that okay with everyone?
Danno
was that written down?
Axic
It's the options we discussed in the last call
https://notes.ethereum.org/@ipsilon/SJbHuChTj
In Ipsillon team,
Anyone strongly in favor of Flags field?
Doesn't seems like anyone feel super strongly about it.
Pawel
Matt
Danno
Matt
Axic
Matt
Axic
what we are arguing is whether we sould go with 2.0 or not?
the example of 4844 with all the changes , we understand we cant change all the layer in a single protocol upgrade
Matt
Greg
Matt
Greg
Danno
Alex
Matt
Greg
Matt
Axic
Matt
(From chat) Ayman - we would love to see some EIP updates or separate Eips for these v1.1 and V2
Date: Feb 22, 2023
Agenda: https://github.com/ethereum/pm/issues/728
Recording: https://youtu.be/2r5PpAmesuU
Playlist - EOF Breakout Room Meetings: https://www.youtube.com/playlist?list=PL4cwHXAawZxpxjx7t3Aqo01pZYfHjaqG0
Links shared in chat
Axic started the meeting.
(Danno)
(Ayman)
(Ahmad)
Axic:
With EVM1
We'll move to 1.1 by creating a copy of unified specs and modify the changes was my thoughts.
Ayman - what is meant by non-returning functions ?
Axic: wouldn't be returning to the caller
Ahmad - how to use non-returning function
Axic: it is now a part of another EIP
D: Do all functions have to have a flag?
Axic: I haven't been a part of the validation
D: we should get that clarified on the spec
Axic: specific case of solidity already knows
D: what if Vyper or other have bug?
Ax: yeah. Daniel and Pawel may have more context
Axic: what we can discuss is that assuming we need to have this flag, where to store?
Ah: what's the size and benifit "Pure flag" will do
Axic
https://notes.ethereum.org/@ipsilon/SJbHuChTj
we are unsure if it makes a lot of benefits at the moment
Options
Danno
I see acouple of uses in the EOF world
but I am concerned about the utelity
Axic: I don't think we are going to implememnt this in 1.0 or 1.1
Ayman
Axic
Written data, buffer, non returning functions, I mean, if they marked non returning, it just means that they're not returning to the caller.
They have to be terminating. They have to have, like a terminating instruction at the end, so they still have to clearly stop execution, and regarding the purity.
If we would have security flags in the type section that would have to be enforced by validation.
And what that means is that those given code sections couldn't use specific instructions.
So if it would set said to be like a view function that would mean it couldn't use S.
Door. Couldn't use call, but could use as slow then static call, and if it's pure, then it couldn't even use as slow as an example.
So it had to. It would need to be done at validation time.
Ahmad:
I mean, like about the view and the pure like. I understand that Po.
But again, what is the use case like? What what benefit will they bring to EVM?
Axic:
I would say it's more like, the security, I mean 2 cases where it helps.
It's it could help, it's security. And it could also help with execution.
Time, because one could translate different functions.
Yeah, I see I mean you said Erot. Yeah, exactly.
I mean, if you know. But some of these don't really touch states.
You may. Yeah, you may have like more efficient options, I mean to be honest, we haven't really explored like the concrete usefulness.
It does seem to be useful, but just stating again, that the main reason we discussed this, whether we want to be future, compatible and heavier flex field.
First of all, and if not of these, make if you don't wanna be feature compatible, then we should just choose the option.
Have a special value for the non-turning functions.
Greg, I think you has your mic on. Maybe you wanted to add something.
Greg
It sounds like there's something extent you're just asking, what can we validate?
That would be clearly an error at run time.
And anything we can validate that would be an error at run time, which is probably worth validating, even if we can't easily think of a use case right now.
There's still a lot of users out there.
Axic
Yeah. So anybody has like any other hunch. If any, any of flag would be useful, generally apart from the ones we discussed.
Any other feature which could be enabled with Flex.
Ayman
I mean, we can flag functions that may fail.
Axic:
You mean, like the user reverts or have unexpected failures, you know, like out of gas or?
Yeah, can we maybe take like a just around? And where are we leaning towards?
So one option is having, you know, flexible flags.
We're not having them, because we don't see too much value.
Do you wanna like get everyone to just say which direction they're leaning towards.
Ahmad
I would go with extensible flags, but only like very limited, so I wouldn't go with 8 bits with the full byte.
I would go like something like 4 bed or something like this.
Danno
I'm weekly against, because I'm concerned about the the effort return ratio that we're gonna get out of this.
I'm not seeing what critical spaces opening up. They can only ever be opened up now, because if we needed to, we could get another format where we could put flags in it different.
Section that we could add later rather than having to put it into the type. 3.
Section, not type 3, like, but sign 3 data so I'm hesitant to get fully on board with this without, you know, a concrete value of saying this is how it makes it better in the future when we do implement it.
So that's kinda what I'm waiting for.
Axic
And I'm just trying to write up a comment on the checklist just to record.
You know what we discussed. So, Daniel, you're leaning towards, not adding flex right now.
Only addict them when when the need arises. Is that correct?
Danno
Yeah, yeah, and you know, creating space for things that we might have, I'm afraid we're gonna wind up with something like, you know, the bloom bits again in the receipt, something that sound like a good idea.
But no one ever actually implemented that, you know, are continuing to impose restrictions on us as we go forward.
Ahmad
No, I can't right now. After I heard the history, I kind of agree, and the whole idea of opio F is that upgrades can be virgin and contracts can be virgin, and since everything is virgent, what preventing us from just introduced these new flags that are needed
later on with the new Virgin. And we can easily upgrade all contracts into new contracts with this virgin with these flags, because we can probably introspect the code and see that like this function does not return and we can flag it in that case, if needed but yeah, basically.
If we can also check like, if we are, gonna have a pure flag or a view flag, we can check what that type of instructions are executed inside this function, and if there is, if these E codes are not used, then we can market with these flags all so the upgrade path is
clear, and there is no need to include it from now.
Danno
So when I say weekly against if it goes in anyway, I'm not gonna block it.
So that's what I mean by that.
Axic
I kind of agree that we have the flags.
Or this exact reason that we can make upgrades, but at the same time.
Reflecting to the past couple of months. It seems to be a lot of pushback in terms of hitting multiple versions.
So maybe that just means, you know, we. The version is really just a last resort, and you know, for things like this, it would just mean that the feature wouldn't be worthy introducing, because nobody wants a new version, and maybe that's correct because if the feature is useful
enough. Maybe that's the forcing function. But then, just checking, based on how much respective in the Uf.
Itself got. Maybe the system isn't perfect yet.
Ahmad
But does that mean that in the case that we want, we add this 8 bit field that we would have a hard work implementing this new pure view blah blah flags without a bump in the version of EOF
Axic
That's a good point.
Ahmad
I'm pretty sure it goes against the whole.
Idea of uf, like the whole idea is that we want to have things be clear, as if it's this specific version, then it has these specific set of handling of instructions and validations, etc.
Etc. Etc. And that anything that changes it needs a version, bump!
That was the premise. As far as I knew. I don't know.
Danno
So some of the pushback that I recall from the offset interop is that they want a future world where clients only need to have one version of the Edm for a current 4 I mean, they're not doing any historical validation.
Axic
yeah
Danno
They can get rid of it and remove it. So we're gonna be stuck with at least 2 because of legacy.
And ef but they don't wanna have like 5, because it's 4, 4, 4 different versions of Eol.
So that's the reason why they want the pushback, so that so that it occurred, for there's only the eof version of the legacy version.
So we would if we were to do breaking change, we would need to have some sort of a a transpation that we can point at the old contracts to bring them into new States.
So that's some of the pushback against just adding a new version is they don't want out of control code growth, like we've experienced with the current legacy version of of the Evm we've got, we're basically on 9 versions that you need a tweak and to figure your EVM to be able to validate all stuff back to the previous history once it's all the previous history version, then you don't need 9 versions.
But then you know they don't get rid of the thing where they still have to have 2 versions of the Evm. So they wanna try and put a lid on that.
That's where some of the the desire to not have multiple versions at the same time.
And I think the compromise they're willing to make is there's not multiple versions of EOF
At the same time.
Greg
Adding, a pure is compatible.
We don't need to bump the version, because if something isn't marked pure, it doesn't matter that it is.
In fact, pure, adding a pure flag later just allows us to check that something that the author claimed to be pure was in fact pure, but it has no effect on what went before.
So yeah, as much as possible. We can add new features without without breaking anything.
Danno
But the concern I have is, if you care about peer, you're probably doing an analysis anyway, and you could get the answer that it's pure without the flag.
So? Why are we requiring everyone to calculate and validate peer, when the utility cases for the pure flag existing, we're not existing are kind of small.
I'm concerned that we're pushing work on everyone for something that only one implementation, my benefit from.
And then by my benefit, I mean, they could actually calculate it themselves.
Since they already care about that data. That's my concern with the current flags out there again.
If they go in. I'm not gonna you know. Push back or try and sabotage it.
But I want us to think about, you know. Is this the right thing to do?
Greg:
Yeah, I don't know, but it's more like stating the number of arguments to a function.
You're just stating part of the interface that you can check checking it.
It, checking it at validation time. Otherwise you can do for optimization purposes, but not for checking the interface.
I don't. I don't know how far we might want to go with that. But anything that you can specify about the interface to be checked. A validation time increases the type safety of your program.
Danno
Right. But in the case of function arguments, we're actually matching up to make sure that we have this many on the stack before we proceed.
That count has an impact on the interpretation time, where is the impact of a peer in theory has no impact on the interpretation time?
I don't see I would need to be presented with some.
How would this make the interpreter better? How would this make?
You know, I definitely make an aot compiled better, because, you know, even in the cloud, because you still have to keep in the message frame the link to the state well, for period you get rid of it to the State.
But for like read-only, you know it. Where is the advantage of this?
Where does this be up and provide value to the execution process?
Would be my question rather than it's nice to be explicit about what you're adding.
What is it? Actually changing?
Greg
I don't know that it adds anything. It's just type safety at validation time.
You don't need the number of arguments you can check.
It. Validation, time that the stack is okay without stating upfront what the number of arguments is, you can just check and validation time that you use the arguments consistently.
So any of this is a matter of what do we want to state in the program itself to type, check and validation time?
And peer sounds useful.
I don't have a strong opinion on whether we should have peer.
I'm just saying that's the point of it is as I said, there might be other points, but that's the main.
Axic
Yeah, I think that all your reasoning is, it's correct that you know.
If, I'm gonna be pushed to burden on everyone, even if nobody uses the feature but I think like this, pure and view is actually a bad example for that, because we do you need to do code validation of each of the code sections.
And what this flag would do it's just reduced the number of accepted instructions in the validation run so in that sense, it doesn't actually put like extra burden on the Vm because the validation has to be done anyway.
But yeah, otherwise, I definitely agree that we shouldn't really add features which the Vm.
Wouldn't benefit from.
Yeah, Ayman on. Please go ahead.
Ayman
Yeah, I was just gonna say that I kind of agree with you.
Since these validations for pure and for view and other stuff.
Can be done, they will be done once. They will not be done twice as runtime, or even if they are not included.
Us flags like. If the Vm implementer needs to know if a function section is a pure function section, they don't need a flag to verify it, because the flag would be just I kind of end the case on to to validate whether the compiler is telling the truth, but I
wouldn't come to use to use case. We will validate it anyways, and based on the results we will for aot will emits code, or we will interpret code, or whatever the need of that flag for us.
But my point is in either ways it will be validated, so we don't need it to be in byte.
Axic
So I think the entire debate whether to have flags or not goes back to this one premise, whether we can have flags and then introduce features.
To the bumping. the EOF Version right? Because if if he cannot, then there is no point having, like a forward, compatible field, cause.
If you need a new version, we gonna change, or we could change the format. Anyway.
Ahmad
100%
Ayman
To be honest. This feels like like a very primitive, effective system that we were trying to add to the bytes code.
Here your total, or whatever other effects this can be added.
But I don't think the Vm. Will benefit from them, since.
verify them. If our Vm has some specific implementations, that are installing security.
So we don't need to impose them on everyone to.
I have to validate these functions or these flags, while we know that only certain ones will need it because they have some specific technological stuff that goes underneath.
Ahmad
So to clarify. What I mean is saying, is that if a client is seeing a benefit in having and defining, if this function is pure, or if it's view, then they can simply while validating the function, check the OP.
Codes, and if it accesses memory in load, it's a view, and if it doesn't, then it's a pure, and in that case they can flag it.
But without imposing this on everyone. Is that what you're trying to say? Amen.
Ayman
Yeah, exactly. So they can do it for themselves and use it themselves, not everyone else.
Axic
So there's one more use case we thought about is the init code.
Marking the code section which is used as in its code, and they're having, like a number of different designs on how even this code creation, like in New F 2, could work.
And but these factory contracts you could definitely have, like multiple in it, codes in the same container.
But it's unclear, you know, which direction we're gonna go with this.
And from that's that reason, just having just mandating there, that the first code section is in a code is good enough.
But there's one other site to this is had to actually finalize the creation within the init code and in legacy.
We just use the return of code to return the entire code we want to place into the State.
But any us to. It's slightly more complicated because we don't wanna have access to all the code and everything in memory.
So the current designs have a new instruction called Return Contract, which take a memory area for auxiliary data which gets appended to the container and and sorry that this was so long winded.
But the one problem, or like it's not a big problem.
But just one thing we need to do is check whether we are in an init code context, because outside of that, this return data return contract should not be valid.
So if we would have this in it code as a flag, then we could easily easily validate that this return contract of code only is present in code sections which are meant to be in code.
Ahmad
But again this will be introduced in Eof 2, which is a virgin bump.
So if we really need it in the flag, we can just say, Okay, then we will introduce the flag in version 2 and not introduce it in version one.
Danno
We were also contemplating making Vof quote to a forward compatible that doesn't require a version bump!
So that's part of the design space that we were trying to keep available, so that all the byte codes are still the same.
It's just suddenly you can now use these new opcodes that are introduced.
If you follow the rules. So there is also a path for keeping, you know, 4 compatible changes that don't require a bump like we've been doing forever in the legacy.
So one of my concerns about this is one of the discussions we had about the space we wanted for create was we wanted 0 ability to put up codes in memory cause that has I've been doing a little bit of zk, research that has a very positive impact.
If the execution and the logic are entirely separate.
So I mean, maybe we need to keep it open just in case it has for net code, and just do the bitpacking and don't use any of the flags.
That might be the solution that we have here. But I'm skeptical of some of the flags, but the nickel flag we might need that space.
We might not in that everyone's gonna use a nit code.
But I'm still in favor of solutions that involve Byte code, never hitting operational memory that would make things a lot better for the Zk world.
But I think may open up new possibilities. But that's the discussion we're gonna have in much future date.
We just need to preserve space for us to do what we need to do.
So that might be the argument. We need to keep the flag space open.
Axic
So if you would have to send it code flag, then then you would be in favor, having, like a flax filled.
Danno
So I I think the possibility that they could flag, I think, is a strong argument to the possibility of a pure and static flag, so that I think there is.
There's case for we need to keep it flags open, but not specify any of them.
In the 1.1 version, but just downline. These are the things we're considering.
But we're not committed to shipping any of them yet.
Axic
Yeah, exactly. I mean, we wouldn't define any of them.
We only have 5 min left. I think maybe the best way forward, because we didn't had a number of people.
Like. I've been like active previously on this call.
Maybe we shouldn't do a final decision on this today, anyway.
So I would suggest that you know, all of you.
Just think about this. You can leave comments on the document as well, and then maybe on the next call we should be in a position to make a final decision on this.
But there's one last topic I think we can fit into the 3 min.
What is the best way for the Us. 1.1 spec.
And the number of options I see is we just create the diff just state, you know how it changes from us.
One and under option is that we take a copy of this unified spec and just modify it.
So it has everything clearly. What 1.1 would look like, and then you know whether any of these should be any IP or not.
So what's the but still you, what direction should we go?
Greg
I'm not sure what document you're referring to at this point, but I'd really like to see a man up Eip pulling the salt together, cause we have a lot of hack.Md is sort of scattered around. It seems nice I can't always find them, and I can't always can't always use them effectively.
Cause. I'm not in the organization.
Danno
In addition to a matter eip, I would kind of be in favor of going back and changing the eips.
I mean using's never shipped in an approved fashion.
So they're not finalized stuff like we would be increasing the scope of what operations are invalid.
We'll be adding entries to it. I think we just go back and edit that E to add it to it as far as the differential, and people who are curious about the history can just go back to to get the Github and look at the state of the spect at a certain time
so that's you know. Maybe in the comment stream we could point them to a static copy of the Markdown and say, here's what the meta-eat looked like.
At this point in time for those interesting, but I don't think we need to keep this rejected version in in eips, because it wasn't ever fully shipped and finalized.
But you know, if we wanna do a new one that specifies the changes on top of those 3 eats that's a viable path or 5 each, or haven't been Eastern. This.
Axic
Yeah, I think that only reason we haven't just gotten changed.
It because we've seen there, you and maybe this is wrong.
But we seem very that they're the clients who started work on us.
One. They can complete that work with the test suite.
As it is, and the Ips, and then maybe it's easier to once everybody is on on the same page, just to modify the Ips, and roll out the ewf 1.1 changes.
But maybe this, this is a better assumption, and we don't need to wait for everyone to finish it with one.
Greg
What are we actually going to ship?
That is what's actually going to go to final.
Axic
Hopefully 1.1.
Greg
Then that's what the IP needs to describe. Right?
Axic
Yeah, I think, basically, it's not affected that much because basically
But you're getting that in mind. What would you?
Are you guys planning to merge through the current set of Prs, which is the F one.
Or if you do like this 1.1, then you would just keep them open, and then do the changes there.
What is that?
The second call.
So!
Yeah, so like, the idea is that we don't really like to merge stuff.
If it is not tested on the ethereum tests, consensus tests, etc., etc.
So we keep everything in a Pr and a branch. We keep updating it.
If eof. V. 1.1 def. Spec is finalized, then we will implement the changes, and then we can then test everything.
Once the tests are finalized. It's always for.
Never mind, it's all the bottleneck is always ethereum tests.
In my opinion, if these are finalized, then we can move a lot quicker.
In my opinion.
Okay. Then, since we are like on the to what they are, I think my suggestion is then that we can probably create a single Pr on the Ips repo and not merge it, which has all the changes, and we can we can discuss that the changes there and hopefully all the
consensus tests are our execution. Tests are merged soon enough with 54, 50 in the depths.
We can just record, you know, all the commitations of like the final Us.
One test suite and eips, and we can record it in the checklist.
And so we people want to test for us one. They can still do that.
And we can start merging the IP at that point.
Does it sound like a plan?
Sounds reasonable the Pr, I think, solves the other eip concern, and we could have one location for them, and just merge the Pr.
When we're fine ready to finalize it.
Date: Feb 08, 2023, 2022
Agenda: https://github.com/ethereum/pm/issues/712
Recording: https://youtu.be/W6A23FhyfQc
Playlist - EOF Breakout Room Meetings: https://www.youtube.com/playlist?list=PL4cwHXAawZxpxjx7t3Aqo01pZYfHjaqG0
Links shared in chat
Matt Garnett started the call with a quick recap (since interop).
(Danno)
Tag Matt in case of issues
Danno - issues around read & get base fee
Matt: Nethermind or Erigon?
(None present)
(Matt)
(Axic)
Matt: Looking to implement B11 R? (check at 5:33 min)
Axic: Is that block builder
Matt: Yes, this is required to be used with the execution spec test.
I think T8 is the only requirement to be used with Retest ETH. With the Python spec test, we should have B11 R as well.
Axic: We haven't discussed it yet.
Danno: My concern with B11 R is that it is very tightly coupled with the chain format, the current Petricia trie. Will that be possible to have Python clientuse one client use T8 and other client B 11 R?
Will that hybrid discussed as an option?
Matt: We could add the ability to the Python spec or testing library to different binaries. But I am not sure what do you mean by B11 R tool is tightly coupled with like the Patricia trie because it should really just be like Computing the RLP of a block and computing the hash over that
Danno: yeah maybe I'm thinking of t8
Matt: Yeah
Danno: but the thought that's crossing my mind is you know with this utility of this for likely or two clients they're doing switching their hash tree to like the sparse Markle tree, is there a way to make these tests useful?
For the layer 2 they're pushing evm compatibility so we can run a test on and say no you're not here's your errors or yes they pass the tests here have a cookie
Matt: yeah that was a good question we should’n think more about that for sure I do
think that a lot of the ways these things are structured it's something that we can’t support with
relative ease but yeah it's just getting to the point where we might be boiling
the ocean to support everything and right now we want to make sure that we are supporting L1.
Danno: Focus on Goerli and Mainnet
Matt: we can think more supporting L2.
Anyways we can talk more about this on testing the last thing that I wanted to say on this is I think that supporting B11R would be great and I think that you know writing the tests in the python formats is is pretty nice because it's really simple to change all the tests where I think that with the retest ETH format it's a little bit more difficult to go back and change tests as the spec changes. and we could talk about that more in a few minutes is are there any more updates on clients?
(Axic)
Axic
Pawel
Matt
Pawel
Matt
Danno
Matt
Danno - 1.1 will be beta
Pawel - 1.1 is what we are testing, we can apply additional changing for testing
Danno - we can't ship both. so 1.0 is valuable for testing but if shipping 1.1 , Besu won't be able to support 1.0.
Axic
We need to do as much as possible to be done with what can be shipped in Cancun
Matt: Stay vigillent to SSZ changes
also keep an eye on this proposal in general wrt Cancun as it is goining to be relatively large for Exec client
v1.1 is the best bet as it will be difficult to have EOF, 4844 and SSZ in one upgrade.
Axic
-> Axic screen share and discuss
v1
v1.1
v2
(watch video)
Matt
Axic
-> we need to decide which is a better direction
Axic
Matt
**Danno **
Axic
Pawel
Matt
Axic
Danno
Matt: All right
Axic
zoom chat
Date: Jan 11, 2023, 2022
Agenda: https://github.com/ethereum/pm/issues/705
Recording: https://www.youtube.com/watch?v=PKwMCmxHcas
Playlist - EOF Breakout Room Meetings: https://www.youtube.com/playlist?list=PL4cwHXAawZxpxjx7t3Aqo01pZYfHjaqG0
Links shared in chat
Matt: It was decided last wee that we have EOF Implementers call every alt. week of ACDE to get a hold with the game plan for EOF, at least for next couple of months.
none
Remove PC verbiage
Matt: Danno listed (Remove PC verbiage), would you like to explain?
Danno
Alex
4600 still has how PC is modified
the intenet is about the internal PC representation not what it is returning
Alex
Danno
Matt
Pawel
Axic
Danno
Matt
Danno
Matt
Support in tracing
Danno
Ipsilon team updates
Unified EIP?
Danno
Matt
Alex
Matt
Alex
Matt
the contract creation aspect is under specified
implementers may be comfortable with smaller specs
in that case, we lose the importance of unified specs
I think, as things tends to change, it is good to have them at a single place
Pawel
Matt
Danno
Alex
(at 30:00)
Danno
Matt
Danno
Mario
Matt
Mario
Matt
Ahmad
Danno
Mario
-I'd agree that wouldn't be a good test case
Ahmad
Ayman
Matt
Alex
Matt
Ayman
Matt
-> continue talking in the #interop channel
Matt: Are people okay with tests in Shanghai + EOF or change it to Cancun?
Danno
Ahmad
Matt
-> let's put tests in Cancun
Danno
Alex
Matt
Pawel
Andrew
Daniel
Matt
Danno
Matt
Ahnad
Matt
good to spend time and figure out what needs to be done that week
Probably Tuesday
Tim wants to have a session about EOF 2 on the idea of Vitalik
continue talking about async
what can be prepared in a week and half?
Ahmad
Matt
Pawel
Date: Jan 02, 2023, 2022
Agenda: https://github.com/ethereum/pm/issues/692
Recording: https://www.youtube.com/watch?v=Q-sUTwCvm6M
Playlist - EOF Breakout Room Meetings: https://www.youtube.com/playlist?list=PL4cwHXAawZxpxjx7t3Aqo01pZYfHjaqG0
Links shared in chat
Matt
Danno
Andrew
matt: will discuss terminating today.
Andrew:
Pawel:
Pawel
Ahmad
matt: next on agenda
Rodrigo:
matt: let's move on
Pawel: what has changed since last call
JUMPF
instruction, partly because of some other changes on the way, decided to remove.PC
instruction decided to be rejected by validationRETF
does not clean stack - automatic stack clean up was removed from the spec. the compiler will take care
matt:
pawel:
Ahmad:
matt: what do you mean?
Ahmad:
matt:
Ahmad: whats the use for data section?
Matt: for contracts using as data, where data could be used for execution.
Martin: CODECOPY - does that operate on whole container
Matt: yes
Danno: Vitalik wanted to have it
Pawel:
matt: what are the main tasks?
pawel:
danno: usecases will have big limitation, i think we should fix it before including
pawel:
Danno
matt
GregC
Martin
greg
martin
matt
danno
pawel
matt:
Ahmad
martin
Ahmad
martin
Ahmad
matt
Ahmad
matt
Danno
Matt
Pawel
danno
Pawel
matt
matt
Andrei
Matt
Andreai
Matt
mario
matt
marek
matt
Marek
danno
matt
tim
matt
Andrew
matt
Ahmad
matt
Ahmad
Pawel
matt
mario
Andrei
mario
matt: Martin doing some fuzzing
danno
matt
mario
danno
pawel
matt
Pawel
matt
-> next EOF breakout - make a call after ACD
Date: Dec 15, 2022
Agenda: https://github.com/ethereum/pm/issues/690
Recording: https://youtu.be/bOID9rklh4U
Playlist - EOF Breakout Room Meetings: https://www.youtube.com/playlist?list=PL4cwHXAawZxpxjx7t3Aqo01pZYfHjaqG0
Links shared in chat
Geth
(Matt)
Besu
(Danno)
Erigon
(Bob)
Vyper (Bob)
Solidity (Axic)
Ipsilon team
Pawel
header format
Matt
Pawel
Matt
Moody
Pawel
Matt
Pawel
Danno
Pawel
Greg C
Matt
->More support for flexibility on chat
Axic
Moody
Alex Beregszaszi
Moody
Alex Beregszaszi
Danno Ferrin
Moody
Danno Ferrin
Moody
Matt
stack cleanup on RETF and JUMPF
Pawel
Danno
Daniel
Greg
Pawel
Greg
Daniel
Pawel
Daniel
Pwel
Matt
Greg
Matt
Pawel
Danno
Pawel
Matt
Daniel
Matt
Danno
(Chat)
Danno
Axic
How about considering leb128 in the header however?
Danno Ferrin
Alex Beregszaszi
Ayman
lightclient
Ahmad Bitar
Moody
Danno Ferrin
disallowing unreachable code?
Matt
- Do we want to add?
Greg & Pawel
- yes
Matt: needs to be added in EIP as not in unified specs yet
EOF spec level open issues
(None)
Greg
- will have max heights field
Matt
- EIP still needs to be updated
Danno
- RETF with an empty return stack is an exception, correct?
- If we get RETF, the call will be retured?
Pawel - Yes
Matt
Matt
- targetting for Jan 05
- EOF needs to be Shanghai ready. What people think?
- I'll be available as much as I can, if anyone has any questions
- If we have spec tomorrow eod, people will be working on test
Other discussions
- Post by Vitalik, take a look
- Vitalik says, if upgrading EVM, new possibilities are there. He is proposing banning Opcodes.
- Relatively big change. Will be discussed on ACD.
- what team can do is join ACD ready with EOF
Alex
- when we proposed EOF, we wanted to have a data copy opcode
- data copy will be used for data section
- a lot of contract depends on immutable
- EOF code outside from the legacy code can be viewed
- I am interested in restricting stuff that came up last week, last minute changes that we didn't explore
Bob
- will be useful to have a full testnt
Matt
- cross client testing is higher priority than testnet
- testnet & cross client can be done in parallel
Date: Dec 02, 2022
Agenda: https://github.com/ethereum/pm/issues/677
Recording: https://youtu.be/586Y_bb7myc
Playlist - EOF Breakout Room Meetings: https://www.youtube.com/playlist?list=PL4cwHXAawZxpxjx7t3Aqo01pZYfHjaqG0
Links shared in chat
Geth
(Matt)
Crypdough.eth: I'm not a part of any client team but I'm going to work on the GETH implementation of EIP-5450 this weekend
Besu
(Danno)
Nethermind
(Marcin)
EthJS
(Holger)
ETC
(ziogaschr)
Axic
Matt
Next steps:
Daniel K:
Matt: People may have breaking point with more EIPs is my thought
Tim: Will it be enabled for the entire EVM?
If not done in the 1st version will require version bump?
Matt: No. It's not a requirement for the functionality we need in EOF
It will be a h/f when done but is a compatible upgrade.
Matt - worried to go to ACD with a new EIP to be added to the Shanghai upgrade. I feel we should focus on what we have now
Daniel: We want it and can write something for persuading
Danno: Write about Gas saving, it may help
Matt: Gas saving may go a long way
Tim: If you do want to discuss on ACD, I can post it in advance. Starting a pre-discussion may help get added in Shanghai consideration.
Hearing for the first time on Thursday will have push back.
Matt: Screen sharing - General checklist
General
GColvin: I think it is a good idea.
Matt: Are we happy with the current position?
People feel strongly about changing?
Axic: the idea will be all EOF Opcodes will go in the range. Doesn't really matter
Matt: Revisit in future.
GColvin: Will make sense to keep them together, leave a little room to expand.
Axic: Probably Call F should be next to JUMP
Matt: Has been accepted
Axic: 3670 has some rules. We are improving motivation.
It would make sense to merge them together.
Matt
EIP-4200: EOF - Static relative jumps
Matt : stick with currently specified (+3 bytes)
Additional RJUMPV
It is a JUMP table fixed in the code. Jumps are specified.
Skip unless specific comment
Stack cleaning -
GColvin: Prefer users to clean
Axic: The final way to determine will be to measure the impact in next 2 weeks. That could be a datapoint to decide. If there are measurable differences and no major downside then we should go with it but it will depend on the numbers.
Matt: Probably wait to see
Daniel: We want to avoid
Axic: Implemented by Pawel
Matt: Terminate instructions don't care if the stack is clean
Axic: Pawel may explain. There is always a terminating instruction but not the last instruction. Need to be confirmed with Pawel.
Matt: Best to look into this document.
(Check video at 0:36)
Matt
Ahmad: Specific time to finalize all EIPs? Now, all EIPs are in PR?
Matt: Won't say it is finalized; early next week looking for spec freeze for client implementers
(video at 0:42)
A few attempts were made. Few different options
Goals are defined in the document.
Axic
Matt: Client team - how do you feel in general about these proposals?
Danno
Axic: The goal explains
Ahmad
Matt: Fixed order and extensibility will be nice to have.
Axic
Matt: How to move fwd towards making decision to modify the container formats?
GColvin: It seems like in the course of discussion, only one meet all the points and generally meet the goal.
Matt: Not making any decision today, but seems like "Sections kind" is where most of the people are leaning towards.
Will make decision on discord discussion in next few days.
Matt:
Launching EOF testnets
Matt: From Geth, less than 1 week needed. In 2 weeks should be ready for testnet
Ahmad: Nethermind can join the testnet
Besu - Danno - Seems okay
Matt: Opening a cross clinet testnet is critical, but reasonable optimistic goal.
Date: Nov 18, 2022
Agenda: https://github.com/ethereum/pm/issues/666
Recording: https://youtu.be/fperqiUlYTY
Links shared in chat
Matt Garnett lead the session. The main goal waas to go through the checklist by Epsilon team and make decision on open items.
Matt: I think so for now - if for some reason shanghai falls through, it could be removed.
Matt: I am in favor.
Matt: I am generally in favor of the proposal.
Matt: Anyone in favor of allowing the legacy contract creation?
Axic: Is there a usecase? Unless a usecase is found, we don’t need to allow legacy contract creation by EOF.
Matt: Let's be restrictive in the default case.
Matt: Thoughts on this?
Axic: Code size limit =container size limit. Current limit would apply to everything
Axic: The main qn is are we open to complicate eip-170 - likely. No
Matt: Let’s not complicate 170
Axic: We should ask, maybe Martin, why was this limit added in the first place, then we will get an answer.
Jochem (Comment): What if "remove selfdestruct" EIP gets in?
Matt: What do people think about deprecated or not?
Axic: I am in favor of call code; more clarity will depend on the future of Selfdestruct
Matt: I think is better of without restriction
Crypdough: max code size was introduced during Spurious Dragon
Draganrakita: should be okay just to remove. Should have done long time ago.
Axic: If no changes are made in EVM for Self destruct then EOF shouldn’t allow it.
Dragonrakita: in both cases, we are removing selfdistruct.
Matt: Anything else on 3670?
Matt: Axic is in favor of +3, because it is more jumping fwd than backward
Danno: Jump-3 becomes an infinite loop?
Axic: yes
Matt: I have no objection, anyone else?
Pawel: I have a slight preference
Daniel: the offset doesn’t make much of a difference for Solidity pov. Doesn’t matter to us (Solidity team).
Matt: we are still at +3 bytes, not sure of making decision, think we should just stick with what we have.
Axic - 2 data points may help decide
- Different EVM implementation
- Solidity team
Pawel said current evm has a difference, we can look at evm implementation. We want to make evm impl. Simpler.
Danno: JSR & Java does it from the current PC not the next. Let’s change it as Java & JSR want it changed.
Pawel: Any other language?
Matt: Let’s revisit after we collect more info. Maybe next week?
Axic: there is one more data point Jumpdest
Daniel: We will share what we at solidity get as use cases for this.
Matt: People seems to be in agreement
Matt: It feels like it make sense to have it in array?
Danno: 2 is code repeated
Matt: No decision yet. Looks like there are different ways to do it.
Pawel: That's complicated. Related to validation as well. For EOF Functions EIP, we don't have strict validation yet.
Mostly we need to have number of output specified for an input.
It seems we need to modify the stack, unless we keep it like this from how it goes. Maybe we can discsuss later offline
We can discuss this later when we go to stack validation as it is kind of repeated there as well.
Matt: yeah
Daniel: It may shift the complexity to us, but that should be fine, we have been doing that anyways.
Pawel: yeah, that's correct. We are awrae of it.
Daniel: it's fine. It won't make things easier for us but won't make it harder as well.
Pawel: Okay, I can handle this later with proposed changes.
Matt: seems okay
Danno: that will limit to meg and half
Pawel: no, the code size limit
Matt: It seems like people are in favor. To me 256 seems like a small number
Matt: I think if we go with the mandatory type section, this isn't all that necessary since we'll probably just want to drop the section ids.
Matt: write a couple different approaches to compare
Axic: in favor of parsing at expense of deploy
Matt: Martin has been loudest voice not in favor of this EIP.
Danno - is there anything than future hitting that we can pitch for?
Pawel - No - I think this is the best time to introduce
Matt: Motivation section has been described as underwhelming by a few people. It would be good to expand on how 5450 can improve the situation with JITing bytecode, etc.
Next steps