Storage

Dual Storage System

In the original Ethereum L1 the main storage is an Merkle Patricia Trie (MPT) stored in a KV database. It is simply and straightforward. It suffers from performance issues due to its design. Let along handling the workload from parallel execution.

A single state update modifies multiple trie nodes along the way, all requiring new writes to the LevelDB. The root hash must be recalculated, leading to many redundant disk writes. Fetching account data requires traversing multiple trie levels, each stored separately in the DB. This results in multiple random disk reads, slowing down state access.

While concurrent reads are OK on MPT by principle, updates much be sequential, which is another challenge because nodes must be added one-by-one, creating a huge bottleneck. This problem only get worse when dealing with workload associated with

Dual Storage System

Arcology's solution utilizes a dual storage system to optimize execution and state management. It consists of:

1. Flattened Key-Value Datastore: Used for state access during execution. This database is optimized for fast and efficient retrieval of state data. The flattened database is updated synchronously.

2. StateDB with a Parallelized Merkle Patricia Trie (MPT): Maintained separately to support root hash calculation and Ethereum RPC Enquiries. The StateDB is only updated asynchronously, decoupling from execution to enhance performance.

Once the conflict detector has verified that there are no conflicts (or has resolved any that were found), the state changes can be committed to the state database. Clear transitions represent the successful commitment of these changes to the state database, ensuring the blockchain state is updated consistently. Storage is the single biggest performance bottleneck in the original Ethereum design.