- The Ethereum Object Format (EOF) is a set of proposed changes for the Ethereum blockchain that could have a significant impact on the ecosystem and smart contract development.
- The EOF is being developed by Team Epsilon, an Ethereum Foundation funded team focused on EVM improvements.
- The EOF has received contributions from execution clients (Geth, Basu, Nevermind), compiler teams (Insolidity, Vypr), and the F Store 2 project.
- The EOF aims to address unimplemented and unadopted EIPs, providing solutions for various issues in the Ethereum ecosystem.
- Some of the features proposed in the EOF address account versioning, subroutines, data separation, eliminating call code and self-destruct, multi-byte functions, and procedures.

- EOF (Ethereum Object Format) is a container format for Ethereum virtual machine code that aims to solve problems with the existing EVM.
- It does not redefine the bytecode or reimplement the VM, but rather organizes code and data in different places and introduces a header to specify these locations.
- EOF fixes EVM evolution problems by allowing opcodes with immediate arguments to occur anywhere, not just in push opcodes.
- It also prohibits problematic behaviors within the VM and ensures that code in the code section is valid functioning code.
- Adding new immediate argument opcodes to the EVM can cause security issues and can change the semantics of existing contracts, making any such proposals rejected.
- The evolution of the EVM can be done through compatible changes (adding new functionality without altering existing contracts) or incompatible changes (altering functionality that other contracts depend on).
- EOF will operate in parallel to legacy EVM smart contracts on the mainnet, allowing compatibility and interaction between the two.

- The difference between EOF and legacy EVM is in their feature set and packaging.
- EOF and legacy EVM code are almost the same in terms of how they work and their semantics.
- The system architecture involves jump desk analysis and executing the code using op codes and message frames.
- Adding new op codes involves adding more operations to the list of operations that might be executed.
- EOF container validation and legacy code will have different features and provide different data to the message loop.
- There are operations that are only valid for legacy EVM and some only valid for EOF container EVM.
- The 8 main feature categories of EOF include the EOF container itself, static jumps, subroutines, code and data separation, and more.
- The object format of the container is described, including the magic bytes, versioning, sections, metadata, and raw data.
- Static relative jumps will ban old dynamic jump opcodes and introduce vector jumps.
- EOF functions allow for calling and jumping to subroutines, with stack height restrictions encoded into the container.
- EIP 663 aims to increase the number of stack items that can be duplicated and swapped.

- EIP 663 is being developed to increase the number of stack items that can be duplicated and swapped.
- The swap instruction may evolve into something called exchange, providing more access to stack items.
- EIP 7480 removes the read half of code introspection capabilities, allowing access to the data section instead.
- Create and create2 instructions are replaced with create3 and create4 to remove code introspection.
- Gas observability is addressed by banning gas operations and replacing call codes with new call instructions.
- EIP 3670 enforces code validation in EOF contracts to ensure all code is executed validly.
- EIP 5450 validates the stack size to eliminate the need for stack validation checks during execution.
- A future EIP is being discussed to prepare for address space expansion in EOF contracts.

- The speaker discusses the implementation of EOF (Ethereum Object Format) and its impact on the Ethereum Virtual Machine (EVM).
- The speaker explains that extra data in ABI calls would be stripped away by opcodes, but EOF allows for preservation of this data.
- The speaker mentions that there are 9 opcodes being replaced with EOF equivalents, 7 opcodes being removed, and 9 opcodes being added, resulting in a net gain of 2 opcodes.
- The speaker highlights that EOF may lead to smaller contracts and potentially improve security tooling.
- Backward compatibility concerns are addressed, such as the ban on self-destruct in EOF and the need for separate EOF and legacy contracts.
- The speaker mentions different versions of EOF (small, big, mega) and the preference for introducing only one EOF validator to limit the number of versions.
- There is some uncertainty about the support for EOF among execution clients.
- The speaker suggests that the implementation plans for EOF will be discussed further after the Istanbul meeting.

