Query and Create Exercise as multiple parties

General
,
22

@Ratko_Veprek because it was only disclosed out-of-band via the public party. my own party doesn’t have visibility on that contract in terms of the ledger so I can’t fetch the contract.

1 Like
23

@dliakakos so, the ledger-api itself should support what you are looking for. and i do see your point. for quite a while, we have said that we still need to add something like a “public section of the ledger”, which amounts to your broadcast. however, so far, this hasn’t been a top priority, so it was never followed through up to now.

however, if you look at the canton identity management system, it actually already supports public parties in theory.

with respect to the http-json api: i don’t think that the http-json api should try to implement different semantics on the permissioning / how to use parties. in that sense, i would also expect that you can du multi-party subscriptions there.

and btw, multi-party subscriptions were added three years ago because maintaining 100 open subscriptions, one for each party from a single app was a nightmare.

2 Likes
24

Yes, but that’s related to another semantic issue, the fact that a contract-id are opaque. Once the meaning of contract-id is changed such that they also refer to the payload, we solve quite a few issues at once: public parties, out-of-band disclosure, read delegation.

1 Like
25

Agree. I’d be interested in @bernhard 's stance on what’s planned for the read model overhaul.

26

I agree with @cocreature. From a conceptual point of view I expect we should be able to support submitting a command on behalf of multiple parties.

I think we don’t have it, because it has not been a priority. And it could be an expensive change, as it affects many components.

1 Like
27

I agree with all the problems/requirements stated here, and will add a few more. I talk about this topic as a whole as “Read Delegation”

Requirements: Given a contract ct with stakeholder party party_s controlled by user user_s and another party party_a controlled by user user_a

  1. user_s should have a way to make ct available to user_a for both read and write by party_a. Ie user_a can get ct from both the Ledger API and JSON API, and a way to interpret transactions that use ct as inputs.
  2. This mechanism should not require user_s to archive and recreate ct
  3. Nobody other than the signatories of ct and the two involved users and parties should need to know that this sharing has happened.
  4. The mechanism should be in DAML so that “read delegation” can be part of the application logic. E.g. user_s should be able to delegate party_s's the right to make ct available to party_a to another user/party
  5. The mechanism needs to work on any DAML Ledger
  6. The mechanism needs to work independent of Ledger Topology
  7. The mechanism needs to work in a dynamic topology where new parties join.

In addition to this, we have a few constraints that are expensive to lift:

  1. Parties do not have a cryptographic identity on the ledgers, only participants do
  2. Transactions are submitted by a single participant
  3. To interpret and submit a transaction, the submitting user must have access to sufficient information on the submitting Participant to submit the whole transaction. Ie there is not “interactive submission” where the Participant goes around the network to fetch data.
  4. Participants do not communicate “out of band”. ie there is no way for the contract data of ct to make its way from Participant 1 to Participant 2 without a transaction.

Solving this broad topic of “Read Delegation” is tough, and to answer your original question @dliakakos, yes, we have considered special “public” parties and handling this on the auth and API side, but that approach falls short or requires serious work to lift the constraints.

  • Requirement 1: Unless you have foreseen the ability to share a contract, you can’t add it after the fact. Stakeholders can by default not change the set of observers. Thus requirement 1 is not met.
  • Requirement 2: Using parties / observers requires ct to be archived and recreated whenever the set of observers changes. Some changes like adding a user/party to a group can be solved on the IAM/API level, but not all, so Requirement 2 is only partially met.
  • Requirement 3: Anyone that sees the contract sees to who it’s visible. Using “group” parties alleviates this problem, but does not remove it. Thus requirement 3 is only partially met.
  • Requirement 4: Since this mechanism manages read delegation using the IAM system, it’s completely outside of DAML. So requirement 4 is not met.
  • Requirement 5: This mechanism requires a single party like public to be hosted on all Participants. This puts a new requirement on DAML Ledgers (Parties being hosted for read/write on many nodes), that not all currently support. Furthermore, there is a completely open question as to the governance of such parties. In a fully distributed system, who holds the master key to public? For more fine-grained groups, who administers them? In other words, I think this mechanism works just fine for DABL and DAML on SQL where there’s a clear operator, but there are wide-open questions in distributed infrastructures. Ie Requirement 5 is not met.
  • Requirement 6: Due to constraints 2, 3 and 4, being able to read and submit as two or more parties relies on both parties being hosted on the same participant. Thus, this mechanism is highly dependent on ledger topology, meaning Requirement 6 is not met.
  • Requirement 7: Let’s say we have Alice and Bob each on their own Participants, and using a shared public party. Now Chloe comes along and connects her own Participant. Somehow she acquires the master key for public and informs the network that her Participant now has the right to read data for that party. Where’s the data coming from? The only people that have it are Alice and Bob. But by constraint 4, there is no mechanism to get it.

