Ethereum Object Format (EOF): Necessary Evil or Needless Complexity?

Transcript

someone. >> Hello. Hello. >> Uh hello. Uh welcome to today's session. My topic today is isan object format ef necessary evo or needless complexity. And uh before the session starts please let me briefly introduce myself. Uh my name is Luis and I'm a white hat from D5 hack lab. The Defi Hacklab is the biggest uh web3 security community globally and we're excited to have you all here and defi hacklab is also the place where I conduct attack incident analysis and we also have uh security boot camp and I'm glad to be part of the

uh instructors and I also like to uh conduct audit join audit competition on different platform especially fully container and sometimes uh I join CDF challenges also. Yes. And my topic today is EOF. EOF is not the abbreviation of end of file. It stands for Ethereum object format. And here uh before uh dive deep into EOF, we could have some background knowledge in EVM. EVM stands for Ethereum virtual machine and you can view it as the engine for all the smart contract to

execute on Ethereum uh ecosystem. When uh when a blockchain is EBN compatible, it use the same instruction set as Ethereum mainet including layer 1 and layer 2 and in other ecosystem like Solana uh they use SBM and fortose or three they use move BM and uh come back to EOF. UF is an enhancement of uh EVM. It includes more than 15 EIPs and the definition uh the specification is defined in EIP 76 and

92 and here is a this is an OSEN list. If you want to know more about uh EOF you could check this Owson list. All right. And what is the current status of EOF? First, we could take a look at the Ethereum upgrade timeline. We already have Pectra uh upgraded in May this year and Fusaka is scheduled in November uh this year also and after that we will have Glamand maybe in Q2 uh next year. EF it was originally scheduled in PCRA but because PCRA is too large so it is moved to Busaka but

during uh the discussion there is a heated debate against EF so uh it now it was removed during an interrupt testing meeting and this process is unusual because um in a typical Ethereum decision making uh process. This big decision usually uh are made during ACDE for execution layer meeting but this decision is made during an interrupt testing meeting and uh there are a lot of dramas going on uh during the UF discussion

and why is these dramas? Um this is a timeline for the discussion. At the very beginning initially oore dev uh acd believe flat eof is an huge enhancement for legacy EVM because it could resolve so many long-standing issue for legacy EVM. But after the community uh start to really look into the EOF design, they think that EVM should remain simple and EOF is too com complicated and some uh security members from CO 911 they emphasize that um if there if the

EF design is too complicated, it might introduce some potential show security issue in the design. So we should also uh so like also uh emphasize that EVN should stay simple and if you are interesting in his uh statement you can check this article. So in order to respond to community's concern, the epsilon team who proposed effort different types of ef uh type type A to type D EF and after weeks of discussion uh Okore Death again they almost reach a

consensus to ship the type DOF but before the final decision link Res and Aragon they are one of the uh Ethereum client team. They regret on their decision and they decided they do not want to uh upgrade to EOF. They want to completely remove EOF from the future Ethereum upgrade. So the final result is that EOF is removed from Fusaka upgrade and I think in the future upgrade uh like glam end uh ef will never be will never happened.

So we talk a lot about uh the dramas in the EOF decision and we could come back to see why we we could come back and first uh check why we need EF and uh what is the disadvantage for EF upgrade. All right. So the first problem in legacy EVM is that there's no versioning or structural layer layout for legacy EVM contract the by code there's no uh ELF header like uh uh like in Linux we have ELF header that specify the version and some related information

but in legacy EVM there's no similar uh feature and this make it hard to duplicate some legacy up close. For example, in the past a certain foundation and the community really want to deprecate the self-destruct operation because it is very dangerous but because there is no versioning so it makes it really hard to do this and the uh the other problem is that there's no code validation during deployment time in legacy EVM. So uh you could deploy and define or invalidate bico onto the ether mannet.

As a result uh the first improvement for ef is to introduce a container structure that provide a structural layout and the bon b version burgeoning header. This is the uh container for EF. In a container um there are two parts. The first part is the header and the second part is the body. And you can see in the header there's a metric value that tell you uh this B code is EF compatible. And this version the following bite is the versioning. So you can see this is the uh first version of EOF. And if in the future we want to duplicate some up

code, we could check this version to see whether this up code is activated in this specific version. And for the layout uh in EF there's different sections. For example, we have type section, code section and data section. And in the past all the code and data are uh are all within the is uh the same by code but now the code and data section are separated.

Okay, we will come back later for more detail in this structure. Let's go to the second problems in legacy EVM. The second problem is that EVN uses dynamic jumps over static jump and the relevant operation is uh jump and jump I for conditional jump and jump test. And um if we want to do better program analysis that static jump would be more helpful. And static jump would enable us to do uh better function boundary definition and label uh more clear function arguments and also improve the control flow

