Rholang name's storage optimization
wangjia184 opened this issue · comments
For each name in rholang, it could be stored with a number of continuations and data items.
The scala version's RNode
- stores all continuations of the same name in a single LMDB key, which is determined by
blake2("${name}-continuation")
; - stores all data items of the same name in a single LMDB key, which is determined by
blake2("${name}-data")
This is low efficient. E.g. suppose there are 1000 data items in certain name, the rholang runtime has to load all the data items to get one of them.
Is there a reason behind this design? Can we do better?
I'm not expert in RSpace so also interested to know more. But let me chime in with what I know (or I think I know). From high level view I guess these are a couple optimisations that can take place:
- Continuations can be split from patterns, so when you need to match continuation for datum, you just read/decode pattens (which are lightweight) and if you meet match - then you read actual continuation for that pair
pattern-continuation
and invoke it. - Datums and continuations are shuffled when searching for match, so you might read, decode and match them against counter datum|continuation one by one, if you have ability to read and decode them separately.
Thanks to @zsluedem, I see a reason for this.
Suppose there are two sibling blocks (X & Y) in the blockchain, and their parent block is P.
There is a name x
in block P.
Block X removes(consume) some datum from it.
Block Y adds(produce) some datum to it.
In fact, they conflict each other.
Anyway, if a new block is proposed by inheriting from either X or Y, the new block should see different result in name x
, either from P -> X or P -> Y. It implies that there are two name x
's from logic view. Storing all continuations / datums in a single key makes it easy to support blockchain environment.