Twenty questions you asked about Canton & Daml 2.0!

We recently held a webinar on the much anticipated Canton and Daml 2.0 with engineers and product managers on the team. If you missed it, you can view it here:

At the end of the webinar, we answered some really great questions from the attendees and  thought it would be great to share them with everyone!

1. What are the differences between Daml 2.0 and Canton? What does it do to warrant its own name?

There are a few differences that are related:

1. First, the Daml language is a smart contract language that satisfies the Daml ledger model and the associated runtime attributes (e.g., time, causality).
2. Second, Canton is the distributed ledger and protocol that faithfully implements the Daml ledger model, along with the associated runtime attributes (e.g., time, causality). 
3. Collectively, the Daml solution stack includes the Daml smart contract language, Canton for the DLT, and an underlying synchronization layer.
4. In short, with Daml 2.0, Canton is bundled into our overall product solution stack.

2. Daml 1.0 was open-source, but is 2.0?

Digital Asset is committed to open source and Daml 2.0 continues to be developed in the open as much as it was before. The SDK is still developed in the same repo (https://github.com/digital-asset/daml), while Canton has its own Github repo (https://github.com/digital-asset/canton). 

3. Is Canton compatible with Daml Script (for on-the-fly allocation of parties, etc.)? Or is there a new way to do things?

Canton participant nodes implement in full the Ledger API and support Daml Script. Specifically, with regards to party allocation, the only change is that party IDs are now no longer limited to the provided party ID hint, but as long as you haven't hard-coded party IDs in your application, there's no impact on it. When Daml script executes multiple nodes there may be a need to perform manual synchronization and an appropriately defined config file.

4. When is Daml Hub expected to catch up with Daml 2.0? When will we see Daml Hub have support for Daml 2.0?

We’re working on updating Daml Hub to Daml 2.0. We can’t give an exact date however, we expect it to be live in the next two to three months.

5. How many releases have included Canton with Daml 2.0 on production use cases?

Daml 2.0 GA builds on top of Daml 1.0, which is already in production. Daml 2.0 GA was released last month, so it is starting to be deployed in production. Our customers have been implementing their applications on top of Canton’s Beta releases for the last several months.  The first of these is slated for production in the next couple of months. As an aside, there is a Canton release every month with new features and bug fixes.  

6. Will there be an example of how to use the system?

There are extensive demos and tutorials in the documentation for both Daml and Canton.  Please go give it a try. There are also YouTube videos that provide more information in our channel.

7. What features of Daml 2.0 are not available on specific platforms now (e.g., Fabric, etc)?

As of April 12th, PostgreSQL and Oracle are GA. Fabric and Besu are being released in Daml 2.1 GA which should be available when you read this.

8. Fact-check me: Canton encrypts the transaction messages that are distributed to all but read by the only parties intended to participate in the transaction.

You are very close. Daml and Canton have the notion of subtransactions. This allows the enclosing transaction to be decomposed into subtransactions that are only sent to the party/node that needs to see the subtransaction. So, the payload messages are only sent to the party/node and not to all nodes. Of course, both the payload and envelope are separately encrypted.

9. Does the Canton protocol at all change the way certain contracts are divulged to parties as a result of Exercise consequences?

Canton faithfully implements the Daml ledger and semantics. What can be done in Daml is also possible in Canton. Please be aware that contract key uniqueness is not supported with the early access multi-domain feature.

10. Your privacy model doesn’t appear different than that of Corda?

There are important differences. This blog post calls it out: “Privacy on the Corda Ledger has some issues, in particular, if you interact with a particular state, your machine gets access to the entire history of the state.” This means that the entire history of the asset can be available for viewing.

11. The reverse of fully private data is the recovery requirement for failed nodes. Is that a responsibility of Daml or client apps?

It's a correct observation that uploading all your data to thousands of servers will eventually help you with recovery of data. The flip-side is that you can't do that with confidential data, from a commercial and also from a regulatory perspective. Canton is flexible enough to let the user make the choice on how far they want to distribute the data so as to support different methods of recovery (recovery from backup, recovery from peers, etc.). Data at the participant node is not private because, by definition, the participant’s parties need to see it. So, the participant node can be backed up and then used to restore a failed node. When a restored node is connected back to the domain, it will automatically catch up to the state of active contracts by receiving periodic snapshots of information from other participant nodes.

12. Is there anything wrong with having the public party as the only observer on every contract?

Canton supports a party on multiple nodes as a preview feature. However, there are limits on the number of nodes that can host the same party, as these participants are mentioned explicitly in the message. Enhancements to make this more efficient (e.g., group addressing and broadcasting) are on the backlog.

13. Is there any slide(s) that covers a use case in which a submitting node interacts with two domains?

Check out the “Composability” demo.

14. Is there support for SSI (Self Sovereign Identity) and credentials in Daml?

In principle, Daml templates (i.e., smart contracts) can be constructed for an SSI capability, but it is not built in to allow a range of possible solutions. An identity in Canton is a self-sovereign identity. However, Canton separates the system identity from the legal identity. The system identity problem is solved using standard asymmetric cryptography. This enables building appropriate Daml models that solve the legal identity problem within Daml application code by establishing proof of a connection between a legal identity with a system identity. As there are countless ways for a legal identity to be expressed and certified, Canton enables this functionality in a Daml application so that a range of model designs can be used. 

15. What about the user management differences between Daml 1 and 2.0? How is that going to affect compatibility?

A user is a new and additional concept. The old behavior is still supported. However, while previously you were more free to choose the party names, they are now made up of a chosen identifier and a fingerprint of a key. Therefore, a user allows a participant to use self-chosen names to refer to a set of parties (which can not be chosen).

16. How are we handling the private keys of each participant node?

The documentation has been updated to list the complete list of keys. This update is available in the Daml 2.1 release at https://docs.daml.com/2.1.0/canton/usermanual/security.html# .  

17. Daml language (programmer) can use Canton driver to natively encrypt data in the ledger. How is this different from non-canton ledgers like Hyperledger? Isn’t it possible for the programmer to encrypt the content of the block in Hyperledger if she or he wishes to do so? The value of native cryptography provided by Daml and Canton Driver isn’t clear. Can you elaborate?

Yes, you can encrypt the contents of a block in Hyperledger, but all you have is an encrypted block. This may be sufficient for public tokens. But what else is needed for smart contracts?  Let’s start with how Daml explicitly defines parties, rights, and obligations in a distributed system. Canton honors these directly, so that the programmer does not have to code in things between organizations, including: The need for sub-transaction privacy, data ownership management, built in mechanisms to avoid programmer errors, granular permission management, atomic synchronisation, authentication, authorization, encryption, security, trust, and, composability. The total order broadcast mechanism is a small part of the value that Daml and Canton bring. An analogy is that any business application can be written in assembler without an operating system, but we don’t do this for obvious reasons.

18. Why do we use SQL DB? Can we not use couch DB or any other DBs? Is Canton configurable with other DBs if we wish to use others instead of SQL?

Canton is not opinionated about a particular database and is designed to make it easy to add other vendors. Canton can be used with PostgreSQL and, if you’re using Canton Enterprise, Oracle. These two databases have been the ones requested the most, so naturally, we wanted to make our customers happy. There's no inherent reason why Canton cannot be implemented on top of other databases, but right now we are focusing on these two implementations.  

19. Is there any slide(s) that covers a use case that a submitting node interacts with two domains?

Check out the “Composability” demo.

20. How does the newly added participant node validate (or with what proof does it check against) “Alice balance” during a transaction?

There is no such thing as "Alice balance" when a new node joins. All Daml contracts are stakeholder based agreements. A participant node that is added fresh has no agreements, so it has an empty ledger.