1 Introduction of cross-chain bridge

Currently, various public blockchains with different types of assets and protocols have made it hard for them to communicate with each other directly, which brings a lot of inconvenience to users. For example, if a user holds bitcoin assets, but wants to invest or spend in the Ethereum ecosystem, the most direct way is to swap them through a centralized exchange. However, the process is cumbersome, time consuming, and requires multiple payments of fees.

The development of cross-chain technology makes it possible for users to interoperate between different blockchains (e.g., asset trading and information interaction), and the most widely used implementation is the cross-chain bridge. This article will first introduce cross-chain technology and related implementations, and in our next article, we will introduce the cross-chain bridge projects based on the above technology.

2 Interoperability of cross-chain

Interoperability of blockchain is a combination of Interaction, Operation and Ability. The interoperability of blockchain mainly includes three aspects: one is the interoperability for the application layer, which mainly solves the problem of tight coupling between the upper layer application and the underlying chain; the second is the interoperability between chains, which mainly solves the problem of “chain-level silos”; the third is the interoperability of data off the chain, which mainly solves the secure and trustworthy interaction of data off the chain. In this article, we mainly discuss blockchain interoperability in terms of cross-chain transactions, i.e., the interaction of assets and information between different blockchain systems.

Three interoperability techniques in blockchain will be described in detail below.

2.1 Notary mechanism

The notary mechanism is the simplest technically implementable cross-chain mechanism, which is essentially an intermediary approach. By introducing one or more trusted third parties, they continuously listen to the events on the chain and are responsible for verifying and forwarding cross-chain messages on other chains based on the information obtained from the events. There are three main ways to implement the notary mechanism.

1. Single-signature notary schemes

The simplest notary mechanism. This approach selects an independent node or institution to act as a third-party notary. The notary performs tasks such as data collection, verification, and transaction confirmation throughout the cross-chain interaction. This approach is highly-compatibility and fast in transaction speed, but its use is limited to scenarios such as cross-chain asset swapping.

2. Multi-signature notary schemes

In this approach, the notary is a group of independent nodes or a federation of institutions with a key for each node, and the transaction is valid only when a certain percentage of notaries sign on the cross-chain transaction to reach consensus.

This approach weakens the centralization risk of single-signature notary mechanism and has higher security, even if some nodes are maliciously attacked, it will not affect the operation of the whole cross-chain system.

3. Distributed-signature notary schemes

This approach uses MPC multiparty computation to ensure the security and privacy of the key compared to the multi-signature notary mechanism. The key is split into multiple pieces and randomly distributed to the notary, but the complete key cannot be derived from these pieces, and the complete key can be assembled only when a certain percentage of notaries sign together.

2.2 Hash-locking

Hash-locking is known as hash timelock contract, which uses the one-way nature of hash function and low collision, through hash lock and time lock to complete the cross-chain technology of asset exchange between different chains without a trusted third party as a notary. Among them, the hash time lock requires the receiver to confirm the receipt and generate the proof to the sender within the specified deadline, otherwise the funds will be returned. The sender can use the proof of receipt to access the receiver’s funds on the target chain or trigger related events.

This approach ensures that the total amount of assets on the same chain remains unchanged, but it can usually only be used for transfer operations. The following is an implementation of atomic exchange based on hash-locking in the Lightning Network.

1) User A generates a random number s and calculates its hash value H(s).

2) Sending the value of H(s) to user B on another chain through the network.

3) user A sets a time lock t1 and uses H(s) to lock the BTC in the script of the chain he is in, which restricts access to the locked BTC to only those users who can provide the value of s.

4) User B on another chain, after confirming the above transaction on the chain where A is located, similarly sets time lock t2 (t2 < t1) on the chain where he is located, and at the same time uses the received H(s) to lock his BTC in the script of that chain.

5) User A sends the value of s to user B’s script at time t2.

