New Ethereum talks, every Monday. The week's conference uploads by event, in your inbox.

Loading player…

Unpacking EOF: Applications in Developer Infrastructure and Tooling | Devcon SEA

DevconTue, Oct 7, 2025, 12:00 AM

In this talk, we will delve into the Ethereum Object Format (EOF), a pivotal component of the upcoming Pectra hard-fork, focusing on its profound implications for development infrastructure and tooling. EIP-7692 introduces a new execution environment and a structured format for executable code, bringing extensive changes to the Ethereum Virtual Machine (EVM). How will it affect developers? What will make their lives harder and what easier? Speaker(s): Nebojsa Urosevic, Pavle Drobnjak Skill level: Intermediate Track: Core Protocol Keywords: Core Protocol, Developer Infrastructure, DevEx, 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] working as a software engineer and leading the virtual machine team so the idea behind this talk is to zero in on the effect of eof the ethereum object format on developer experience developer tooling and to focus primarily on debugging hopefully by the end of this talk I will convince you that eof will make it possible for the web3 debugging experience to be Miles Ahead in comparison to web to uh currently um there are many debugging issues in regards to solidity everyone who's ever written a smart contract knows how hard it is to debug it during development and after it goes into production broadly speaking uh issues could be bucketed into two groups one of them is the fact that we are lacking a proper debugging format and the other one is the fact that you could execute optimized and unoptimized versions of the same contract and get different results these two issues are in a sense interwined so let's say that you'd like to debug a program in traditional programming SL web2 uh you would need to debug it using the debug release if you would use the re the release executable you would have much less debugging info therefore you would have much less data about the state of the program at the point that you were trying to debug so the issues are that in order to have the exact same amount of data when you're debugging solidity you also need to debug it using the debug release SL executable which means that you would need to debug the unoptimized bite code since there are differences in execution between the optimized and unoptimized bite code effectively you could have a debugging session that's been running locally where youve executed a certain code path and when you replay that input in production or in a local session using the optimized version of The Bite code you could get entirely different results the main culprit behind this is the gas op code which is being executed every time there is a call and which can also be injected into the execution VI an assembly block let's say that we've got both the optimized and unoptimized versions their gas consumption is different therefore the value that will be pushed in at the stack when a guess op code executes will also be the different and if a control flow consumes that value we will get different results therefore we cannot be sure that when we are debugging using an unoptimized version we are actually looking at the things that we' like to see and the lack of a proper debugging format disallows us from having the exact same data data granularity that we would have while debugging in a traditional programming language um eof offers solutions to these two Problems by changing the structure of the evm it will be much easier to define a proper proper debugging format and to extract the same kind of data that you are able to extract in traditional programming languages uh but there is also one uh extremely interesting development that happens inside of the eof that allows us to have semantically identical executions between optimized and unoptimized versions of the bite code um gas op code is removed as well as other op codes that whose output depends on the code structure such as code hash code copy external code cach external code copy therefore when we get to a debugging format that will allow us to have to extract the same kind of data we will be able to spin up uh debugging session that will have the exact ex same output with a with an optimized bite code and an optim unoptimized bite code and this is my final step towards convincing you that web3 debugging experience could indeed indeed be better but I'm running out of time so I will be quick um let's take a look at a single request SL transaction um let's make it an HTTP standard request that lands on a server so every program that executes has both has two kinds of input a code and state when you land on a specific server the state that you're getting as input uh is fragmented it's either either in radus it's either a local variable it's either in pogress but if you execute a transaction on the blockchain the state is localized therefore you can replay the exact same input that you had in production if a transaction let's say failed in your local development environment and if you are able to extract the same kind of data via a new debugging format and have the same execution in unoptimized bite code and is and in as in optimized you basically can replay every production request locally with exact same environment as in production and that's it thanks thank you very much for the presentation uh so we don't have any questions yet I I have one uh is there any implementation of a debugger that uses a so far or not yet not as far as I know this is a thesis it can be looked at it that way um some of the clients have implemented the O but some have not yet have not done it yet okay let's go to that question uh do you have any insights on if EF affect source code verification I'm trying to think off the top of my head I do not have any insights as of right now as I haven't thought about it so source code verification okay so yes it does affect it um source code will be verified on the protocol level every time a contract is deployed there will be no need for jump dust analysis every time uh jump desktop code is executed as it is removed from the virtual machine alog together in EF contracts mhm uh and uh let's try to answer one more question uh which difference besides gas consumption can be between optimized and nonoptimized codee so optimized uh code depending on the number of iteration that you optimize it with um so there's a flag that basically says I want to this contract to be executed optimally if it is executed x times and you can say that it's a th000 times so if it's executed a thousand times on average it should have uh much less gas consumption than in in comparison to the nonoptimized bite code so optimized bite code can uh throw out entire sequences of the bite code it can also merge sequences of bite code and every time you change the bite code you basically affect the G the gas consumption

Automatic transcript — names and jargon may be misspelled.