Component overview
Domains
A Canton domain consists of three entities:
-
Sequencers
-
Mediators
-
Topology manager
We call these the domain entities. The high-level communication channels between the domain entities are depicted below.
In general, every domain entity can run in a separate trust domain (i.e., can be operated by an independent organization). In practice, we assume that all domain entities are run by a single organization, and that the domain entities belong to a single trust domain.
Furthermore, each participant node runs in its own trust domain. Additionally, the participant may outsource a part of its identity management infrastructure, for example to a certificate authority. We assume that the participant trusts this infrastructure, that is, that the participant and its identity management belong to the same trust domain. Some participant nodes can be designated as VIP nodes, meaning that they are operated by trusted parties. Such nodes are important for the VIP confirmation policy.
The generic term member will refer to either a domain entity or a participant node.
Sequencer
Ordering
The sequencer provides a global total-order multicast where messages are uniquely time-stamped and the global ordering is derived from the timestamps. Instead of delivering a single message, the sequencer provides message batching, that is, a list of individual messages are submitted. All these messages get the timestamp of the batch they are contained in. Each message may have a different set of recipients; the messages in each recipient’s batch are in the same order as in the sent batch.
Mediator
The mediator’s purpose is to compute the final result for a confirmation request and distribute it to the participants, ensuring that transactions are atomically committed across participants, while preserving the participants’ privacy, by not revealing their identities to each other. At a high level, the mediator:
-
Collects confirmation responses from participants,
-
Validates them according to the Canton protocol,
-
Computes the conclusions (approve / reject / timed out) according to the confirmation policy, and
-
Sends the result message.
Additionally, for auditability, the mediator persists every received message (containing informee information or confirmation responses) in long term storage and allows an auditor to retrieve messages from this storage.
Topology Manager
The topology manager allows participants to join and leave the Canton domain, and to register, revoke and rotate public keys.
It knows the parties hosted by a given participant. It defines the trust level of each participant. The trust level is either ordinary or VIP. A VIP trust level indicates that the participant is trusted to act honestly. A canonical example is a participant run by a trusted market operator.
Participant-internal Canton Components
Canton uses the Daml-on-X architecture, to promote code reuse. In this architecture, the participant node is broken down into a set of services, all but one of which are reused among ledger implementations. This ledger-specific service is called the Ledger Synchronization Service (LSS), which Canton implements using its protocol. This implementation is further broken down into multiple components. We now describe the interface and properties of each component. The following figure shows the interaction between the different components and the relation to the existing Ledger API’s command and event services.
Transactions
This is the central component of LSS within Canton. We describe the main tasks below.
-
Submission and Segregation: A Daml transaction has a tree-like structure. The ledger privacy model defines which parts of a transaction are visible to which party, and thus participant. Each recipient obtains only the subtransaction (projection) it is entitled to see; other parts of the transaction are never shared with the participant, not even in an encrypted form. Furthermore, depending on the confirmation policy, some informees are marked as confirmers. In addition to distributing the transaction projections among participants, the submitter informs the mediator about the informees and confirmers of the transaction.
-
Validity and Confirmations Responses: Each informee of a requested transaction performs local checks on the validity of its visible subtransaction. The informees check that their provided projection conforms to the Daml semantics, and the ledger authorization model. Additionally, they check whether the request conflicts with an earlier request that is accepted or is not yet decided. Based on this, they send their responses (one for each of their views), together with the informee information for their projection, to the mediator. When the other participants or domain entities do not behave according to the protocol (for example, not sending timely confirmation responses, or sending malformed requests), the transaction processing component raises alarms.
-
Confirmation Result Processing. Based on the result message from the mediator, the transaction component commits or aborts the requested transaction.
Applications
A DAML application refers to an application developed using the DAML programming language.
In DAML programming, every action within the system is treated as an asynchronous operation, and contention is considered a natural and expected occurrence. However, managing contention is essential to ensure optimal application performance. The goal is not to eliminate contention entirely but rather to handle it gracefully and reduce its impact.
Designing a DAML application involves understanding the sources of contention and employing various techniques to manage it and enhance performance. These techniques include bundling or batching business logic to increase transaction throughput, maximizing parallelism through sharding, and avoiding large sets of observers that can hinder parallelism.
When designing a DAML application, it is important to identify areas of contention, split contracts across natural lines to reduce contention, partition contracts along logical divisions, and minimize the number of partitions accessed in each transaction. Additionally, leveraging contention-free representations whenever possible can be beneficial.
DAML, being a functional programming language, follows functional programming principles, which contribute to safer and more secure smart contract development. Embracing functional programming practices is recommended when building DAML applications.
The DAML SDK provides developers with tools and libraries that simplify the development of multi-party applications. It includes features for defining the application’s schema and implementing off-ledger code that can utilize the Canton APIs.
The diagram below shows the components often used in a Daml deployment. High availability is achieved via either active-active (HTTP JSON API Service, sequencer) or active-passive (participant node, mediator) clustering. Node scaling is achieved via horizontal scaling with participant nodes requiring sharding across participants.
Collections
a collection refers to a feature or area within the workspace of an application where files containing Daml models, triggers, automation, and UI assets can be uploaded and managed. The collection acts as a centralized repository for these files, making it convenient to deploy and redeploy them across multiple ledgers. It provides a structured way to organize and store the necessary components of the application.
By utilizing the workspace collection, users can easily deploy files into a ledger by either clicking the "Deploy to…" button or by directly dragging and dropping the file into a ledger. This streamlined process simplifies the deployment of assets and promotes efficient management of the application’s resources.
Additionally, the workspace may include pre-built sample applications that are fully functional. These applications can be deployed to their own dedicated ledgers with a single click, further enhancing the ease and speed of deployment for users.