EVM object format (EFO) comprehensive upgrade analysis

author:Dragan rakita,Paradigm translation: good Ouba, Bitt chain vision world

EOF (EVM object format)

EOF (EVM Object Format) is a set of small EIPs designed to improve EVM.It introduces a new byte code format to prepare for the future of EVM.

EOF’s advantage

The value of EOF is difficult to explain because it is not a single thing, and because it has been delayed in the fork and many years of development and research, and the evolution of different versions, the explanation becomes more complicated.

The purpose of this article is to summarize these advantages and explain them in one sentence:

Advantages:

1. EOF allows the operating code GAS pricing change

• If the pricing of gas changes, the traditional bytecode may be different.

2. Remove gas observation

• This means removing the GAS operating code, and the gas limit in the call/delegatecall/staticCall.

3. Allow L2 to change gas according to its use case

• For example, the high cost of Hash operation in ZK L2.

• EIP-7667: Increase the gas cost of hash functions.

4. Reduce the size of the byte code and reduce the use of gas

• Early data indicates that the size of the code/initialization code and the amount of gas usage decreases:

• The deployment of UNISWAP-V3 decreased by 6.5%and the deployment code.

• Deploy uniSWAPV3Factory to use about 14%of less gas, call Runtest to use about 9%less gas.

• ENS DNSREGISTRAR deployment decreases by about 6%initialization code and about 1.5%of deployment code.

• ENS calls ProveandClaim: Use about 10%less gas.

5. Allow bytecode conversion and upgradeable

• Removal code observation means removing PC, Create/Create2, ExtCodehash, ExtCodesize, ExtCodecopy, CodeSize and Codecopy operation code.

• If the code is changed, the traditional contract will not be able to run.

• This will allow us to modify the EOF bytecode when introducing Verkle in the future.

6. EOF enable operating code immediately number

• Open the possibility of opening Swapn, Dupn and Exchange.

• This provides more freedom for Solidity to the stack size, and solves the depth of the stack in Solidity.

7. Remove expensive jump target analysis

• In Reth, the analysis results are preserved with bytecode, but other clients are different.Remove the jump target analysis before the contract execution improves the speed.

• With the removal of analysis, we can increase the maximum bytecode size in the future.

8. Static analysis becomes easier

• Sub -programs for compulsory and more structural control flows make the fuzzy test more effective, and can achieve static analysis of linear time.

• The separation of data and code is easier to reason.

9. EOF bytecode can be compiled into faster bytecode

• EOF bytecode can be compiled into a machine code.

10. Future proof EVM

• The version and structure of the byte code allow it to be scalability.This is especially useful for L2 and standardization.

• An example is EIP-7701: Local account abstraction with EOF has added a new head part.

11. Address space expansion

• The new EXT*Call operating code is filled with zero by requiring the address field to prepare for future address expansion.When Ethereum decides to expand the address space, EOF has been prepared for these changes.

Integrated with current EVM

For developers, an important problem is the effort, test costs, and the cost of maintaining these operating codes required for changes.

The new operation code will not conflict with the traditional operating code, and EOF’s verification will not touch the abandoned operating code.

EOF’s encoding and decoding can be blurred.Verification is a new thing. There are about 500 lines of code in REVM, but there are many edge conditions that need to be covered, and the concentrated energy needs to be correct in each implementation.

Create a transaction for the EOF bytecode, similar to EOFCREATE but requires verification before execution.

Most operating codes are very simple:

• ExtCall (0xF8), ExtDelegateCall (0xF9), ExtStaticCall (0xfb)

• It has the same blueprint as the abandoned call, but removes Gas_limit and memory output fields.

• Before the introduction of ReturnAtaload (in a very early fork), the memory output of the call operating code must be set before executing the call operating code.This does not allow dynamic output.

• EOFCREATE and ReturnContract

• It is the new content of EOF and requires special treatment.

• Exchange (0xe8), Swapn (0xe7), Dupn (0xe6), DataCopy (0xd3), DataSize (0xd2), DataLoadn (0xd1), DataLoad (0xd0), RJUMPI (0xe1), RJUMP) V (0xe2),Returndataload

• The logic is simple, most of which only need to be implemented by 10-20 lines.There are not many edges that need to be covered.

• Callf (0xe3), RETF (0xe4), and JUMPF (0xe5)

• The subroutine stack and the stack verification are required, and the complexity requires about 20-30 lines.

• It needs a developer for about 2-3 months.Test work has begun.At present, there are about 2,000 handwritten verification tests, and the status testing is also underway.

The change is concentrated in the EVM, so the integration of the rest of the client depends on the client’s architecture and the location of the byte code.

ExtCodeSize and ExtCodehash need to know whether the account is EOF and return the pre -defined value (0xef00 size and hash), which may slightly change the client’s integration method.One idea is to save the IS_EOF logo in a normal account form to jump the byte code to load the byte code when calling any ExtCode type operating code.

Effect on L2

The biggest problem is why L2 does not implement these changes?Should we stop EVM improvements on Ethereum L1?

The reality is that L2 is not ready, not only that, they have no platform to help integrate these innovations.The byte code version control helps build a platform that can be used by L2. The removal of the code can help relieve upgraded problems. Gas changes help ZK L2 to eliminate DDOS vectors of gas bombs (for example, hash in ZKValue is very expensive).

More importantly, EOF is not only a format, it also requires the support of language (solidity/vyper/huff), and it requires the support of the tool chain to use.It requires an ecosystem to use it. This format provides more stability for L2 to innovate on it.

Disadvantages: Traditional bytecodes still exist

This is a common problem.Traditional bytecies will exist forever. If we do not provide alternatives, we will be in trouble.With the bytecode of an alternative format, in the future, we can transition and remove the traditional byte code when the state expires.

Summarize

EOF is not the next dazzling thing. It is the maintenance EIP to repair the initial EVM version. There is no other way to solve these problems except destroying it.It is necessary for the further development and future proof of EVM.