🤝 DAIC partners withPawtato

The Canton Engine Room: How Validators and Applications Interact

Published:
Last updated:
In our previous article, we investigated what the Canton Network is and how its fundamental functionality operates. Here, we dive even further into the engine to see how its participants, Validators and Applications, work together to create a secure and interoperable network. This serves as a guide for any organization looking to launch an app, run a node, or participate as a core infrastructure provider.

Key Takeaways

  • The network is designed as a two-level system, which includes private subnetworks for isolated activity and a public backbone for interoperability purposes.
  • Validators for Canton are stateful, meaning a user's private information is associated with a certain node, which needs to be accessed by a direct connection.
  • The Global Synchronizer connects independent applications to allow for atomic, secure transactions without external bridging.
  • Applications on Canton are built with the Daml smart contract language, which defines the core business logic and privacy rules.

The Key Players on the Network

The Canton Network itself is a "network of networks," and its architecture is defined by a particular set of roles and interactions of its major players. For an application provider, it's essential to understand that they are not just building software, but are also operating a core part of the infrastructure for their own service.

Applications (Apps): The Business Logic of the Network

Applications are the business logic of the network. They are Daml-programmed smart contracts which establish work flows for everything ranging from asset tokenization to payments and derivatives.  An application's smart contract logic and data are not hosted on a single central server. Instead, they live and are executed on the Validator Nodes of the participants involved.

The company that provides an application is called the operator (OP). One thing to know is that an operator installs their own Canton private deployment, which creates a subnetwork for their own service. This deployment consists of two primary components that the operator manages:

  1. A Validator Node: The operator's own validator is where the application's core smart contract logic and its data live. This validator is technically no different from any other participant's validator.
  2. A Private Synchronizer: The operator also runs a synchronizer (or Synchronization Domain) for their subnetwork. This component acts as a private, secure "traffic controller," ordering the encrypted transactions that occur between the participants of that specific application.
Source Source

By running both a validator and a synchronizer, the application operator creates and controls a self-contained, private environment for their service. They are then responsible for allowing the validators of their users (customers) to connect to this private synchronizer to participate in the application.

The Nodes: Canton's Distributed Foundation

Whereas many blockchains have all nodes doing essentially the same thing, the Canton Network is constructed based on a complicated architecture of custom nodes collaborating. Understanding their distinct roles is key to grasping how the network provides both privacy and connectivity.

Validators (Participant Nodes): Private Gateway to the Network

If an application is like a secure, private office, a Validator is the front door and filing cabinet for that office. It's the central component that a user or institution uses to connect to a network, acting as their own entrance to storing information and completing transactions.

Each Validator is responsible for validating transactions only for the users and on-chain identities (Parties) that it hosts. This is a core part of the "proof-of-stakeholder" model, which ensures that a user's private data is never broadcast to uninvolved participants on the network. Because a user's data lives on a specific Validator, these nodes are stateful. This means that to read a user's private data, an application must connect directly to the validator that hosts them, as there is no single, universal endpoint to see all private data on the network.

An institution can self-host its own Participants Nodes, use a third-party Node-as-a-Service (NaaS) provider, or use a validator managed by their application operator. Validators receive an incentive to participate in the form of payment for their work in Canton Coin (CC), including activity rewards for staying on the network and rewards based on the share of network usage they provide.

Super Validators: Guardians of the Public Network

If Validators are the private gateways for individual participants, Super Validators (SVs) are the trusted, known organizations that act as the collective guardians of the public network infrastructure. They do not run private applications, instead, their primary responsibility is to operate and maintain the Global Synchronizer, the decentralized service that enables interoperability across the entire Canton ecosystem.

Their most critical function is to provide a secure sequencing service. When participants from different, independent subnetworks need to conduct a transaction, their validators send encrypted messages to the Global Synchronizer. The Super Validators then mutually agree, through a Byzantine Fault Tolerant (BFT) consensus protocol, on the exact timestamp and order of the messages before transmitting them to the corresponding parties. This process lies at the heart of supporting atomic, cross-domain transactions. During all of this, the Super Validators are unable to view contents of private transactions being ordered by them, so interoperability never leaks confidentiality.

Apart from sequencing, a Super Validator's responsibility also encompasses the general health and administration of the public network. They also validate all transfers of the local network utility token, Canton Coin (CC), operate key network utilities like the Name Service, and participate in the on-chain governance guiding development of the Global Synchronizer. As a way of ensuring their interests are aligned for long-term success of a network, Super Validators are motivated by having the privilege of minting Canton Coin (CC) as a reward for securing and running a core infrastructure.

The "Network of Networks": Understanding Domains and Subnetworks

The Canton Network is designed on the foundation of Synchronization Domains and subnetworks. A subnetwork is essentially a private instance of a Canton deployment, formed as a collection of validators that all plug into one, common, shared Synchronization Domain. It is then a self-contained, exclusive environment that is reserved solely for that group's activity, and has the benefit, among other things, such as increased privacy, control, and exclusive scalability.

Source Source

The synchronizer (or Synchronization Domain) acts as the traffic controller for its subnetwork. Its primary job is to provide a routing and ordering service for the end-to-end encrypted messages that pass between validators. It keeps the validators "in sync" by assigning a timestamp to each transaction, but it does not validate them and cannot see their contents.

While creating private subnetworks is excellent for control, it can lead to "independent islands" or "data silos" that cannot easily interact. This is where the Global Synchronizer comes in. It acts as the public backbone that ties all these varied private subnetworks together.  When a transaction needs to involve participants from different subnetworks, their validators can all temporarily connect to the Global Synchronizer to settle the transaction atomically, all while preserving privacy.

The Flow of a Transaction: From Private Subnets to the Global Network

The interaction between Validators, Super Validators, and Applications comes to life when we follow a transaction. The process depends on the scenario either the transaction is local, that is, lying inside one particular subnetwork of one application, or the transaction should link separate, independent applications.

Scenario 1: A Transaction Within a Single Private Subnetwork

Imagine a private application for tokenizing real-world assets, operated by a single entity (the "OP"). Within this subnetwork, all participating institutions connect their validators to a single, private synchronizer managed by the application operator.

When one institution wants to transfer a tokenized asset to another, the process is entirely contained within this private environment. The transaction begins when a command is submitted via the sender's validator API. The validation then follows the "proof-of-stakeholder" model, where only the validators of the sender and the receiver are involved in checking their respective parts of the deal. Once they confirm the details, they send encrypted messages to the private synchronizer. The synchronizer, acting as a neutral traffic controller, assigns a timestamp and puts the messages in the correct order without ever seeing the content of the trade. After the ordered messages are received, the involved validators commit the transaction to their respective ledgers, completing the transfer securely and privately.

Scenario 2: A Complex, Cross-Application Atomic Transaction

The true power of Canton's architecture is revealed when a transaction needs to span multiple, independent applications. Consider a Delivery vs. Payment trade involving three separate services: an Asset Tokenization app, a Digital Cash app, and a Trading app.

In this scenario, the buyer, seller, and the three application operators are all stakeholders who must participate in the final settlement. The challenge is that they all operate on different, independent subnetworks, each with its own synchronizer. There is no single private synchronizer that connects all five parties.

Source Source

To solve this, the validators of all five parties dynamically switch from their private synchronizers to the public Global Synchronizer for this specific transaction. The Global Synchronizer is managed by the Super Validators, who then carry out the key sequencing function.  They get the encrypted transaction messages from all the five parties and through a secure BFT protocol reach agreement on the correct order, ensuring the entire DvP is treated as one single, atomic operation.

Even when using this public infrastructure, privacy is preserved. The Super Validators running the Global Synchronizer do not get to view the transaction details (the particular asset, the price, nor the parties' identities) because they are just sequencing encrypted packages. Once the Global Synchronizer has ordered the transaction, the five validators seal the result on their private ledgers, atomically settling the trade. They can then go back to the use of their private synchronizers on other tasks.

This two-tier setup - private subnetworks for isolated activity and a worldwide, public backbone for interconnectivity - is what enables Canton to offer the privacy of a private chain as well as the connectivity of a public one.

Security and Error Handling in the Network

The Canton Network integrates resilience into the foundation, employing a distributed framework in which synchronizers and validators work autonomously. This design prevents single points of failure, meaning the system can keep running when separate elements have problems.

For instance, timeouts are enforced network-wide to prevent indefinite waits, ensuring decisions are made within bounded times. Flexible confirmation policies let participants trade off between integrity and availability: options like VIP (trusted party) or full confirmation adapt to different risk levels.

Fault tolerance is achieved through mechanisms like contract locking during validation, which detects and rejects conflicting transactions early. The Global Synchronizer, run by super validators, incorporates BFT consensus for ordering, tolerating some faulty nodes without compromising sequence integrity.

The Daml SDK and the Canton runtime let all errors be reliably classified to guide responses, ranging from transient failures to security notifications that need operator action.  All errors carry a unique code, a tracing correlation ID, and machine-readable information for automation. For example, contention errors prompt quick retries, while internal violations alert operators without exposing sensitive data. In the worst cases, like mismatches that could represent malice, the system logs full information for audits and gives clients limited information, securing data integrity.

Conclusion

The Canton Network's design is a powerful combination of public and private infrastructure. Validators provide secure, stateful gateways for users within private subnetworks, while Super Validators operate the Global Synchronizer as a neutral public backbone that connects these independent environments.  It is all held together by an economic model that incentivizes all participants - infrastructure operators, as well as application builders - based on the utility that they contribute towards the network. The result is a reliable foundation with aligned incentives, designed for the next generation of institutional finance.

The information provided by DAIC, including but not limited to research, analysis, data, or other content, is offered solely for informational purposes and does not constitute investment advice, financial advice, trading advice, or any other type of advice. DAIC does not recommend the purchase, sale, or holding of any cryptocurrency or other investment.