- The speaker hopes that security concerns about the proposed changes to the Ethereum Virtual Machine (EVM) will be resolved through education and discussion.
- They believe that implementing a parallel WebAssembly (WASM) Virtual Machine (VM) or making translations with the existing EVM could address some of the security issues.
- The speaker mentions the importance of test nets for testing the compatibility and functionality of the proposed changes.
- They emphasize the need for a container format and code validation for improved security and performance.
- The speaker acknowledges the skepticism of some execution client developers due to the size of the proposed changes but argues that freezing the EVM could lead to fragmentation in the smart contract ecosystem.
- They believe that Ethereum should continue to define the industry standard format to maintain its dominant position.
- Monitoring the impact of the changes could include tracking the deployment of new smart contracts and adoption by other blockchains and rollups.
- The speaker suggests that in the future, only EOF contracts may be accepted, allowing for analysis and potential reformulation of legacy contracts.

- The plan of record for Hedera is to use the EVM from Basu as a library with minimal integrations.
- The team wants to avoid shipping a white elephant and is looking for ways to judge the success of their project.
- An alternative to the EOF mega spec was considered, which involved replacing the whole system with Wasm, but it was dismissed due to performance issues.
- Other alternatives within the EVM were considered, such as putting markers in the code, but they had drawbacks.
- The advantage of the container format is that it provides a self-contained and compatible forward evolution of the EVM bytecode.
- The use of immediates in the container format also offers code size saving opportunities.
- The developers community is encouraged to provide feedback on the improvements lined up for the next upgrade.
- The goal is to break as much as possible in one go rather than in multiple steps.
- The TenCon upgrade is expected to have the most EIPs, and shipping all of the EOF features would be a record in itself.
- The interview concludes with a thank you to viewers and subscribers and an invitation to ask questions on the topic.

- The Ethereum Object Format (EOF) is a proposed set of changes for the Ethereum blockchain that aims to address various issues in the ecosystem.
- The EOF is being developed by Team Epsilon, funded by the Ethereum Foundation, and has received contributions from various execution clients and compiler teams.
- Some of the features proposed in the EOF include account versioning, subroutines, data separation, and eliminating certain opcodes.
- The EOF will operate in parallel to legacy EVM smart contracts on the mainnet, allowing compatibility and interaction between the two.
- The EOF container format organizes code and data in different places and introduces a header to specify these locations.
- The EOF aims to fix EVM evolution problems, ensure valid functioning code, and provide compatibility and interaction between legacy EVM and EOF contracts.
- The implementation of EOF may lead to smaller contracts, improved security tooling, and the need for separate EOF and legacy contracts.
- There is some uncertainty about the support for EOF among execution clients, but further discussions will be held after the Istanbul meeting.
- The speaker hopes that security concerns can be resolved through education and discussion, and suggests exploring the use of a parallel WebAssembly VM or translations with the existing EVM.
- The speaker emphasizes the importance of test nets, container format, and code validation for improved security and performance.
- Monitoring the impact of the changes and potential acceptance of only EOF contracts in the future are mentioned.
- The developers community is encouraged to provide feedback, and the goal is to break as much as possible in one go with the TenCon upgrade.

Resources: 
-----------------
Slides - https://docs.google.com/presentation/d/1Ti_A7kOdI-I8kSCMAXJbmr-JR53W-1ayG9aGcwoN0N0/edit#slide=id.p

Mega EOF - https://notes.ethereum.org/@ipsilon/mega-eof-specification

YT shorts - https://youtube.com/shorts/xqM74oBE63Y?feature=share

PEEPanEIP - https://www.youtube.com/playlist?list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F

EIP-3540 & EIP-3541 - https://youtu.be/E02THhW-yTE

Prague - https://www.youtube.com/playlist?list=PL4cwHXAawZxqOHV_F40AJbzcl8b6tG8xw

Check out upcoming EIPs in Peep an EIP series at https://github.com/ethereum-cat-herders/PM/projects/2

Follow at Twitter
--------------------------
Danno Ferrin @shemnon | Pooja Ranjan @poojaranjan19

