Why the Key Assertion & Fetch are defined as actions on the ledger

Questions
1

G-d willing

Hello,
Why does the ledger need to capture actions (Fetch & Key Assertion) that don’t make any changes to it?
Is it for recording all operations that require communication with the ledger?
In addition, according to the explanation here, is key assertion being recorded only when a party tries to exercise a choice on a consumed contract? Or are there other operations that “triggers” this action?

Thanks,

2

In summary, to preserve subtransaction privacy while informing signatories of what they’re promised to be informed about.

When a fetch happens, as with nonconsuming choices, that needs to be communicated to the signatories of the fetched contract. You might think this is implied by the body of the choice, but the signatories are not necessarily aware of the fetching choice being exercised according to the privacy model.

Consider this dummy example:

template SigOb with
    sig: Party
    ob: Party
    n: Int
  where
    signatory sig
    observer ob

template Downstream with
    me: Party
    sigob: ContractId SigOb
  where
    signatory me
    nonconsuming choice CheckOb: Int
      controller me
      do
        SigOb {ob, n} <- fetch sigob
        assert $ ob == me
        pure n

testit: Script ()
testit = script do
  alice <- allocateParty "Alice"
  bob <- allocateParty "Bob"
  sigob <- submit alice $ createCmd SigOb with sig = alice; ob = bob; n = 42
  ds <- submit bob $ createCmd Downstream with me = bob; sigob
  n <- submit bob $ exerciseCmd ds CheckOb
  pure ()

The last submit yields the following transaction (use “Show transaction view” in Daml Studio to follow along):

  TX 2 1970-01-01T00:00:00Z (User:77:8)
  #2:0
  │   disclosed to (since): 'Bob' (2)
  └─> 'Bob' exercises CheckOb on #1:0 (User:Downstream)
      children:
      #2:1
      │   disclosed to (since): 'Bob' (2), 'Alice' (2)
      └─> 'Bob' fetches #0:0 (User:SigOb)

(corrected as of Daml SDK 2.8.5)

The fetch (node #2:1) needs to be disclosed to Alice, but Alice has no permission to see the exercise (node #2:0) that precipitated that fetch. So there must be a separate transaction node that can be included in Alice’s projection.

2 Likes
3

G-d willing

Hi @Stephen, first of all, thank you for your detailed answer.
Following your example, how is (node #2:1) visible to Alice? I mean, how can Alice know that someone fetched her SigOb contract?

4

Alice can use appropriate identification with the participant API to see all transactions that have been disclosed to them. The rules of Daml say any fetches, like any nonconsuming choices, are disclosed to all signatories, and Alice is a signatory.

Further details might deserve a separate thread, though, e.g. “why”.