analysis. For example, reconstructing the control flow graph and tools like static analyzer or fing tool or foral verification tool would benefit from this uh static jumps feature in legacy EVM. If you want to define the function boundary, you need to detect two patterns. One pattern is the co- pattern and the other one is the return pattern. Here we could check the co- pattern. For example, um if you want to uh identify a co- pattern, it would be a push and a jump operation.

So this is a simple uh example. Uh this is a internal function code. But if you want to know the return address for this internal function code, you need to identify uh this push operation. And this is the return address and it will be difficult because uh there might be extra operation in between. So you might need to use some tricks or some algorithm to decode this value. All right, this is one problem for defining a function boundary. And the second problem is that if you want

to decode the input argument numbers or output argument numbers, you need to execute the uh by code in green. You need to uh calculate the state changes in this area and that would be the input argument numbers for the following uh function. And how do EOF solve these problems? For the first one, uh the co and return pattern they use different operation.

For co uh it is split into co f and jump f. Jump f is for non- returnturning function and for the return operation it is replaced by the return f up up code and a new uh a new component is introduced to EVM. It is called the return stick. And whenever oh uh in the past uh you need to do you need you need some algorithm to define the functions boundary. But now we have a structural format like this one and we have co-section and each co-section now represents one

function. So we no longer needs to decode the function boundary because each co-section now represents one function. And when you want to know the return address for each internal function code, uh you could directly ch check the return state item. When we want to do do an internal function code, there will be a co-f operation following by is uh following by the co- index you want to jumps to. And the uh and the return address will be pushed onto the return stack. And when you do the return, uh, the EVM will pop out an item on the return stack and then jump back to the

specific code section. So the function boundary problem is solved in EF by these three operation. And for the input argument numbers and output argument numbers they are solved by the type section in EOF. Uh we already introduced the co- section and there is another section called the type section and in type section each four bytes represents the input argument numbers and then and output argument numbers and max stake increase for uh the corresponding code section. So when you're doing when you are doing the

program analysis, you can directly read the information in type section and label this information in each co- section. It would be more easier for uh tooling developer. All right. And let's move on to the third problems in EVM. Uh if you are you are a smart contract developer, I think you must see this arrow message before. It is called stack to deep. And why do we need why do we have stack to deep issue? Uh because when you are passing arguments to a specific function, you will push this parameters onto a stick.

And when you want to access this value on the stack, you would use this operation. Uh you might use swap one to swap six or dup one to dup six. And it it is too limited because you can only access uh up to 16 labels deep in the stack. But when you when your item are uh not within this range, it will trigger this arrow. In EF, three new up codes are introduced. Uh the first two one the first two is uh the dupe end and swap end. They allows like extend the stack

assets limit to 256 levels deep. And the third one is exchange. It allows you to uh specify two position on the ST and directly swap the items on the ST. So uh how will it this improve the the EVM? You could check this stack ordering here. Uh we originally have the stack ordering AB D C and we want the final result to be A B C D. Uh in the past we need three swap operation.

So the first one is swap A and C. The second one swap C and D and the final one swap D and A and you got A B C D. But now you could specify you want to directly swap D and C. So the final result will be the one we want. So the same result but now we only need one operation. Uh that's how the list EIP improves the uh improves the legacy EVM.

Okay. And to sum to summarize, there are some uh long-standing issues in legacy EVM and EOF tries to uh resolve this issue by introducing uh structural layout and burgeoning headers and also uh they introduce static jumps uh to replace the dynamic jumps and um um for the stack to deep issue they introduce They extend the original up code to access more uh more uh items on the stack.

And to uh to achieve this feature, you have duplicates seven legacy up code and introduce more than 15 new up codes. You can check this table for the duplicated up code. uh all the code related operation are duplicated but there are replacement for that for them uh the code is replaced by ext uh this similar operation uh the similar replacement for this co-op operation and the jump operation are also duplicated like we already mentioned earlier they

are replaced by the co f jump f and return f for the uh static jump and create and create two are also duplicated. So if you're using some uh contract creation factory you could no longer use them. Okay. And this chart shows that uh in order to test efer foundation create a lot of deaf net to do so. But in each defnet they found new issues in current specification or the

current design. So so they need to uh introduce new EIP to resolve this issue. So uh so far we introduced so much features that is introduced in EOF and how they improves the EVM and it now uh EOF looks good because we no longer we will no longer have stack to deep we will have burgeoning header and we will be easy to deprecate up codes. If your apps improves the legacy EV so much so so much why are some people still opposed to this changes?

Uh so let's talk about the problems in EOF. The first problem is that there's no clear time schedule for EOF. Uh here are some tooling or development stick for Ethereum ecosystem. If you are a smart contract developer, I think you're very familiar with these tools. Uh we have compiler, we have solidity compiler and we have viper compiler that allows you to write smart contract language that looks like python. And we also have hoff compiler that allows you to write low-level assembly smart contract. And we have development