Topics Covered
--------------------------
0:38 - About topic
1:15 - Meet Danno Ferrin
4:30 - About EOF 
5:00 - Presentation begins
5:25 - Who is working on EOF?
8:52 - List of unimplemented & unadopted EIPs
10:43 - What is EOF?
12:27 - Why immediates?
16:58 - Evolution modes for the EVM and EOF
19:16 - How does EOF interact with the existing EVM?
20:37 - Abstract EVM Execution Architecture
22:24 - Opcode Loops
23:33 - What are the major features of EOF 
25:30 - EIP-3540: EOF- EVM Object Format v1
28:00 0 EIP-4200: EOF- Static relative jumps
28:49 - EIP-4750: EOF - Functions (aka code sections)
29:43 - EIP-663: Unlimited DUP and SWAP
30:30 - EIP-7480: EOF - Data section access instructions
31:10 - EOF CREATE3 and CREATE4
33:46 - EIP-7069: Revamp CALL Instructions
35:45 - EIP-3670: EOF Code Validation
37:02 - EIP-5450: EOF Stack Validation
38:20 - Prepare for Address Space Expansion
40:32 - EOF Opcode Changes Summary
42:52 - Impact on security & gas cost?
45:35 - Backward compatibility concerns, if any?
49:00 - EOF shipment plans?
49:55 - What can go in?
51:24 - Dedicated devnets or testnets
54:34 - EOF wrt Ethereum long-term vision? Why some execution devs are not onboard?
57:40 - Metrics & impact on Ethereum network?
1:00:20 - Any alternative to Mega EOF?
1:04:07 - Message to the community

Ethereum Object Format or EOF is the set of proposed changes for the Ethereum blockchain.

They may have a significant impact on the Ethereum ecosystem and smart contract development.

If you are a smart contract developer or interested in learning about EVM's upcoming changes, stay with us.

I'm Pooja Ranjan, and I'm joined by a popular Ethereum client developer to talk about a bunch of proposals for EVM improvement with a future upgrade.

To learn about EOF and MegaSpec, we are joined by Dano Fahreen, an Ethereum client developer with Hyperledger Basin.

Let's begin our first section, Meet the Guest, Where I request our guests to briefly talk about their professional background, how they joined Ethereum and anything else they would like to share to inspire our listeners to join the Ethereum community.

So yeah, I came into Ethereum through interest in blockchain and I came through interest in blockchain through Bitcoin.

In a previous life, I was a desktop application developer.

1 job I had and I'd left, I found this really interesting visual analysis tool called Y-Graph, which has a lot of graph layout tools.

JavaFX was the library that made, laying these things that really neat.

And I needed an application that really showed an interesting graph.

And so this is about the time when Bitcoin first hit a thousand dollars.

And I looked at the Bitcoin spec, learned about how this UTXO thing kind of made an acyclic directed graph and thought, that would be really interesting to visualize that scale.

So I started out by, you know, creating an app that visualize that.

And I happened to stumble right into some exciting things happening with Mount Gox.

Gox things started doing this, this triangle split of everything was splitting twice and going down.

I initially thought about doing blockchain forensics, but I thought it was a little creepy.

Having been on both sides of the forensic side.

It's creepy no matter which side you're doing it on.

So I thought I'd try and get out of blockchain and I thought, I'll go to Google, that'll get it out of my system.

And then it worked for about 2 and a half years.

And then the way Google works is, you know, you often switch projects and your project's finished and you need to find another 1.

And right at this time is 1 of the recruiters from ConsenSys called me up and said, hey, have you been following the Ethereum stuff?

And even though I'd been trying to get out of Ethereum, I've been following all the stuff that had been happening with like the Shanghai attacks and with the Dow.

And I was really interested in a lot of the stuff going on.

I just didn't feel like, you know, I could give up Google.

But when this recruiter called and said, hey, you can be a core dev on the, what was then called the Pantheon project and contribute to it.

So I quit my comfortable job at Google and I went full crypto.

And that was about almost 5 years ago, over 5 years ago now, that I joined ConsenSys.

I stayed there for almost 3 years, did a brief stopover in Reddit to work on some of their community point stuff, but then I came right back.

And right now I'm working at a Swirls Labs, which is a company that does a lot of the development for Hedera.

And I spend almost all of my time working on the EVM stuff within Hedera.

And I contribute to the BASU client to keep all their EVM stuff up to date, as well as pushing the future of the EVM.

So yeah, I still, I've worked in BASU for almost 5 years, just with different employers, still working on getting various parts of it.

It's kind of a, In my opinion, it's a little bit neglected because there's a lot more shiny objects have a lot bigger issues.

But I think, you know, if we keep neglecting it, it's going to be 1 of those things that kind of sneaks up on us.

So that's why I've had a lot of interest in a lot of these proposals to try and make the EVM better.

And I think EOF is kind of a synthesis of the best ideas that's going to move the EVM forward in the direction it needs to go.

Like from Forensic, Google, Consensus, Ethereum, Reddit, back to Ethereum and now contributing to EVM, you have quite a lot with you to share with the Ethereum community.

