Why EVM chains can never be as fast as Solana

by
Solana logo

Solana is fast. Why can't the EVM get to the same speed?

Non-native instructions

Native vs virtual instruction sets

When a computer runs programs, it does not look at code and know what to do. Instead, the code must be compiled into a series of instructions which are processed by the central processing unit, or CPU. If you've recently migrated to an M1 Mac, you'll quickly notice that there are several programs that do not run on your new computer. This is because the M1 Mac uses the ARM instruction set, whereas the Intel-based Macs use x86.

Instruction sets may be specialized to a specific purpose. For example, here's a graphics card's instruction set. It contains special operations for loading textures and vertices, since the hardware is specialized for 3D rendering.

However, there are instruction sets that do not correspond to instructions that the CPU hardware can directly interpret. These are generally referred to as virtual machines, because unlike physical machines, their instruction set architecture does not correspond directly to hardware.

Despite the indirection from machine code to virtual code, virtual machines are not always slow. The Java Runtime Environment, which processes Java Virtual Machine (or JVM) instructions, is able to operate at near native speeds due to a technique known as just-in-time compilation, or JIT. What the JRE does is it takes the opcodes of a JVM program and converts them to native machine instructions "just in time" for execution. When the program or function is executed, there is no longer overhead in processing individual instructions.

Runtimes not based around instruction set architectures do this as well, such as the V8 JavaScript runtime found in Google Chrome and Node.js.

Shortcomings of the EVM

The Ethereum virtual machine processes instructions for each Ethereum transaction. These instructions are not executed natively on a computer; instead, they are interpreted by block producers. On Ethereum, this is miners, and for other EVM chains, these are validators.

However, Ethereum cannot easily benefit from JIT compilation.

Each opcode is associated with a cost, meaning that

On the EVM, transactions are metered by a virtual machine.

Possible optimizations:

  • JIT compilation
  • A new instruction set. This however means that we are no longer using the EVM.

Serial processing

Blockchains are linear finite state machines; that is, they have a state, and for each transaction they process, the state is modified.

Solana is able to process transactions in parallel due to Sealevel: a runtime that knows what storage will be mutated and which ones will merely be read.

The EVM, on the other hand, is not as elegant: it d

Cross-shard communication

There is a hack to have infinite TPS: to shard.

Imagine if

In this post, I explore the different design decisions Solana has made to be the fasted blockchain in the world.

Thanks for reading! Have any questions, comments, or suggestions? Feel free to use the comment section below or email me at [email protected] and I'll do my best to respond.

Alternatively, you can view the source of the post here and send a pull request.