Page Comparison

...

https://docs.google.com/spreadsheets/d/1MHEWeha6zOhEV39fye-3trZlg50R13jRAjbjvgE2OSw/edit?usp=sharing

Comparing the RSpace Next to original RSpace we can observe: 

...

• it's easy to observe that the Datums are divided into two types
  • the interesting part "balances", they take up 196 + 197 + 198 bytes
  • the boring part of maps of revvaults 1167 + 1876
  • in this case (rev transfer) the map does not change, so storing it again is just a consequence of not having enough introspection into the data in RSpace 

    Jira Legacy
    server System JIRA serverId 50130123-f232-3df4-bccb-c16e7d83cd3e key RCHAIN-3528

  • the potential saving by having Datums share data should be of the size of the registry (2900 bytes in this case)
  • in theory this can be achieved by providing peek semantics
• Continuations consist of the purse contract being created (persisted)
  
  • it seems that all these pieces should not make it to the tuplespace at all since they will go out of scope post the purse being empty
  • it seems that there is a possibility to not persist the continuations over and over but simply point to them with data 

    Jira Legacy
    server System JIRA serverId 50130123-f232-3df4-bccb-c16e7d83cd3e key RCHAIN-3529

    • this would boil down to a one time cost of the contract in a schematic form ~ 2500 bytes + 1760
    • and a reference with indexes and values stored on each transfer with 7 unforgeable names
    • the gain here is not obvious and needs further inspection

Trie vs data in RSpace Next

In the above example it looks like the data and the trie are taking up roughly the same amount of data but that is misleading. There is an initial cost to making a new trie but its growth will not be linear to the amount of data put into the tuplespace (TODO this should be shown).

It looks like the next steps is to make the data take up as little space as possible.