<\/p>\n
The Ethereum Virtual machine stands out as somewhat unique compared to the majority of other Virtual Machines available. In my\u00a0earlier article<\/a>\u00a0I elaborated on its usage and highlighted several of its features.<\/p>\n <\/p>\n The Ethereum Virtual Machine (EVM) is a basic yet potent, Turing complete 256-bit Virtual Machine that permits anyone to run arbitrary\u00a0EVM Byte Code<\/a>.<\/p><\/blockquote>\n The go-ethereum initiative includes two versions of the EVM. A straightforward and uncomplicated\u00a0byte-code VM<\/a>\u00a0and a more advanced\u00a0JIT-VM<\/a>. In this article, I will clarify some distinctions between these two versions while discussing certain attributes of the JIT EVM and the reasons it can be significantly faster than the byte-code EVM. The internal workings of the EVM are rather straightforward; it consists of a singular run loop that endeavors to carry out the instruction located at the current\u00a0Program Counter (PC<\/em>\u00a0for short). Within this loop, the\u00a0Gas<\/em>\u00a0is computed for each instruction, memory is augmented if needed, and the instruction is executed if the preliminary conditions are met. This process continues until the VM either concludes successfully or returns an error by triggering an exception (e.g.\u00a0out-of-gas<\/em>). <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n Upon the completion of the execution cycle, the program-counter is incremented to proceed to the subsequent instruction and it continues this process until it has concluded. The EVM possesses an additional method to\u00a0alter<\/em>\u00a0the program-counter via what is referred to as\u00a0jump<\/em>-instructions (JUMP<\/em>\u00a0&\u00a0JUMPI).\u00a0<\/em>Rather than allowing the program-counter to increment (pc++), the EVM has the capability to leap to arbitrary locations within the contract code. There are two jump instructions known to the EVM: a standard jump that is interpreted as \u201cjump to position X<\/em>\u201d and a conditional jump which is interpreted as \u201cjump to position X if condition Y is satisfied<\/em>\u201d. Whenever such a jump takes place, it must consistently land on a\u00a0jump-destination<\/em>. If the execution lands on an instruction that is not a jump destination, the program fails\u200a\u2014\u200ain essence, for a jump to be valid, it must invariably be succeeded by a jump-destination instruction if the conditionyielded true.<\/p>\n <\/p>\n Before executing any Ethereum application, the EVM traverses through the code to identify all potential jump-targets, subsequently cataloging them in a map that can be referenced by the program-counter for retrieval. Each time the EVM comes across a jump-instruction, the validity of the jump is verified.<\/p>\n <\/p>\n As you may notice, the executing code is fairly straightforward and effortlessly interpreted by the byte-code VM, leading us to the conclusion that despite its simplicity, it is fundamentally quite primitive.<\/p>\n <\/p>\n The JIT-EVM adopts a distinct method for executing EVM byte-code and is, by nature,\u00a0initially<\/em>\u00a0less efficient than the byte-code VM. Before the VM can execute any code, it must first\u00a0transform<\/em>\u00a0the byte-code into segments that the JIT VM can comprehend. The setup and execution process is carried out in three phases:<\/p>\n <\/p>\n <\/p>\n Initially, I attempted to check if the JIT program had completed compilation and to transfer the execution to the JIT\u200a\u2014\u200athis all transpired during runtime in the same loop using Go\u2019s\u00a0atomic<\/em>\u00a0package\u200a\u2014\u200ahowever, it was unfortunately slower than allowing the byte-code VM to execute and subsequently utilizing the JIT program for every sequential invocation post-program compilation completion.<\/p>\n <\/p>\n By segmenting the byte-code into logical components, the JIT gains the capability to examine the code more accurately and to optimize whenever necessary.<\/p>\n <\/p>\n For instance, an exceedingly simple optimization I implemented was consolidating several\u00a0push<\/em>\u00a0operations into a single command. Consider the\u00a0CALL\u00a0<\/em>instruction; it necessitates 7 push commands\u200a\u2014\u200ai.e. gas, address, value, input-offset, input-size, return-offset, and return-size\u200a\u2014\u200abefore execution, and instead of iterating through these 7 commands one by one, I\u2019ve streamlined the process by gathering the 7 commands and appending the 7 values into a single slice. Now, whenever the\u00a0beginning<\/em>\u00a0of the 7 push commands is executed, it performs the optimized instruction by instantly appending the static slice to the VM stack. Of course, this is only applicable for static values (i.e.\u00a0push 0x10),<\/em> which frequently occur in the code.<\/p>\n <\/p>\n Additionally, I enhanced the\u00a0static jump\u00a0<\/em>commands. Static jumps are those that consistently redirect to the same location (i.e.\u00a0push 0x1, jump<\/em>) and remain unchanged under any conditions. By identifying which jumps are static, we can pre-validate whether a jump is legitimate and falls within the contract’s limits, and if so, we generate new instructions that replace both the\u00a0push<\/em>\u00a0and\u00a0jump<\/em>instructions, marking it as\u00a0valid<\/em>. This alleviates the VM from executing two instructions and eliminates the need to confirm the legitimacy of the jump, thus avoiding the costly hash-map lookup for valid jump locations.<\/p>\n <\/p>\n <\/p>\n Comprehensive stack and memory evaluation would also integrate seamlessly into this architecture, allowing substantial blocks of code to consolidate into single commands. Furthermore, I aspire to incorporate\u00a0symbolic-execution<\/a>\u00a0and transform the JIT into a fully functional JIT-VM. I believe this would be a logical progression once the programs grow large enough to leverage these optimizations.<\/p>\n <\/p>\n <\/p>\n
\n
\n<\/p>\nByte Code Virtual Machine of Go-ethereum<\/h3>\n
\n<\/p>\nfor<\/span> <\/span>op<\/span> <\/span>=<\/span> contract<\/span>[<\/span>pc<\/span>]<\/span> <\/span>{<\/span><\/code><\/pre>\n <\/span>if<\/span> <\/span>!<\/span>sufficientGas<\/span>(<\/span>op<\/span>)<\/span> <\/span>{<\/span><\/code><\/pre>\n <\/span>return<\/span> error<\/span>(<\/span>\"not enough gas for op:\"<\/span>, or<\/span>)<\/span><\/code><\/pre>\n <\/span>}<\/span>\n<\/span><\/code><\/pre>\n switch <\/span>op<\/span> <\/span>{<\/span><\/code><\/pre>\n <\/span>case<\/span> <\/span>..<\/span>.:<\/span><\/code><\/pre>\n \/* execute *\/<\/span><\/code><\/pre>\n <\/span>case<\/span> RETURN:<\/span><\/code><\/pre>\n <\/span>return<\/span> memory<\/span>[<\/span>stack<\/span>[<\/span>-1<\/span>]<\/span>, stack<\/span>[<\/span>-2<\/span>]<\/span>]<\/span><\/code><\/pre>\n <\/span>}<\/span><\/code><\/pre>\n pc++<\/span><\/code><\/pre>\n}<\/span>\n<\/span><\/code><\/pre>\n<\/div>\n
\n<\/p>\nIntroducing JIT VM<\/h3>\n
\n<\/p>\n\n
Subsequent Steps<\/h4>\n
Final Thoughts<\/h3>\n