WIP
Persistence optimization
Cold Store
...
There is a limit to how much data can fit under one name in LMDB. The current implementation assumes that it will never be reached.
Random part
| Code Block |
|---|
RSpace.createWithReplay[
F,
Par,
BindPattern,
ListParWithRandom,
TaggedContinuation
] |
...
This creates an awkward situation for RSpace - it cannot share data as every piece is unique (the random part guarantees this).
Proposed solution
Cold Store is the "binary dump" of rholang. Whatever makes it through checkpointing will be persisted in this structure.
...
It should not affect other pieces of RSpace.
When will this become relevant?
As soon as it is observed that users use channels to persist more than a couple of values.
...
It was also observed during the initial vault demo when one channel was used as a logging channel.
Bind Patterns for continuations
This reorganization also relates to https://rchain.atlassian.net/projects/RCHAIN/issues/RCHAIN-1851
...
This fits pretty well with the notion of storing the contents of a channel as a list of pointers do bytes plus metadata (random part, bind pattern).
Hot Store Changes
During checkpoint, RSpace requests a list of changes from the HotStore.
...
Optimization of the creation of the changes list would be to track such values and never pass them to the Cold Store - this way fetching of the internal representation of the state to check if a key actually exists can be omitted.
Finalization
The process of finalization is not automatic and no mechanisms around requesting and discovering finalization were introduced.
Essentially this means that finalization is not part of the system. It is possible to trigger finalization manually and get the current value of it but:
- manual finalization means that if the chain is big enough requesting finalization will stall a node (vector of attack)
- finalized blocks will not be automatically discovered, therefore they will not speed up the system
- the threshold is node-specific, which means this can be abused (e.g. threshold of -1.0)
RholangCLI
It would be beneficial to allow the RholangCLI to set its "tip" to an existing block hash.
This can be achieved similarly to how ReportingCasper manipulates the state of RSpace and the HotStore.
The gain would be that a user could run rholang against some relevant state.