Thank you so much for all the work you have done in this space so far.

Before we dive into today's talk, I want to share that EOF was originally proposed by team Epsilon and EIP 3541 reject new contract code starting with 0xEFI is already deployed on the mainnet with an earlier Ethereum upgrade.

So If you missed the talk on EIP 3541 with team Epsilon, please check out episode 36 on Ppenip at Ethereum Catherders YouTube and podcast.

So if EVM object format, I always want to call it a Ethereum object format, but it's actually EVM object.

Or if you want to go another layer, it's the Ethereum virtual machine object format, which I've seen some people actually use when they decompose it completely.

It's a big collection of a lot of different EIPs that work together that really don't stand alone, although they do a lot of different things.

But the first thing I want to talk about is who's working on EOF.

As Pooja mentioned earlier, this is the brainchild of team Epsilon.

Epsilon is an Ethereum foundation funded team and they're focusing on EVM improvements.

In a prior life, they were focused on the eWasm project where they were going to replace the EVM with an Ethereum version of Wasm.

They spent a lot of years on it And it never fully deployed on mainnet because a lot of the work they did proved out that there were some issues with it that didn't quite meet the performance standards they were hoping for.

They know all the great reasons why it's not quite going to work for Ethereum with all the constraints.

So since then they've reoriented and they've been focused entirely on the EVM.

And EOF is really the synthesis of a lot of the work and a lot of the knowledge that they have, as far as what's going to work in the EVM and what's not, and what's something that we could move forward to and things that are just not going to work for Ethereum.

The second group of people that have come in recently in the past year or 2 have been the execution clients, mostly represented by 3 big clients, Geth, Basu, and Nevermind who have been working with this with the team Ypsilon on the EVM channel.

We have calls every other week to try and build up and actually implement the spec that we had it.

Back around January of this year, we actually had all of these 3 clients had fully functional versions of a version of the EOF spec called BigEOF.

And, you know, we were going through fuzzing testing and we were pretty far along fuzzy.

There are just some issues with some of the compiler stuff that I supported pulling it out of Shanghai.

And some people had bigger objections with things on some of the other issues that I'll listen.

They're now part of what's called the mega EOF spec.

There's another client there listed EVM1.

That is the C++ client written and maintained by Team Epsilon.

It's the sort of client that is suitable for inclusion as a library in just about any piece of code you'd want to write.

So there is a library that you can put in EVM with all these features and anywhere you want it, written and supported by an EF-funded team.

The third group that I think is worth mentioning, and this has happened in the past 6 to 8 months, and I think is an important addition to building EOF, is we've got the compiler teams, calling in and actively contributing and asking for more things and saying, this works for us, this doesn't work for us.

Now, when you think about it for a VM, the compiler teams are the real customers, so the real people who take whatever their high level languages and compile it down to actual VM code.

Now, Insolidity and Vypr have had significant input.

A lot of the changes that you'll see and a lot of the changes we're considering are direct results of some of the things they want to use EOF and to make sure that there's no size regressions or gas regressions, that they can get what they need and it has all the features that they have.

And Another group that's called in, all our meetings are public for the EVM implementers group.

There's a group, I think it's called the F Store 2 project.

And this is a group of people who are really excited about using smart contracts as data storage, cheaper than offline storage.

This is for stuff like NFTs and other sorts of features where you need to have the data available at all times, but you don't want to necessarily pay the storage fees for it.

And they've been there making sure that their concerns and their needs are fulfilled.

You know, that some of the opcodes we've talked about and some of the solutions are directly to get those needs.

So we've been talking with community members, compiler teams, execution clients, and of course, Team Ipsilon, the team that came up with EOF and wrote most of the specs that we're going to talk about today.

So it's been a pretty broad base of people working this.

This isn't just somebody in their basement coming up with bright ideas.

Started out that way, but it's grown to something much more accepted by the community, I think.

So going to a bit of the background, why EOF?

So I went through all the EIPs and I tried to list all of the unimplemented and unadopted EIPs that are out there.

The stuff on the left is the stuff that's actually active.

And the stuff on the right is what's called dormant, or I can't remember exactly what the word is.

But they have, these are basically the ones that are, have no 1 maintaining, no one's contributing to any more.

So effectively, they're considered functionally inactive and not being worked on.

And I actually ran out of slide space to write all the inactive VMs.

