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 ...


7

There are two separate concepts: the blockchain and the database. The blockchain is an immutable log of transactions, e.g. transfer 5.0000 EOS from usera to userb. The database holds mutable state information, e.g. userb has 10.0000 EOS. Contracts modify the database in response to actions. Even though the database is mutable, you can recreate it at any ...


5

If there is only one instance to be created, I agree you should use a singleton for your case instead of a table directly, as this is what singletons are used for. For API, you can check the eosio/singleton.hpp file, and here's a quick example using a singleton: #include<eosio/eosio.hpp> #include<eosio/singleton.hpp> class singleton_example : ...


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 ...


1

When storing and accessing sensitive user-data, using the Multi-Index DB API, what considerations should be made to respect the user's privacy? This is not doable as by the definition all data in a public blockchain is public. If possible store data on the server side and/or only hashes of data in the blockchain.


1

To run logic against data in a Smart Contract it's going to have to be in a visible state so achieving Privacy would fail. I'd further question why sensitive or private data would go to chain in the first place as even if it is encrypted via asymmetric or symmetric means the key can always be leaked or cracked when we achieve processing power fast enough, ...


1

Yes, as you're saying, it should simply be a single table with a single row that contains your data as a struct with the 3 fields. You would need to define your struct and table as something like this: //@abi table state i64 struct state { string field1; string field2; uint64_t field3; // Set the primary key to a constant value to store ...


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. probably. 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 ...


Only top voted, non community-wiki answers of a minimum length are eligible