# The Future of EOF: Layer 1, Layer 2, and Beyond! by Danno Ferrin | Devcon SEA

- Speakers: [Danno Ferrin](https://streameth.org/speakers/danno-ferrin)
- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2025-10-07
- Duration: 22:43
- Watch: https://streameth.org/watch/yt-NeKMerFPJoM
- YouTube: https://www.youtube.com/watch?v=NeKMerFPJoM

## Description

While the EVM Object Format provides a mechanism to modernize the EVM, the container format itself provides a stable path for innovation and experimentation within the base and rollup layers of ethereum, as well as rollup layers, and even chain free execution.

In this presentation we will show how the structure of the EOF container may be adapted to support these potential use cases.

Speaker(s): Danno Ferrin
Skill level: Intermediate
Track: Core Protocol
Keywords: Layer 1, EVM-equivalent, Politics, EVM

Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum, https://warpcast.com/devcon
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/ 

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. 
Devcon SEA was held in Bangkok, Thailand on Nov 12 - Nov 15, 2024.
Devcon is organized and presented by the Ethereum Foundation. To find out more, please visit https://ethereum.foundation/

## Transcript

[Music] but I think it's time we need to step back and see what eof could be in the future and what real power unlocks are happening now I name this layer one layer two and Beyond because a lot of these features we're going to see is going to get some differentiation in a compatible way amongst layer twoos and other chains and other uses such as offchain use but I'm going to focus mostly about what I term as oh yeah some so I'm an independent contributor there was a joke in there that I completely forgot about and um you know that's that's kind of a lame tieline who do I work for I work for a company called numid LLC which is a single person company so I can be a freelancer and get tax and get uh health insurance in in the US and I can have any title I want I mean why can't I just be a senior Consulting principal staff engineer sounds great better than that I could be the director of execution verification and assessment but I'm just going to stick with the independent contributor so and so when I when I think about the future of eof I like to think about what's in front of us what's on the horizon and what's going to be over the horizon and you can think of that as what will happen on mainnet what may happen on mainnet and what might happen on mainnet because it's kind of way out there there's a I'm going to talk about a few things that definitely are going to happen not in the first eof Fork maybe in the first eof Fork but on Forks afterwards and then some things will probably probably see on Layer Two first and then some things that are going to be experimented with and if they're really useful we'll see them come into eof into the main net so first let's talk about what will happen and what's in front of us and these are focused on things really to make pre-compiled contracts a lot better and a lot easier so we don't need to do those anymore so pre-compiled can just be just run the evm and you get all the performance that you need um so what's wrong with pre- compiles were they're bad for client code bases they're bad for security and they're bad for project management they're just just really difficult to to execute and deliver in a uniform way it's much better to let people write the code that they want in the evm and execute it the way they want the first piece is evm Max there was a talk earlier today that went really into depth what evm Max is about what you can think about it is it's math that lets you do uh stuff on cryptographic elliptic curves a lot easier a lot faster and a lot more efficient and also lets you do things on curves that are bigger than 256 bits because that's what your typical security is um it's got some new OP codes um it has a separate memory space and it helps you move stuff in and out of it and that's just focusing on the modular but there's another piece of math that we're probably going to need in the future in the next four or five years when Quantum uh when Quantum algorithms actually start impacting us and that is single instruction multiple data operations and this is for things like lattice encryption which uses kilobytes arrays of numbers that are um stretched out and calculated and and computed in large fashion in vectors and it's inefficient to do this individually so to really support lattice encryption inside the evm we're going to need a lot of different instructions that do it on a vector basis and this these aren't going to be really good for AI inference it uses a lot of the same stuff but we're not going to do AI on the Chain so there is an EIP out there don't pay too much attention to it I'm certain it's going to change this is just a mapping of Intel AVX onto what it might look like for the evm there's a chance some of this might show up in the evm max proposals but this is something to keep an eye on in the next four to five years because we will need to get some sort of support for Vector math to do large quantities of math calculation on the chain and some of the things that we can do in EO are to say we're going to need kilobytes or megabytes of memory in that in the headers and we can propose to say how we're going to solve those the last thing that's going to come on onto the onto the stage that is definitely going to happen for us for the evm is a legacy and eof parody right now there are a few things that you can't do in Legacy that um that you can't do in eof that you can do in Legacy um some key support for some smart contract wallets uh the ability to bring contracts in from your smart contract wallet into an entry point and bring it in right now that's fairly difficult uh for e but there are some solutions that we're going to solve that um and of course we could there might just be uh Native account abstraction that would be we support it in there um but there's also some features like um detecting if you have an EA that are essential for libraries like open Zeppelin another thing on the horizon that we're going to look at and this slide speaks as though it's it's it's a given but it's not necessarily a given is is sunsetting um as much of Legacy as we can perhaps making it impossible to deploy new Legacy contracts maybe not this is going to be a process where we need to make sure that the eof is Legacy for the things we want to preserve and we want to keep that's the first step is to get the parody and then we can start looking at all the other contracts that were deployed before and see what sort of features they have and that are depend can these be brought into a validated sense can these be brought in and used within the context of what EF allows or are they going to be doing crazy things like like doing jump locations from call Destination and is it essential that we preserve those um and also are they doing things like polymorphic code addresses do we want to support those or break those so those are some of the things we need to look for so the main takeaway from this slide is in a couple years we either need to have an inplace plan for howun to deprecate Legacy and not let new Legacy code be deployed or we need to have an answer of we can't do this because of reasons X Y and Z and that's okay and by that's okay meaning we can still snark all of the main net contracts just for these few cases it's going to cost them a lot of money and we're okay with that so finally what are some of the things on Horizon this is where things get a lot more exciting and a lot more uh leveraging some of the features inside of eof um and the key thing is we're enabling better execution on Main net and we're going to prove some of these features probably unroll it before they hit main Nets and they're going to be hitting things like account abstractions we're going to try unbounding the code size who wants to write a contract larger than 24K that's going to be safe now in eof and we're going to show you some of the ways that it's some of the issues that's going to be affected and another thing to look at for the in the future is concurrency not just parallelism but concurrency being able to take these operations um these contracts and split them up and run them in isolation safely um which is you know usually a for parallelism concurrency will feed into a lot of the parallel efforts and make it a lot better so first let's look into a native account abstraction um there's actually a proposal out there and I was speaking with some of the devs earlier this week um at a at a conference we had in offsite um EIP 7701 uh proposes using some features within eof to make Native account abstraction easier and the key thing is adding into the eof Container the notion of multiple entry points um typically when you run an eof contract you have to start at entry point0 but what they're going to do is they're going to put they propose putting definitions in the header to say you know what you could use section two section three or section 47 but each of these entry points has a specific role and when you execute that contract you're trying to execute it with that role then you would actually use that entry point instead of entry point zero what's nice about this is if you have a contract that is validating or serving as a pay Master with entry points you can be certain that the evm is only calling those entry points if they're coming in with a role and you can be sure that it's being used properly from within the system and not just called externally by someone hacking the system with some few random solidity selector addresses so there's proposed in there right now five different roles um one for deployment and two for validation and execution of your smart contract wallet and two optional pay Master validations and the way that would work is when you're doing a validation for your contract we would call your contract and keep the role and if it sees the has Center validation and it has a separate entry point we would use that to execute it instead same with validation execution and post transactions this allows us to ensure that these this code in these sections only gets called when that role is relevant next thing we're going to look at coming up on the horizon is unbounding the contract size um currently the limit is 24 kytes and this is a a a size that was set basically during the Shanghai attack and it equates to 6 megabytes of gas in about 2017 so it was as big as you can make a contract when the contract size was first imposed but it was put in as a safety measure in case that there was some other exploit in contracts that people didn't know about well there was one and putting this contract size limitation in place is actually quite handy um there are some really nasty jump dust attacks that you could do um with Cate that could really consume a lot of time and space and basically all of the clients we fixed this in Shanghai by charging every bite that we were going to validate for a contract so this is not a problem anymore but if between Shanghai and the Shanghai attacks it's kind of funny we fixed it in Shanghai um if you would have done this jump Des attack you would have really caused damage to the network now what's interesting though is that eof validation gets rid of jump Des validation the validation is performed when you put the eof contract on the Chain once that validation is done you never need to do it again so looking at this I mean it's like well what's wrong with six with 24K can we just increase it you why can't we just increase it to another larger value and this goes along the argument of saying well 640k ought to be enough for anybody let's just pick a big number and we're never going to hit that it's never going to become relevant that's the sort of comment that's going to come back and bite us even though as you do research on this you'll find out that Bill Gates never actually said that comment even though it's oftenly credit to often credited to them so before we completely Unbound it the size limit is going to be increased probably double it and maybe double it again and even when we Unbound it it's still going to be limited by the amount of gas that you have in a blocker for your transaction so so if you're going to deploy a gigabyte size contract I hope you have a system that allows you to use a trillion bytes of gas and in some offchain systems that's exactly what you're allowed to do um Peter cesi from G created a little burnt pixel thing um where you can use the evm to to create pictures and render them and it takes billions of gas it takes a whole lot of gas more than you could ever execute on chain so Unbound gas seems to be something we need to be able to handle um but more than likely we're just going to be increasing the size to more reasonable sides to get rid of the problems now in eof however looking forward to this a truly unlimited size does present some problems there are some Natures of the way that eof is written that you can only have code sections 64 kilobytes in size um that you can only have 1,24 sections um that your jump destinations are limited to plus or minus 32k from your location in theory you could deploy a contract up to 128 megabytes if you have maximum code sections and maximum subcontainers but practically the maximum contract size right now is 64k so how would we fix this probably in a few years when we get to the point where this matters we'll deploy something called variable length quantities into some of the headers into some of the op codes and make that as an option that contract developers can use if they need it um these headers instead of being a fixed bite length would use encoding in the bytes to have a variable length so you can have truly arbitrarily sized contracts what's interesting about this is if you're using smaller values the vqs actually save bytes and if you're once you're outside of those it costs a little bit of btes but the but once you get past 64k it makes impossibly large things possible um so the downside is that the header must be streamed now you can't check based on the sizes of op codes that might change the way that we validate but something like this is going to be needed to truly un unlock the full size of all possible contracts and and we'll get there uh just as soon as we can increase the contract size which is not the easiest thing to get done on ACD the final thing that's on the horizon is that I'm personally advocating for is we do a little bit more attention of what we can put on the evm to support concurrency a lot of concurrency actually happens outside of the evm cross-chain communications sharding uh mailboxes semaphor and all that but there are some things that we can put in the evm that'll actually make some of these concurrency things simpler and allow us to use things like the isolation um in the asset protocol to make these transactions more isolatable so if you have a bank from W if you have a large bank account you can do all sorts of withdrawals from it in sequence and not lock up lock up everyone from using that account until they process all those transactions there's two main ways we're going to look at supporting concurrency Atomic operations and it's been proposed for deferred execution whether we ship these or not remains to be um I'm an advocate of at least Atomic operations and there's been some push back on the Deferred operations we'll see what what happens there but I wrote a proposal EIP 7519 that solves the basic problems that are needed um for uh Atomic storage is just have an sedit and S debit op code you can take your storage memory and say add 100 subtract 100 now that seems really simple and seems really boring when you're looking at at the evm level but the implications are actually in the proof level and in the vertical level because you're no longer saying take a value from one to two you're saying take the value and just add one I don't care what it is just add one figure out at the end what it's going to be and from that we can split things apart and we also put in things like um having the uh overflow and the underflow detection in there to make sure that if you're withdrawing money from an account that the transaction's not going to succeed unless there's actually money in there this is truly like a bank credit and a bank debit I mean is literally the sort of stuff that you grab an undergraduate database book and you look in the concurrency section and it's like one of the first examples use use relative and Delta values so we need to put that into the evm so that can be possible the next one um that's been proposed is queuing stuff to the end of the block uh is was was was the proposal put up by Micah but basically taking a transaction have transactions spawn other transactions um there's been some push back but there's a sort of thing that we need to look into and other chains on l2s and l3s and offchain may use this feature to have transactions spawn other transactions in other ways it provides interesting opportunities um for out of sequence transaction processing finally what are some of the things over the horizon what are some of the things that are not realistically being planned but what's some of the great potential that we might be able to do in eof a lot of this is adventures in metadata the eof header has a rich opportunity to put all sorts of Random information about things that may or may not be relevant to the execution and allow you to do all sorts of interesting things with the values and that is not something we could do before eof because we didn't have a good place to put this metadata and read it and understand it and make it safe so one example is we could so so in order to support this we could even put into the header to say hey we're using experimental eips we could put in a list of the eips we use maybe the version and maybe some parameters like here's the op codes where they M to so you can create these experimental contracts and you can use them in some EVMS and the EVMS that don't support those experimental features will be able to read it and say hey hey hey I don't support this sedit stuff I don't support this sedit debit op code so I just planel won't delete won't use it and we can figure out those things out when you're loading the contract in on the create transaction rather than when you build an entire system and you're trying to use the advanced feature and suddenly you realize that push zero is not supported on this VM so putting those sort of that sort of information in the header is going to make it really easy to support experimentation in eips and in code going forward another thing we could do is we could put alternate by code formats it doesn't have to be evm in eof we could put wasm in there we could put arm we could put risk V it could be the primary op code or even more exciting you could put two versions of the op code you could put an evm version in there or you could put a risk V version in there so when you're running it on one system you can run the evm version and when you're running it in ZK systems you can run the risk V version now it's going to be on the compiler to make sure that those two versions are equivalent and provide the equivalent systems but it's a great way to pre-compile and pre- optimize operations on different chip instruction architectures and when it comes to gas golfing being able to hand weak the op codes in each of those systems is key another thing to look forward to is something called Progressive pre- compiles this is a pitch that was raised on uh ethereum magicians where they have the idea of well let's just take instead of having pre-compiled let's just take all our fancy math and get a standard evm implementation of this and then let's feed it through the create to create transaction that gives us an address and that way we know that that address is going to be where the op code is and let's just make our pre-compile code there do whatever the pre-compile is the upside is if you don't have that pre-compile in your system you can just deploy the evm code and if you do have the pre-compile well it's cheaper and faster and more efficient the problem comes in in that how do you codify what the cheaper gases in the systems for the pre- compiles when they are actual no local pre-compiled and how do you deal with systems that want to prove the evm execution rather than using the pre-compile logic and make sure they get the right gas costs well in the evm we could specify alternate entry points like we did in 7701 instead of saying that this is for validation we could say that this is for the gas cost and based on the input data here's what the gas is so we can go from ancient systems of measuring gas to fancy high-tech versions of of predicting gas without having to execute the contract and again it's on the pre-compiled developer to make sure that those numbers match up properly and if systems don't want to use this gas they can just reject that field and use the evm execution another thing we could do is we could take the solidity dispatch we could wire this into the header um in the front of almost every single smart contract is a bunch of SW switch code where they're trying to figure out from the first four bytes where to jump to to execute your functions coming in we could put this in the header and we could just have this as a part of the call dispatch and have it go to one of the different entry points based on your selector we could save a lot of gas and do it really efficiently inside of the EVMS and finally another thing we can do and this is something that I thought of after I wrote my slides came to the conference and watched a panel about contract verification we could put the contract verification data in the metadata in the header rather than just having it as random code bytes at the end of the data section this is an actual live contract this is the Tron to usdc Unis swap V2 contract and you can see they put a lot of metadata at the end that doesn't necessarily have to be used at runtime and could be encoded to say here's your debug symbols here's here's the uh bzzr link to get the source code and here's the version of solidity that we use to compile it and they could put that in the header and you could read that and uh you wouldn't have to have that exposed and you could put a lot more semantic meaning inside the eoff header and this would make people who do validation much much more excited so what will be what could be and what might be the future um you know there's what could be on Main it one day what will be on mainnet has to do with with with with the eips that are already proposed things to watch for our our account abstraction Unbound contract size and some concurrency initiatives that are starting up and the things that might come up is just random plays in in the metadata there are some great opportunities in there so thanks uh nope that's not me that's not me that's me thanks thank you Dan apparently you're a man of many heads all right for our audience if you just join us um feel free to scan the QR code on the screen to ask some questions uh but we do have some already on the mircat platform so we'll start with the first one will the shift to eof impact ethereum's security model um so security means a lot of things in a lot of different contexts um when you're talking about the security of a compiled bite code it's going to have huge impacts because we can verify the stack Heights you can be secure about your code um but as far as the security of um like am I authorized to transfer this dii contract to the other thing um it's going to have it's not going to make anything better or worse on the application layer of people using evm So within the evm it's going to improve the security standing and for people using the evm not going to make things worse but it's not going to make things better all right and our second question any chance for a 64bit evm um there is a chance uh because what's interesting right now to give some context to that question the evm as everyone in the audience is probably aware of is a 256bit register VM machine and that presents some ahead of time compilation issues that you got to play games with the types on the stack if we dropped it down to 64 bits there's a lot faster and better code that we could put in um that's the sort of thing that you could you know over the horizon encode into um the evm header that says by the way my register sizes are 64-bit and everything in here operates in 64 bits I mean that's that's an excellent investigation that some l2s might want to do yeah maybe in the near future all right and our last question which of these proposals would involve changing the eof version number that's an excellent question so when you talk about uh version numberings there's like major numbers and minor versions and that's kind of some of the the the heartache that came with making eof is we had to do a lot of breaking changes from the initial evm things that that were incompatible and that you couldn't figure out were different so everything that I proposed here is something that I would call minor updates soft Forks so if you imagine the world of all contracts that are valid in eof version 1.0 and you add a feature none of the contracts in that first set are invalidated but you grow the set of valid things I would consider that to be a minor upgrade and everything that I proposed merely grows what is a valid the contract because of the validation so we're not breaking anything that came before we're increasing and adding new features so I don't think anything I propos would require changing the major version number of eof all right I think that's all the questions we have thank