Different blockchains support different characteristics (e.g., throughput, scalability, availability, consistency) that may make them suitable for specific dapps. [Koens 2019] review identified 12 characteristics to compare Cross Chain Technologies (CCTs), but [Kannageisser 2020]’s review considered 43 characteristics. Blockchain design tradeoffs limits the optimization of different blockchains ensuring that no one design meets all characteristics at the same time. Hence more powerful dapps will need transactions that cross blockchains. [Koens 2019] distinguishes blockchain interoperability in the following categories: (1) Interoperability between two smart contracts within a single blockchain (e.g. between Corda apps, which are smart contracts on a single Corda ledger); (2) Interoperability between blockchain platforms (e.g., between Bitcoin and Ethereum or Corda); (3) Interoperability between a blockchain and legacy systems. (e.g., between Ethereum and a traditional banking payment system). Cross chain technology (CCT) helps to achieve interoperability by enabling data exchange between blockchain designs or with external systems.
There are a number of use cases for transactions operating between blockchains. [Buterin 2016] identified Portable assets (tokens), Payment-versus-payment or payment-versus-delivery, Cross-chain oracles, Asset encumbrance and General cross-chain contracts. More recently [Kannengeisser 2020] identified four use cases for cross chain technology: asset transfers, asset exchanges, cross-chain oracles, and cross-chain smart contracts. In asset transfers, assets are moved from one distributed ledger to another. Asset exchanges (a special form of asset transfer), allow users to spend assets of one blockchain in return of assets from another distributed ledger (e.g., trading of cryptocurrencies or other assets). Rather than moving assets, cross-chain oracles, in contrast, provide information from one distributed ledger to another. Cross-chain smart contracts describe the ability to trigger the execution of a smart contract on another distributed ledger, which can increase the level of automation. The literature identifies other use cases, but [Kannengeisser 2016] argues these are combinations of the previously presented use cases (e.g., sharding can be assigned to the cross-chain oracle use case). The table below summarizes these use cases. Assets are distinguished from other data because they represent some notion of value e.g. a token. Asset transfers and exchanges may imply some notion of token portability as desirable- recall that tokens have some common behaviors not just a data type, and token portability would require those behaviors to be executable in the context of both blockchains.
[Buterin 2016] Identifies three main design patterns for blockchain interoperation: notary schemes, where a (trusted) party or a group of parties agree to carry out an action on chain B when some event on chain A takes place; Sidechains/relays, systems inside of one blockchain that can validate and read events and/or state in other blockchains); Hash-locking (setting up operations on chain A and chain B that have the same trigger, usually the revelation of the preimage of a particular hash). [ISO 2019] provides some consideration of information transfer between blockchains, but only considers cross chain and side chain transactions. [Kannegeisser 2020]’s structured review identified three distinct patterns: manual asset exchange (MAE), notary schemes, and relays, as well as a fourth, hybrid pattern, which includes the three distinct patterns. [Kannegeisser 2020] considered hash locking to be applicable in all of the identified patterns.
Blockchains have been around for about 10 years, but it has been the emphasis on smart contracts over the last 5 years that has raised increased the interest in alternative crosschain arrangements to support a broader range of applications beyond cryptocurrency trading. In this environment, the academic literature is reacting to new commercial and open source development activities and trying to balance that with more traditional academic studies. [Koens], for example, discusses the cosmos and polkadot interoperability solutions that they felt were commonly deployed. [Kannengeisser 2020] focused more on published literature but in a structured review process its not easy to capture information sources not in academic literature. Despite the importance of CCTs to a number of proposed applications for smart contracts, they remain a potential weak spot in the trust chain and may have other performance issues. Consensus protocols on one blockchain already limit computational throughput for smart contracts.
Transactions requiring consensus across multiple blockchains will likely suffer further performance degradations. From the perspective of blockchain as a database, transactions on that database should be “atomic” i.e., they either completely succeed or roll back to the prior state with no change made. For transactions across blockchains the mechanisms of both blockchains assuring atomicity have to be satisfied (see e.g., [Herlihy 2018]). While traditional databases commonly provide mechanisms for atomicity, the distributed nature of blockchains also creates other challenges for transactions around determinism and idempotency (see e.g., [Demir 2019]. Single point interconnection mechanisms avoid these issues, created others as the single points must be trusted and may be susceptible to failure. Blockchain consensus mechanism are deterministic in the sense that honest nodes achieve the same results from all nodes, but if the distributed nodes obtain inconsistent off-chain data (e.g., due to a time varying source read at different times) this inconsistent data can cause the consensus mechanism to fail because all the honest nodes will no longer reach the same result. Transactions are idempotent if repeatedly invoking the same transaction does not change the result. With the distributed nodes of a blockchain all generating output transactions to impact external systems, those external systems need to react in an idempotent manner to avoid inadvertently repeating a transaction. Note that this applies to external systems that are not blockchains as well. This may be problematic for legacy systems that were not designed to accommodate multiple attempts to invoke the same transaction. This is also problematic for cross-chain smart contracts that invoke control of cyber-physical systems where a single controller paradigm is common. This is not to suggest that such problems are insoluble, but rather there is some tradeoff in computing resources required (e.g., additional state, communication etc.), and the design patterns for such solutions may not be ones that many software developers are familiar with.
References
[Buterin 2016] V. Buterin, “ Chain Interoperability”, Sept 9th 2016
[Demir 2019] M. Demir, et al. “Security Smells in Smart Contracts.” 19th Int’l Conf. on Software Quality, Reliability and Security Companion (QRS-C). IEEE, 2019.
[Herlihy 2018] M. Herlihy,”Atomic cross-chain swaps.” Proceedings of the 2018 ACM Symposium on Principles of Distributed Computing. ACM, 2018.
[ISO 2019] ISO/TR 23455:2019(en), “Blockchain and distributed ledger technologies — Overview of and interactions between smart contracts in blockchain and distributed ledger technology systems”
[Kannengeisser 2020] N. Kannengießer, et. al. ,”Bridges Between Islands: Cross-Chain Technology for Distributed Ledger Technology.” 53rd Hawaii International Conference on System Sciences. Vol. 2020. 2020.
[Koens 2019] T. Koens, & E. Poll. “Assessing interoperability solutions for distributed ledgers.” Pervasive and Mobile Computing 59 (2019): 101079.