Open wangjia184 opened 3 years ago
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:
1) 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.
2) 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.
For each name in rholang, it could be stored with a number of continuations and data items.
The scala version's RNode
blake2("${name}-continuation")
;blake2("${name}-data")
https://github.com/rchain/rchain/blob/6dfa65e24599cff8561fa604e1a6c4f6d75bc9fc/rspace/src/main/scala/coop/rchain/rspace/history/HistoryRepositoryImpl.scala#L39-L41
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?