Is there any material providing more details on the consensus protocol in Canton? I’ve looked at the Canton Network whitepaper but it would be good to have a bit more detail on how transactions are initiated and committed, and how consensus is achieved along with sub-transaction privacy. Thanks!
2 Likes
I can provide a link to an internal presentation:
Recording:
There are further pointers at the end of the presentation.
Thanks for this question, Ian.
We use the term “proof of stakeholder” to highlight the most distinctive aspect of the Canton consensus protocol: all the stakeholders to a transaction validate it, but no one else in the network sees its content. Canton’s privacy model guarantees that only the stakeholders ever see the input or output state of the transaction, and allows them to all validate each transaction in which they have a stake. This contrasts to “proof of work”, for example, where a transaction is committed once a validator (miner) has proven that it has done the necessary work to earn the rewards for committing a transaction.
The Canton consensus mechanism works in two stages. First, the stakeholders for the transaction select a Canton synchronization domain (“sync domain”) to sequence the transaction and provide a two-phase commit guarantee. Second, once the transaction passes through the synchronization domain, all stakeholders to the transaction execute and validate it. The two-phase commit ensures that all the participants in the transaction will receive the transaction in the same sequence, and that they all commit it; if the required stakeholders don’t confirm that they are ready to commit, the transaction will roll back.
The sync domain can be a high-throughput, centralized service if all the stakeholders trust a single operator to run it. Or, if the stakeholders prefer a trustless approach, they can route the transaction to a decentralized sync domain that uses BFT consensus to provide the necessary guarantees.
A stakeholder authorized as a Submitter in the smart contract logic signs each transaction; the participant node encrypts it and sends it to the requested sync domain. The sync domain sequences the transaction without seeing its content. It routes the transaction to the Canton participant nodes hosting the stakeholders, collects confirmations that the participant nodes are ready to commit, and then tells the nodes to commit synchronously. If a stakeholder rejects the transaction or does not respond soon enough, the transaction will roll back.
Each participant node then executes the transaction by decrypting it, calculating the results, modifying contract data and updating the UTXOs for the stakeholders involved. The participant node then exposes this to the appropriate stakeholders hosted on that node. (For the highest level of security and privacy, each stakeholder should operate its own Canton Participant node.)
This produces a common state seen only by the stakeholders to that transaction. In effect the stakeholders have created their own blockchain subnet on the fly, and they can continue to transact on that data with full consistency and privacy within that stakeholder group.
To provide an even higher guarantee of consistency the stakeholders can send cryptographic proofs, called “Active Contract State Commitments”, to all the stakeholders in their group, confirming that they committed the transaction and produced the same resulting UTXO state. This higher guarantee makes it possible for different stakeholders to use different types of databases to store their state: in the rare case that one of those databases contained an algorithmic flaw that led to slightly different results, commitment proofs would reveal the flaw and allow the difference to be resolved. Commitment proofs even allow stakeholders to prune the history of their subnet, since commitments provide high confidence that the stakeholders share the current state in common.
Notice the important difference between these stakeholder groups and other blockchain subnets: Canton provides true interoperability with atomicity and rollback among all stakeholder subnets as an integral part of the protocol.
Here’s how Canton makes full, atomic cross-subnet integration possible:
First, each transaction includes the identities of all its stakeholders
All transaction inputs, both data and functions, are encrypted such that only the stakeholders in a given stakeholder group can decrypt and execute them.
A single transaction can include sub-transactions that each involve different groups of stakeholders. This means that a single atomic transaction can span multiple stakeholder subnets.
The Canton sync domain synchronizes the entire transaction across all the stakeholder subnets without observing its content, and the participant nodes roll the entire transaction back if it fails.
Each stakeholder subnet, for each sub-transaction inside this larger atomic transaction, sees only the inputs and results for which they have the appropriate keys.
I hope this helps illustrate why we sometimes use the term “proof of stakeholder” to refer to the Canton consensus protocol:
Each transaction is committed only when all required stakeholders to the transaction have validated it.
The stakeholders to a given transaction agree on which sync domain to use to provide a guarantee of ordering and two-phase commit
The Canton participant nodes hosting the stakeholders execute the transaction atomically, in a common order.
The nodes produce hashes of the UTXO state shared among the transaction’s stakeholders. Only those stakeholders have access to this shared state, and all stakeholders can prove that they participated in the transaction and achieved the same result.
4 Likes