Page Comparison

...

• 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

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

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

  • 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
    • a proposal of making this go away is to introduce a one-time-use purse that will be consumed when money is draineddrained 

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

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

  • 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

...