Decoding Ethereum Object Format (EOF)
EthereumZuri.ch 2023 · April 2023 · 36:12
Mário Havel, Miao Zhicheng, George Kobakhidze, Nebojsa Urosevic and Anton Permenev discuss the EVM Object Format (EOF), an upgrade meant to turn the Ethereum Virtual Machine into a more sophisticated computing platform. The panel covers EOF's technical details, its role in the Ethereum protocol, the related EIPs and how it could make the system more efficient and secure while allowing future upgrades without breaking backward compatibility.
Speakers
Topics
From EthereumZuri.ch 2023, hosted by EthereumZuri.ch.
Transcript
foreign [Music] everybody um moving on to the next panel this will be my easiest introduction of the day because I'm going to hand over the mic to Stefan and he'll do the rest thank you very much man uh so uh I think
we all feel great to be here and thank you all for listening and we'll go straight to the point uh today with us are meow from superfluid uh Mario from ethereum Foundation George from consensus Anton from chain security and nebucha and myself are from tenderly guys if you want to say like one or two short sentences about yourselves introduce yourselves and we'll get straight to the point uh today oh okay um yeah I was building super turkey yes uh yeah so I'm from I'm from uh super fluid we've been building uh the uh the magical token called super token for
quite a while and uh um I don't know enough about eof but I I hope I can provide some also my new thoughts about it also for this one I think um hey everyone I'm Mario I work with ef uh specifically protocol support team uh which is a team which helps to coordinate the work around core devs and uh well uh also to um test ship hard Forks so I'm more of a technical part of this team where I dive into some research around the the uh current research and I'm I've been running uh the protocol Fellowship so I'm helping to onboard new core developers uh yeah
hi everyone my name is George I'm from consensus diligence and I mostly do smart contact security audits some tooling and some zkp research here and there nowadays uh hey everyone uh I'm nabusha one of the co-founders and tetherly uh we are building a developer platform that helps Builders be more productive and efficient when they're building and testing smart contracts um mainly I'm working on our custom virtual machine that is capable of extracting more data during the runtime uh hello my name is Anton I'm from security we are also doing audits for uh ethereum smart conference and uh also
internally we're doing different tools and keeping Nicole's eye on all the changes in a bytecode and uof including it affects our security tooling a lot let's say and yeah thanks guys so uh for the intro uh nebucha will really shortly go through like the the what ethereum object format is but we wouldn't want to focus too much on the technical aspect aspects of it today we would like to focus on what the E what kind of impact eof will have in the space and on developers so I wish up take it away um right I'm going to do just the short intro and anybody from the panel can also chime in if they have something to
add so basically ethereum object format introduces this new way of how smart contract byte code should look like um by that I mean it it restricts uh how the exactly the sections of the byte code need to behave and look like and this has uh a lot of implications uh the first one is that on the runtime we no longer need to do and perform some checks which can in essence help us with the scalability of the whole ethereum but as a consequence we need to do some checks on the deployment
time um right yep that's basically it I mean if anybody has something yeah I would mention just one important thing that like the whole name is wrong here like I was I was telling the organizers and I I think it was changing the schedule but it's still here it's not ethereum object format it's evm object format uh okay so we are talking about the ethereum virtual machine the the heart of ethereum the the I want to see the brain the the execution environment which right now it has to work with just like like a blob basically just like bunch of bytecode uh just um when you are deploying a contract it doesn't have any structure it's just a bunch of bunch of code and evm goes code
by code byte code by code first it verifies whether it's correct whether it can even execute it uh whether it exists whether it has enough of gas whether it doesn't break any computation and that's um and this can be well uh externalized to do it at the moment of deployment which is great not just because we save your time at execution but also so but also we will prevent having just a mess on the Chain which is unexecutable um and uh yeah just just to mention right like so now instead of just like random pieces of code it will be structured like we have a header this is the code this is the the data and when the evm comes it can tell like okay the
header explains the version that that's one important thing that will be the versioning and uh this is the code that I'm looking for and I need to verify this right right it's it's good that you mentioned versioning because that's basically where we wanted to start uh so like what will be the implications of versioning I mean how do you see that going down and propagating through the levels all the way to the to the depths or whatever you're building um should I tell playing it I mean I mean I I can I can choose who talks but George looks like he wants to say something okay so yeah no I think uh since we're talking a little bit less technically more like narrative almost at this point um first of all I think one thing I want
to say is that this is the first big change to the evm itself especially after all these upgrades to the protocol now it's uh finally we're get putting the spotlight on like one of the main things probably about this whole uh ethereum ecosystem so that's first big change and then the second that within the change itself we have the notion of versioning so it's kind of an interesting thing how now we're going to be looking at even more explicitly looking into upgrading very core parts that are not even necessarily backwards compatible parts of the protocol as we're going to be upgrading them and then on top of that we're gonna even have an explicit versioning part to it meaning that we are explicitly looking to have several different potentially not compatible versions of code kind of
living on ethereum and we might have correct me if I'm wrong some some contracts they're going to be able to speak to each other in future potentially not being able to speak with each other let's say if we have uh eof version 13 right it might not be able to be to be speaking to version six and then we're speaking in the green room right before this uh it might be interesting that this is might spill out to different layer twos and how they might have their own dialects of the eofs running there in different containers or code containers that might be a little bit slightly different from the mainnet and might be compatible but maybe one way not the other way and just overall kind of I think it's it's interesting how this is isn't just a major upgrade of the evm itself but in
itself within the upgrade we have a notion of that it's going to be changing more and more I also wanted to maybe like add something that Mario mentioned before like that's basically this could be chunk of an executable code right it's actually one of the cool things is that they're going to be introduced also data sections right for like bytecode is not only executable code for many things the parts of a bytecode contain actual data because there is like code copy of codes and so on that can be used for uh immutables right the factory contracts needs to store the byte code of the contracts they need to be deploying also somehow right and like alternative is doing it in storage but
it's super expensive and there is no like a way to load large chunks of storage in one go there you only can access it word by word so it's like for many places uh the byte code is used as a kind of data storage right and for me it's like this is honestly a really nice feature because now you can clearly distinguish between what's executable and what is used as like data right that's one of the important things to mention that like it's the biggest upgrade to evm in a while like I mean like the most significant upgrade we had was push zero this week but uh yeah like the evm today looks almost the same like
three years ago and the folks from the Epsilon team axig Pavel Andre has been working on evm upgrades since like the evasm era and uh this is something which they put a lot of work into so I'm hoping that that it's going to going to like this this changes in the evm are very slow it's also one thing so we mentioned the versioning yeah I wanted to react to that because I mean it's um uh like we'll basically now have different I want to save version as of evm but it's not like fully what people might imagine because there is you cannot the changes that can be done in the each version are still limited it's more like it's it's it's the new version can add
new features uh it cannot it cannot change things right so so we can see that uh the the contract or the the um the developer can actually uh can actually see that he's using this version and uh and he's um uh he's compatible with with the new features let's say so it will might be even even easier to add more features but um also it's like maybe more standardized approach to have the various EVMS around the ecosystem especially layer twos right um because uh I think arbitrim already announced it but uh the idea was already like a year back at least like we could have kind of better version I don't want to
still quote me on this but like another like version of evm where we uh changed improved something and this is running on layer twos they tested and maybe it get bootstrap to maintain it at one point um but uh again like this breaks the equivalency right which with some people are trying to to reach and generally like there is a lot of issues with eof as well like it's not it's not all fairy tales like it's pretty pretty a big uh uh big problem to solve uh that's why it got pushed from Shanghai to maybe Cancun maybe Prague um and um yeah and uh one thing is that now we are going to basically break the evm for all of the forks which is like half of the
the crypto coins out there yeah so I I'd like to add that right so it's not just a rainbow and sunshine and this might be also the fragmentation and now it's not only a technically a new arena for us to innovate but also probably a politically a new arena for fragmentation right so there are political actors like kill switch for small country what if the someone decide oh this evm that specific feature you know enabled by better version versioning which is technical Excellence perspective what if the political kind of hijacking center right so I think that part uh uh we often let's talk about in the technical Circle but often uh encrypt crypto there's a lot of this kind of good and evil
sometimes uh can emerge as a conversation especially around us we have a lot of layer twos that are coming out like white labeled like exchange exchange based layer twos like let's say the coinbase one that could definitely see something that there yeah and as well as you mentioned like the fragmentation of the chains but you also have the fragmentation in the tooling space yeah so the layer above like the l2s is like and the evm is programming language and the layer above that uh is the tooling the security components the decompilers ETC and they would also need to keep up with all the improvements on the on the object format as well so yeah I also wanted to add something about the features uh because it was mentioned
here like basically we are adding features but honestly if the area of one at least like how it's now it's technically we're constraining how the code can look and what it can do it's technically a removable features you can say it's uh by forcing this blob of data that's now to be of a certain shape we are technically disallowing certain behaviors that are kind of allowed before and I think I don't know if it will make into the final eof one or it will be some professoriers for example self-destruct up codes is going to be kind of replaced by something seven dollar codes and this is you can say also like a feature removal right and it's technically like even like there was one proposes like our engineer
Hubert resorf maybe people know proposed to UF itself on the discussions and it's maybe going to be accepted is it if there is no gonna be longer a way to delegate call from the eof into the vanilla evm version just because otherwise this will be like a back door to access all those features this technically right now we are removed in eof right but of course like going further maybe you have three four files is going to be more feature Rich than UF one right so this is what you actually just said is a nice segue into like the following topic uh which is basically I mean sure they're like good sides and bad sides and people are going to use you
have in various ways but like how do you see it starting to propagate into the in the developer Community like what do you see are the first use cases or usages for you have in which types of projects I mean any kind of thoughts on on that front you want to share I guess one thing because we're also trying to uh battle this question earlier and trying to think like how is the adoption actually going to happen one thing that kind of Springs to mind and that often how these special in our space these things happen is there's probably going to be a big player like a big project big protocol you know the the uni swaps of the world that's going to release their their their new smart contract version and they're gonna have
it probably you know all up to date and then all the t's crossed and the eyes dotted with the eof container version you know with the the newest UF whatever that's going to be you have one or whatever that form is going to take and they're going to say we're now you know fully doing it up to the uof contract with all the um with all the things removed that need to be removed all the things there that need to be there and then other players later on as is usually the case in our space will start to Fork this and that's going to start to propagate this and then since these are going to be popular contracts our security tooling is going to need to start to catch up with this and it's going to start to adapt these features more and then other security
tools are going to start to follow and slowly and slowly everything is going to kind of avalanche from there uh it's definitely just one of the ways I think that that option is going to happen but probably in my head a big player is going to do this and then that's where it's going to go and it's funny that you mentioned the uniswab because I mean they've been pushing for the 1153 is it the transient storage right I mean they had their own solution basically and now now they kind of have to wait for the UF uh yeah I mean um because I mean first of all it needs to be implemented in compilers right I mean solidity have that doesn't have it because it well it's not even specified yet we don't have final eof specs so like I'm uh what I'm hoping for is that
it will be on the solidity level or the compiler level it will be uh natively uh or like there won't be like some optional experimental feature but it will be easy to use so it will be basically utilized automatically by any contract and um yeah they hopefully we'll save a bunch of gas yeah I'm not so sure of the increment increment incremental changes uh the best way to actually get this out I'm just wondering if there's a chance for a bit more Leap Forward type of improvements that people maybe something from scratch like a new channel or something that uh they say hey how about we start from scratch in this particular chain to demonstrate uh something like a
really really new uh as opposed to incrementally fix something in the ecosystem already so but it's actually interesting that you talk about like starting new chains with these updates because with things like uh ZK VMS they need to completely rewrite all their circuits with every single upgrade I even wonder that say because there's a couple of ZK VMS you know supposedly over your life today uh for them to upgrade to the with this new eof version I wonder if it's easier to just start a new layer too um and then you know start a new instance of their ZK VMS with these upgrades as opposed to maintain the existing one and then try to upgrade it
to the newer version with the eof um but um to to actually support these leaps as what you're saying because for them especially for these circuit based ones it's going to be very difficult to always keep up to date with incremental upgrades for all of this yeah yeah I mean it's great if you mentioned it like it was one of the point to be raised like that there is like five ZK evm projects right now and uh they will have a like for it's not trivial to to change uh something so so big as evm uh there or the eof there um but also on the for all of the client teams for all of the ethereum clients what it means now is that they basically need to maintain different versions of evm because you you want to do the full
sync and now you need with each hard fork or like in this case let's say with each give your version an EF version later you need to you need to execute this piece of student introduction then okay we switch the new one and uh that's that's a lot of code paths to be maintaining yeah and on the adoption I think uh George and Mario you mentioned a good thing uh I think that this space is incentive driven and like uh dabs need to find a way to uh like to reach the broader audience and for that they need better virtual machine and so they're pushing for the Innovation on the virtual machine then the virtual machine is pushing the Innovation on the compiler
level then they are pushing the Innovation on the tooling and then we are also giving it back to the dev developers so it's like this whole circle of like incentives that and everybody is pushing in the in the in the right direction but yeah of course it's like this Innovation I think it's essentially is foreign [Music] jump up codes right and introducing new static jumps and like call and because exactly they're not gonna need to do the checks on like validity of the
destination addresses and so on I think it's most likely they're going to be cheaper and this adoption can come just from the fact that using eof1 is cheaper right I also recall I think that now well now once EF comes out on-chain validators specifically for like layer twos like a thing for optimism say you know the arbitrums of the world I think even for them it's not going to be actually cheaper to run their on-chain verifiers to actually verify you know verify the state changes submitted by sequencers uh and that's you know that's cheaper cheaper proofs cheaper roll ups and that's Downstream cheaper for the users of those roll ups that's also more
adoption right if if I'm one layer two that doesn't adopt this and my competitor adopts it and now suddenly they have much cheaper gas costs for their transactions because of the eof because their Unchained validators are that much paper I'll be is that much more encouraged to adopt this this new version as well do you guys think I mean one of the biggest things with tof is definitely a much better utilization of resources and paying less gas in cheaper gas but do you think that EF will have an impact on security a positive impact of security as we hope it will or you know we're gonna find some other problems down the road I would say it's really a good question and it's really undetermined uh that's
why I'm here yes out um like last thing I remember was um One update in Constantinople using where is that uh storage operations were repriced and something like ethereum like not so zero solidity was using the gas limit for reinforcing uh like Appropriations during the calls that just need to send the value and you had enough gas on like the 2 100 guys I think to basically emit an event and after the reprise you actually could do some storage operations and it was a like problematic in this case like what I'm thinking what's essentially happened in that
update and why it's relevant to us it's uh the system allowed more Behavior than it was before right and now like with the UF at least how it looks like again the behavior is not added it's removed mostly right so at this point I would say once there is no back door to delegate call back to their more feature Rich uof I'm not super concerned about the security because you're technically just making more restricted systems that shouldn't break easily but of course because the tooling needs to catch up with all these changes maybe there's going to be some compiler box again and so on right this is this is always a
danger right so it takes a while to test and to validate such big changes so yeah um on you mentioned before the call app op code I think it's going to especially help us validate not just certain contracts but look at the whole chain more holistically and understand better what's going on like right now when you have the evm execution you basically almost have no idea what's going on with not non-verified contracts but with the eof and the code sections we can better understand uh what's what's happening inside there
I mean yeah I think that to that point especially because you know a big thing right now in security is doing like War Room analysis you know on a post-mortem analysis and trying to determine what happened where with what contract and why would those transactions uh with the eof supposedly it should be it should be much easier to actually perform some of these analytics on you know the attacker contracts and whatnot but it's interesting because assuming that once the UF comes out you will still be able to for some time deploy Legacy contracts which are a lot more of a you know random bike not random but an unstructured bytecode that is much harder to actually decode and understand I wonder if the attackers in those cases will exclusively deploy non-eaf
contracts to throw off all the new tooling that will be better you know better able to understand eof contracts instead um but of course you know that's I think gonna be attackers are going to attack always I mean it is going to hate um but on the other hand for for good contracts and for good bugs good bugs you know non-malicious non-maliciously occurred bugs with eof it's going to be much easier to understand what happened and what you know what's going on there and what what the what those attacks did besides besides you have obviously improving the development process and hopefully the average quality of a smart contract um do you guys see like eif or like
smart contracts being used in any kind of well I don't want to say innovative ways because everything that we're doing in this space is more or less Innovative but something that we haven't seen up until now is it gonna open some new doors for people to do things differently or to do new things or something like that immediately no I mean in eof itself like the ones is going to be recent it's like again less features of say something that's now present in solidity like function pointers it's gonna be pretty harder to do it without Dynamic jumps right but what's big thing is versioning right yeah and this versioning all the doors
are can be opened well this dog but it was like a year maybe two years ago um about how eof can work with a current abstraction yeah yeah so uh actually we might see some improvements on that front like uh actually utilizing it for more effective or more feature full account obstruction and um yeah I'm wondering how the data like now when we have the space for the data whether it will be maybe I mean uh what I was hoping for before was that this can be utilized uh better to store the L2 data but we will have blobs for that maybe sooner than you have so yeah we'll see we'll see about that
and like since the effects of UFO propagate and you guys mentioned like we need to develop tooling and everything else uh and this is not a tenderly chill although it's our panel how do you think UFL impact tooling as a whole um well I can start yeah we're doing like security tooling right and sometimes like we did a uh like static analysis on a bytecode technically it should become easier for such kind of tools which needs to dive into a bytecode analysis just because uh Dynamic jumps where let's say not the most ideal thing to deal with especially during like some symbolic execution
when you can jump to symbolic uh I mean solidity things got in most cases had a good enough invariance where it never happened but for generic byte code like it's like any byte code that you can ever deploy it was like a real problem so for security tooling on a bytecode it's going to be most likely easier no an interesting thing there is I think there are some comments also online around the eof about this is that because we had to deal with these problems as this in security telling some of them were maybe even the majority have already been kind of solved like we've adapted our security tools for that um so ironically while the impact is
that it's going to be easier to create newer versions on this eof stuff we've already have existing code to deal with the previous problems so we're going to have kind of like both this is going to be easier to adopt I guess newer tools and create newer versions of these tools but also interestingly we're going to need to maintain both at for the time being to take care of the Legacy contracts as well so there's a little bit of uh that's like a negative thing now that we're gonna have to take take care of like both types of contracts or you know styles of contracts on chain I think the existing tooling is definitely will push back on this Riser because no one pays them to actually do the upgrade it's like uh like ethos can have to upgrade their stuff I mean they're well paid but there
are people that are doing other tools may not have the position to actually support both versions and the economic incentive has to be also there for them right um and then yeah you mentioned an interesting thing that uh the tooling is going to have to keep up I mean I completely agree with that uh the interesting part there is that uh we're still in like this is the version one and the community is still yet to see the uh real implementation of this and the possibility of the UF uh I think that once they get a sense of how they can utilize this uh what would be the improvements for them that they uh if were implemented that they would benefit
from like we're going to see a huge number of use cases for it and then the tools uh and security components will try to adapt based on that and I think there's like huge room for improvement in that area awesome so the spotlight is back on me you want more hard questions no I I have one more because um like the people at least some of the people who want to know uh well UF is just getting started and we don't really have still any kind of best practices or guidelines or use cases which you could refer to either good or bad like do you
think the the best practices will be led by you know the ethereum foundation or the team behind the eof or it is more likely to come from one of the projects which will implement it well and use it well and act as a use case to be replicated throughout the industry I think it's a silly answer but uh all of them uh specifically because the team behind the um that's pushing the eof the teammates that you're mentioning I mean they are just excellent I mean they maintain so many pages about this and they constantly update all of them and they you know provide all this stuff so many he can deducts yeah yeah exactly I don't know how many hack MD docs I had to go through for this panel
um so without a doubt I feel like once we get closer to implementation and once we have all these things already set up with the specs and whatnot they're gonna also give out you know here's what we think is best practice because of course means their their child their baby but likewise I think as I was mentioning earlier I think one or two bigger projects are gonna try to jump on this to also claim the spotlight quite frankly say we are the first big one that adopted fully this eof spec and here's how we did it here are best practices and then that's going to be the new Holy Grail of other developers projects to like follow this so but I do think there's definitely going to be different pushes and some for altruistic reasons like the Epsilon team not to help out with their own little project
for the sake of the ethereum ecosystem and some a little bit more lucrative to like say like we are the first ones who got this UF spec right and here's our best practices and do it like that um um yeah just to mention again like with the academy pages I believe it actually made some like solidity examples or some some uh some examples or of how EF should be used not sure if it's best practices but because I mean we are still too early uh not that we don't have implementation we the specification is also not properly figured out like the latest what I would recommend the latest reading is the Mega eof end game if I'm correct right so like that would be the the current state
of the of the eof um and then yeah what I'm interested in are like what do we find will be the race to be the first contract not not like do it properly but just to be the first eof contract on the main ad yeah we saw that in with push zero as well first dkvm so uh you can make nft out of there or whatever the first year Well we probably will make an end of the other one uh we have couple more minutes uh I would like to leave this time for you guys to share some final thoughts or whatever you find interesting about eof or like you know whatever crosses your mind actually have a question to the rest yes
I have a question uh so like we mentioned it's like best practices but this practice best practices you mean like for most developers they are not working with a bytecode right they're working with solidity in this case are you thinking that like solidity will change a lot because of how the bytecode that's literally needs to compile into real change honestly it's like there's a layer between developers and bytecode which is solidity and I expect like if it's done well people won't even feel the change maybe it's like the only best practice so far don't use function pointers well I I'm not really quite sure on this one
but I feel like uh I'm gonna correct me for my own colleagues but you could end up utilizing the data part of the of the code a little bit differently right and I feel like there could be some clever tricks and best practices around that that could be utilized so things like that I think could come up I mean like the best practices are inline by byte code right if you are a proper sold at the hacker so I mean there is the layer but uh yeah I mean that's what I was mentioning like I hope it's all the implementation the compiler will work so smooth it like we won't even notice but still for a simple version is something that you need to work with right like there will be some some subtle changes that we notice yeah it's very interesting and speculation like what if
Viper does you have better than solidity yeah yeah actually I wanted to mention like that there's an another thing or a tooling that I hope that Viper will catch up on eof and uh fee Fe as well which is which is all already production already and now they will have a lot of work to catch up as well yeah but in a way they have in a way they have less work to do because they haven't been so spread out but I I get your point completely yeah uh never ship some closing thoughts oh um just that uh I'm really excited about uh the implementation of the UF it's been like what nine years since we made any like significant changes on the evm byte code
and this opens the door to like new possibilities and like uh once we change the base layer uh the the layer above that are going to change as well and probably introduce some new way uh um of developing and more introduce ways of having more security uh on each bubble layer as well yeah I completely agree I think the most exciting part for me is like what this change means and that it's not a protocol change now it's the evm the Computing change and then in itself it has suggestions for future changes and future upgrades and I feel like it's just going to encourage a lot more uh maybe even wild experimentation and
what could happen with the evm later um and yeah that's just exciting awesome I I honestly completely agree with that guys thank you so much for being a part of this panel I think I speak in everyone's name that we all enjoy this and for you guys thanks for listening and I hope you found this fun and useful uh a big Applause for the guys [Music]