To achieve interoperability across heterogeneous blockchain, several techniques have been developed. Here, we will present three technical solutions for cross-chain transactions, analyze their characteristics and discuss their potential risks. These three solutions are the notary, hash-time lock, and relay model.
The Notary Model
The most intuitive approach for achieving interoperability across chains is to set a trusted third party, such as a notary, to coordinate the cross-chain operations by being responsible for the verification and forwarding of cross-chain transactions. Two types of notaries may be used; a single-signature notary or a multi-signature notary.
A single-signature notary, also known as a centralized notary, collects transaction data from the source chain, validates it and initiates the execution of the transaction on the target chain. It is a simple model with high processing speed. However, its disadvantage is its vulnerability to the failure or misbehavior of a single node.
With a multi-signature notary, a cross-chain request, initiated by ‘Account A’ in ‘Blockchain 1’ needs to be successfully verified by the majority of notaries. Once verified, the signatures are published on the corresponding transaction to be executed on ‘Blockchain 2’. In order to tolerate Byzantine faults, the cross-chain transactions can be processed only if more than two-thirds of notaries achieve consensus and sign the transaction.
Blockchain 2.0 has provided, for the first time, a reliable decentralized execution environment for smart contracts that automate asset management under trustless conditions. Smart contracts are automated protocols controlled by code, providing read and write functions as user interfaces, and triggering specific operations based on the users’ transactions, that operate in a trustless environment.
The hash time lock model is a cross-chain technology deployed by smart contracts. The specific process is as follows:
- The initiator of the cross-chain transaction chooses a confidential random number S, then calculates the hash value h=Hash(S) of S and sends it to the responder of the cross-chain transaction
- The initiator and the responder lock their asset into the smart contract, with the intention of trading with one another across their respective blockchains. Both contracts are locked using the key h, while the key to unlock the assets is the random number S. The assets are locked into the smart contract for a time duration denoted by T1 and T2 respectively, where T1 must be greater than T2. Only the initiator and responder can unlock the respective assets using the random number S.
- The initiator unlocks the assets in the contract by announcing S within time T2. If the time exceeds the duration set by the initiator, the contract automatically returns the assets to the responder.
The hash time lock model effectively solves the trust problem inherent in the cross-chain process. As long as the initiator maintains confidentiality of the random number S and the time window, (T1 – T2) offers sufficient time for the responder to unlock the assets, both parties can realize a cross-chain transaction in a decentralized manner.
The Relay Model
The relay model for cross chain transactions is an abstraction of cross-chain operations where the data verification in the cross-chain process is abstracted into a consensus problem at the relay layer. A blockchain with improved scalability is developed on this abstraction layer and a third blockchain, the relay chain, then emerges for interoperability.
In the relay model, a series of relay nodes are deployed in each blockchain network, which are responsible for monitoring and synchronizing the transaction data of that blockchain to the relay chain. The consensus nodes of the relay chain verify the validity of cross-chain transactions and trigger the execution of the corresponding transactions.
- The figure and listed steps show a typical relay model cross-chain transaction
- The user initiates a cross-chain transaction request in the source chain
- The relay node monitors and synchronizes the transaction data to the relay chain
- The relay chain consensus node verifies the validity of the transaction
- The consensus node constructs the corresponding transaction
- A supermajority of consensus nodes signs the transaction, forming a signature set
- The relay node monitors the transactions and signatures
- The relay node carries the transaction to the target chain
The consensus mechanism of a relay chain determines the performance and security of the cross-chain service. Classic Byzantine fault-tolerant algorithms, such as PBFT, are able to achieve high throughput under the condition that the supermajority of nodes is correct. Improved versions of Byzantine fault-tolerant algorithms, such as HotStuff, further reduce the complexity of the communication and support a larger scale of nodes participating in consensus.
Relay chains are technically difficult to implement, as they require high levels of engineering complexity, however, they have advantages. Relay chains with smart contracts can form a cross-chain service network, with one relay chain communicating information between multiple blockchains, broadening the scope of value transfer. Poly Network is an example of a successful implementation of the cross-chain relay model.
The relay model realizes an abstraction layer for interoperability, allowing data between heterogeneous blockchains to be exchanged and validated securely. In the case of Poly Network, a relay-chain has been built for more efficient data exchange and validation. Beyond that, there is the possibility for native economies to bloom within Poly Network’s ecosystem thanks to its complete blockchain infrastructure.
Interoperability in Crypto
All three of the aforementioned cross-chain bridge solutions were developed to achieve interoperability across heterogeneous blockchains, which offers many benefits. These solutions have been implemented and have been proven to work. In addition to this, new iterations and continuous improvements are being made to these models.