tooling like hard hat and hard foundry that allows you to write uh unit test framework and also doing the fuzzing test and there are other tools like web3.js ethereum.js that allows uh front end developer to integrate the smart contract interaction into their front end framework. And we have security tooling for example B code analysis tool or fuzzing tool or formal verification tool. And uh for smart contract development, we have very well-known uh open Zeppelin libraries

that allows you uh that allows you to uh reuse a lot of popular ERC like ERC20, ERC uh 721 for NFT. But just imagine if EOF is upgraded on Ethereum minute but list toolings are not upgraded accordingly. What would happen when you are writing smart contract you or uh you want to compile but you compile the your compilation generate the legacy EVM B code your B code cannot be deployed on is mainet. So everybody cannot deploy

the bico and the problem is that uh there is no I think there is no much effort put on coordinating this tooling development. So uh we don't know whether when Fusaka is complete this tooling will upgrade to the latest version to be ef compatible. And the second problem that here is there is no clear benchmarking for EOF. uh when developing EOF, people argue that EOF will save a lot of compilation time because there is no uh there is steady jump that could help uh this

tooling uh faster and we have exchange or similar up code that can reduce the operation count. But how much will they how much compilation time will it actually reduce and how much ble size will will ef uh reduce. There's no clear benchmarking. People just talk about uh it might it might reduce or it might uh have some benefit but there's no clear benchmarking.

Uh yeah there's no comparison be before and after EF and the third question is that in the future Ethereum will adjust it to ZKVM architecture or the lynchron architecture. So it will use uh CKVM to do the proving and will EOF be uh will the CKVN benefit from the EOF upgrade? There is no clear benchmark for that and I remember Viper even do do an analysis on this uh like compare the eof upgrade to the Viper generated legacy EVM by

code to see whether which is which has better performance for ZKVM and the result is that the Viper generated EVM by code is much faster or a a little bit faster than eof. And the final one is uh in each newly added uh ef up code, how does this gas code being defined? I believe that there's no clear benchmarking because I'm currently contributing to the benchmark for Ethereum and before I joined I I did not see any benchmark for EOF. So it would be very dangerous

because if a up code is mispriced you could generate a block full of the specific up code. If the block execute more than 4 seconds this might harm the entire blockchain consensus. So that might breaker's 100% uptight record. And the third problems in EF is that uh there's no there's limited impact analysis on backward compatibility. We deprecated create and create to up codes in UF but there are so many tooling or so many uh factory using this uh using the create to pattern but the new uh the

new up code uf create it has totally different patterns from create 2. So some existing smart contract patterns will break and for the ext uh it no longer accepts the gas as a parameter. But if you are a smart contract developer and you have integrated cross train before you know that there is a parameter called uh callback gas limit. If we could not pass the gas uh the gas as a parameter to the external code then the cross trend bridge they no longer can restrict the callback gas limiting they they will

need to find work around for that and there's uh more related instance for this and the other concern is that uh we introduce so many features in UF but Do we really need all this feature for Viper? Uh they don't have stack to deep issue because they resolve this issue by better memory management skill. And the second problem is that the specification keeps changing uh like I like I showed before in each defnet they will discover new issue and there are new challenges that needs to be solved.

So um there might be potential security issue in each uh in each uh improvement or in each new EIP. So that is very dangerous and there might be some vulnerabil vulnerability we cannot discover during testing or implementation phase. And the third one I think is the most important one because uh even if you upgrade to EOF you still need to maintain a legacy EVM. So for client developer there will be maintenance effort and for the beginners for inan ecosystem they need to learn uh the two version of virtual machine and

is it is a lot of effort and in the future we might introduce Rexifi or other instruction set then people need to learn three different virtual machine when you want to write some secure smart contract. So the final decision is to remove UF during lab meeting and the idea is that we don't want to be risky uh to such big changes that might break 100% uptime and the second one is that uh there's not much backward compatibility analysis. So uh this change might break some applications assumption

and the third one is that uh okra death ACD their main focus for uh foraka this year would be pure death to scale the blob scalability. So we should now make we should now let UF uh delay the progress for pure DAS and that this ends my presentation today. Thank you very much. I think this is very big topic. So it's really hard to uh introduce all the features and all the tradeoff uh within one talk. So if you're interesting in uh EOF or the

Ethereum virtual machine uh we could uh we could discuss after this talk and u I'm from defa talk and here. Do you have any questions about the um UF or other some cool things?

Okay. Okay. Break 100% up time. Execution layer. Consensus layer. Consensus layer. Benchmarking.

Time limit. Oh, >> consensus part. Uh ACD Okay.