Use of contracts through divulgence and readAs?

Questions
1

Hi, I see the use of divulged contracts are being deprecated (and are incompatible with pruning), and that I can exercise a flexible choice on a contract (I’m not a stakeholder of) given readAs rights (to one of its stakeholders). I have 2 questions related to this:

Question 1: I’m wondering if it is necessary to disallow the use of divulged contracts that is being created within the same atomic action, e.g., a contract is created and divulged to Alice, and then Alice exercises a flexible choice on it? Please note the following:

Note 1: Alice can be certain that such a contract (being created and divulged within the same atomic action) is still around within the same atomic action.

Note 2: As a workaround one can obviously add Alice as an observer for a split second to the contract, i.e., as a first step of the atomic action, add Alice as an observer to the contract, and then remove her as a last step (if there are such choices on the contract i.e.). However, adding those choices feel somewhat superfluous (if only used within this context), and some information is also leaked to the stakeholders of the contract (namely that Alice is added as an observer to the contract for a split second).

Note 3: Another workaround (which obviously is not always possible) would be to give Alice readAs rights to one of the parties of the contract being divulged (then it is no need to add Alice as an observer for a split second). In that light it feels like one could as well allow exercising a flexible choice on a created and divulged contract within the same atomic action (at least one can derive that behaviour by solely looking at the DAML code).

Question 2: As Alice can exercise a flexible choice on a contract (of which she is not a stakeholder) through readAs rights (to one of the contract’s stakeholders), why is she not allowed to fetch its contract data (note that she knows the contract id)? A workaround would be to let Alice exercise a flexible choice on the contract that returns the contract data, but adding such choices feels somewhat unnecessary.

3 Likes
2

For your first question you are correct that this doesn’t cause issues with pruning. The main reason to disallow that imho is that it’s somewhat non-compositional in the sense that you can do things within a single transaction that you cannot do across multiple transactions. As a rule of thumb, doing things across multiple transactions should only give up on atomicity but otherwise behave identically.

For your second question, we have to distinguish between two separate concepts:

  1. Authorization, these are the authorization rules you know. For a fetch, at least one of the authorizers must be a stakeholder, for an exercise the authorizing parties must be a superset of the controllers.stakeholders, for an exercise the authorizers.
  2. Visibility, before multi-party submissions this enforced that the submitter must “know” about all contracts that are referenced (fetched, exercised) in a transaction. With multi-party submissions this is extended to one of the actAs or readAs parties “knowing” about the contract. And without divulgence “knowing” is equivalent to being a stakeholder on a contract.

readAs has no influence on authorization, it purely affects visibility. So the reason fetch (might) fail is that you are still lacking the authorization. By providing a choice on that contract the authorization rules work out. An alternative is to call fetch in the context of another choice where you have authorization of at least one stakeholder.

2 Likes