6) After the contract verification of user B is passed, the locked BTC is sent to user A, and the s value is obtained at the same time. At this point, if the transaction exceeds the t2 time limit, the cross-chain transaction will fail and both parties will get back the assets to be swapped.

7) User B will send the obtained s-value to User A’s script within t1 time limit. After its verification is passed, the script sends the locked BTC to user B. If the timeout also makes the cross-chain transaction fail.

2.3 Side chain/ Relays

Side chains and relays are the most commonly used cross-chain mechanisms, both of which can parse and verify the main chain blocks and ledger data by collecting information from the original chain. However, there are several differences between the two: firstly, side chains are subordinate to the main chain, focusing on improving the scalability of the main chain, invisible to the main chain and usually sharing the native tokens on the original chain, while relays have no subordination and focus on cross-chain data transmission; secondly, side chains need to synchronize all block heads when processing transactions, resulting in slower speed than relay chains; finally, the security mechanisms of side chains and main chains are independent of each other. That is, sidechains have their own consensus protocols, which are usually designed for specific types of transactions, meaning that they usually do not inherit the security properties of the main chain, and when using a sidechain, users will lose custody of their funds and rely only on the security of the sidechain. Relays, on the other hand, rely on the main chain for authentication.

Relay is essentially a cross-chain operation layer abstracted from each main chain, which is a convergence and extension of the notary and sidechain mechanisms. The main role is to act as a communication hub to collect data and forward messages between different blockchains, applicable to heterogeneous or homogeneous blockchains.

The basic technique of sidechain implementation is Two-way Peg. The cross-chain process is actually locking a token asset on one chain while generating another token asset on another chain. The two-way peg technology is to solve the problem of how the target chain determines that the token asset has been securely locked during the cross-chain process. BTC-Relay, considered the first sidechain on the blockchain, allows users to verify bitcoin transactions on Ethereum by embedding the Bitcoin SPV function in a smart contract.

The technology can currently be implemented through the single-custody model, consortium model, drive chain model, and SPV model.

1. Single-custody model

The simplest way to implement. The basic principle is the same as single-signature notary. Locking and verifying the release of sidechain assets is achieved through a notary.

2. Consortium model

The basic principle is the same as multi-signature notary, and the risk of centralization is reduced by using multiple signatures in the above way.

3. Drive chain model

In this model, the transaction processing node acts as a notary, and is responsible for the custody and unlocking of funds. The specific process is: the transaction processing node submits the asset lock information from other chains to the block and initiates a draft, and after voting and confirmation, the specified asset is unlocked in the current chain.

4. SPV (Simple Payment Verification) model

The main chain and the side chain verify whether the assets are securely locked by SPV. The following is an example of the concrete implementation of this mode in BTC-Relay.

1) User A sends tokens to a specified address on the main chain that contains sidechain information to lock the main chain assets.

2) Waiting for a confirmation period to allow the above transaction to be confirmed after the consensus of the main chain.

3) The user submits a minting transaction and the SPV proof of the corresponding main chain asset locking transaction in the side chain, and the side chain block verifies the validity of the above transaction according to the SPV proof, and after the verification is passed, the side chain will mint the token but the asset is in the locked state.

4) Waiting for a period of competition, the purpose of which is to ensure that the asset is completely locked, so as to prevent double-spending attacks. For example, waiting for the number of verifications of the SPV block head to be greater than 6.

5) The sidechain unlocks, allowing it to circulate freely on the sidechain.

3 Cross-chain interoperability protocols

3.1 Asset swap

Blockchain is usually divided into the following four ways when transferring assets across chains: the first way is lock and mint, which will lock assets on the original chain and mint the corresponding assets on the target chain; the second way is burn and mint, which will burn assets on the original chain and mint assets on the target chain; the third way is atomic swap, which will exchange assets on the original chain directly to assets on the target chain with no trust required, so it does not need a trusted third party in the first two approaches; the fourth approach is liquidity swap, which will create a pool of liquidity funds on different chains, where users can exchange assets directly from the pool to the original assets on another chain, and in addition the liquidity provider can also fund the liquidity by providing tokens. Typical asset swapping protocols are Plasma, Rollup, etc., which will be described in detail below.

