Key concepts of Canton Network applications

The sections below define the key concepts that the rest of the documentation builds on.

App providers, app users, and end-users

An app provider is an organization or business entity that operates a Canton Network application for the benefit of its users. Often the app provider also develops the application. App providers typically operate software of their own.

An app user is an organization or business entity that uses a Canton Network application.

An end-user is a human that interacts in the name of an app user organization or business entity with a Canton Network application. A typical example is an employee trading in the name of a company.

For retail applications, the concept of an app user coincides with the one of an end-user. That is not the case for enterprise applications, which is why we distinguish the two concepts to avoid confusion.

Canton Network infrastructure

Canton Network applications are built on top of the Canton Network infrastructure, which manages the state of the Canton ledger and its change log. That infrastructure consists of the following two kinds of nodes:

Validator Nodes

store the shard of the Canton ledger that they are entitled to see and validate Daml transactions affecting that shard. See the Operate sub-site for the documentation of validator nodes.

Synchronizer Nodes

are used by validator nodes to coordinate the commits of transactions affecting their shards so that no double-spends happen and all transactions are valid. See the Subnet sub-site for the documentation of synchronizer nodes.

The Global Synchronizer is a synchronizer that is implemented in a decentralized fashion. Most validator nodes on the Canton Network can be assumed to be connected to the Global Synchronizer, which makes it a good default for executing transactions that span multiple Canton Network applications. The documentation for the Global Synchronizer is maintained on https://docs.sync.global/.

Daml parties

Access to Canton ledger data is managed at the granularity of Daml parties, which are best viewed as identifiers for cryptographic keys that remain stable even when keys are rolled.

Daml parties are hosted on Validator Nodes, which store their data and validate transactions affecting that data. Validator Nodes broadcast information about which Daml parties they host via the Synchronizer Nodes to which they are connected.

App providers and app users are assumed to have at least one Daml party under their control, which represents them towards other app users of Canton Network applications. They may operate the Validator Node hosting their Daml party themselves, or they may host their party on a third-party validator node that they trust with data confidentiality and transaction validation.

Frontends, backends, and Daml models

Canton Network applications follow a similar architecture as web applications or enterprise services. They provide frontends for end-users to interact with the application. They provide backends to manage access to ledger data, integrate with off-ledger systems, and automate on-ledger workflows. They might additionally provide Daml models, which define the on-ledger data schema and workflows that app users use to interact with each other as part of the application’s business processes. See Canton Network application architecture design considerations to learn about design considerations for these components.

Note that not every Canton Network application requires building and operating all of these components. Use the guides in System design to help you with deciding which ones to build.