Why Ethereum is slow — and how we can fix it

By re-writing ECDSA and KECCAK with SIMD arithmetic, asmcrypto makes Ethereum run faster.

Ethereum Mainnet has a theoretical maximum Transactions per second (TPS) of 238 — assuming the simplest transactions, Externally Owned Accounts (EOA) where we can only transfer the ETH gas coin from one account to another. For more complex transactions, we must execute code on the Ethereum Virtual Machine (EVM) which is compute intensive. What is it that make Ethereum so slow and how can we fix it?

We’ll show that by thinking orthogonally about algorithms used in blockchains, we can make almost any blockchain run a lot faster with tens of thousands of complex transactions per second possible on modest hardware.

Part 1 — Networking

The Ethereum Mainnet is composed of many nodes which are mostly instances running on cloud servers. A subset of these nodes, those hosting validators, must exchange messages to reach consensus with one node proposing a block and at least 128 of these must take part in a “committee” to vote on the validity of the block. This involves exchanging many messages over poor internet connections with high latency and then broadcasting the result to all the other nodes on the network. This is a limiting factor.

Mainnet does not attempt to be fast, instead it prefers to be reliable. It has a slow block time of 12s to allow time for nodes to send their messages and has mechanisms to deal with unresponsive nodes through economic incentives. With a large number of nodes — over 10k according to Etherscan’s node tracker — getting agreement takes time.

Part 2 — ECDSA and KECCAK

On faster networks, we are still limited by network latency but another problem becomes apparent. Every transaction is signed using the Elliptic Curve Digital Signature Algorithm (ECDSA) and the public key (your Ethereum address) must be recovered from the signature of the KECCAK hash of the transaction bytes.

This ECDSA recovery takes around 30μs per thread on a modern desktop machine and probably a lot more on cloud hardware which is highly virtualised.

The state root of the block is calculated using many thousands of KECCAK hashes. Existing implementations of KECCAK are suboptimal, resulting in the state root taking quite a long time to execute.

We can use more threads to compute ECDSA recovery, but threads cost money.

The “gold standard” of ECDSA is the secp256k1 library which has many “tricks” for computing the modulo arithmetic and equation solutions of ECDSA and contains collective years of work to improve its performance, but as we will show, this can be beaten.

Likewise, tinykeccak is the most commonly used keccak library in the Rust space We will show that we can beat this too.

Part 3 — The EVM

Even if we fix the problem with the ECDSA recovery and state root calculation, we then need to look at the EVM. The EVM is a 256 bit stack-based interpreter that executes code in contracts. Existing implementations such as Revm, the Rust EVM, are interpreters. They typically take hundreds of machine instructions to execute every virtual instruction.

But interpreters are not the only way to execute code. We’ll show that we can get two to three orders of magnitude improvement in execution performance.

Fixing RPC and networking

The fastest standards-compliant Ethereum engine is currently Reth.

https://github.com/paradigmxyz/reth

Ethereum uses JSON RPC to interact with the chain. asmjson is a library intended to fix performance issues of existing JSON parsers such as serde_json.

[embed]GitHub - atomicincrement/asmjson Contribute to atomicincrement/asmjson development by creating an account on GitHub.github.com

This library uses SIMD instructions to classify 64 bytes of JSON text at a time, skipping characters without needing to check them. This gains an order of magnitude over more pedestrian JSON libraries.

The rbft Ethereum network is a fast qbft-style Ethereum implementation using Reth which achieves 14k+ TPS on a single node.

[embed]GitHub - raylsnetwork/rbft: Rayls Byzantine Fault Tolerant consensus built on Reth Rayls Byzantine Fault Tolerant consensus built on Reth - raylsnetwork/rbftgithub.com

Fixing KECCAK and ECDSA

asmcrypto is a library for improving KECCAK and ECDSA performance without using large numbers of threads. Like asmjson it uses AVX512BW SIMD instructions. This library provides two functions, one that computes eight register-parallel KECCAK hashes and the other the computes eight register-parallel ECDSA key recoveries.

[embed]GitHub - atomicincrement/asmcrypto Contribute to atomicincrement/asmcrypto development by creating an account on GitHub.github.com

These functions are still at an early stage but are faster than libsecp256k1 recovery by about 40% and tinykeccak by six times.

These functions need further work with the functions re-worked in assembly like asmjson which is 40% assembly code.

Fixing the EVM

There must be more “fast” EVMs out there than stars in the night sky. I have a nascent project to JIT compile Ethereum contracts. This is showing good promise at present, but needs some work to cover 100% of EVM test vectors. tests show about 250x performance improvement so far over interpreted EVM bytecode. Challenges include optimising out MSTORE/MLOAD pairs, computing dominance of the control flow graph and reducing most 256 bit operations to 64 bits. There are plans afoot to use RiscV as the EVM bytecode and this technique could be extended to this, although our work with EVM brings new life to the old bytecode.

I’ll release this project when it can execute the whole of Mainnet — perhaps in a few minutes if the database support is also fast.

Conclusions

It is possible to boost the performance of Ethereum by several orders of magnitude without changing the design. The JSON RPC, ECDSA recovery, execution and state root calculation all can be improved.

Reth is currently the winner in the Ethereum node stakes but once our current suite of libraries is considered stable, we can show considerable performance improvement by combining Reth with high performance algorithms.

If you want to contribute to the development of these libraries with time or money, get in touch.