Better EVM performance has been desired since before I first joined the Ethereum community in 2016. Martin Becze, Vitalik Buterin, Paweł Bylica, Martin Swende, the eWasm/Ipsilon team and others have been actively working on EVM perforance since before I arrived. The EVM is at the very core of the Ethereum execution layer and its performance affects the entirety of our technology stack and our community. With the advent of the Etherum Object Format suite -- especially its validated stack use and static control flow -- it is now possible to resume an important piece of my work towards creating a more performant EVM. I envision two phases of development, and am seeking funding for the first phase. Phase 1. I want to craft a compiler from EVM code to an executabe intermediate representation. Rather than code for a virtual stack machine, this will be code for a high-performance virtual register machine. Phase 2. I want to craft a compiler from this executable IR to actual machine code, with an initial target of 64-bit AMD/Intel CPUs. Why we need better EVM performance. For many smart contracts we don't need better performance -- the vast majority of gas is spent on SLOAD. But where it matters -- especially the execution of cryptographic codes -- it really matters.

I try here to sketch out how a simple compiler of EVM to machine code could work, and why validation is needed for the compiler to work. Stack and Register Machines Let's consider two very simple virtual machines -- a stack machine and a register machine. The stack machine has just the following instructions <OPERATOR> PUSH value POP JUMP address JUMPIF address

Abstract This proposal provides a complete, efficient, safe and static control-flow facility. It introduces two new opcodes to support calling and returning from subroutines: RJUMPSUB relative_offset -- relative jump to subroutine RETURNSUB -- return to PC after most recent RJUMPSUB. It depends on the two new opcodes proposed by EIP-4200 to support static jumps:

Abstract This EIP proposes to validate at initialization time that contracts will not underflow stack, jump to invalid locations, or execute invalid instructions. This further implies that subroutines are always called with and return the same number of argument and that looping will not change the stack height. Linear-time validation algorithms are required and one is provided. Motivation Safety For our purposes we define a safe EVM contract as one that cannot encounter an exceptional halting state. Unsafe code can attempt to overflow stack, underflow stack, execute invalid instructions, and jump to invalid locations. Unsafe contracts are exploits waiting to happen. From the standpoint of security it would be best if unsafe contracts were never placed on the blockchain. Validity

Abstract Introduce the ability to have several code sections in EOF-formatted EIP-3540 bytecode, each one representing a separate module. Each code section has a corresponding type section which specifies one or more procedural entry points to that module. Two new opcodes,CALLPROC and RETURNPROC, are introduced to call and return from these procedures. Motivation Currently in the EVM everything is a dynamic jump. Languages like Solidity generate most jumps in a static manner (i.e. the destination is pushed to the stack right before, PUSHn .. JUMP). Unfortunately however this cannot be used by most EVM interpreters, because of added requirement of validation/analysis. This also restricts them from making optimisations and potentially reducing the cost of jumps.

Abstract Five EVM instructions are introduced to define, call, and return from named EVM procedures and access their call frames in memory - ENTERPROC, LEAVEPROC, CALLPROC, RETURNPROC, and FRAMEADDRESS. Motivation Currently, Ethereum bytecode has no syntactic structure, and subroutines have no defined interfaces. We propose to add procedures -- delimited blocks of code that can be entered only by calling into them via defined interfaces. Also, the EVM currently has no automatic management of memory for procedures. So we also propose to automatically reserve call frames on an in-memory stack.