An article to understand the classification and summary of cross-chain related technologies
I recently looked at cross-chain related projects and summarized cross-chain related technologies. The so-called “cross-chain”, the semantics of “cross-chain” on one chain can be correctly executed on another chain. At present, cross-chain projects mainly realize the mapping of assets on one chain to another chain. From a technical point of view, I personally think that there are three main types of cross-chain technologies at present: HTLC, cross-chain bridge (based on consensus) and cross-chain bridge (based on light client). The related technologies and projects are summarized as follows:
1.HTLC（Hash Time Lock Contract）
The principle of HTLC is relatively simple:
If Alice and Tom want to exchange assets, Alice first creates an HTLC, and Tom then creates an HTLC with the same Hash. Simply put, Tom and Alice created a “lock” with the same secret key to lock their assets. When Alice uses the secret key to open Tom’s assets, Tom can use the same secret key to open Alice’s assets. Of course, both Tom and Alice need to confirm the assets and lock time.
The realization of cross-chain through HTLC is simple and guarantees the atomic operation of both parties of the transaction, but it is required that both chains support smart contracts, which limits the two parties to the transaction and the assets exchanged are indivisible. In fact, in order to ensure effective transactions between the two parties, the two parties need additional communication channels to reach a consensus in advance.
2. Cross-chain bridge: based on consensus
Cross-chain bridges based on other consensuses are logically implemented better. The consensus confirms events on one chain and executes them on another chain. The security of the entire bridge depends on the strength of the consensus. Consensus, in addition to the traditional consensus mechanism (BFT, PoS, etc.), also includes multi-party computing (MPC) and multi-signature.
3. Cross-chain bridge: based on light client
In order to verify the information on the other chain on one chain, the light client of the other chain is “run” on this chain. Usually light clients are based on the SPV (Simple Payment Verification) protocol. SPV is derived from BTC and is mainly used in the PoW consensus chain. Celo and Harmony have also implemented light clients based on their own chain’s consensus algorithm. A pure PoS consensus chain is more difficult to implement light clients, because consensus relies on staking, and staking consists of transactions. In order to realize light clients, exhaustive staking transactions are unrealistic.
The two chains of the cross-chain bridge verify the status of each other’s chain through the light client. This kind of cross-chain bridge relies on Relay to synchronize the block header information of the chain in time. Because to synchronize the block header, some factors are required as follows:
1. Synchronization frequency and cost: There is a cost to store block header information on another chain. Especially chains with higher tps have more blocks.
2. Confirm the main chain and block confirmation: According to the consensus of the chain, the main chain is determined by the block header information. Taking the PoW chain as an example, block confirmation is generally confirmed by the number of subsequent blocks.
There are several ideas for optimizing synchronization fees: 1/random challenge (NiPoPOW, FlyClient) 2/zk-SNARK (including recursive zk-SNARK). Choose some typical introductions:
The traditional SPV light client implementation method is adopted to realize the cross-chain from BTC to ETH. Obviously, in order to synchronize the block header of BTC, Gas is consumed in ETH. When the Ethereum Gas price is relatively high, the synchronization fee is relatively high.
FlyClient uses random challenge and MMR (Merkle Mountain Range) technology to reduce the number of light client synchronization blocks. The purpose of the random challenge is that all blocks in a certain range do not need to be synchronized to the chain, and some blocks are randomly selected to be synchronized. In order to verify the blocks that are not extracted on the chain, all block information is organized through MMR. MMR is a variant of Merkle tree, suitable for scenarios where nodes are added. MMR, compared with the ordinary binary Merkle tree, has the characteristics of low cost of updating leaf nodes.
zkRelay also tries to reduce the cost of synchronizing blocks for light clients on the chain. Unlike FlyClient, zkRelay uses zk-SNARK proof. The validity of a block within a range is submitted to the chain by the off-chain proof, and the chain only needs to check whether the proof is valid.
Celo is an interesting project. The Celo project itself has nothing to do with cross-chain, but it provides some new ideas for light clients. In order to achieve a lighter client, Celo uses recursive zero-knowledge proof technology to recursively prove the connection information of the block header. One proof can prove the legitimacy from the genesis block to the current block. A light node only needs to synchronize the latest proof to determine the validity of all blocks.
Summa (Stateless SPV)
The above-mentioned projects are also optimized in terms of reducing the cost of synchronization on the light client chain. Summa provides a new idea:
Excerpted from the PPT introduced by Summa. The Summa project observed an interesting fact: the block header of one chain is synchronized on the other chain, but many blocks may be wasted. The reason is that there are no transactions that need to be proven in these blocks. Summa assumes an “Ecnomic” security approach: Prove that a transaction is in a block, and there are several block confirmations after the block. Summa believes that it is very uneconomical to continuously generate blocks after forged blocks. With such computing power, the real blocks should be calculated. In this way, there is no need to store light node information on the chain, but only need to provide the corresponding block and the proof of confirming the block when a transaction needs to be proved. This method is also called Stateless SPV (Stateless SPV). Of course, this kind of economic security assumption needs to be considered, especially in the case of low difficulty, it is relatively easy to forge a block and confirm a block.
For traditional chains without on-chain computing power, it is impossible to implement light clients of other chains on the chain. In other words, if only through the light client on the chain, only one-way cross-chain can be achieved on these chains. In order to achieve two-way cross-chain on these chains, Xclaim implements two-way asset mapping with the introduction of a mortgage role. Xclaim proposed three operations in the paper: issue (issue), swap (exchange), redeem (redeem). Take issue and redeem as examples to see the role of mortgage:
Most chains support the transfer function. The mortgagor acts as an intermediary and accepts transfers of other people’s funds when another chain (supporting smart contracts) is secured. The transfer initiator can prove the legality of the transaction on another chain by means of light client verification. On the other chain, after verifying the legal cross-chain transaction, the transfer is performed.
After the burn operation is proposed on a chain, the mortgager observes it and initiates the transfer first. And after the transfer is successful, provide a proof of transaction to the smart contract on the other chain to “redempt” the funds. Simply put, on the basis of only one of the two chains supporting smart contracts, through the role of the mortgager, two-way cross-chain operations can be completed. The fundamental reason is that the transfer transaction on the chain can be confirmed and verified.
Cross-chain is a complicated topic. It is relatively simple and realistic to achieve cross-chain through other consensus. HTLC can realize the atomic operation of the two parties of the transaction, but the transaction is limited to two parties, and in order to provide the efficiency of the transaction, the two parties need to communicate in advance. Verifying the state of other chains by implementing light clients on the chain is a direction that has been explored. For the PoW chain, the realization of light clients on the chain needs to consider the cost of block header synchronization and the main chain confirmation logic.
Posted by:CoinYuppie，Reprinted with attribution to:https://coinyuppie.com/an-article-to-understand-the-classification-and-summary-of-cross-chain-related-technologies/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.