3.1.1 Plasma

Plasma contains a series of smart contracts running on the blockchain, enabling cross-chain interaction by indirectly interacting with the sidechain. It can create unlimited branches of child blockchains that are smaller copies of the main Ethereum chain with their own consensus mechanisms. The bandwidth required for calculations and transaction data is performed on the sidechain, and only transaction results are periodically posted to the main chain. Each child blockchain relies on the security of the “proof of fraud system”, which can be challenged by anyone.

Plasma is actually not a project per se, but a framework. There are various implementations of Plasma MVP, a sidechain based on the UTXO model, which uses the POA consensus algorithm, i.e., there is only one operator involved in the consensus. In terms of business type, the project only supports transfers, and there are two kinds of scenarios: Deposit and Withdrawal/Exit, which will be introduced separately as follows.

1. Deposit

1) The user initiates a Deposit call transaction to send a certain amount of ETH or ERC20 tokens to the main chain Plasma smart contract, and a DepositCreated event is generated after the transaction is successfully executed.

2) Operator monitors the event and generates a block containing only one transaction. This transaction is created for the user by the contract calling the deposit() function to create the sidechain asset Creat (DepositCreated,amount).

3) The transaction created on the sidechain contains two input UTXOs and two output UTXOs. At the time of deposit, only the first output UTXO is not 0, and all other values are 0, as follows.

4) Operator sends the merkel root of the block to the main chain contract, which generates the BlockSubmitted event.

5) The user monitors the event, verifies its validity and the deposit is successful.

2. Withdrawal/Exit

1) The user initiates an Exit transaction to the Plasma contract on the main chain, which contains some necessary parameters to specify the location and legitimacy of the UTXO to be withdrawn: the block number (h) where the UTXO to be withdrawn is located, the transaction number (Tindex) within the block, the UTXO number (Uindex) in the transaction, and other parameters that identify the location of the target UTXO, as well as information a series of transaction confirmation signatures and other information. In addition, a margin EXIT_BOND is also provided.

2) The transaction is placed in a priority queue, and the priority is calculated according to the following formula.

The reason for calculating the priority to determine the order of withdrawal according to this formula is to ensure that all previous UTXOs can be safely exited in the event of a malicious transaction, i.e. the old UTXO is always withdrawn before the new UTXO.

3) Exit transactions need to wait for a challenge period before they take effect, as fast as 7 days and as slow as 14 days.

In an Exit transaction, a dispute challengeExit is initiated if another user finds malicious behavior in the applicant. The dispute requires a valid Merkle proof of the UTXO dispute subject. If the dispute is successfully verified, the disputed object’s transaction will be removed from the queue and the margin will be awarded to the user who initiated the dispute.

Since Operator is responsible for packaging blocks to the main chain, it can monitor all transactions on the sidechain, and the presence of certain malicious actions on it will lead to serious consequences, such as double-spending attacks.

To address this, Plasma also has a number of designs in place to avoid these situations during withdrawals/exits. The first is the priority queue mentioned above, whose main purpose is to ensure the safety of users’ funds in the event of a malicious transaction. This priority is determined by the above formula, firstly by the order of the blocks, secondly by the order of the transactions in a single block, and finally by the balance in the transaction, while the above three values uniquely determine the position of a UTXO. Thus the above priority formula ensures that old transactions have higher priority than new ones, which means that if an incorrect transaction (e.g., double-spending attack) is added to the block, then all transactions before the incorrect transaction are executed first and then the incorrect transaction is executed last, which will make the double-spending attack fail.

