mLSM: Making Authenticated Storage Faster in Ethereum Authors: Pandian Raju, Soujanya Ponnapalli, Evan Kaminsky, Gilad Oved, and Zachary Keener, University of Texas at Austin; Vijay Chidambaram, University of Texas at Austin and VMware Research; Ittai Abraham, VMware Research

Abstract: Ethereum provides authenticated storage: each read returns a value and a proof that allows the client to verify the value returned is correct. We experimentally show that such authentication leads to high read and write amplification (64x in the worst case). We present a novel data structure, Merkelized LSM (mLSM), that significantly reduces the read and write amplification while still allowing client verification of reads. mLSM significantly increases the performance of the storage subsystem in Ethereum, thereby increasing the performance of a wide range of Ethereum applications.


The paper dates to 2018, to what extent has ethereum absorbed the findings?

1 Answer 1


Similar techniques are used in Firewood by Avalanche.

Traditionally, projects that employ Merkle Tries have relied on existing key-value embedded databases, like LevelDB or RocksDB, to efficiently manage this workload even though they are unaware and unoptimized for how the Trie-structured data is written/read during block verification/state syncing.

Over the coming months, we will release a series of reproducible benchmarks comparing the performance of Firewood to other blockchain databases, including our own MerkleDB. Firewood and MerkleDB will share a common Merkle Trie format that will allow them to be used interchangeably with a re-genesis event. The final goal of all this work is the eventual integration of Firewood into all Virtual Machines (X/P/C/HyperSDK) that Ava Labs maintains to unlock differentiated scalability across the Avalanche Network.

As this is a node implementation detail (there are more than a handful of Ethereum node applications, and then various node applications for other EVM chains, and each use different databases from SQL to LevelDB), the detail what database the node software uses is irrelevant for Ethereum as a whole.

  • sure, but what about EF ? Commented May 29 at 15:49
  • Ethereum nodes are mostly not developed by the Ethereum Foundation. Commented May 30 at 8:54
  • So, EF did not influence the data storage structure used by Ethereum. EF has nothing to do with the Level DB is what you are trying to say. Commented May 30 at 18:20
  • There is no "data structures used by Ethereum". There are data structures used by several nodes and those nodes are developed by different developers and those developers are not Ethereum Foundation. There is not a single boss designer who wakes up every morning and things "these will be the Ethereum data structure." Commented Jun 3 at 7:26
  • Yep, I read the paper finally. It is very confusing they contextualize Ethereum as a single actor. Commented Jun 7 at 8:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.