The Canton Network: A Comprehensive Guide

Digital Asset recently announced its plan to launch the Canton Network, which is anticipated to become a network of networks, based on the Daml smart contract platform and the Canton synchronization protocol. The announcement already contains a list of partners which plan to use and/or take part in the operation of the network, including (but not limited to) BNP Paribas, Capgemini, Deloitte, Goldman Sachs, and Microsoft.

Seeds of the Canton Network already exist: as they write, “as of early 2023, financial institutions transact over $50 billion daily on limited-access subnets of the Canton Network”. Canton Network participants are expected to begin testing interoperability capabilities across a range of applications and use cases in July.

In parallel with the announcement and launching of the Canton Network web site, Digital Asset has published a white paper under the title “Canton Network: A Network of Networks for Smart Contract Applications”. 

The white paper covers three topics:

1. An evaluation of some “current smart contract networks” in terms of privacy and scalability, as a justification of the value of the Canton Network.

2. A compact summary of basic, Daml and Canton related concepts already explained in depth in the Daml/Canton documentation. Additionally, an explanation is provided how the Daml ledger model is an essential enabler of decentralization and scalability.

3. A description of the Canton Network.

In this blog post, we will mainly focus on the third topic. The reason for this choice is that 1) the exposition of the first topic is a bit limited and serves as an explanation of the general thinking of the creators of Daml and Canton: they wanted to create a blockchain solution which has better privacy and scalability properties than its competitors 2) the second topic serves as a reminder of concepts which are probably familiar to many of Halborn readers (although we recommend reading also these sections because of the connections between the Daml ledger model vs decentralization and scalability). For the presentation of the third (and a little bit of the second) topic, we will highlight some key terms which in their general meaning are probably familiar to many readers, and explain what they mean in the current context.

A Network of Networks

The most famous “network of networks” is the Internet: it was born from connecting local computer networks. For those readers who are interested in the enterprise blockchain solutions, the Corda network can also come to mind: it is positioned as “a publicly-available internet of Corda nodes operated by network participants”.

In the context of the Canton Network concept, “network of networks” means the following: 

A simple Canton network consists of potentially multiple participant nodes and a sync domain. The participant nodes act on behalf of ledger parties. The sync domain is basically a message queue between the participants, also providing sequencing and time stamping service. 

Operators of participant nodes already currently can interact with other participant nodes if they connect to one or more common sync domains. Participants can choose which sync domain they want to use, and switch sync domains during operation.

The network of networks will be different from the collection of isolated private networks by the existence of at least one permissionless virtual (distributed) sync domain, operated by a group of independent companies called Super Validator Collective (or SVC). The SVC will charge a fee to the users of the sync domain. Other companies can also operate private or public sync domains and charge a fee for their usage.

A Permissionless Network

In general, a permissionless blockchain network like Bitcoin or Ethereum is such that anyone can join as a “miner”. In the context of the Canton Network, “permissionless network” means that anyone can operate private or public sync domains and charge a fee for their usage.

Application Composition

“Composition” here refers to the mathematical concept of function composition, namely performing an operation on the result of a previous operation. In the procedural programming paradigm, where side effects are not accounted for in the type system, function composition is problematic. The functional programming paradigm fixes this handicap so that side effects (like a ledger update in the case of Canton) and the atomic composition of functions with side effects is accounted for in the monad type class. That’s why it’s convenient that Daml is a functional programming language.

For the Daml ledger model, application composition is possible because the ledger stores an append-only array of transaction graphs (more specifically transaction trees). The graphs refer to their dependencies and contain their consequences or sub-transactions as sub-graphs. Each party sees and validates only the subtransactions they are stakeholder to, but each party’s ledger view is a valid ledger in itself. Atomic transaction composition is achieved by the fact that a transaction graph as a whole is either appended to the ledger or not, so it cannot happen that a transaction with multiple legs is committed partially.

In the context of the Canton Network, application composition means that Canton guarantees the atomicity of cross-subnet transactions, with the limitation that Canton allows cross-subnet transactions only whenever there exists at least one sync domain to which all transaction participants are connected.

Application composition makes it possible for parties to create higher-order workflows, including atomic transactions across multiple applications, processed via a sync domain selected by the applications.

Proof-of-Stakeholder Consensus

In the blockchain world, there are several “proof-of-X” consensus mechanisms used like proof-of-work in Bitcoin or proof-of-stake in Ethereum. The Canton consensus protocol is called proof-of-stakeholder consensus. It seems that the goal here was to come up with an expression which is at the same time similar and different from the other “proof-of-X” expressions. The “proof-of-stakeholder” part can be interpreted so that every compound transaction is jointly validated by the stakeholders of its sub-transactions.

The Canton consensus protocol consists of two layers. The first layer of the consensus is a two-phase commit protocol that replicates each contract to the contract’s stakeholders in a similar way to the atomic commit protocols of sharded databases. (This is different from Bitcoin or Ethereum where the whole network state is replicated at every node.) The second consensus layer is a sequencing protocol which assigns a timestamp to every transaction request in order to establish the order of conflicting requests. (Timestamp here doesn’t mean an absolute time, but refers to a vector clock, which is used in distributed systems to establish consistent ordering.)

Byzantine Fault Tolerant (BFT) Consensus

BFT consensus in general means that in a distributed system the consistency of broadcasted messages can be guaranteed even if some of the participants are malicious.

In the context of Canton Network, BFT means that in the case of a virtual CSP’s distributed sync domain, this sequencing protocol runs as a replicated state machine secured by a Byzantine Fault Tolerant (BFT) consensus algorithm. Thus, the virtual CSP determines a total order on transaction requests within a sync domain, and transaction processing is deterministic.

UTXO

The expression UTXO (unspent transaction output) comes from Bitcoin. It refers to the fact that “coin” is an abstraction. What the Bitcoin ledger actually stores is creation and spend events. Value is represented by creation events for which no spend event was recorded yet. 

In the context of Canton and the Canton Network, UTXO is used as a metaphor, referring to the fact that “active contract” and the Active Contract Set (ACS) is an abstraction. What the ledger actually stores is events which are either creation events or exercise events (consuming or non-consuming) on existing creation events. An “active contract” is a creation event for which no consuming exercise event was recorded on the ledger yet. The main difference between Canton and Bitcoin is that in Canton an exercise event can be non-consuming, so preserving (not “spending”) its underlying creation event.

If you’d like to learn more about Daml and Canton, check out our Introduction to Daml and Canton, our article on Workflow Compositions with Daml Applications, and our article on Daml and Canton’s Security. And stay tuned, there is more to come! Upcoming topics we will be publishing about shortly include:

• How to interact with a Daml/Canton ledger from the outside?

• The benefits and challenges of learning Daml