But there is the possibility that Operator can intentionally package the wrong transaction before the user’s transaction, and for this case there are actually two signatures in Plasma’s transactions. The first is that when a user initiates a transaction, the transaction itself is signed and then sent to Operator for packaging. The second is that when the transaction is added to the block, the user signs it again, which is called a “confirmation signature”. If the user follows this rule correctly, the user will never issue a confirmation signature until the transaction is packaged by Operator, i.e. Operator cannot write illegal transactions before the user’s transaction.

Problems with Plasma.

1) Each user must monitor and verify all transactions across the Plasma MVP chain to guard against malicious transactions and exit in a timely manner. But validation is costly and increases on-chain overhead.

2) Data availability problem: If the Operator of the side chain only publishes the block header and refuses to publish the transaction data off the chain, this will make it impossible for the main chain to verify the correctness of the side chain.

3) The withdrawal/exit operations take a long time and must wait until the end of the challenge period.

3.1.2 Rollup

The difference between Rollup and Plasma is that Plasma puts both data and computation off-chain, but this approach suffers from the availability of data off-chain. To address this issue, Rollup only moves the computation (and state storage) off-chain, but keeps some of the data for each transaction on-chain. Specifically, the solution aggregates hundreds of off-chain transactions into a single batch, executes the transactions on the sidechain in batches, and then “packages” the finalized transactions and releases them to the main chain in batches, thereby increasing the transaction speed of the main chain. This way of storing data on the chain allows anyone to perform all the operations in Rollup locally, allowing them to perform functions such as fraud verification, initiate withdrawals, and even package their own transactions.

A smart contract exists on the Rollup main chain to maintain a root node of the state tree, the node data includes: account balance, contract code, etc., but the state tree itself is not stored inside the contract, the tree is generated by the side chain every once in a while through the transaction and execution results of the data, as shown in the following figure.

A batch of transactions consists of a highly compressed set of transactions, along with the previous state root and the new state root (the new state root generated after the execution of the batch). The contract will check whether the previous state root in the batch matches the current state root and, if so, will switch to the new state root, as follows.

In response to the question of who can submit batches, Rollup has the following options.

1) Anyone can submit, which is the simplest one. However, due to the existence of multiple participants, if batch transactions are published in parallel, this process of generating proofs or posting batch transactions to the chain can result in excessive overhead.

2) Centralized sequencer: Currently the most common method, a single centralized sequencer submits batches of transactions.

3) Sequencer auction: The highest bidder is entitled to become a sequencer by means of an auction.

(4) PoS voting: Anyone can deposit specified tokens into the Rollup contract, and then one of the depositors in each batch of transactions can be randomly selected as a sequencer. The probability of selection is proportional to the number of tokens deposited, and the disadvantage of this method is that it leads to a large amount of unnecessary funds being locked.

DPoS voting: The sequencer selected in the auction, if there are bad operations such as offline or packaged malicious transactions, token holders can vote to kick them out and hold a new auction to re-select the sequencer.

A problem in Rollup is how to determine the correctness of the post-state root in a batch, because if a forged post-state root is submitted without any cost, then an attacker can forge that data to make all tokens available to himself. Rollup currently has two typical solutions for this problem, ZK-rollups and Optimistic-rollups.

Optimistic-rollups use proof of fraud, where the Rollup contract keeps track of the entire history of the state root and the hash value of each batch of transactions. If someone finds that the post-state root of a batch is incorrect, they can generate a fraud proof to post to the contract, and if the contract validates it, it will restore that batch and all subsequent batches. Typical projects are Arbitrum, Optimism; ZK-rollups, on the other hand, use proofs of validity, and each batch contains a cryptographic proof of ZK-SNARK, which proves that the post-state root is the result of a correct execution.

3.2 Information Interaction

3.2.1 Polkadot

Polkadot is a heterogeneous multi-chain platform supporting multiple blockchains, enabling de-trusted interactions between multiple blockchains, with three types of chains in its architecture.