And this is even cherry picking some of the EVM stuff there, taking some of the obvious stuff out there that doesn't apply.

And from the stuff on the right, everything that is in a darker color is actually addressed by some of the features that are part of EOF.

And the stuff in lighter color, I think quite, you know, taken care of by EOF.

You know, like SIMD might benefit from some EOF features with the immediate arguments.

But account versioning, subroutines, data separation, getting rid of stuff like call code and self-destruct, multi-byte functions, procedures, These are all taken care of by some of the EOF proposals in 1 way or another.

So the reason I put this list together is to show that some of these ideas that we're trying to fix in EOF have been around almost since the dawn of the EVM.

I mean, when it was written over the weekend, there were some really bright computer sciences people who wrote it, who knew a lot about CS and a lot about what they needed to do with VMs.

But in a weekend, they didn't have time to sit and ponder about the 10 year needs of what a rich ecosystem would be.

I mean, that would be, you know, they were just working, worrying about getting something working as soon as possible.

So this is kind of the natural evolution of what success looks like, is some of the problems are much greater than could have been imagined at first.

So this is an attempt to solve some of those, the success related problems from the VM.

So we've talked about EOF, other than the collection of VIPs, what is EOF?

At its core, EOF is a container format for Ethereum virtual machine code.

It's not any fancy re-implementation of the VM.

We're just putting things in different places and being deliberate about the way we're naming it.

And we're taking our code and our data in the VM code, we're putting them in different places.

We're putting a header in to talk about all the different places we're putting the code.

And we're also including things like requiring that all code that is in the code section be actual valid functioning code.

You can't just put garbage in the code section.

Now in data, it's not called garbage, it's just called data.

But as far as the code, we need it to be real functional code.

Now, because of this, the EOF structure fixes a number of EVM evolution problems just by the nature of its existence, of how it's setting things up, and the spaces it's preserving for other behaviors.

The biggest thing is it allows opcodes with what's called immediate arguments.

You're probably familiar with these if you look at the push instructions, all the bytes that follow the argument or it's called immediate arguments in compiler parlance.

So we allow immediate arguments to occur anywhere, not just in push op codes.

And the second thing that I'll go in later, because it's a lot longer list and a lot more esoteric, is it prohibits problematic behaviors within the VM.

So if you put it in the EOF in the container, you put the code according to the rules.

There's a lots of problems that you just won't have to deal with if we get everything we want into the EOF.

And eventually, you know, we can get there through multiple steps.

But probably a question for later, you know, why mega versus big versus small?

I'm an advocate of breaking things once and getting it done once and forever.

And I think we can get there, but other people have different opinions and we gotta work together as a community to figure out how we're gonna get there.

Let's talk about a little bit of a story of why immediate are such a big deal.

Let's add immediate relative jumps, which is, you know, EIP 6.16 had a variance of this.

So in, in EOF, we defined the E0 instruction as a relative jump.

And it takes 2 immediate bytes after it, which form a signed 16 bit integer, kind of like push 2.

And that tells you how many jumps forwards or backwards we want to jump from.

So over here on the right, we can see, you know, how it would look in EOF for these jumps, instead of seeing a 65, you would see an E0 and we would go forward 128 bytes.

Or if you wanted to go backwards, you'd see an E0 FF80, which to complement encoding, is 120 bytes behind you.

Now how this would look in legacy code is a bit different.

If we were going forward, we would push 2 bytes onto the stack.

And if we're currently at PC 100, if we want to go forward 128 bytes, really, we would say we want to go to number, to absolute number 1080.

So we would push them to that destination out there, and then we would jump.

And if we want to jump backwards, we would push backwards and forwards to the same.

You just put your final destination, and then you jump.

What's interesting is there is a slight savings in size just from the push operation.

And also we can get rid of the jump desk.

What security problems could we possibly have from this?

And here's the problem to just introducing new immediate byte codes, a new immediate argument gets in, is it has to do with a jump desk instruction, existing EVM byte code does have a validation rule.

And then what they're saying is that when you do a jump operation, the operation of points 2 must be a 5B jump desk operation to make sure you're not jumping to points in the code that aren't intended to be entered.

So there's a second step in that, and that these jump desk operations cannot be inside of immediate data.

And at the time that this rule was made, Immediate data only consisted of push operations.

So here's an example of what, you know, we take this random bit of EVM code, this may or may not be useful valid code, but it demonstrates the issues.