As you can see, the mechanism falls quite short of meeting what we need for “Read Delegation”. Even in simple cases like “public” data, I see problems. Removing those problems would require a lot of expensive work to lift the constraints, but would ultimately still only solve a few of the requirements. Hence, I do not believe that multi-party read/write via the API is the right mechanism.

So what is the right mechanism, I hear you ask? It comes in multiple steps:

First, we add a mechanism that does exactly what’s needed in Requirement 1. A way to get ct into party_a's view in such a way that it’s available for read/write. One way to do that is to just “attach” ct to a contract that party_a observes. This meets Requirements 2, 3, 4, 5, 6, 7 automatically.

This mechanism is quite low level - each “sharing” operation, requires a message contract, and the messages need to be updated whenever ct changes. Thus, you need a lot of app logic to make it happen, and the number of transactions explodes with a public contract and lots of parties.

Hence, the next steps are to optimize. The developer UX can be improved using a standard library of contracts and automation that just make this “broadcasting” happen. My original mock-up for DAML Triggers was actually based on exactly this idea.

Then the traffic problem has to be addressed. Rather than sharing “in band” using message contracts, the sharing has to be moved out of band, removing constraint 4. Some mechanism for the Participant of party_a to subscribe to the participant of party_s to receive any updates that party_a is entitled to. And here you can optimize a lot according to topology. If party_a and party_s are colocated, this sharing can be made near-zero cost.

4 Likes
28

While I agree that we don’t solve the general delegation problem with multi-party readAs and writeAs permissions, I think it’s still worth implementing this feature on the JSON API under an experimental feature flag. Implementation effort is very low as I understand, and it will allow us to gain more insights and experience into the problematic.

2 Likes
29

agree with @drsk here

The general solution is prob far and many iterations away. In the meantime, we have a real & present dev roadblock that we can solve in a relatively straightforward way. My guess is that, over the long run, we will benefit from both the generic daml-level feature and the api-level feature and will find ways to utilize both.

4 Likes
30

@gerolf correct me if I am wrong. The multi-parties are discouraged. Support for multi-parties might/will be removed from the Ledger API.

@Martin_Huschenbett agreed (at least he did not oppose the idea suggested by @Stephen) that it makes more sense to implement multi-party support as part of the daml-ui client-side API (or maybe JSON API). The API user will have to provide multiple JWTs (one per party), daml-ui or JSON API will merge multiple requests (one per JWT) based on contract IDs.

That is the summary of the last meeting.

31

@eric_da here is the ticket: Add multi-party support to JSON API JWT · Issue #5948 · digital-asset/daml · GitHub you can prioritize it.

In the meantime the solution is to send multiple requests, one per party/JWT and merge them on the client-side.

32

That’s not the reason I remember.
Besides that, would you expect a typical application having to manage subscriptions for so many parties at once? Even when filling a local ACS, it’s probably safer from a data segregation point of view to keep separate streams.

As mentioned by @stefanobaghino-da already, multi party subscriptions come with a runtime cost (which depends on number of parties in the request and number of events in the transaction). Would an initial client side library solution work as well?

1 Like
33

Moving this to General as it’s a very involved discussion without a singular answer :slight_smile: