Lesson 5: Canton multidomain applications

Captions as YouTube publishes them, usually machine-generated, so names such as Daml and Canton can be misheard.

1. 0:05

   daml applications are multi-party applications that span multiple participant nodes in sync domains they can also be composed by combining other daml applications in this lesson we will look at a few different ways of thinking about how to compose daml applications to transact across one or more Canton sync domains let us say that there is a bank that provides an app to its customers to manage and transfer their cash balances on Ledger one of the bank's customers

2. 0:37

   that uses this app is company a the app defines daml templates to represent the account balances of their customers as well as the state of the workflows these daml templates are compiled into DARS that are installed on the customers and the bank's participant nodes the bank app specifies that it wants the participant nodes to use the bank's sync domain for synchronizing the transactions and so company A's participant node uses the sync domain

3. 1:08

   specified by the bank app it is important to remember at this point that the job of a sync domain is to sequence route and confirm the transactions across its participant nodes this process is orchestrated by the sequencers and mediators that are part of the sync domain so when the stakeholders of an application assign a sync domain to contract data they effectively choose from where they want transactions using that contract data to

4. 1:38

   be sequenced routed and confirmed let us say that a bank employee is an end user from the bank and a company a employee is an end user from company a both of these employees use a web UI to submit commands to their participant nodes given this setup let us trace the flow of actions when the bank employee uses the app UI to issue a $100 on Ledger cash to company a this command goes to the bank's participant node from where it is routed to the bank

5. 2:10

   sync domain the sync domain will root it to company A's participant node which will then send a confirmation back to the sync domain once the sync domain receives this confirmation it will send a final commit message to both the nodes to commit the transaction in their own respective ledgers this will create a shared contract present in both the bank's and Company A's private contract state which shows the bank as the issuer and Company a as the owner of

6. 2:41

   $100 now we want to expand this scenario a bit we now also have a Central Security depository or CSD and Company B CSD is also an app provider and has its own CSD app which is used by Company B CSD D and Company B have their own participant nodes where the DAR files for CSD app are installed similarly Company B has a security asset issued by CSD which means that CSD and Company B have a contract in their private contract stores showing Company B as the

7. 3:19

   owner of the asset now let's assume a company wants to offer a Marketplace for exchanging these tokenized assets the functionality offered by this company is DVP or delivery versus payment let us call this company DVP exchange this exchange can now build another app called DVP app which will introduce a new set of smart contracts that will use the smart contracts in the bank and CSD apps Canton offers the mechanisms to create this kind of composed app by

8. 3:55

   composing workflows from multiple apps to build this deliv delivery versus payment app we need to have the following setup the DVP app must have the bank app and the CSD app doors on its participant node this will allow DVP exchange to provide the complete functionality by using the templates from the bank app and the CSP app second the parties that are interested in using the DVP functionality must have all three DARS Bank app Dar CSD Dar and DVP

9. 4:29

   dar to enable this exchange so as shown here company a and Company B have all three DARS on their participant nodes third for this scenario we have all participant nodes using the same sync domain it is possible to have the bank and the CSD organizations to have their own sync domains and we will see that scenario in our next example shortly and finally since the company a and Company B employees will will be interacting with the bank app CSD app

10. 5:02

    and the DVP app they will have three different web uis to carry out the actions in the DVP workflow let us now look at the DVP workflow starting with all apps using a single domain we start with a contract that shows company a as the owner of $100 and another contract showing Company B as the owner of 20 security assets note that a copy of the first contract will be stored in the PCS of the bank and of company a similarly a

11. 5:36

    copy of the second contract will be with the CSD and with Company B now company a extends a proposal to exchange $10 for company B's one CSD asset through the company a DVP app UI Company B accepts The Proposal from its DVP app UI an employee at company a then uses the DV VP app UI to create a request to allocate $10 of the cash to this DVP for security reasons this follows a PayPal style checkout process after creating that request the DVP UI redirects the

12. 6:15

    employee to the bank app UI to review and approve the request similarly Company B then requests CSD to allocated side of DVP which is one asset the DVP app creates a request and sends to Company B for approval once both company a and Company B approve the requests the bank app backend splits out $10 from company A's contract and marks it as reserved similarly CSD app backend splits out one asset from company B's contract and marks it as reserved these

13. 6:52

    reserved assets are locked by the counterparties involved in the transaction now the dvb app backend can per per form the atomic swap making company a the owner of one CSD asset and Company B as the owner of $10 as you can see DVP app uses the bank and CSD contracts to perform this functionality which means it needs to have access to the contracts to split and Swap and this requires these contracts to be assigned to the same

14. 7:23

    sync domain as the DVP app so far we have seen the architecture where all these parties in participant nodes are using the same sync domain the decision to choose a domain depends on which domain the stakeholder parties can trust and because of that as most often the case will be in the real world the three apps that is the bank app the CSD app and the DVP app will be in different sync domains so let us add one more variation to this architecture where the three

15. 7:56

    apps Bank app CSD app and and gvp app are using three different sync domains while the overall workflow Remains the Same as before a key change required is to get the contracts reassigned to that sync domain which is being used by the app acting on the contracts in this example this would be required at three points in the workflow first when company A's DVP app creates a request to allocate $10 for

16. 8:27

    DVP the request will have have to be assigned to bank's sync domain for company a to approve it from the bank app similarly the request to allocate company B's asset will have to be assigned to CSD domain for it to be approved through the CSD app second once the allocated contracts have been split out by the bank app backend and the CSD app backend they will have to be assigned to DVP sync domain so that DVP app can perform the atomic swap on them

17. 8:59

    and finally after performing the atomic swap the two contracts will be assigned back to their respective sync domains that is the bank domain and the CSD domain this example demonstrates the ability to compose multi-domain applications in Canton spanning organizational and application boundaries without compromising on data sovereignty privacy and security it also enables composing new daml applications thereby developing Advanced and complex

18. 9:30

    services and enabling future Innovation let us now summarize what we have covered in this lesson Canton provides two features for extending the functionality of daml applications first we can compose daml apps by combining the workflows of two or more daml apps to compose an application using other daml applications the composed application needs access to the doors of the applications that it is using in its

19. 10:01

    functionality second if these apps are in the same sync domain the composed app can get access to the contracts required for completing the transactions but if these apps are in different domains as often is the case it needs to get access to the contracts by getting them reassigned to the composed apps Sy sync domain so that it can perform some action on them that