# EOF Implementers 11

:closed_book: Notes #11
--

:::info
### EOF Implementers Meeting 11
**Date**: April 05, 2023
**Agenda**: https://github.com/ethereum/pm/issues/748
**Recording**: https://www.youtube.com/watch?v=rnCAvOv8Rq8
**Playlist - EOF Breakout Room Meetings**: https://www.youtube.com/playlist?list=PL4cwHXAawZxpxjx7t3Aqo01pZYfHjaqG0
**Earlier notes**: https://hackmd.io/@poojaranjan/EOFBreakOutNotes


**Links shared in chat**
* https://github.com/ipsilon/eof/tree/eof-rs
* https://notes.ethereum.org/@lightclient/rJ0nTvKIj
* https://notes.ethereum.org/@ipsilon/eof1-checklist
* simple tests for CREATE3 - https://github.com/ethereum/tests/pull/1204

:::

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

## Client updates

### Besu
Danno
- mostly easier opcode implemented
- architectural changes make it easier
- data opcode implemented
- changes will make things better rather than re-writing

Axic
- How much time did it take? was it straight fwd?

Danno
- Not writing test yet
- the hardest part is just re-writing
- Apart from CREATE it wasn't too difficult

### Nethermind
Ayman
- implemented most megaEOF specs
- CREATE opcode and new tx type remained to be added

### EVM1 team
Pawel
- Alex provided update in the last ACD
- Nothing bad happened so far
- we put some effort into updating Geth impl. to agree with EVM 1.
- We needed to put time to testing infra, it's finished
- we need to get the previously submitted test updated
- It doesn't conflict with Shanghai tests
- We'll review details to check if there are any issues.

## Compiler updates
Barnabus
- Can we start testing?
- Create devnet for EOF changes?

Matt
- Might be a little early for that.
- Most clients are reaching to compliance

Barnabus
- Let me know if it changes

## Spec updates
Matt
- is there any updates that we want to talk about or anything that was found during the last two weeks?

Danno
- I've a few implementations (three) added in Discord thread. A fourth one that I just thought of should be less controversial.
- I'll just start with that one.
- What is the first version we're gonna ship with the first version -Swap and dupn?

Pawel
- I think so, but not sure on the decision

Danno
- I motion we had it let's put it that way formally added as part of eof. I know solidity has been pushing for it

Pawel
- yeah yeah they literally wanted this. I think what they said like some time ago is that if EOF will not go in Shanghai and there will be more time to like rework some features they would still like to have this Swap and then dupn.

Danno
- yeah and the overhead this is one of the simpler ones to implement because we've got already written this stuff to do the uh the multibite operations. we've already got you know the op code filtering and stuff like that so this is perform an implementation perspective it's not that hard to add and it provides significant value to the solidity team so
- I think it will be a good add
- testing will be harder part than writing it. Which is just the case with everything.

Axic (chat)
- On swapn/dupn I wanted to add that it would be the first thing “chopped” if we need to reduce scope. With that in mind I think fine to include it.

Matt
- Yes, usually

Jtriley
- yeah so while we're on the discussion of the spec itself, so I mentioned in the forums briefly but I think it would just be easier if maybe we kind of talked about it a little bit here instead of doing an async but yeah - - so I'm working on both a parser that validates eof containers and then also like eof code gen for the Huff compiler
- but in the parser, it's a WIP
- It's public but messy
- It's on Rust
- I was working with the guy on RETH impl.
- he wants it to be really vast, some weired optimization that way.
- I was looking to do it that way but there is some complications around
- like doing it sufficiently in a single pass if you could maybe link the the existing rest eof container that'd be great
- Right now the header is dynamically sized but I think with it being statically sized and then moving like the metadata about the size of the different code sections like moving that to the type section
- I think it would make the the header parsing a lot faster right you could effectively just you know use a mask right to validate the constant bytes and then the ones that you know maybe some other value then we could extract that info real quick
- and it would be a lot less jumping around so if we want to check a specific code section we need to go header & type section
- if we move that into the type section then it's all in one place in the type section.
- Curious of anybody else's thoughts on?

