Semantics of witness_parties in the gRPC API

Questions
1

A few questions about the witness_parties for a CreatedEvent or an ExercisedEvent in the gRPC API. The value of this field is said to be determined by TransactionFilter.

  1. what if I get the transaction through a GetTransactionById call, that has no such filter? I assume that these are then the requesting_parties?
  2. is there any way to get the information about the witnesses not hosted on the local node? Can I supply non-local parties in the transaction filter (putting authentication concerns aside)?
  3. the description of the field for CreatedEvent says its value are the informees of the event in one case, and contract stakeholders in another. But the Projections section of the ledger model defines informees of Create actions exactly as the stakeholders, so I don’t see what the difference is
2

The whole idea of having the witness parties in the response is simply to allow the client of a multi-party request to distinguish to which party an event is visible among those included in the request. The answer to 1 is that witness_parties is going to be the intersection between the requesting_parties and the witnesses for a given event.

The answer to 2 is more complicated, as it largely depends on the ledger implementation. There are ledgers that may want to guarantee that a party is not automatically visible to any participant. You can supply a non-local participant in the transaction filter, but on privacy-preserving ledger implementation you will only be able to see those events that involve said party on that specific participant, not the whole set of events regarding that party on other participants).

The answer to 3 is that unfortunately the Ledger API does not use the same vocabulary as the ledger model document. The proper term to be used instead of informees is probably witnesses (but I could be wrong).

1 Like
3

Thanks! Do you mind if I then submit a PR to change the “informee” in the comments, since “informee” isn’t used anywhere else in the gRPC docs?

Obviously, witness_parties cannot be the full witnesses as defined by the ledger model, since the full witnesses might not be known to the party (nor the participant). In general, a party whose projection is rooted at an action A, shouldn’t learn the non-informee witnesses of A.

For context: I’m implementing auto-synchronization for submitted transactions in a distributed setting (Canton), such that you can submit a command at one participant, and wait until all involved participants have seen it. The lack of such sync has been a source of a lot of bugs in demo apps written for Canton, and is a reason why DAML Script is currently not very usable in a distributed setting. Implementing the sync requires learning the full witnesses of a transaction (these are always known to the submitter), but I think I can abuse the solution with non-local parties for the time being.

4

Not at all. I believe there are many misnomers in our code and docs, the more we can fix, the better.