Hi,
I have a few questions on Canton interoperability.
Q1. What type of Interoperability Canton provides? Does it support cross blockchain Interoperability like if we want to interact from Hyperledger Fabric to Corda Blockchain? If yes, can you please provide me with a sample code reference or example of a business use case where I can see that?
Q2. What are the different modes currently supported by Canton Interoperability. By modes I mean Asset Transfer, Data Transfer or a DvP exchange. Are this supported as of now in Canton? Or are this in the future scope? If these are supported can you please provide me a code example or a business use case where I can try out this things or if any theoretical example is available.
1 Like
I’m sure you will get more comprehensive answers than mine, this is just a general hint: Canton can use a limitrd number of other blockchains as storage layer, meaning storing encoded Daml ledger data as opaque blob. Afaik you cannot oob create common workflows using Daml and say Fabric smart contracts. Theoretically you can write bridge applications for this but in this case you have to have strong trust in the operator of such client applications.
Hi, Gyorgy
Your answer is right: there are no special Canton features for interoperability between Hyperledger and Corda, or between any other non-Canton blockchains. Customers can build bridges that are similar to any other cross-blockchain bridge, and as you note that bridge will typically have lower security and higher trust requirements than the blockchains it integrates.
One subtlety: the primary way you would use a non-Canton blockchain together with Canton would be to provide a sequence for the Canton transactions. As you note, the transactions are opaque encrypted blobs, so it’s not as meaningful to think of that layer as providing “storage” for Canton. It’s really more like a transitory storage to support transaction sequencing. In fact we think it’s a good idea to delete the history up to some point, since it has no value over time. The actual blockchain is stored on the Canton participant nodes, with each stakeholder group forming its own private blockchain, forming and sending proofs of consistency among the members of that stakeholder group. The power of Canton is that we can produce interoperability between those private blockchains by automatically forming new stakeholder groups while preserving atomicity and consistency guarantees.
2 Likes
Hi, Avartha
As Gyrogy has already correctly pointed out, Canton does not provide native interoperability between non-Canton blockchains.
To your second question: the Daml language, the Canton protocol, and the open Canton network can support all the modes you’re describing, and more. It is a generalized interoperability solution.
That means that any Daml application that uses Canton can define a counterparty and form a transaction that will atomically create, read, or update and archive data on two or more nodes at once. This will support asset transfer, data transfer, atomic delivery vs. payment, and any other multi-party workflow where different entities host the various nodes, and different organizations offer the assets.
So, for example, a mortgage originator could offer new mortgages using a Daml app they’ve built using a privately operated Canton sync domain, and give their customers the ability to run that app via their own Participant nodes, with the Daml templates executing both on the application provider’s node and the customer’s node simultaneously, to product identical state.
Then those customers, and the mortgage originator, could link their participant nodes to a second application provider that bundles and trades mortgages. Canton would allow them to write a Daml smart contract that would add a mortgage to a bundle and change its ownership to the purchaser of that new security, while automatically and atomically updating the participant node of both the mortgage originator and the original mortgage purchaser.
So by using Canton, two separate Daml applications (mortgage origination and mortgage bundling/securitization) become fully integrated.
3 Likes
Yes, thank you for highlighting this.
Hi Wayne & gyorgybalazsi,
Thanks for replying to the questions and really appreciate your time.
I was going through this article which mentions interoperability between HLF & Ethereum.
But according to your answer it seems it can’t be done.
Can you please put more highlight on this as this article seems to be 2-3 years old and provide us with some sample implementation of whether this can be done or not currently
Link to the article - Digital Asset Open Sources Daml Code for CBDC Interoperability - Daml
Hi, Atharva
We still support the cross-chain bridges described in the article. They’re not part of Canton; they’re separate messaging bridges that work like other cross-blockchain bridges. Customers can use one of the bridges we’ve constructed or (since Daml is open source) they can build their own.
The Canton protocol works quite differently from cross-blockchain bridges. In other ecosystems, like the Ethereum ecosystem, or Cosmos, or Avalance, or Polkadot, you only get messaging and maybe some asset transfers across them.
Canton provides full smart contract interoperability across separate chains built using Daml, and it preserves privacy while doing that. This is a fundamentally different level than you can achieve among other blockchains, including between Canton and non-Canton blockchains.
Another detail: separate from integration across blockchains via bridges, Canton can borrow the ordering consensus from various systems including Fabric and Besu (or from a simple relational database). That’s because Canton separates transaction ordering, which happens on sync domains, from transaction execution and validation, which happens on participant nodes.
Each network in the network of networks can choose its own sequencing service, but Daml to Daml interoperability via Canton is not affected. For example, a Daml contract that by default synchronized via Besu-backed sync domain can interact atomically with a Daml contract that by default synchronizes via a Fabric-backed sync domain, and one that synchronizes via a native Canton sync domain.