Skip to content
This repository was archived by the owner on Jun 17, 2022. It is now read-only.

Dealing with big states #104

Open
mhemrg opened this issue Apr 7, 2018 · 4 comments
Open

Dealing with big states #104

mhemrg opened this issue Apr 7, 2018 · 4 comments

Comments

@mhemrg
Copy link

mhemrg commented Apr 7, 2018

Lotion stores the state in memory. So how can we deal with big states?

@arsen3d
Copy link

arsen3d commented May 10, 2018

Example:

+initialState [];
+app.use(function (state, tx) {
+   state.push(tx);
+})

@mappum
Copy link
Contributor

mappum commented May 10, 2018

In my opinion, it's OK to keep the state in memory since it doesn't have to be huge. For example, after 9 years of the Bitcoin blockchain's existence, the UTXO set is still less than 2 GB which is very doable for even low-end hardware. I prefer being smart about not dumping unnecessary data into the state.

However, long-term I'm sure there will be use-cases for large states, so eventually mutating/accessing the state object could be async, and it could all just come from disk. Of course, performance for disk-state will be much slower than if it was kept in memory.

@arsen3d
Copy link

arsen3d commented May 10, 2018

@mappum, Is there an example of how to keep the state lean, while persisting and validating the data as it comes in to

app.use(function (state, tx) {

Is it a good idea to store the data via rest API on IPFS for example or are the tx already stored in tendermint anyway.

@mappum
Copy link
Contributor

mappum commented May 10, 2018

The txs will already be stored in Tendermint so you don't have to worry about that, but if for instance your blockchain was dealing with large data files then it would make sense to only store the hash/identifier of the data in your state, and store the data itself on IPFS.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants