Canton Domain - Are we really solving blockchains interoperability here?

As we know, Canton Domain offers ledger synchronization and total ordered mutlicast. The Canton Domain can be set up as a trusted vs un-trusted way of architecture. So in a trusted setup, we can use SQL DB, and in an un-trusted, we use the Blockchain/DLT for ledger synchronization and total order multicast.

Q1. Using Canton Domain with SQL DB has a single point of failure. So does the Canton offers ways to make it fault-tolerant synchronization using BFT/RAFT algorithm?

Q2. With Canton Domain on Blockchain (Corda DLT, HL Fabric, Ethereum, etc) are we really achieving interoperability?
When we say interoperability, for example, I should be able to design an atomic transaction that uses a Token issued on DAML Ledger to settle transactions on another Blockchain. But I don’t think Canton Domain on Blockchain is solving this problem. However, it is just making Canton Domain fault-tolerant.

Please throw light on the above two questions.

2 Likes

Hi @balajimore , welcome to the Daml forums. Those are both great questions.

First, we have to distinguish between general consensus protocols like Paxos and RAFT, and Byzantine Fault Tolerance (BFT).
Paxos and RAFT solve for consensus in distributed, but trusted environments. They solve for crash availability/partitioning fault tolerance of the type “make sure my system still operates as long as three out of five servers are operational and connected to each other”. They do not tolerate malicious participants.
BFT algorithms try to solve for the latter. In a BFT consensus protocol like PBFT, you can tolerate nodes that proactively try to subvert the system. They solve the problem “make sure my system still operates correctly as long as three out of five servers honest (and available and connected)”.

So to answer Q1: Using Canton with SQL DB support highly available settings based on a HA deployment of PostgreSQL or Oracle, which removes the single point of failure in terms of crash fault tolerance. Using RAFT instead of a HA database would not change the security properties of the system and barely affect the fault-tolerance.

Achieving Byzantine Fault Tolerance is the point of the blockchain drivers for Fabric, Besu, etc. To make Canton fully Byzantine Fault Tolerant (which is still in the works, there are limitations and centralised components still), Canton needs to tun its own synchronisation protocol over a BFT network and consensus layer. We do that by accessing those consensus layers through fully integrated blockchain platforms.

The interoperability offered is that Daml applications can interoperate with each other across different synchronisation backends. Ie you can have transactions that involve both IBFT 2.0 on Besu and Fabric’s own consensus on the other side. You can think of that as “consensus interoperability” maybe?

What you are talking about - making a Solidity ERC-20 token transact with a Daml-native asset is indeed something else. I might call that “application interoperability”. Since “Blockchain” is a pretty broad term, “Blockchain Interoperability” ends up meaning a lot of different things to a lot of different people. The third thing I’ve seen that term applied to is what I would call “API interoperability” - abstraction layers that make different Blockchains’ functionality available through a single API.

4 Likes

Thanks @bernhard for details.

Certainly ‘Canton Domain’ enables the Consensus Interoperability or plug-able consensus). Sometime is quite true with other DLT like RE Corda.

However, in which context the HA Domain and RAFT would not have any change in privacy? I think this only possible when there is right strategy in place to ensure democratic selection of participants/cluster node. Please shade a light!