The whole point of blockchains is to enable multiparty transactions and workflow. One of blockchain’s promises is to provide a shared ledger to reduce the numerous technical integrations needed between different business partners. However, as blockchain networks have proliferated, each network has become relatively siloed, requiring integration between them, often in a bespoke manner.
Hyperledger Cactus aims to provide a singular framework to enable each of the networks to interoperate. It’s a low code, standardized integration.
At launch it supports most of the major enterprise blockchains including Hyperledger’s Besu, Fabric, Indy, Iroha and Sawtooth, as well as Quorum and Corda. I also provides for public blockchains through the Go-Ethereum client and Xdai.
Interoperability or integration?
Interoperability is thought of as transferring tokens between networks on public blockchains, invariably as atomic swaps. This is just one subset of the functionality that Cactus supports. If you think of an atomic swap, each token stays on its native blockchain. If you and I swap ETH for Solana, then ETH remains on the Ethereum blockchain, but ownership transfers from you to me. The asset doesn’t move across chains.
When we chatted with the Cactus team in May 2020, there was an emphasis on blockchain ‘integration’ versus interoperability. “Some people define interoperability as strictly token or asset based transfers between DLT networks,” said Accenture’s Michael Klein. “And so to avoid the over-use of the term interoperability, we went with the more general term because it (Cactus) can be used for more purposes.” There are two broad additional purposes.
Companies might want to transfer an asset from one ledger to the other, as in moving it. That could involve locking or burning a token on one blockchain and recreating it on another. An example could be NFTs minted on one particular network, and a decision is made to migrate to a different platform. We’re aware of several examples of this migration in the past.
Many enterprise blockchain applications emphasize workflow, which is more about sharing data between blockchains rather than assets and is particularly important for supply chains. This is another kind of integration that Cactus supports.
From a user perspective, Cactus provides a set of APIs. It describes itself as an SDK of SDKS which means that the unique features of the underlying blockchains are accessible for interoperability. However, Cactus can’t magically plaster over these differences.
For example, transactions are considered final in almost real-time on many enterprise blockchains, whereas for Bitcoin, it’s more or less final after an hour. So if Bitcoin is integrated with an enterprise blockchain for settlement purposes, that delayed finality impacts the enterprise blockchain side.
In terms of architecture, some interoperability solutions rely on a central chain with the individual blockchains operating as sidechains, such as the Polkadot public blockchain.
Cactus instead relies on validator nodes for each individual blockchain. The validator nodes for one blockchain interact with those for another blockchain. It describes these as similar to trusted third parties. However, there could be multiple validators for each blockchain. The more validators, the less trust is required, and at some level of decentralization, it’s potentially trustless.
Other interoperability solutions
Cactus is just one of four interoperability projects under the Hyperledger umbrella. We’ve previously written about a Hyperledger Labs project YUI initiated by Datachain. Japanese card payment company JCB is exploring its use. There’s also the Weaver Labs project started by IBM and the in-production project Firefly, which is more of an orchestration framework than just about interoperability.
Outside of Hyperledger, the options include SETL’s PORTL, Digital Assets DAML, and Overledger. The well known public blockchains focused on interoperability are Polkadot and Cosmos, and YUI is a derivative of Cosmos.