The first one is Relay chain, which is located at the core of Polkadot, mainly used for forwarding cross-chain transactions generated on each parallel chain, recording the transaction status of each parallel chain, and transmitting the verification and execution results of transactions, and BFT(byzantine fault tolerance) is adopted to provide unified consensus and security for the whole system. The chain itself does not contain any transactions, but is only responsible for the top-level cross-chain transaction routing, and DApps are developed and deployed on the parallel chain.

The second is the parallel chain (Parachain), which is only responsible for the development and deployment of DApp applications in specific business scenarios, each existing in parallel, and developers can choose the blockchain system underlying the parallel chain based on the problems in specific application scenarios. Its chain itself does not have block consensus, and its security is provided by the validator of the relay chain through Polkadot’s shared security model.

The third is the bridge chain, a cross-chain structure specially designed for heterogeneous chain development. For example, when Ethereum needs to interact with Polkadot relay chain, Ethereum data needs to first go through the bridge chain in the Ethereum underlying system to normalize the cross-chain information before it can be converted to the form needed for Polkadot network interaction. The chain has its own consensus algorithm and is connected to Polkadot through different Bridges for interaction.

At its core, this is achieved by providing a relay chain that stores all information about all other chains connected to the relay chain in the form of blockchain data from each independently operating parallel chain connected to the relay chain. There are four types of participants in the network, including Validator, Collector, Fisherman, and Nominator.

Validator: has the highest authority and is mainly responsible for the block output of Polkado network. By running a relay chain client, it verifies the blocks output of each nominated parallel chain during each block generation round of the whole network. When the blocks of each parallel chain have been identified by its validator, the validator assembles all parallel chain block heads into relay chain blocks and performs consensus blocking.

Collector: helps the validator to collect the necessary transaction information in each parallel chain, package and execute the relevant transactions, and then attach a zero-knowledge proof to the result of the executed transactions and submit it to the validator of that parallel chain.

Fisherman: Not directly involved in the process of block packaging. The fisherman can get the reward benefit by reporting the illegal behavior of a staked participant and providing a valid proof with signature. Illegal acts include the signature of a validator on two different blocks with the same parent, or the verification of an invalid block on a parallel chain.

Nominator: is a group of people who have an interest, and the validator is elected by the nominator. After the nominator chooses the validator, it can maintain the entire Polkadot network on its behalf by staking its own interest to the validator, in such a way that the nominator and the validator can receive the same proportion of rewards and penalties.

Each parallel chain has two message queues, an output queue engress and an input queue ingress. The process of cross-chain transactions between parallel chain A and parallel chain B in Polkadot is as follows.

1) Chain A stores the cross-chain transactions into its own output queue engress.

2) Collator of chain A collects normal and cross-chain transactions of chain A and submits them to the Validator collection of chain A.

3) After the Validator collection of chain A validates successfully, it submits the current block header information and the information in engress to the relay chain.

4) After the relay chain confirms the block and the cross-chain transaction routing using the consensus algorithm, the Validator on the relay chain submits the corresponding transaction of chain A from the engress queue of chain A to the ingress queue on chain B.

5) Chain B executes the block and the transactions in the ingress queue and modifies its own ledger.

Since the consensus of all parallel chains happens synchronously, there will be no security issues such as double-spending for cross-chain transactions.

3.2.2 Cosmos

Cosmos and Polkadot are similar in that they both relay cross-chain messages through a relay chain to create a heterogeneous cross-chain platform, but there are some differences between them. Firstly, there are two roles in the Cosmos network: Hub and Zone, where Hub is a relay chain used to handle cross-chain interactions and Zone is a parallel chain in Cosmos. There are different Hubs in the Cosmos ecosystem as central hubs, and each central hub can be connected to its own partitioned Zone, while different Hubs can also be connected to each other. The network architecture is as follows.

