# EOF Implementers

:closed_book: Notes #13
--
:::info
[Quick Notes #13](https://docs.google.com/document/d/1w_yoxm0O-RwX7cguBRSjMYs5qv40uYoh3961MNS1sEg/edit#)
:::

:closed_book: Notes #12
--
:::info
[Quick Notes #12](https://docs.google.com/document/d/1w_yoxm0O-RwX7cguBRSjMYs5qv40uYoh3961MNS1sEg/edit#)
:::

:closed_book: Notes #11
--

:::info
[Quick Notes #11](https://hackmd.io/@poojaranjan/EOFImplementers11)

## Summary
- It is a little early for EOF devnets for testing changes.
- swapn/dupn will be added to specs
- Alex suggested discussing specs changes wrt to ERC-4337 in a future meeting.
- Alex will update new checklist for mega-eof with client teams testing repo links added to be shared for cross client reference.
- Next meeting - April 19th at 15:00 UTC.
:::

:closed_book: Notes #10
--

:::info
### EOF Implementers Meeting 10
**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?

### Clients update
#### Besu
**Danno**
- I haven't done anything in the past two weeks I've been distracted with another issue at hydera so that's a pretty easy one.

#### Geth

#### Nethermind
- not much added besides implementation of JUMPF EIP

#### EVM1
- Merged EOF EIP
- it implements everything according to scale of EOF
- Dec vesion of EOF
- PR is fully merged
- it does everything with an exception of mega EOF
- did spec work

Matt: Any update on GoEthereum

Axic - Hugo worked on that
- PRs on the repo
- some bugs are identified

Radoslaw
- I ran the state of EVM1
- found couple of them seek test files
- related to different issues
- 1st - not burning all the gas
- 2nd issue is realated to CallF

Matt: Any other clients update?

(None)

#### Compiler update
Axic
- haven't been doing anything extra since Dec
- DSolidity team is waiting on confirmation before investing any more time

## [Mega EOF end game specs](https://notes.ethereum.org/@ipsilon/B1nnZ1fl3)
Axic
- we agreed to make a PR to describe the changes, haven't done but duplicated and mentioned the changes
- we could do a diff
.
.(at 12 mins)
- We can have a recommended version at the known address
- besides that Data opcode
- if the target is EOF, we treat it as EOF 00
- It include delegate call change
- In this version, we chose to disable both, for the unknown unknows
- there are some oints that needs to be discussed

Matt
- if I delegate call to EOF. Can have a Legacy contract for

Danno
- that's my concern
- I am not seeing taking away features instead of adding them

Matt
- I am generally in favor of knowing unknown unknowns
- but given the use case,

Axic
- coming from Danno are important

Matt
- yeah, it is pretty important
- Are there any outstanding comments

Axic
- bigger questions regarding specs are
- discuss Delegate Call
- Inint code list on the tx; decide on the limit and cost.
- I have some idea on limiting, but haven't worked on that yet
-

Matt:
- Init code is validated?

Axic
- Last time we decided CREATE tx, following that , we don't want to validate on the tx level as the cost will be insane

Matt
- so it will just be the data cost in the INIT code

Axic
- yes

Matt
- becasue it is accessible, the blob data is only receiving the half of the data

Danno
- it can be design issue that only one blob per block

(at 18 mins)

Axic
- Inint code including auxilary data
- not sure if we can reach to an agreemnt today

Danno
- It will break Uniswap & Sushi Swap Assumption

Axic
- the cost of inint code in transaction, may get an agreement but hashing require more brainstorming

Matt
- Make sense
- Anything else on specs

Danno
- have soem questions
- is there a need to keep 6364

Axic
- I don't think we need to keep it.
- It could be removed later for breaking changes
- no strong opinion

Danno

Matt
- Should we talk about scoping?
- cool
- does it make sense to have EOF in 2 parts of Mega EOF in 1 unit?
- Thoughts

Axic
- I do have an opinion, but don't want to sway

Ayman
- we want EOF to go in one unit from Nethermind, no intermediate step just one

Danno
- for me it's a key for 4844 scheduling
- As we start closing down the scope, I am open to options

Matt
- In my view pushing EOF will be difficult,
- we could realistically be doing next year
- I like the idea of doing EOF in one go.
- but will be difficult from testing point, I worry

Danno
- we can't test everything until it is complete
- it is a question of how much testing infra we want to put in

Matt

Mario
- I haven't been looking into it recently
- SO far my thoughts are they are already complicated

Matt
- I guess that's perspective of non-Ipsilon people
- Ipsilon team wants to share

Axic
- I am leaning towards including all at the same
- I am concerned aout the size, and this will go outside the boundry of the EVM
- It is a big worry for me
- Once we cross this boundrym it will be coordination wise getting there
- So far we're working within the EVM
- there can be other proposal that people think more important than EVM
- If we have to split , I'd like to include Data Opcode, & roll out as they are simple.
- In 2nd roll out - Create 3Ctreat 4 and tx

Greg
- It make a lot of sense to me
- I'll be motivated to see go in soon

Danno
(at 36 min)
- the scheduling coming up in next ACD will be the driver

Matt
- generally agree
-
- keep an eye out for later release if realized the scope is quite large
- we can cut down for a future fork

Matt
- What other things need to be done to move EOF forward
- Most of the things Ipsilon team is already working

Ahmad
- I'd emphasize on test cases as we depend a lot
- Hive test
- It's worth thinking about that

Matt
- Ii agree but to generate these tests, we need ref implementation
- Make a copy and start working on the future branch

Axic
- the more annoting part is the testing
- wrt to fork
- We can consider it for Cancun, and in the process if it feels like we need to split then will do it for the next fork

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
- Create 3 was a bit more work but all of them were already worked on
-
- everything outside create 4 we should be in a good position in next week or a week after
- if anyone is available to start collaborating, that will be way forward

Matt
- Cool
- Would you want you set a target date?
- for specs "frozen" so client team can start implementing.

Axic
- we should start some basic tests soon

Danno
- do we have the header format

Axic
- added this morning by Andre

Danno
- I am going to work more on this
- will see to it

Matt
- sure, there will be more discussion when people will see Mega EOF

Axic
- anyone got to a chance to read the Mega EOF

Matt
- Glazed over

Mario
- qn regarding this and the previous version
- should I keep separate branches for the test for prev & Mega or how should we go about it

Andrei
- how implementation should be organized
- it's not difficult to have them separately, but it's up to you

Mario
- Okay, thanks

Matt
- Any final comments

Thanks!
Awesome work on Mega EOF.

:closed_book: Notes #9
--

:::info
### EOF Implementers Meeting 9
**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**
* https://notes.ethereum.org/@ipsilon/BJujV7-Tj
* https://github.com/ethereum/EIPs/pull/6546
* https://github.com/ethereum/EIPs/pull/6328

:::

Matt welcomed everyone.

### Clients update
**Besu**
(Danno)
- we're starting to test out its T8 and software um and getting some feedback from the testing team
- it runs against the execution client specs and just running around some of the undocumented corners that we're encountering and
- what's expected like if the reward's negative they don't want any block reward touched or stuff like that.

Matt
- cool uh Alex anything to add from evm1?

EVM 1 (Axic)
- I think you're very close to merge the Big EOF with PR which basically implements everything matching what are in the eips and the test Suite um because previously these were like several different PRS.
- I believe Andre is on the call so he could expand on it but I think we have a mostly finished implementation of the 2.0 stuff in regards to create. I can give some updates later on on the call but we did a number of like back and forth in in terms of the design but I think we're nearing down at one design which is a bit different to what we discussed.

Matt
- okay yeah cool let's talk about that in some more time. Marek anything from Nethermind?

**Nethermind** (Marek)
Ayman mostly covered that, so.
- Adjusted to the latest changes
Ayman
- okay uh for Nethermind, we implemented a draft for v1.1 and for jump F just to be ready and currently trying to see how virtual will be easily integrated into what we have right now and we kind of have some opinions when it comes to what has been discussed and what we try to implement hopefully we'll discuss them later this call

Matt
- okay it doesn't look like anyone from the compiler teams is here I don't know, Alex if do you have any thing to share on that front if not we can talk about specs?

Axic
- yeah I don't have anything but the Solidity team has an offsite thing in the last week
- which probably is more about planning and
- I expect you to get more feedback from them starting next week once they finish with offsite

Matt
- that okay sounds good also that made me think I remember talking to somebody at ETH Denver who is saying that arbitrim is planning to roll out an implementation of eof has anybody here talked to the arbitrim team at all

Danno
- Is that EOF or EVM

Matt
- Unsure, but one who told me had worked on EOF
- I think that it is uh it's eof not EVM+

Justin
- what about evm Max

Matt
- that is a separate thing

Justin
- Okay

Axic

- you know with the evm plus they may have read our minds. They realized we were thinking about renaming EOF to evm next or EVM Plus but we are too slow to make a decision and announce it on Twitter.
- so I guess they they picked up the evm plus name instead and
- Greg what is evm plus?
- it's nothing to do with evm as far as I know, its WASM.

Danno
- It's Arbitrum's way to allow smart contracts to call wasm smart contracts.

**Axic**
* Hugo is working on Go-Ethereum PR
* Moving everything to Cancun as currently everything is set to Shanghai
* He is almost finished and we will push them to testing suit.

Specs update
- Axic
- since 2 weeks, we (Ipsilon team) have 2-3 discussions for changes
- looked into PRs
- madeup our mind for flags & 1.0 & 2.0 changes
- https://github.com/ethereum/EIPs/pull/6546
- It's about changing table size
- Is anybody against merging this change?
- At least I know, Danno was

Matt
- It feels uncofortable to have this table size as proposed.

Danno
- There is no clean way to allow what we have to allow without this wierdness

Axic
- the reason we are leaning towards this test because the proposed change is done through the users side
- the use case benefit

Matt
- I agree with the reasoning.

Axic
**Nonce behaviour**
- https://github.com/ethereum/EIPs/pull/6328
- Pawel can better explain
- https://notes.ethereum.org/@ipsilon/BJujV7-Tj
- we think the lagacy EVM code is allowed to have EOF code is the best option
- The proposal is that the lagacy EVM code can not (Check video at 17- 25 mins)

Axic
- as we progress with 2.0 there are chances it will be simple enough to move ahead with 2.0. Until that is figured, this is the option we are looking at.
- In short, either we go with this option or 2.0 directly

Ayman
- we don't do 1.0?

Axic

Ayman
- from our pov, we'd like to do all of them not separately.
- We don't have to keep extra stuff in mind

Axic
- Exactly we ended up disliking pieces that you mentioned

Greg C
- why we could not go to 2.0 just yet

Axic: shared number of changes
- 2.0 isn't fully designed
- We'll get more clarity by next call
- The next implementer call should be a good time to decide the direction we are going

Pawel
- 2.0 is mostly the CREATE3

Danno
- we are also reworking

Axic
- 2.0 is more of a soft ver bump

Pawel
- we have most of the things done for 1.1
- we can continue testing
- 2.0 is more in a design phase

Axic
- we move on to spec discussion and circle back if we have time at the end
- In 2.0 the CREATE instruction don't care about the account nonce
- We can't fully ignore the nonce

Pawel
- the spec how it works is unclear
- the nonce is bumped when you create a
-
- the create tx, the nonce is always bumped
- (at 30 min)
- https://github.com/ethereum/EIPs/pull/6328
-
- we need to make sure EVM imple and test implementation are in sync

Matt
- Anyone have an opinion
- I don't feel super strongly

Danno

Axic
- Prevrando instead of #

Danno
- yes
-
- you do have a deterministic contract

Axic
- I think the majority of contract don't create anything problematically
- Uniswap is one exception with Factroy

Danno
- I'm more concerned about college /boot camp

Axic

Danno
- We need to create

Axic
- we need to create distinction between the two
-

Danno
- we don't need to fix it today, but keep in mind

Axic
- we haven't looked into this and any help will; be appreciated

Danno
- where can we find it

Axic:
- the state of the art is the PR
- https://github.com/ethereum/evmone/pull/553

Matt: Anything more on CREATE 3?

Danno

Axic:
- edge case we found was data size limit

Links are stored on EOF hackmd
Specification section we can put 1.0 & 2.0 ?

Axic
**Flags**
- We discussed in the last meeting but we were torned.
- Init code as a flag doesn't seem to be a good way
- Our proposal is to have a

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
- prefernce to have
- easier to flag
- It's harder to explain why these values been accepted

Matt
- I do like 0X81 for forward compatibility
-

Danno

Matt
- Anyone strongly agianst 0x81?
(None)
- I think we shouldjust go ahead with this. Is that okay with you Alex?

Axic
- I am the only one to have the flag field.
- Not strongly want to champion that
- I am okay with the decision

Matt
- want to talk about EOF2?

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
- It's possible but I am not sure how irt will turn out with SSZfication
- Couple of different camps
- It will be useful
-
- Any other thoughts on EOF2 ?

Greg
- Who is involved in SSZ discussion

Matt
- Me

Greg
- If we are working on new transaction type then let's get it done.

Danno
- so for me if we're gonna do by what's currently called pre-compiles it opens up a can of worms because there's a pre-compiles we could always used to do through evm code but now we got something we can't do through evm code and we're publishing system barriers. I mean I'm fine with that but it's it's newground that we should make sure we do correctly.

Alex
- https://notes.ethereum.org/XUduD_XBS5yOQkw0uPZ_iA#Crazy-transaction-version-Option-3
- I may have been a tiny bit misleading so even the pre-compile option requires some changes to the transaction format but not as severe as introducing like a special create transaction. I mean all of this is written down in in this EOF2 document but I do understand the document is long and confusing so likely it may not be clear enough what is being meant um but some of that is under this heading.
- In short what this means that we would have another kind of create instruction like **CREATE4** or whatever which gets the init code from a transaction context and the change we would need to do to the transaction formats is the way we have you know like the blob data in the in the 4844 transactions we could have another list of blobs and these are init codes, ***init code blobs*** and this new create instruction would take an index and index into which of these init code blobs is being used from the current transaction context.
- so that would be the size of the changes um and this is against the option where we introduced like a special create transaction type
- the the main reason I'm leaning towards is just the complexity of having a new transaction type but also for more for compatibility reasons because it seems that now transaction types are proliferating there's just you know a new transaction type every single year and this doesn't seem to be a sustainable path.
- if we would end up with proposing this option I would actually go strong in the you know SSZ discussions to state that this new like 4844 transaction type is only for in contract interaction it cannot be used for any kind of creation and it will have these like init code blobs as well
- in that Paradigm we only have the Legacy transaction types which are as complex as they are today but this new unified transaction type will only be used for interactions and it can have a number of different hidden payloads used for different meanings.

Matt
- we're a couple of minutes over time now we should probably wrap this up any last comments?

Greg
- just the one I made in chat that anything we don't get out in Cancun itcould be years before it gets to the main chain.

Matt
- yeah okay

Axic
- one concluding comment, I think in the next implementary call we should dedicate it to the eof 2.0 discussions and I think we will work hard from Epsilon to actually post a document before that but let me know if you have any any other like strong opinion and we shouldn't pursue like this you know transaction Direction I was explaining

Matt
- okay yeah that sounds good
- thanks a lot guys we'll have the implementers call number 10 in two weeks
- I'll post the agenda for it hope you guys have a good rest of your week

(From chat) Ayman - we would love to see some EIP updates or separate Eips for these v1.1 and V2

:closed_book: Notes #8
--

:::info
### EOF Implementers Meeting 8
**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**
* https://notes.ethereum.org/@ipsilon/BJujV7-Tj
* https://notes.ethereum.org/@ipsilon/eof1-checklist

:::

**Axic** started the meeting.

### Clients update

#### Besu
(Danno)
- Specs are setteled for implementation
- ready for implementation test

#### Nethermind
(Ayman)
- doing implementation of EOF 1

(Ahmad)
- Qn. when going to hf, it would be 1.1 withouth the first version
- is there anything to discuss about 1.1

**Axic**:
- definetly a lot to discuss

#### Ipsillon
- starting with EVM 1
- fully supported
- not 100% complete, logs bloom filter is being implemented
- Current version is fully capable of EOF test
- EVM 1 could be used to fail test
- Besu seems to be the best clients to test with implementations already done
- We found some cases, error handelling

With EVM1
- we did complete review of the checklist
- testing suites are mostly complete
- 4750 & 5450 haven't been merged
- we consider eof1 almost complete
- type section flag yet to be discussed
- It opens up to support more flags
- If purity make sense, we'd like to discuss

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
- The callee has exact number of output
- Solidity has the main use case in error handelling functions
- The return of function wouldn't be validated

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
1. Reserve value
2. top bit as a signal and bottom 7 bit (check audio at 24 mins)

**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**
- should compiler be visible

**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.

:closed_book: Notes #7
--

:::info
### EOF Implementers Meeting 7
**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**
* https://notes.ethereum.org/@ipsilon/BJujV7-Tj

:::

Matt Garnett started the call with a quick recap (since interop).

### Clients update

#### Besu
(Danno)
- EOF v1
- engaged in reference test
- did differential test, clients working
- ready to ship v1, but probably not with shanghai
- unrelated, exec. specs test in progress

Tag Matt in case of issues

Danno - issues around read & get base fee

Matt: Nethermind or Erigon?
(None present)

#### Geth
(Matt)
- not too much of update
- spend talking on EOF v2 specs
- some outstanding small issues to be updated
- doing differential testing agains bunch of clients

#### EVM 1
(Axic)
- Andre has been working on CREATE3 imple
- Here’s my suggestion for a [roadmap](https://notes.ethereum.org/@ipsilon/BJujV7-Tj)
- Implementing may help find issues and edge cases with design
- Yesterday T8 & transition support has been merged with EVM1
- Should accelerate testing

**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?

### Updates on Compiler
(Axic)
- From Daniel, they implemented everything but RJUMPV
- working on optimization
- re-enabled optimizer
- helping in create discussion

### **Specs update**

**Axic**
- shared a document that gives a summary and overview of what we can do
- Here’s my suggestion for a roadmap: https://notes.ethereum.org/@ipsilon/BJujV7-Tj
- Pawel will provide more update
- major changes what we will be doing under EOF v1
- we don't want to influence testing

**Pawel**
- v1 is missing about CREATE, invalid create code
- we went and updated implementation testing. there is aone edge case that requires additional infra on EVM v1 . We didn't try it yet.
- with CREATE and CALL instruction,
- we will try EVM 1 to fully confirm with the test.
- not prepared with 1.1
- but want to include changes that we already agreed to include
- I don't have the list right now
- however at interop we concluded that we should cripple the ability CREATE contract

**Matt**
- so you're saying by disabling CREATE the original op codes not talking about the the new ideas with CREATE like the transactions?

**Pawel**
- yeah I didn't fully spec out this new CFREATE instruction the new CREATE semantics if we need to handle all the edge cases the similar way or maybe some of that cases will go away. I'm not sure about that.
- But yeah by disabling I think we kind of ended up on the on this position that if we want to deploy EOF in two phases and so we want this new fancy CREATE semantics then we need to kind of disable it for now and then introduce it later without need of modifying the EL version.
- so yeah more or less there will be only option to create EOF contracts starting from a transaction so this is kind of partially functional system but I think it's good enough to start with.

**Matt**
- Make sense. any questions on EOF 1 & 1.1, v2?

**Danno**
- so 1.1's not forward compatible extension of 1, right? because we're removing features. only one would ship?

Matt
- 1.1 will be target for shipping
- 1 is already around and there is a lot of testing, but 1.1 will follow

**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**
- i think we don't necessarily want both at the same time
- the sane way to enable is with version bump
- there may be unnecessary complication
- we need to spend time on spec for 1.1 before jumping guns on every clients
- we can keep working on 1 testing
- in parallel specs of 1.1 can continue working

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.

### Testing
- Outstanding PRs need to be reviewed?

**Axic**
- I'd propose to share the document I propose.
- Most of the people are heavily involved

-> Axic screen share and discuss

v1
- what is today, but has delegate "Restriction"

v1.1
- changes different to v1

v2
- v2 enables contract creation

(watch video)

**Matt**
- when doing a create tx non-EOF, it makes a lot of difference

**Axic**
- it is a deviation with what we have today but in line with v2
- Please give it a a read. the important part is that ...
- the call data copy and v2 will work together

-> we need to decide which is a better direction

**Axic**
- gas instruction
- we can adjust stipend in v1.1 but could get rid in v2

**Matt**
- Testing
- we don't have the testing team but Ipsilon team added some tests
- https://github.com/ethereum/tests/pull/1159

**Danno **
- we need separtae set of test
- new ref. test is coming up which is very good
- it is very nice and practically tutorial

**Axic**
- Hugo has been focusing on writing tests
- 5450 test cases, close to completion in next week or 2.
- outstanding testing

**Pawel**
- how much other team are going to test the implementation
- we can drop some changes to specs to 1.1 if teams are open

**Matt**
- I won't be working on updating EOF impl. for another month, fine with dropping specs to 1.1 changes

**Axic**
- we can work on 1.1 without the need of Geth

**Danno**
- I think the only real barrier for 1.1 is going to be the changes to the color code for gas introspection I think all the other tests in there or just get rid of tests that use the user change the test to fail um so as far as you know just don't write tests for EXT and code copy stuff except for the v11 I don't think there will be too much collision between these two versions.

**Matt**: All right

**Axic**
- Solidity Metadata
- with the data section, it seems to be we could have multiple data section.

**zoom chat**
* Ayman to Everyone (Feb 8, 2023, 10:37 AM)
Hmm, and how does that relate to CREATE/CREATE2 ?
* Danno Ferrin to Everyone (Feb 8, 2023, 10:37 AM)
CREATEx requires the bytecode to live in execution memory. If it hits memory it can be introspected and manipulated.
We want to allow data manipulation (constructor calculated constants) but not code manipulaiton. That's a not-so-easy problem that has multiple soliutions pending, hence the split delivery

---

:closed_book: Notes #6
--

:::info
### EOF Implementers Meeting 6
**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**
* https://github.com/ethereum/EIPs/pull/6261
* report: https://hackmd.io/@etgDMnCFQgS7tnZ9yjkOPw/Sk4RrJsco
* https://notes.ethereum.org/@lightclient/HyWJKV7qi
:::
### A few decisions from the call:

* Explain everything must be relative if PC=0 is removed.
* Section always for EOF code, PC relative.
* Change expected exception from integer to string.
* Use cancun instead shanghai+eof
* Need to discuss delegatecall
* **Goals** before interop
* pass all released tests
* implement reference test runner
* think about spec changes that still need to be made for EOF1
* bonus: think about EOF2 (banning most of code introspection) and consider how compatible EOF1 is with that view

**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.

### Client updates
#### Geth
- clean up, not much performance work
- PRs to clean up , errors log in
- For reference test, will talk in testing discussion
#### Besu
- basically cleanup
- Optimization

#### Nethermind
- minor optimization

#### Erigon
- (none)

#### Solidity
- nothing substantial
- PR draft for implementattion
- Uniswap tries to run testing through them, yet to hear back from them
- Hopefully will have more data soon

### Compiler updates
none

### Spec updates

**Remove PC verbiage**
Matt: Danno listed (Remove PC verbiage), would you like to explain?

Danno
- now that we don't have PC and JUMP, I'd like it to be removed

Alex
4600 still has how PC is modified
the intenet is about the internal PC representation not what it is returning

Alex
- if we relax PC = 0?

Danno
- we can bring back when need absolute positioning, may be hard but not impossible.

Matt
- no problems either way

Pawel
- never connected to explicit value 0

Axic
- need explicit mention
- maybe under security consideration?

Danno
- we need to have some agreement on PC for tracing

Matt
- Anyone having stron opinion?

Danno
- if we keep it under relative code section

Matt
- code section non zero
- Section always only for EOF code

**Support in tracing**
Danno
- fine with **no spec change** but would be good to have tracing clarity

**Ipsilon team updates**
- started to work on some ideas, a document is started
- hopefully will be shared early next week
- discussion will be for interop

**Unified EIP?**

Danno
- easier to have unified EIP

Matt
- deprecate other EIPs and have one EIP
- and with time the unified EIP prevails

Alex
- do you mean a brand new EIP with copying specs or new EIP altogether, what's the suggestion

Matt
- A new EIP may be written which has content from existing EIPs

Alex
- some concerns with unified EIP
- the motivation, and other mandatory feilds may double the text
- but some of the text could be cut back when duplicate
- not sure if all implementers are happy with the unified spec

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
- 2 changes from my end
- data stack to operand spec
- on the testing side, we are focusing on comparing GETH implementation with EVM 1
- as of today, only one issue remaining
- the issue is in CREATE
- the test specs in geth impl. the init code ios invalid, caller nonce is invalid. Could have been discussed somewhere
- if resolved, we will be in a good position
- most tests are coming this and next week
- we're in a good spot right now.

### Testing updates

Matt
- there has been talks on having referennce tests
- some proposals
- 1. writing ethereum/test repo
- I made some suggestions, wrote a hackmd with [report](https://notes.ethereum.org/@lightclient/HyWJKV7qi)
- anyone having strong feelings?

Danno
- besu is getting one of the two test cases correct

Alex
(at 30:00)

Danno

Matt
- it will be a good line of experience to have more clarity on why things are failing

Danno
- i think REVERT byte should be oushed, right now it's optional

Mario
- I have seen cases where it is listed.
- It depends on the clinet in the order of the check they are doing.

Matt
- should I extend the feild tests format?

Mario
- that could be one suggestion
- not sure if we are lowering the coverage of the test cases.
- I could give an example, but dont quite remember now.

Matt
- there could be a case of unexpected end of file where there could be two different output

Ahmad
- EOF should be treated as normal case in case of EOF00

Danno
- there are other ways

Mario
-I'd agree that wouldn't be a good test case
- eg (at 36:00)

Ahmad
- I wantt o note here with expected error exception
- for Nethermind, for min. valid EOF code could be
- I see what you are trying to do with expected exceptions, but i think that would create a lot of problems

Ayman
- we should make sure whatever included in the test case is valid
- so we have multiple happening in the same test case
- I'd prefer not doing that

Matt
- we could do it as a tool
- what we care is clients passing the tests
- as a test writer, saying that I am expecting to fail this test this way,...
- It is not going to be perfect signal
- but if people are okay, we will see how it goes.

Alex
- I'm in favor of giving the strict version a try
- in ideal case it will be nice to have all of the EOF conditions be properly specified, but that is a long term goal

Matt

Ayman
- fuzzing of the header has to be tested, can be done in different order; but the result has to be the same.

Matt
-> **continue talking in the #interop channel**

Matt: Are people okay with tests in *Shanghai + EOF* or change it to *Cancun*?

Danno
- I'm flexible

Ahmad
- fine either way

Matt
-> **let's put tests in Cancun**

Danno
- itr's a good marketing

Alex
- speaking of Cancun, there has been some proposal of EOF which were proposed late, could we include them in Cancun?
eg SWAP DUP

Matt
- I am abit apprehensive
- we have a lot more time now, may have greater ability for range of changes

Pawel
- I feel like current specs are 1.0, can have 2.0 with additional changes
- once everyone is on same level of testing, 3-4 additions will be added top EOF eg SWAP DUP, JUMPF, one to enable on compiler side and the 4th one on Delegate compiler
- not sure of committment, but should have revert ability

Andrew
- it was mentioned in the last ACDE call that there are some hacks that could be applied to EOF
- I'd perfer not to have hacks
- for extra features, it is already big enough. I'd fix bug than adding new feature

Daniel
- I'd like to see relaxing the stack validation
- may be able to suggest changes

Matt
- we want to understand what's useful for you

Danno
- stack validation could be critical to ...
- swapdup can be added in 1.1 rather than having valid or invalid

### Interop

Matt
- had a talk with Tim, will be ideal to have a separate chat
- what do people think

Ahnad
- Ayman won't be there but I will be there

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
- what is the status of Ethereum tests for EOF? are they finalized

Matt
- I just feel like we're early in the cycle now that we have the presets on devnets because we **have outstanding specs problems that needs to be resolved** mainly like constructor problem.
- Until we solve that, it seems like building devnets is not as much signalled.

Pawel
- tests aren't final yet.
- in preparation
- still some moving parts

:closed_book: Notes #5
--

:::info
### EOF Breakout Meeting 5
**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**
* https://github.com/ethereum/EIPs/blob/81c25d0bfe8e3f3337f312a9961a220aa57d9bfc/EIPS/eip-5450.md
* https://github.com/ethereum/EIPs/pull/5993/files
* https://github.com/ethereum/tests/pull/1127
* spec change to EIP-3860 - https://github.com/ethereum/EIPs/pull/6249
* https://github.com/lightclient/execution-spec-tests/tree/eof-tests/fillers/eof1

:::

### Main spec outcomes:

* don't allow extra data after initcode for now
* no DATACOPY opcode for now, but generally a good idea
* if don't have DATACOPY though, CODECOPY must be used and that doesn't sit well with the proposal to ban code introspection and would therefore require an EOF bump to depracate.
-> **next EOF breakout** - make a call after ACD

### Client updates

#### Geth
Matt
- trying to maintain impl. for latest spec changes
- working on testing
- we found differential fuzzing issues
- next few days will resolve issues

#### Besu
Danno
- doing fuzzing
- spec implemented
- few things to implement, mostly there

#### Erigon
Andrew
- with geth PR
- almost same as geth
- terminating and jumpF have been removed

matt: will discuss terminating today.

Andrew:
- trying to figure out which instructions are terminating

Pawel:
- important for 5450, we need to know which are there.
- spec is referring to terminating
- not sure if PR is merged or still a Draft
- will check and send link

#### EVM 1
Pawel
- implementation of v1spec
- plan for fuzzing today/tomorrow
- bug fixing

#### Nethermind
Ahmad
- implemented latest EIP
- will proceed with specs impl. asap

### Compiler updates

matt: next on agenda

Rodrigo:
- daniel worked on implementation of EOF-Functions (EIP-4750), not sure of details.
- There is a draft PR here https://github.com/ethereum/solidity/pull/13825 based on the latest unified EOF spec.

matt: let's move on

### Spec updates

Pawel: what has **changed since last call**
- dropped `JUMPF` instruction, partly because of some other changes on the way, decided to remove.
- the `PC` instruction decided to be rejected by validation
- `RETF` does not clean stack - automatic stack clean up was removed from the spec. the compiler will take care
- need to improve or add specific instruction for it
- container format has been decided and updated.

matt:
- Are we through container format decision?

pawel:
- not yet
- remaining spec issue is still there

Ahmad:
- data section isn't clear in the EIP
- should be included in specs, to make it clear

matt: what do you mean?

Ahmad:
- As per my understanding Data section is there for parameter including?

matt:
- it's still an open question
- need to recalculate evm size

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:
* this is the core issue as how CREATE works?
* CREATE is like call data, always empty.
* separate stream of data from the call data; this isn't the current situation
* sometime contract wants to create return address, it becomes complicated.
* not a great solution, but may have a limited inability.
* we may find a better solution but can't be included now

matt: what are the main tasks?
- decide extra data in init code
- appending the code
- how it works

pawel:
- solidity can handle the additional codes.
- the constructor of create2 may create an array, but complicated
- i'd keep it as is as we have no time for it
- we may lose some use cases, but thats better to quickly patch

danno: usecases will have big limitation, i think we should fix it before including

pawel:
- i think construct work
- agreed there will be some issues and we may not know what are the issues
- returning empty code isn't valid in some cases
- empty account will be created but not reflected; these usecases will be affected

Danno
- we need to consider how to handle empty code if we support EOF

matt
- we can later allow empty code
- we may not need to come to consensus right now

GregC
- good to have know
- should allow empty code

Martin
- it deploys with nonce 1
- leaving it forever to handle it any input

greg
- i thought the idea was to leave less behind the actual code

martin
- yes

matt
- as long as people deploy empty contatiner, will not have over head
- it will allow contract deploy with size 0
- we won't be storing 10-20 byte contatiner

danno
- maybe out of scope of EOF, but should be considered

pawel
- i missed the nonce
- but they are applied when hold

matt:
- discuss 0 code contract
- leaning towards no change unless have example for otherwise
- we should leave as is and decide in the future

Ahmad
- data copy opcode - does anyone feels strongly against adding it to 3540?

martin
- what's the proposal

Ahmad
- adding an opcode

martin
- i am not opposed to the idea but will be opposed to throwing new instructions at this point as we need to finalize

Ahmad
- if added later, it will totally be a new EOF version

matt
- we can add in another fork

Ahmad
- okay

matt
- people have to pay for call data load in the meantime

Danno
- should roll out with some warning

Matt
- yeah

Pawel
- immutable contract
- the warning may not help
- i'd like to spend a bit more time, learning observaibility of the code

danno
- codecopy maynot copy code kind of warnings

Pawel
- the structure of the container maynot change at all

matt
- we will talk about Vitalik's proposal from Thursday
- let's move to testing

### Testing updates
* in progress tests by Ipsilon: EIP-3540: Unified Spec Tests tests#1127

matt
- Ipsilon team writing tests

Andrei
- PRs open for 3540 test, client teams can try.

Matt
- i ran and past those tests. should be possible for other clients to run those tests
- -when we might be able to release those, any idea

Andreai
- 3540 needs to be reviewed from testing team
- 3670, 4750, 4200 PR are there
- https://github.com/ethereum/tests/pull/1127

Matt
- mario has written some tests
- i was trying to use it for latest update
- we are going to trying get that merged soon

mario
- i'll prioritize and have it ready for you

matt
- we need to get some test suits published and released for clients
- we should be ready with testnet before ACD
- will be working on testing on next couple of weeks
- will get test suits ready
- is it doable for clients?

marek
- we may end up with consensus issue, we may have to debug

matt
- yeah, we are trying to be on the same page
- clinets comfortable with testnet wed next week

Marek
- before ACD would be hard, not time to fix issues
- nexxt week sounds better

danno
- we will be doing fuzz testing than testnet

matt
- getting test suits before ACD is is a good idea

tim
- testnet - one broader testnet and all team to join will be a good idea

matt
- focus on getting test suits
- testnet next week
- depend on convo in next ACD

Andrew
- shanghai core is the core idea
- i'd like to finalize the change of 3860 and enable all Shanghai core EIPs in Shanghai

matt
- i'm in agreement with that

Ahmad
- any strong proponent in merging to EIP

matt
- i think people aew in agreement in merging

Ahmad
- EOF test suits does not include that as of now

Pawel
- we should wait till thursday

matt
- i think we should change and can revert if disagreement in ACD

mario
- ipsilon team- you need something from demitrii or me

Andrei
- you may also take a look if you want

mario
- okay
- i can take a look on Python test and Demitrii can look rest, but if I get time, will check

#### In progress tests by @marioevz + @lightclient: https://github.com/lightclient/execution-spec-tests/tree/eof-tests/fillers/eof1
* fuzzing via eofparse

matt: Martin doing some fuzzing

danno
- we have different tests - transaction tests, general state test, blockchain tests
- i can put together a proposal to signal what I am thinking of for testing

matt
- make sense to me
- we should aspire to after shanghai?
- we can decide in austria

mario
- just the contatiner

danno
- yes

pawel
- this kind of testing - valid-invalid and byte code is a good idea

matt
- questions and comments regarding EOF?

Pawel
- should there be any report for ACD from our end

matt
- just the testing suit released
- client test passing status
- other thing people may want to talk about is vitalik's proposal; will be a good idea to revisit and about the impact.

-> **next EOF breakout** - make a call after ACD

### Testnet planning

:closed_book: Notes #4
--

:::info
### EOF Breakout Meeting 4
**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**
* https://notes.ethereum.org/@ipsilon/eof1-checklist#Spec-level-Open-Issues
* https://notes.ethereum.org/y4SGusnuReaKDysjuoVJ1w?view#Section-kinds-with-arrays
* https://notes.ethereum.org/ttCtHNsWSwe0EVk-jsW7-A?view#Container
* https://ethereum-magicians.org/t/eof-proposal-ban-code-introspection-of-eof-accounts/12113?u=moodysalem

:::

### Clients team update

**Geth**
(Matt)
- Rewritten implementation of EOF with different approaches
- implemented unified specs from scratch
- tests are still sparse; will be working on test next week
- helping Mario for cross client test

**Besu**
(Danno)
- 5 EIPs implemented (1st pass)
- EOF container specified in unified spec
- relative jump will be unaffected if EOF container spec changed
- start interoping

**Erigon**
(Bob)
- Tracking Geth changes

### Compiler updates

Vyper (Bob)
- started work on Dec 14th
- Timeline : TBD
- looks like volume of changes will be smaller

Solidity (Axic)
- number of PRs available, waiting to be merged
- Optimazation stages disabled, gas optimization is observed.

### Spec updates

**Ipsilon team**
Pawel
- merged changes Andre reviewed
- functional change is that 3670 does not require ...(?)
- mostly editorial changes
- missing is main container format
- plan to reach "stack validation"
- An issue "stack cleanup" stopped from reaching to the last EIP (at 10 mins)

### [Spec-level Open Issues](https://notes.ethereum.org/@ipsilon/eof1-checklist#Spec-level-Open-Issues)

**header format**
Matt
- It seems like Besu & Geth have implemented unified ver of spec format
- How to continue moving this forward?
- https://notes.ethereum.org/y4SGusnuReaKDysjuoVJ1w?view#Section-kinds-with-arrays

Pawel
- want to think on how many bytes it used, but there is a trade of some fixed number of bytes will be added in the header.
- it also has additional benifits
- it saves the linear redundancy
- Decide if we need to go with fixed format or maybe a bit fancy.

Matt
- Vitalik post's takeaway. Not have too many EOF version. More leaned towards flixble (18:00)

Moody
- dumb question, has protobuf been considered for the container format?

Pawel
- both directions

Matt
- Make decisions so clients be ready by Jan 05

Pawel
- I am in favor of being flexible, more generic
- if no one protests for saving every last byte of format; I will go with bit more flexible.

Danno
- Same question, but SSZ?

Pawel
- Didn't explore fully
- someone may present example how that will look like

Greg C
- prefer flexible format
- we need future version bumps
- adding opcode not change version

Matt
- container format currently (afaik) https://notes.ethereum.org/ttCtHNsWSwe0EVk-jsW7-A?view#Container
- can take this offline
- Any comment now will be good to have
- finalized version for review later today/tomorrow

->More support for flexibility on chat

Axic
- protobuf likely can’t even be used because it doesn’t start with a EF00 word, but technically I guess ssz could be made fit for that; if there’s a magic outside of those serialisation formats that kind of defeats the purpose

Moody
- you can do EF followed by protobuf

Alex Beregszaszi
- yes, which I think defeats the purpose protobuf in particular relies on
Moody
- the purpose is it's easy to specify in a way that's cross compatible (a .proto file, which can generate code in any language for any client) and it already aims to minimize code size
Danno Ferrin
- Yea, magic values then you code-switch to the serialized stream. Basically it's wrapped

Moody
- minimize wire size*

Alex Beregszaszi
- we did consider using leb128 instead of the fixed 2 byte size fields, but even rejected that because assumed clients would be annoyed by the complexity
- protobuf is at the extreme end of the complexity scale compared to that

Danno Ferrin
- Even with a standard format I still expect hand-written parsers for speed and purpose build parsing.

Moody
- i don't think hand written parsers would beat protobuf on decoding speed but idk
- with protobuf varint you don't have to guess the right sizes (i didn't fully understand that point)

Danno Ferrin
- You haven't seen the Java protobuf parsers. Speed of parsing isn't the issue there, there's so much overhead in the code it gerneates.

Moody
- i don't think the initial version matters as long as it's upgradeable fwiw (banning code introspection)
- i worked at google so i saw all manner of protobuf parsers (and also am biased, i've wanted protobuf in a number of ethereum things)

Matt
- From Geth, will be against integratng Protobuf

**stack cleanup on RETF and JUMPF**

Pawel
- it specify the exact stack heights in the call
- On tech level
- it might be complex, time consuming because we can have functions returning 200 arguments
- not sure if we considered the complexity
- probably most of the use case won't need it but we be prepared for the worst case
- (30:00) sometime needed

Danno
- concern: variable execution time for 300-400 gas if cooded poorly
- should not include

Daniel
- was added to spec after discussion with us, because we don't have cross functional jumpls
- but we are comfortable even being dropped.

Greg
- never liked automatic clean up features
- always add up

Pawel
- from EVM pov, definetly nicer
- why important: would be nice to spend some time.
- solidity started implementing
- I feel we don't have much time, so make decision in a day or 2

Greg
- is there any real use case (35:00)

Daniel
- not sure the current spec has use case for clean up

Pawel
- the original use case was for panic helper

Daniel
- before EOF we have several places for jump code, but EOF doesn't allow that
- 1st experimental result suggests that it is not as bad as feared.
- We could live without optimization at least in the 1 version

Pwel
- Additional restiction help validate whats going on

Matt
- Does anyone feels strongly to keep JUMPF?

Greg
- yes
- if we have a spec that help JUMPF, will be nice to have as Cancun could be delayed (from Summer)
- woukd be happy with a solid spec

Matt
1) drop jumpf 2) don’t clean up stack (as originally defined) 3) look into future introduction of jumpf+memmove op 4) ban function outputs of 255 (0xff) to potentially use in the future
for “reverting function helpers”

- I'd rather be fwd compatible so we be good to consider in Shanghai

Pawel
- the restricted version of JUMPF
- if we can do better later, so it be
- it's better to imagine how will it work in Future

Danno
- I think we should have stack clean up included for some of the security concerns.

Pawel
- looks okay to me.
- we can reach spec clean up later b'coz we can add backward compability later.

Matt
- I think we should do that

Daniel
- if we consider 663 in Cancun

Matt
- reserving the upper byte in a type section of output
- we require 128 bttes of output
- in cancun we will consider if that can be expanded
- and not have automatic stack cleaning

Danno
- DEEPPOP <extent> <retained> extent is the total depth (up to 255) and retained is how many of those in the extent on the top to keep at the top afterwards.

(Chat)
Danno
- I like the idea of protobuf, but the default protobuf code generated by Java is barely "good enough" beccause it tries to keep too many possibilities open (android/server, pojos vs. rich interfaces, etc). When you make a fixed decision on some of those choices there are so many more optimizaitons that van be made. So at least for Java the default parser isn't the most performant option because it serves too many purposes, in conflicting ways most other languages dodge better than Java does.

Axic
- I’d rather push for cbor if protobuf is a serious suggestion, but based on clients I think the only acceptable option would be SSZ (or RLP in the worst case), and none of these seem to be well adapted for it.

How about considering leb128 in the header however?

Danno Ferrin
- agreed, rlp is not well suited for eof.

Alex Beregszaszi
- Protobuf’s varint is basically leb128.

Ayman
- wasnt JUMPF designed for tail optimization ?

lightclient
1) drop jumpf
2) don’t clean up stack (as originally defined)
3) look into future introduction of jumpf+memmove op
4) ban function outputs of 255 (0xff) to potentially use in the future for “reverting function helpers”

Ahmad Bitar
- maybe dumb question, why is SSZ not suited?

Moody
- daniel could you share the code you tested with? curious what code patterns would make deduplication a problem

Danno Ferrin
- Perhaps make jumpf gas 3 + 1 per stack item discarded? That breaks layers with execution and gas costing however.
- Just realized it would need to also include stack input, 1 discarded stack and 800 inputs.

**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
- EVM channel for discussion

### Shanghai Timeline

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

### Next meeting: Dec 29
- hopefully will have testnet by then
- share thoughts on EVM channel

---
:closed_book: Notes #3
--

:::info
### EOF Breakout Meeting 3
**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**
* https://notes.ethereum.org/@ipsilon/eof1-checklist#Spec-level-Open-Issues
* https://notes.ethereum.org/@lightclient/rJ0nTvKIj
* https://notes.ethereum.org/@ipsilon/S1v0lHBwo

:::

## [Spec-level Open Issues](https://notes.ethereum.org/@ipsilon/eof1-checklist#Spec-level-Open-Issues)

### Clients team update

**Geth**
(Matt)
- Not much since the last Breakout Room
- Most of EIPs are already implemented
- Qns regarding container format

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)
- Small EOF changes integrated
- Relative jumps and container EIPs started.
- Sync with Shandong