So we start with a couple of push operations.

We push this value, we push that value, push EO11, and then we push 5B61.

And then we have another opcode that's not push related, another opcode, and we have an invalid opcode.

And then we have another, and this is a known to be, this is actually a valid opcode.

And then we have an opcode that's not recognized, so it becomes invalid code.

And then we have a couple of data things that look like it could be valid op code, and then 2 more invalid op codes.

So when the jump test analysis goes through the EVM, it's going to say that this 1 is not a valid jump destination, and this 1 is a valid jump destination.

And you know, lighting issues of it, would code actually look like this?

We got to realize that when we do these things, we need to make space for what is possible, not what is practice.

Because what is possible is often how hackers, you know, what is possible, but not necessarily good practice is usually where all the good exploits are.

So we need to make sure that what is possible is not going to cause problems.

So if we add our E0 opcode, what's going to happen is the semantics are going to change.

Instead of having in this snippet 1 valid jump destination and 1 invalid jump destination.

If we put an E0 with 2 valid operations come after it, all of a sudden we have no valid jump destinations in this code.

Just by adding a new op code that takes immediate arguments, there are potential contracts out there that might exist that now have invalid syntax.

And you can get around this, you know, with good compiler structures.

The solidity would mostly avoid this because they put all their data at the end, but that's not a guarantee.

The compilers might sprinkle their data all over the code in the middle because Verkle tree might incentivize that because you could put your data in the bits that are going to be loaded.

So the incentives, you know, hackers might use it to kind of stealth deploy.

Some contracts they don't want easily analyzed.

People might put these patterns in to, disrupt decompilers.

There's lots of valid reasons to put these in, to explore these cases that are not necessarily fitting in the current convention, but are possible within the scope of the EVM.

So because it's possible to change the semantics of a contract that's already been deployed, That's why any opcode proposal that's had immediate arguments has been rejected because of the potential security implications and the space we're taking away from already deployed code.

And generally speaking, I'd say there's 2 ways to do it.

There's compatible changes, and there's incompatible changes.

We do a compatible changes to the EVM all the time.

We just add another blob gas code, it returns the value, doesn't take any media arguments, doesn't ruin any other contracts, it doesn't remove any other functionality.

So it adds new functionality to your feature, doesn't change the other stuff.

But let's say we want to get rid of self-destruct.

Let's say we want to get rid of gas from function calls.

That alters functionality that other contracts may depend on.

And there may not be an equivalent feature set.

Some of the proposals for self-destruct have no alternative for if you want to get rid of your contract.

So we're getting rid of feature sets for some of these changes.

So getting rid of self-destruct is an incompatible change.

But just adding a new random opcode is a compatible change, a new block header, no new block header query opcode.

Another thing that we need to be mindful of with compatible and incompatible changes is whether we're making an existing contract bytecode that was valid into invalid code.

Now we can take what was invalid code and make it valid.

But taking stuff that was invalid and turning it into valid code, that was valid, making it invalid, you're basically breaking a contract that may or may not have worked.

There are risks also in sometimes making invalid, invalid there's tricky things to go on with there.

But generally speaking, if we take something you can't do into something you can do, and we'll let you deploy it then, that's generally a compatible change.

Another couple of requirements is that you must exclude all prior contracts the same.

We can't just redefine opcodes and make them do random things.

Changing add to multiply would cause havoc everywhere.

But if we do it in a way that isolates it, then that wouldn't be such a bad thing.

We put add somewhere else and switch them around.

1 of the final steps of this is that if you're doing a compatible change, it's like a minor version upgrade.

It's what's called forwards compatible or backwards compatible, depending upon the scope of the change.

But if it's an incompatible change, it's gonna break things.

And you need to have some way to isolate it and some way to make sure that things still function in the old system, stuff that's been deployed and will continue to work.

So we need to make sure, especially in Ethereum, that whatever changes we do, we can always deploy what's been there.

So how does EOF interact with the existing Ethereum virtual machine?

So 1 of the big things that's proposed for how we're gonna release it on mainnet is that EOF will operate in parallel to legacy EVM smart contracts.

You can compose them together, they can call each other, EOF can call EVM, legacy EVM, legacy EVM can call EOF, and things will work just fine as if it's just another contract.

See all Ethereum Cat Herders transcripts on Youtube

PEEPanEIP #121: EVM Object Format (EOF) with Danno Ferrin