Storage in Libra Core

The storage is used to persist agreed upon blocks of transaction and their execution results. All the data in the Libra Blockchain is stored in a single-versioned database. The blockchain is represented as an ever-growing Merkle tree of transactions. A “leaf” is appended to the tree, for each transaction executed on the blockchain. Please see our documentation and share your feedback.


How about the rich media? Thinking about running a VOICE like decentralized social media on Libra, do I need to host the pictures / videos by myself or on other storage network (e.g. IPFS)?

1 Like

Is there support for engraving (e.g. ability to add a “note/description” to a transaction?) or can something like this be achieved using move/smart contracts?

Couldn’t find anything in this direction by flicking through the developer documentation so far but might just have missed it.

Yes. We define a notion of events used to engrave side effects produced by executing a transaction. You will be able to create your own events through smart contracts.

Please read Libra blockchain deep dive section 2.2 about events.


Thanks for the pointer @lightmark. appreciated!

Libra is built primarily for payments or financially related transactions. We don’t plan to build a distributed computing service or storage system on blockchain. But as a developer, you are free to build on top of Libra by leveraging any existing solutions.

1 Like

If the storage use the Merkle tree structural, how can libra find a leaf quickly with a specified account address? Does libra likes Ethereum which use Patricia Tree to speed up query?

A short answer is yes.
Logically it is a 256-level merkle tree. But we implement it as a PMT and optimize it to leverage the sparsity. So our proof scheme is kinda complicated.
Welcome to our GitHub repo to read the source code. I already put lot of comments under libra/storage/sparse_merkle .


Can you elaborate more on this, you mean like ethereum EVM?

What’s the best DB for Libra Core?

I haven’t read the code about storage yet. But if I were to design the storage, I would choose a content-addressable type of DB just like what git does. :stuck_out_tongue_closed_eyes::stuck_out_tongue_closed_eyes::stuck_out_tongue_closed_eyes:
(Besides, git is actually a blockchain whose consensus come from code-review.)

1 Like

We use RocksDB and design our own schemas on top of it.