Lesson 1: The Canton Ledger Model

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

1. 0:00

   The Canton Ledger model lays the foundation for building Daml applications. Let's say Alice wants to hire a cab and requests Bob, a cab driver, to take her to some destination. Bob accepts the request and tells Alice he'll charge her $150.

2. 0:15

   Alice accepts the quote. Once Bob drops her off at her destination, Alice transfers $150 from her bank account to Bob's account. We're gonna take this process and explore how we could implement it in a Daml application. First, there are four parties involved in the entire process.

3. 0:33

   Alice, Bob, Alice's Bank and Bob's Bank. Second, there are at least three agreements involved between these four parties. One agreement is between Alice and Bob, where Bob agrees to provide cap service, and Alice agrees to pay. This agreement allows Alice to request a cab and cancel the request.

4. 0:53

   She can accept the quote made by Bob or reject it. In a similar way, Bob accepts Alice's request and makes a quote or rejects her request. The second agreement is between Alice and her bank, where she deposits and withdraws money and also makes payment to third parties.

5. 1:10

   A similar agreement exists between Bob and his bank. There's potentially a fourth agreement between the two banks, but we'll leave that aside for now. Daml calls these agreements contracts. In each contract, the action the parties can take are called choices.

6. 1:25

   Notice that in this example, Alice's and Bob's contracts with their banks are similar except for the name of the parties. When creating an application, we often wanna generalize interactions. In this example, we could generalize two interactions.

7. 1:38

   One, to create contracts between cab drivers and passengers, and the other to create contracts between people and their banks. We can generalize contracts and choices in Daml with templates. Templates create contracts between parties.

8. 1:53

   As the parties engage with each other, their behavior is controlled by the underlying contract they agree to. We're beginning to see a multi-party smart contract system taking shape. We've identified the parties and the templates we'll use. Now we need to fill in the logic that models the process workflow. So, let's take a look at that workflow.

9. 2:12

   We'll start by looking at the most likely or happy path for our work. This diagram outlines the actions taken by parties and some of the choices available to them in their contracts. Here we start with Alice requesting a cab. One scenario is that Bob chooses to accept the request and offers a quote. Alice then accepts the quote, and Bob then provides the service.

10. 2:32

    Finally, Alice makes the payment to Bob's bank account through her bank account. Another scenario can be when Bob offers a quote, but then Alice turns it down. There are several scenarios based on what choices Alice and Bob make.

11. 2:47

    The outcome of these choices gets recorded, and this is where the Canton Ledger comes in. The Canton Ledger is a recorded list of commitments made by the parties. Every time a party commits to something, it submits a transaction which gets recorded.

12. 3:01

    For example, when Alice makes a request for a cab, the request gets recorded in the ledger. If she cancels a request because she changed her mind, the cancellation also gets recorded. So the ledger will have a record of her requests and her cancellations.

13. 3:15

    So far, we've looked at the contract between Alice and Bob based on one template, but when we start to analyze all possible scenarios, we realize the complexity of the workflow. So let's show you how we might break down a big and complex process into small parts and try to model them one by one in templates.

14. 3:34

    We can break down the process into four parts modeling, four exchanges between parties. First, Alice makes a cab request and Bob either accepts or rejects that request. This part captures the data required for the cab service to estimate the trip cost, for example, the starting point, destination, time of ride, et cetera.

15. 3:53

    Second, Bob offers a quote for this service and Alice accepts or rejects it. Third, Alice acknowledges the service provided by Bob when the ride is complete and she sends the payment to Bob. And fourth, the funds are exchanged between the two banks. Each of these four parts can be zoomed into one by one and modeled in Daml.

16. 4:15

    If we look at the cab request scenario, there are two parties involved in this process. Alice and Bob, more generically the passenger and the cab driver. A party is an inbuilt data type in Daml that represents an individual or a legal entity such as a bank.

17. 4:32

    When we write a template for these parties to engage in a contractual relationship, we need to assign specific roles to these parties in terms of who can do what and who can see what. There are three such roles. First, signatory. Signatories are a party that can create and archive contracts.

18. 4:50

    They can also view all choices exercised on the contract by other parties. For example, in cab request, passenger and cab driver are two parties. The passenger can create a request, so the passenger is a signatory. We can have more than one signatory in his template.

19. 5:07

    An authorization from all signatories is required to create or archive a contract based on the template. The second role is that of the observer. This cab request can be viewed by the cab driver, and so the cab driver is an observer. Signatories automatically get the right to view the contract.

20. 5:25

    The third role is that of a controller. Controller are specific to the choices that they can exercise. In this example, the passenger is the controller for canceling a request, and the cab driver is the controller for accepting or rejecting the request.

21. 5:40

    Identifying these parties gives us a starting point to start developing templates for the cab request process in the workflow. Let's look at what we've covered so far. Modeling a contractual exchange among parties requires modeling the underlying business process workflow, covering all possible scenarios, and identifying the parties, their roles, and their interactions with each other.

22. 6:00

    A party is a legal entity, a person, or an institution that participates in a contractual agreement with other parties. A template is like a blueprint from which contracts are created. Templates have choices that spell out what action parties can take, and they also capture the logic of the workflow in those choices.

23. 6:19

    Parties are assigned one or more of three roles; signatory, observer, and controller. Signatories are those who can create and archive the contracts. Observers are those who can see the contracts and the controllers are parties that can exercise choices available in the contract.