Hello,
I will describe my question using the following 2 templates:
template PersonalContract
with
owner : Party
value : Int
where
signatory owner
choice Change : ()
with
newValue : Int
controller owner
do
create this with value = newValue
pure ()
template SharedContract
with
admin: Party
owner :Party
cid : ContractId PersonalContract
where
signatory admin, owner
nonconsuming choice ChangePersonal : ()
with
newValue : Int
controller owner
do
exercise cid Change with ..
pure ()
What I want to achieve is a way for the admin to exercise the ChangePersonal choice.
However, the admin is not a party in the PersonalContract template. So, I added the following delegation template:
template SharedPermissionContract
with
admin: Party
owner :Party
where
signatory admin, owner
nonconsuming choice AuthorizeChange : ()
with
newValue : Int
cid : ContractId SharedContract
controller admin
do
exercise cid ChangePersonal with ..
pure ()
And I wrote the following script:
test : Script ()
test = do
admin <- allocatePartyWithHint "admin" $ PartyIdHint "admin"
owner <- allocatePartyWithHint "owner" $ PartyIdHint "owner"
pid <- submit owner do
createCmd PersonalContract
with
value = 1
..
sid <- submitMulti [admin, owner] [] do
createCmd SharedContract
with
cid = pid
..
spid <- submitMulti [admin, owner] [] do
createCmd SharedPermissionContract
with
..
submit admin do
exerciseCmd spid AuthorizeChange
with
newValue = 2
cid = sid
pure ()
But even after creating all 3 contracts, and letting the admin exercise the AuthorizeChange choice, I am getting an error:
Attempt to fetch or exercise a contract not visible to the reading parties.
Contract: #0:0 (Test:PersonalContract)
actAs: 'admin'
readAs:
Disclosed to: 'owner'
Why is that? And how can I resolve this?
It is important to say that I don’t want to have the admin a party in the PersonalContract template.
Explicit contract disclosure allows you to delegate contract read rights to non-stakeholders using off-ledger data distribution.
Contract read delegation allows a party to acquire read rights during command submission over a contract of which it is neither a stakeholder nor an informee.
Here is an example in Daml Script:
template PersonalContract
with
owner : Party
value : Int
where
signatory owner
choice Change : ()
with
newValue : Int
controller owner
do
create this with value = newValue
pure()
choice AdminChange : ()
with
admin : Party
spid : ContractId SharedPermissionContract
newValue : Int
controller admin
do
spid <- fetch spid
assertMsg "Owner must give permission" (spid.owner == owner)
assertMsg "Admin must have permission" (spid.admin == admin)
create this with value = newValue
pure()
template SharedPermissionContract
with
admin: Party
owner :Party
where
signatory admin, owner
test : Script ()
test = do
admin <- allocatePartyWithHint "admin" $ PartyIdHint "admin"
owner <- allocatePartyWithHint "owner" $ PartyIdHint "owner"
pid <- submit owner do
createCmd PersonalContract
with
value = 1
..
spid <- submitMulti [admin, owner] [] do
createCmd SharedPermissionContract with ..
Some edc <- queryDisclosure @PersonalContract owner pid
submitWithDisclosures admin [edc] do
exerciseCmd pid AdminChange
with
newValue = 2
..
pure ()
Notice that even after the “edit,” the admin is neither a signatory or observer of the new contract. He is a “witness.”
To translate this to an application making calls through the Ledger API:
First, owner’s backend would need to grab and share a copy of the created_event_blob. (This would be the equivalent of the Daml Script’s queryDisclosure.)
Then, admin’s backend would take that created_event_blob and include it when submitting the exercise command. (This would be the equivalent of Daml Script’s submitWithDisclosures.)
Thank you @WallaceKelly for a great answer.
I was not familiar with both queryDisclosure and submitWithDisclosures.
I now read that queryDisclosure is:
WARNING: Over the gRPC this performs a linear search so only use this if the number of active contracts is small. Not supported by JSON API
So, my questions are:
So, is there an example of how I can do this using a java and Ledger API?
Is there another solution for this (since we don’t expect to have small number of active contracts)?
Instead of querying the Ledger API for each created_event_blob as needed, you can use the transaction stream to write them into a relational database. Then query the relational database as needed.
I am trying to achieve a mechanism where I can “notify” contracts about changes.
For example, say that I am having an application that stores prices of fuel types (Diesel and Regular Gasoline)
So, I am having a contract for each type of fuel and its price.
In addition, I have providers that have fuel tanks. And they want to know every time how much their fuel worth.
For that:
I am creating a “subscription” contract between the admin and the provider.
The provider develops his own contract with data - to whatever purpose he needs (I don’t have control over it). The only requirement is that specific contract will implement our interface which requires to implement a “Notify” choice.
The subscription contract is storing the interface contract id of the providers specific contract.
So, once my Java application is updating the price of the main fuel type contracts, I fetch all the subscriptions contracts of that specific fuel type, and for each one of them I exercise the “Notify” choice.
So, to achieve this I am thinking of using your solution of queryDisclosure & submitWithDisclosures functions.
What do you think about it?
By the way, I am familiar with PQS. And if I am not mistaken, when running the PQS on behalf of the admin, I won’t be able to exercise their “Notify” choice due to the disclosure issue.
It’s hard to give good architecture and design advice in a forums format with limited understanding of the problem domain. However, I’m glad that I’ve added another tool to your toolbox – explicit disclosure. You will want to use this in your design when you need to make contracts (especially a large number of rarely used contracts) available to non-stakeholder parties. Pricing is a good example provided for that. You move that data flow off-ledger and only store on-ledger the agreements between the parties that result from that off-ledger data sharing.
(Also, I think you realize this, but for those that read this later… queryDisclosure and submitWithDisclosure are the Daml Script functions for unit testing explicit disclosure. The real application will most likely be implemented with a general-purpose language with “bindings” for the Ledger API.)
You are right. The admin’s PQS will not have the contracts for which it is not a stakeholder. It is on the owner’s side that the PQS is helpful. It is the owner that has the contract data and it is the owner that needs to “export” the contract data and share it with admin through a traditional, non-DLT mechanism (e.g., HTTP Rest API). Once the admin has a copy of the contract data, the admin can exercise the choice on the contract by including that contract blob when submitting the exercise command.
I should reiterate. I don’t know your application well enough to advise you to use or not to use explicit disclosure. I just want to make you aware that it is available. Consider this a disclaimer.