Matt
- we discussed
- don't know if there was any kind of final conclusion that this was you know the the way that made the most sense. I think it's the simplest in a lot of ways you know what we have.
- Alex/ Pawel your thoughts?
- I think this was one of the big rabbit holes that we went down whenever we first started pushing really hard for eof in Shanghai.
- and that's where we ended up spending a lot of time was thinking about how to do these code sections and type sections and we ended up having us like a couple small changes to it that substantially increase the complexity.

Jtriley
- Link to notes?

Pawel
- It may simplify the parser but we need to see where do we find the parser section.
- We want to keep the offset in the header only. Might be related to Verkle Tree later.
- I tried to explain why we decided to keep it the way it is.
- To keep the ability for future bumps if needed.

Jtriely
- make sense
- thinking how I can work on it to see how I had that in my mind

Matt
- what is the complexity, run time, extensibility? The [notes](https://notes.ethereum.org/@lightclient/rJ0nTvKIj) have some goals for being extensible. Take a look at that, might help you catch up with it.
- It's always useful to try a look from different perspective

- Thoughts on swapn/dupn to be added?
- **Let's get that in.**
- Danno, you had a few other things you wanted to talk about do you want to move on?

Danno
- a few things I want to talk about before we took the detour on the container format
- the first are the three items I mentioned was reordering the containers so the data segment as last with create3 we're adding new sub containers for deployment in the container and those got put on at the end
- I would like to ask that those get put on before the data element and the reason is for for consistent hashing when we're adding the auxiliary data from the create3 otherwise we would need to rewrite the containers
- in some cases to put it in the tree to get it updated in this way all we would have to do is append the data and update a field to get it correctly and it would reduce things like verkle trees would have more consistent accesses to the various deployments if we keep the variable data at the end.
- the stuff that depends on and part of the problem is because the the data copy operations if you copy across a seam you'd either have to have logic to join the two pieces or rewrite it in memory to get consistent access to this so that's that's one request

Matt
- any thoughts?
-
Pawel
- It make sense to keep it in this order. especially if we're going to append data which means it's much easier to do if it's the end section
- we already have the 3 type section and we added the fourth one right now
- We made all of these mandatory in the header
- it make sense to make this one mandatory
- there can be anindication in the header but it can be byte0/account zero in the header

Danno
- so the data can be skipped if there is no data in the header?

Pawel
- no, it's the other way.
- you now need to indicate the data section but you can put the size 0 there and the same for the subcontainers
- it kind of feels that it does not feel consistent
- we should discuss this at some point
- I am not sure how many bytes are pulled in, maybe 3 additional bytes
- I don't have any problem to put data section as the last one.

Matt
- I will add that to notes. What's more?

Danno
- while implementing calls
- with 4337 coming on the scene, not evaluating environmental opcode
- does provide room for adding new features
- I don't think it will break things
- but will introduce more
- my goal is to reduce those "unless" type of situations.

Matt
- thoughts on that?

Andrai
- combined opcode would mean different number of args depending on immediate?

Matt
- i couldn't quite follow

Danno
- there are a lot of things to discuss about it.
- code run on eof vs code running legacy

Matt
- thoughts?
- table- discuss later?

Danno
- value might be optional
- we are also chopping off gas
- maybe we should table it and let people think about it

Matt
- i don't have context of how important it is
- i prefer just to have separate opcodes
- but I could be convinced otherwise

Danno
- put it out to think about

EXT data copy
- we are losing this by moving on
- there are people using contract for data sources
- where are we on this?

Matt
- thoughts?

Jtriley
- A question - is the objective here to get all new contract to move over to the most recent version of everytime? or creating more specialized contracts that you know maybe like a certain eof number is used for like a specific thing
- data contract will still exist , just not be read just not from any EOF contract?

Danno
- they can still be read but there's another piece that is important for this is that we're not allowing eof to delegate call Legacy contracts to prevent Escape hatches like this.
- my vision is to have 1 or 2 eof versions live at the same time
- if we propose a new backwards incompatible eof version then we would need to have some standard transpilation from say eofv1 to eofv2 and
- All eof1 contracts in the system either as part of a single point migration or when we go to the next version our interpreted or transpiled in the eofv2 and operate under eofv2 so if we do things like we change like some of the stack orders some of the stacks or we totally redo how all the op code mappings work.
- we are going into the concept of code visibility that you can view the code within your concept to make sure that we can maintain this transpilability going into the future
- we'd be able to transpire from v1 to v2, v2 to v3
- Legacy code and you would have eof code of whatever the appropriate Fork version is so I don't think the vision of having multiple versions of EOF is something that we're really wanting to see because of the maintenance burden that the clients have expressed concern about when they see some of this eof some of the eof proposals that are going around.
- does that answer?

Jtr
- if people are writing low level eof codes
- if there are things that are taken care of in a version

Danno
- we'd want eof footprint as small as possible
- we're breaking the gas rules now in Call delegate
- if needed we can bring it back

Jtr
- i think delegate call is a right way

Danno
- Delegate call-in is allowed, but not out.

Ahmad
- Recurring implementation
- old

Danno
* Observability of code
* Delegate call is way we can get around that

Ahmad
* That makes sense
* Pawel
* All of interaction of legacy is because we already have it and not to have new feature
* If we thing data contract is something important feature, probably gas model is not great

Danno
* Data contracts can opt-in
* I think it is a good feature

Pawel
* If you want to
* This can be added

Danno
- I am comfortable doing if we need it.

Matt
* Cool
* Anything else , spec related?

Axic
* One thing
* I spent some time on 4337 support with EOF
* We have everything needed with one exception
* Removing gas ….. Breaks 4337

Dann0
* How important it is?

Matt
* We need to know how much gas will be used
* Otherwise the bundler will just say, I use this much gas without having a complex process

Dann0
- In your smart contract wallet bundle the gas?

Axic
- Each execution included in the bundle

Matt
- I am missing how is that different

Axic
- Right now it is limited by how much
* The user needs to have funds but the bundler will need to select the user with funds

Matt
* The bundler already have to have at least enough gas
* But what Alex is saying each user also have to have that

Axic
* Should have total limit
* Because you can not control the gas limit

Danno

Matt
* I think it makes it reasonably easy for the user
* I don’t say this is the worst thing but will change the dynamics
* What do you think Alex?

Axic
* It is the disagreement
* I haven’t came up with any solution
* Basically what this will boil down to is what is more important
* Removing gas observability
* 4337 style?

Danno
* To allow 4337 to changes to eof, will go against what is the core goal of 4337

Matt
* I think it is a marketing term
* It will end up making changes on protocol changes

Danno
- We can still be able to support on protocol changes

Axic
* My closing thoughts
* I think eof will be pushed back further
* We should have a proper discussion and figure out a strategy on this
* And get a final agreement on the changes on the gas

Ahmad
* Why we want to disallow gas disability

Matt
* It changes the behavior of execution
* One goal of eof is to change contract from one version to another

Axic - **Fun fact**: EIP-2930 access lists were introduced to workaround gas rigidity problems caused by EIP-2929 increases.

### Testing

Hugo
* There are PRs in the test repo
* Adding most of them are almost ready
* Still in draft because there was a pending change to check valid/invalid code
* We cannot check the specific reason why test is failing
* PRs are good to merge into the main branch

Matt
* Awesome
* Can we make it happen before the next call

Hugo
* Yes

Ayman
* We have some test cases that fail and wedon’t know yet, why
* Does Geth passes all test cases

Hugo
* Yes

Ayman
* Can you link the main branch

Matt
- Hugo’s brach is the latest, if you’d share , Hugo

Danno
- Can all client share their testing

Matt
- Can Ipsilon craete a hackmd to track and share with the client team

Axic
- will update EOF2 check list?

Matt
- They are asking v1 and new checklist for mega-eof

Axic
- We can do that

Matt
- Will share update on Issue.
- see you in 2 weeks, thank you all!