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