To support cross-chain operations between parallel chains, Cosmos proposes an inter-blockchain communication protocol (IBC) and uses the immediate determinism of the tendermint consensus algorithm to achieve value and data transfer between multiple heterogeneous chains. Therefore, parallel chains in Cosmos need to satisfy the following two prerequisites.

1) Fast finality: guaranteed by consensus algorithms, i.e. Cosmos’ cross-chain does not support blockchains with probabilistic determination models such as PoW.

2) Strong sovereignty: each parallel chain possesses a set of validators to decide its outgoing blocks. If probabilistic chains (e.g., Ethereum) are to be connected, additional structural support is required.

Other heterogeneous chains outside the Cosmos network system need to pass a Bridge-Zone transfer layer to access the Hub, which is used to relay cross-chain transactions in heterogeneous chains and normalize the data structure in the cross-chain transaction information, specifically including: confirmation of the original chain transaction, generating or burning of the corresponding tokens in the Cosmos network, etc. The following is an example of transferring assets from Ethereum to Cosmos network to introduce the cross-chain communication process of Cosmos Bridge: Firstly, a Bridge contract needs to be deployed on Ethereum, which is responsible for the processing of cross-chain transactions and contains specific interaction rules. If users need to transfer to Cosmos network, they need to send ETH to the Bridge contract to lock it first, but if the cross-chain transaction fails, the system can fall back to the pre-transaction state. Or when the Bridge contract monitors Cosmos for cross-chain transactions transferring assets to Ethereum, then the contract will automatically unlock the corresponding assets. The Bridge contract keeps track of the status of the Zone validators and can share a set of validators with the Hub. The process of transferring Cosmos-ETH to Ethereum is similar, but it burns Cosmos-ETH and unlocks the corresponding asset in the Bridge contract. The process will burn Cosmos-ETH and unlock the corresponding ETH in the Bridge contract and transfer it to an account address.

The messaging between each network Hub in Cosmos and the partitioned Zone where the Hub is located uses the IBC protocol, and when a new Zone is created, a vote by the online governance community determines whether the new Zone can be connected to the Hub, so Cosmos also supports blockchain scaling. The cross-chain messaging between different Zones is shown in the following diagram.

First Zone1 sends a BlockCommit transaction to the Hub, containing the header information of the block and the public keys of all the validators; then if Zone1 tries to initiate a token transfer transaction to Zone3, Zone1 first verifies the legitimacy of the transaction, and if it is valid, sends the transaction to its own output queue and waits to send it to the Hub. The transaction information includes: the initiator Zone, the height of the transaction confirmed in the Zone and the target Zone; next, the relay program in Zone1 generates a Merkle proof based on the transaction in the message queue and sends it to the Hub as a payload in the Packet; the validator in the Hub verifies the proof by SPV verification, and if the verification passes, it sends a message to Zone3. After receiving the cross-chain transaction from the Hub, Zone3 first verifies whether the transaction is a real and valid transaction initiated by Zone1 and sends a confirmation message to the Hub that it can receive the asset from Zone1; finally, the Hub sends a message to Zone3 to send the asset to Zone3. Then a complete cross-chain transaction is completed.

Summary

We have introduced three common cross-chain interoperability technologies, including notary mechanism, hash-locking, and sidechain/relay. In our next article we will introduce the cross-chain bridge projects implemented based on the above three cross-chain technologies.

References

1. http://www.infocomm-journal.com/wlw/article/2020/2096-3750/2096-3750-4-2-00035.shtml

2. https://blocking.net/25385/technical-guide-a-brief-study-of-cross-chain-communication/

3. https://vitalik.ca/general/2021/01/05/rollup.html

4. https://www.alchemy.com/overviews/optimistic-rollups

5. https://wiki.polkadot.network/docs/learn-security#shared-security

6. https://www.alchemy.com/overviews/sidechains-vs-layer2s

Contact

If you have need any blockchain security services, please contact us:

Website Email Official Twitter Alert Telegram LinkedIn