**Nethermind**
(Marcin)
- Some are in Review and WIP
- Justin may have more context of EOF

**EthJS**
(Holger)
- no concrete progress
- base EOF are already ready for quite some time
- Jochem will do the implementation
- may take 4 weeks, will be ready by early Jan

**ETC**
(ziogaschr)
- working with Erigon team
- on Monday will open PR
- Today will try Erigon sync with Shandong

### Testing updates
- Marius has been working on cross clients tests
- team changed opcodes recently

### Ipsilon (updates on specs)

**Axic**
- [checklist](https://notes.ethereum.org/@ipsilon/eof1-checklist) has been updated
- contains matrix and links to related docs
- spent time with LC with checklist
- want to freeze changes by next ACD
- Best time to improve the header
- Will finalize during next week , will be done before next ACD
- No major spec changes coming from Ipsiolon team after ACD
- Ipsilon is working on a [unified Meta spec](https://notes.ethereum.org/@ipsilon/S1v0lHBwo)
- Solidity
- lengthy discussion on Monday after the last Breakout call on effect on Solidity
- put all of the changes on roadmap
- implementing all changes in next few weeks
- will have full support during Christmas

**Matt**
- important to come out with full spec
- changes talked about relatively small, just bike shedding and checking on future compatibility

**Next steps:**
- work through the Ipsilon checklist

### [EIP-663: Unlimited SWAP and DUP instructions](https://eips.ethereum.org/EIPS/eip-663)

**Daniel K**:
- we would want [EIP-663](https://eips.ethereum.org/EIPS/eip-663)
- It will be really helpful for our team.

**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

### **Consider merging EIP-3670 + EIP-5450 into a single specification, condition on EIP-5450 being accepted.**

**Matt**: Has been accepted
**Axic**: 3670 has some rules. We are improving motivation.
It would make sense to merge them together.

### **EIP-3540: EOF - EVM Object Format v1**

**Matt**
- no body feel strongly about either direction
- this is where we are from Discord discussion
- Keep it as specified

### **EIP-3670: EOF - Code Validation**
- discussing not terminating the last operation
- will be merged soon
- discussed in the last meeting

**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.

### **EIP-4750: EOF - Functions**
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.

### **EIP-5450: EOF - Stack Validation**

**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.

## [Unified Spec](https://notes.ethereum.org/@ipsilon/S1v0lHBwo)

(Check video at 0:36)
Matt
* Very readable, more digestible.
* Still WIP
* Early next week people implementing will be able to refer to it.

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

## [Containers specification](https://notes.ethereum.org/@lightclient/rJ0nTvKIj)

(video at 0:42)
A few attempts were made. Few different options
- Array of code section
- Embedded Type Section
- Section kinds with array
- similar to original EOF definition
- feel strongly positively about it
- provides flexibility to add new section in future
- seems like the bst approach
- Multi-level header

Goals are defined in the document.

**Axic**
- The proposal was by Pawel based on the discussion we had.

**Matt**: Client team - how do you feel in general about these proposals?

**Danno**
- I am not touching unless this is finalized
- I have done parsing already

**Axic**: The goal explains
- extensibility
- we want to make header designed in accordance
- we want to make sute not to waste space for Meta data

**Ahmad**
- I'd like to lean towards "Section kinds with array"

**Matt**: Fixed order and extensibility will be nice to have.

**Axic**
- The first version of 3540 have the parser

**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**:
- EOF removes initial bound indes wrt Verkle Trees. Seems like a nice win.

## Summary
**Launching EOF testnets**

- Spec completion: Next Thursday
- Interop: This month
- It seems like most clients are in-progress; just have few things to iron out. If call on Thursday suggests, EOF not going in Shanghai, will have less pressure.

**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.

---
:closed_book: Notes #2
--

:::info
### EOF Breakout Meeting 2
**Date**: Nov 18, 2022
**Agenda**: https://github.com/ethereum/pm/issues/666
**Recording**: https://youtu.be/fperqiUlYTY

**Links shared in chat**
* https://notes.ethereum.org/@ipsilon/eof1-checklist#EOFv1-Checklist

:::
Matt Garnett lead the session. The main goal waas to go through the [checklist](https://notes.ethereum.org/@ipsilon/eof1-checklist#Spec-level-Open-Issues) by Epsilon team and make decision on open items.

### Spec-level Open Issues

#### General
- [x] Rename all EOF EIPs to have "EOF: " prefix. [EIPs#5849](https://github.com/ethereum/EIPs/pull/5849)
Does this make sense for “Static relative jumps”?

**Matt**: I think so for now - if for some reason shanghai falls through, it could be removed.

#### EIP-3540: EVM Object Format (EOF) v1
- [x] Move generic contract creation rules from EIP-3670. [EIPs#5907](https://github.com/ethereum/EIPs/pull/5907)
- Pawel explained what changes are going in
- Code validation will be smaller

**Matt**: I am in favor.

- [x] Forbid EOF → legacy contract creation.

**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.
- Chat Qn: Does EOP break legacy contract?
- **Matt**: EOF does not break legacy contract.

**Matt**: Let's be restrictive in the default case.

- [x] Clarify that overall code size limit of EIP-170 / EIP-3860 still applies https://github.com/ethereum/tests/pull/847#issuecomment-1289657858

**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.

#### EIP-3670: EOF - Code Validation

- [x] Reject CALLCODE and SELFDESTRUCT EIPs#5894

**Jochem** (Comment): What if "remove selfdestruct" EIP gets in?

**Mat**t: 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?

#### EIP-4200: Static relative jumps

- [x] Calculate offset from the current instruction position (not the next one (+3 bytes)).

**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

#### EIP-4750: EOF - Functions

- [x] Set CALLF and RETF opcode numbers EIPs#5921
- [x] Set gas cost for CALLF and RETF.
- [ ] Redefine code section header to be array of code section sizes. EIPs#5928 Discord#evm

**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.

- [ ] Clarify: “If data stack has less than caller_stack_height + types[code_section_index].outputs, execution results in exceptional halt.”
What happens if the stack height is larger than the number? (Option to always require exactly caller_stack_height + types[code_section_index].outputs items, no more)

**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.

- [ ] Change the spec of RETF to clean up the stack for user (i.e. leave only the top stack items in number of function outputs). This requires memmove of the top stack items.
- [x] Limit number of functions to 256 (single-byte immediate for CALLF)

**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

- [x] Reject JUMP, JUMPI and JUMPDEST.
- [x] Replace JUMPDEST with NOOP.
- [x] Reject PC.
- [ ] Reassign EOF section ids to be in order (01: type, 02: code, 03: data).

**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.
- [ ] Make type section mandatory

**Matt**: write a couple different approaches to compare
**Axic**: in favor of parsing at expense of deploy
- [x] Clarify that 1024 data stack limit still applies.
#### EIP-5450: EOF - Stack Validation
- [ ] Lift the requirement to clean the stack for terminating instructions (STOP, RETURN, etc). For RETF see above.
- [ ] Lift the requirement of the last instruction to be terminating (if unreachable). This is one less check to have in the implementation.
- [x] ~~Consider~~ Prototype “single-pass” verification algorithm. [Discord#evm](https://discord.com/channels/595666850260713488/706868829900505180/1041845239322779679)

**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**
* Danno will document motivation for EIP.
* Mario is working on client trest- EVM discussion channel on Discord

:closed_book: Notes #1
--
### EOF Breakout Meeting 1

[Notes](https://notes.ethereum.org/@timbeiko/eof-breakout)