Canton Component Overview
Domains
A Canton domain consists of three entities: Sequencers, Mediators, and a Topology Manager. These are collectively called the domain entities.
In general, every domain entity can run in a separate trust domain (i.e., can be operated by an independent organization). In practice, all domain entities are typically run by a single organization. Each participant node runs in its own trust domain.
The generic term member refers 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 — a list of individual messages are submitted, and all messages in a batch receive the same timestamp. Each message may have a different set of recipients.
Evidence
The sequencer provides recipients with a cryptographic proof of authenticity for every message batch it delivers, including evidence on the order of batches.
Sender and Recipient Privacy
Recipients do not learn the identity of the submitting participant. A recipient only learns the identities of recipients on a particular message from a batch if it is itself a recipient of that message.
Mediator
The mediator computes the final result for a confirmation request and distributes it to participants, ensuring that transactions are atomically committed across participants while preserving privacy. 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
Sends the result message
Additionally, for auditability, the mediator persists every received message in long-term storage.
Topology Manager
The topology manager allows participants to join and leave the Canton domain, and to register, revoke, and rotate public keys. It tracks the parties hosted by a given participant and defines the trust level of each participant (ordinary or VIP).
Participant-Internal Canton Components
Canton uses the Daml-on-X architecture to promote code reuse. The participant node is broken down into a set of services, with the Canton-specific service being the Ledger Synchronization Service (LSS).
Transactions
This is the central component of LSS within Canton.
Submission and Segregation: 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 encrypted form. The submitter also informs the mediator about the informees and confirmers of the transaction.
Validity and Confirmation Responses: Each informee of a requested transaction performs local checks on the validity of its visible subtransaction, confirming that it conforms to Daml semantics and the ledger authorization model.
Confirmation Result Processing: Based on the result message from the mediator, the transaction component commits or aborts the requested transaction.
Sequencer Client
The sequencer client handles the connection to the sequencer, ensures in-order delivery, and stores the cryptographic proofs of authenticity for messages from the sequencer.
Identity Client
The identity client handles messages coming from the domain topology manager and verifies the validity of received identity information changes.
Applications
A DAML application is an application developed using the DAML programming language. DAML applications treat every action as an asynchronous operation, and contention is considered a natural and expected occurrence. Key design considerations include:
Bundling or batching business logic to increase transaction throughput
Maximizing parallelism through sharding
Avoiding large sets of observers that can hinder parallelism
Splitting contracts across natural lines to reduce contention
The diagram below shows the components often used in a DAML deployment. High availability is achieved via active-active (HTTP JSON API Service, sequencer) or active-passive (participant node, mediator) clustering.
Collections
A collection is a workspace area within Catalyst where files containing Daml models, triggers, automation, and UI assets can be uploaded and managed. Collections act as a centralized repository, making it convenient to deploy and redeploy these files across multiple ledgers.
Validators
A validator in the Canton network is a specialized node responsible for validating transactions. Validators operate as part of a broader network that may include both standard validators and super validators. Super validators have additional responsibilities, such as dictating network policies and approving the addition of new validators.
As a participant in the network, validators can earn Canton coins as rewards for their services. These tokens can be used to pay for network services, transfer within the network, or manage traffic costs via the integrated wallet. Validators can also register custom names using the Canton Name Server (CNS) or Amulet Name Server (ANS).
Last updated
Was this helpful?