1. Compared to ethereum what DataStructure is used under the hood to store the world state at any point in time? Is it a flat-db or like in ethereum the world state every account + its storage + balance + contract account storage is rlp encoded and stored in a Merkle Patricia Trie so how does Solana handle this storage ? what is the underlying mechanism being used, what encoding/decoding algorithms are used if any ?
  2. Also is there any potential under the hood deep-dives/resources am not aware of, fire away.

1 Answer 1


From the solana docs:

If the program needs to store state between transactions, it does so using accounts. Accounts are similar to files in operating systems such as Linux in that they may hold arbitrary data that persists beyond the lifetime of a program. Also like a file, an account includes metadata that tells the runtime who is allowed to access the data and how.

Unlike a file, the account includes metadata for the lifetime of the file. That lifetime is expressed by a number of fractional native tokens called lamports. Accounts are held in validator memory and pay "rent" to stay there. Each validator periodically scans all accounts and collects rent. Any account that drops to zero lamports is purged. Accounts can also be marked rent-exempt if they contain a sufficient number of lamports.

In the same way that a Linux user uses a path to look up a file, a Solana client uses an address to look up an account. The address is a 256-bit public key.

I think this makes it pretty clear what data structure Solana uses to store the current state, basically one huge mapping of 256 bit keys to data where the metadata specifies wether it's a program account, data account, etc.

As for how all this is actually physically stored: Standard LevelDB wouldn't be able to keep up with Solana's huge throughput, so Solana invented a new database system called Cloudbreak which is optimized for parallel read and writes and higher performance.

The main ways it gets this boost done is by

  • Using memory-mapped files (as opposed to many traditional databases that just store the entire database on disc) to allow the OS to move some of the database data into RAM where appropriate.
  • Organizing data in the database in such a way as to produce sequential accesses of data at a more likely rate which in turn makes prefetching easier for the OS and CPU (and plays together with the previous point).
  • Having its own garbage collector to clear unneeded memory as soon as possible.

Explaining how exactly it does these would be beyond the scope of this question IMO, however Anatoly's blog post explains it very well in case you're interested in the exact details.

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.