Speeding up Execution (geth)

[trianglesphere]

This is part response to George's ideas on how to speed up geth and part my ideas that I've had for a while.

Blazing fast sync notes

• Putting the database in ram (even through the cache size) makes a lot of sense.
• Multiple NVME SSDs enable high random IOPs with low latency (which helps with loading nodes in the MPT)
• Leveldb - we don't even use leveldb (just a golang re-implementation).
• I'm personally still not sure why the staged sync works as it does - I think the theory is that it has more sequential IO patterns, but I'm not sure why/how that's achieved.

Improving the DB

• @norswap what does you mean by a pure has -> preimage interface to the database
• Caching layer - a lot of DBs don't have much caching themselves, but instead rely on the operating system to handle recently accessed pages.

There are two main issues with the DB

1. Generating / storing / using MPT nodes
2. State lookups (like SLOAD, BALANCE, etc)

Parallelization

I have a bunch of ideas here, but there are a couple optimistic and non-optimisitc (larger changes) ways to enable parallelism. Most (all) of the ideas that I have around parallelism essentially involve keeping individual transactions sequential, but running multiple non-conflicting transactions at once (doesn't play nice with MEV / DEXs / contracts that reuse state).

Rough Gas Processing Speeds

System	Million Gas/Sec
Geth (sdd)	100-150
Erigon (16 GB Ram)	~234
Erigon (32 GB Ram)	~292
Erigon (64 GB Ram)	~390
Ramdisk	800-1000

Notes: Erigon was estimated over syncing the entire chain.