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)?
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
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.
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
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.
(Besides, git is actually a blockchain whose consensus come from code-review.)
We use RocksDB and design our own schemas on top of it.