Hi all,
I’m currently looking at DAML efficiency and storage calculations, and I got around to thinking about the inputs to a choice versus the outputs.
Say, for example, I have a choice that takes in a list, and I exercise that choice with a list containing 1k elements, but the choice logic does lookupByKey using those elements, finding 10 contracts to be archived and updated.
Will the list with 1k entries be stored as part of the transaction, dramatically increasing the transaction size on ledger? I thought the answer would be no, but I’m getting an odd transaction size for one of my workflows so I wanted to double check. And will all 1k lookups affect the transaction size, or just the 10 that produced a result?
Thanks in advance!
1 Like
The entirety of every choice argument is stored as part of the transaction containing that exercise. That is the only way to be able to “validate” the transaction, meaning that an external process can take the transaction data and the DAML code and reevaluate it to confirm that the choice was carried out correctly and honestly.
The result value of a choice is also stored as part of the transaction; hypothetically a ledger client could “simply” take the arguments and reevaluate the choice code, but that is not exactly convenient, and the result is what most use cases really want.
The details of execution are not stored with a transaction. Those lookups are evaluation steps; any client that cares exactly how a choice might be executed must instead take the choice arguments and reevaluate.
The usual way to refer to data indirectly in DAML is by contract key or contract ID. Either of these can be passed as a choice argument, whereupon the choice can lookup a contract already on the ledger by key or ID and retrieve it that way.
1 Like
Apologies, I misinterpreted part of your post. Each lookup will indeed be stored in the transaction as a NodeLookupByKey. (I had ordinary maps on the mind when reading your question, alas.)
1 Like