Structural sharing on-ledger

My question is about structural sharing in contracts.

If I have a contract, with say a member ls = [ 1, 2 ... 100], and then I update this contract like so:

do c' <- create MyContract with l = 0 :: c.ls
     _ < - archive c

Will this use structural sharing to deduplicate my hundred pieces of data on-ledger, or will it store a second list of 101 values, on-ledger (i.e. 201 values in total)?

Or does this depend on the ledger implementation?

Finally, would this affect the ‘right-to-forget’ in the above case? I’ve introduced a dependency from c' to the original c.

1 Like

There is no structural sharing once the data is stored on the ledger in general. You could imagine some ledger implementation that tries to compress things and thereby introduced some form of sharing but as far as I know, the existing DAML ledgers do not try to do this.

You can get sharing in the interpreter so during the execution of an Update. But since those are short lived that doesn’t result in a permanent reference that would prevent ledger pruning.

1 Like

So in short we can expect ledgers to store all 201 value and for the existence of all of them to depend on whether or not the node tries to any pruning? And this would never be up to DAML but the ledger itself?

DAML makes no guarantees other than that the Ledger API behaves in accordance with the Ledger Model. In other words, what’s stored and transmitted is entirely an implementation detail.

Pruning is not the only reason this sort of optimisation is tricky in practice. Nodes don’t know what other nodes already know and nodes usually want to store raw transactions in order to be able to reconstruct from the golden source of truth.

So when Node1 transmits the transaction containing

do c' <- create MyContract with l = 0 :: c.ls
     _ < - archive c

to Node2, it has to assume that Node2 didn’t already know c and attaches it using divulgence. Thus the transaction itself contains the 101 values. If Node2 already knew c, but also wants to store the raw transaction it got from Node1, it has no choice but to store 201 values in total.