Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rholang name's storage optimization #1

Open
wangjia184 opened this issue Mar 25, 2021 · 2 comments
Open

Rholang name's storage optimization #1

wangjia184 opened this issue Mar 25, 2021 · 2 comments

Comments

@wangjia184
Copy link
Owner

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")

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?

@nzpr
Copy link

nzpr commented Mar 26, 2021

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.

@wangjia184
Copy link
Owner Author

wangjia184 commented Mar 28, 2021

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.

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

No branches or pull requests

2 participants