14

We do have the Persistence API to store data for a smart contract in the EOSIO database. I was wondering where this database is located. I understood that it is patterned after Boost Multi-Index.

1) Is it in the filesystem of the block producers or in their RAM? Or can we choose?

2) Are all block producers maintaining this database to evaluate transactions?

3) What happens to this database if the node running it crashes or shuts down? Does the replacing node replay all the db-transactions deterministicly from the chain-transactions?

Improve this question
2
  • 2
    This question mixes things that could be separate questions. "I understood that it is an Boost Multi-Index": it's a new container that's somewhat modeled after Boost's, but with some significant differences. A good separate question might be: "How is eosiolib's multi_index different than Boost's?"
    – Todd Fleming
    Commented May 8, 2018 at 16:46
  • Might be, but main focus of my question was on the storage and procedure, not the differences. I will edit it to clearify.
    – tmm ♦
    Commented May 8, 2018 at 16:54

3 Answers 3

Reset to default
10

EOSIO keeps the state in RAM. All the data for the contracts and transactions are held in RAM.

All block producers (BP) process the transactions and keep an updated state of the database in RAM.

This is why the RAM is one of the most valuable resources in the EOSIO blockchain and has it's own mechanism for reserving and pricing it.

You should seek ways to free old data that is not needed to optimize usage of RAM.

The white paper differentiates between:

  • log storage which will be in disk
  • state storage which will be in RAM

I think this is very different from traditional databases or even NOSQL systems where keeping data in disk is considered the safe way to protect from volatility.

One notable different solution is REDIS which is an in memory DB which gets an "unfair" performance advantage by using RAM instead of disk. REDIS solves the volatility risk of losing all data with a power surge by using a master and slave where once data arrives to the listening slave, it is written to disk. If you want a fast and reliable REDIS server, you can wait for the signal from the slave that the data was saved to disk.

EOSIO has a conceptually similar solution. The BPs are listening on transaction messages and you have redundancy. If one of them fails, the rest will pick up from the correct point and process the messages.

Improve this answer
2

EOS.IO stores indexed state in a custom-written database engine called Chainbase.

This database is optimised for high performance when the entire database fits into memory, and it's expected that block producers will have enough physical memory to accomodate this (as they risk missing their block production windows otherwise).

However, it will degrade gracefully when the dataset is too large to fit into physical memory, and it is likely that a smaller amount of physical memory will suffice for most users, so long as they have fast persistent storage, such as SSD.

Improve this answer
1
  • Apparently Chainbase comes from Steem but has not been updated in 5 months, so may not be a part of the active EOS development. github.com/EOSIO/chainbase
    – Walter K
    Commented Nov 7, 2018 at 9:07
1

  1. multi-index table data is constructed by actions (like insert row, update row value) and BP has all action logs. Also, all current state is stored in RAM.

  2. probably.

  3. Yes, by replaying action logs. White paper mentions "A blockchain maintains a log of all Actions and this log is ultimately stored and downloaded by all full nodes. With the log of Actions, it is possible to reconstruct the state of all applications...."

Improve this answer

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.