Understand the classification and summary of cross chain related technologies

Recently I looked at cross chain related projects , Summarize the related technologies across the chain . So-called “ Cross link ”, On a chain “ Cross link ” Semantics can be executed correctly on another chain . At present, cross chain projects mainly realize the mapping of assets in one chain to another chain . From a technical point of view , Personally, I think there are three main cross chain technologies ：HTLC, Cross chain bridge （ Based on consensus ） And cross chain bridges （ Based on light client ）. The relevant technologies and projects are summarized in the figure below ：

1.HTLC（Hash Time Lock Contract）

HTLC The principle is simple ：

If Alice and Tom Want to exchange assets ,Alice First create HTLC,Tom Then create a file with the same Hash Of HTLC. To put it simply ,Tom and Alice Created... With the same secret key “ lock ”, Lock their assets . When Alice Open... With a secret key Tom Assets ,Tom With the same secret key, you can open Alice The assets of the . Of course ,Tom and Alice Both need to confirm the time of assets and locks .

adopt HTLC Realize cross chain , It is simple and ensures the atomic operation of both sides of the transaction , However, both chains are required to support smart contracts , It defines two trading parties and the assets exchanged are indivisible . in fact , In order to ensure the effective transaction of both parties , Both parties need additional communication channels to reach a consensus in advance .

2. Cross chain bridge ： Based on consensus

The cross chain bridge based on other consensus is logically easy to implement , Confirm events on a chain by consensus , And execute on another chain . The safety of the whole bridge depends on the strength of consensus . Consensus , In addition to the traditional consensus mechanism （BFT,PoS wait ） Outside , It also includes multiparty Computing （MPC） And multi sign .

3. Cross chain bridge ： Based on light client

In order to verify the information on one chain , On this chain “ function ” Another chain of light clients . Usually light clients are based on SPV（Simple Payment Verification） agreement .SPV Derived from BTC, Mainly used in PoW In the chain of consensus .Celo and Harmony It also implements light client for its own chain consensus algorithm . Pure PoS The consensus chain is difficult to realize light client , Because consensus depends on Staking, and Staking Consisting of transactions . In order to achieve light client , Exhausting Staking The deal is unrealistic .

Two chains across the chain bridge verify the status of each other's chains through the light client . This cross chain bridge depends on Relay（ relay ）, Timely synchronize the block header information of the chain . Because you want to synchronize the block head , Some of the following factors are needed ：

1. Synchronization frequency and cost ： Storing block header information on another chain costs . especially tps Higher chains , There are many blocks .

2. Confirm the main chain and block ： According to the consensus of the chain , Determine the main chain through the block header information . With PoW Take the chain of , Block confirmation is generally confirmed by the number of subsequent blocks .

There are several ways to optimize synchronization costs ：1/ Random challenge （NiPoPOW,FlyClient）2/ zk-SNARK （ Include recursive zk-SNARK）. Choose some typical Introduction ：

BTCRelay

Use traditional SPV The implementation of light client is from BTC To ETH Cross chain . Obviously, in order to synchronize BTC The block of , stay ETH Consume Gas. In Ethereum Gas price When it's higher , Synchronization costs are relatively high .

FlyClient

FlyClient Use random challenges and MMR（Merkle Mountain Range) Technology , Reduce the number of light client synchronization blocks . The purpose of random challenge is that all blocks in a certain range do not need to be synchronized to the chain , Randomly extract some blocks for synchronization . In order to verify the blocks not extracted on the chain , All block information passes MMR Organize together .MMR It's a variant of Merkle Trees , Applicable to the scene with additional nodes .MMR, Compared with ordinary binary Merkle Trees , It has the characteristics of low cost of updating leaf nodes .

zkRelay

zkRelay We also try to reduce the cost of synchronizing blocks with light clients on the chain . and FlyClient Different ,zkRelay It's using zk-SNARK prove . The validity of blocks within a range , By submitting the off chain proof to the on Chain , The chain only needs to check whether the certificate is valid .

Celo

Celo It's an interesting project .Celo The project itself has nothing to do with cross chain , But it provides some new ideas for light clients . In order to achieve lighter client ,Celo Using recursive zero knowledge proof technology , Recursively prove the connection information of the block header . A proof can prove the legitimacy from the creation block to the current block . A light node , Just synchronize the latest proof to determine the validity of all blocks .

Summa (Stateless SPV)

The above items , They are also optimized in reducing the cost of synchronization on the light client chain .Summa It provides a new idea ：

Extract from Summa To introduce the PPT.Summa The project observed an interesting fact ： The block heads of one chain are synchronized on the other chain , But many blocks can be wasteful . The reason is that there are no transactions to prove in these blocks .Summa Suppose there's a “Ecnomic“ Safe practices ： Prove that a transaction is in a block , And several blocks are confirmed after the block .Summa It is considered that it is very uneconomical to continuously produce blocks after forged blocks , With such computational power, we should calculate the real block . In this way , There is no need to store light node information on the chain , It is only necessary to provide proof of the corresponding block and confirmation block when a transaction needs proof . This way is also called Stateless SPV（ No state SPV）. Of course, this assumption of economic security needs to be deliberated , Especially when the difficulty is low , It is relatively easy to forge blocks and confirm blocks .

Xclaim

For the traditional chain without computing power on the chain , 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 realized on these chains . In order to realize two-way cross chain on these chains ,Xclaim When the mortgage role is introduced, the two-way mapping of assets is realized .Xclaim Three operations are proposed in this paper ：issue（ issue ）,swap（ In exchange for ）,redeem（ redeem ）. With issue and redeem For example , Look at the role of mortgage ：

Most chains support the transfer function . The mortgagor acts as an intermediary , In another chain （ Support for smart contracts ） With collateral , Accept transfers of funds from others . The originator of the transfer , You can prove the legitimacy of the transaction on another chain by means of light client authentication . On another chain , After verifying the legal cross chain transaction , Transfer money .

Put forward in a chain burn After the operation , After the mortgagor observed , Initiate the transfer first . And after the transfer is successful , Provide proof of transaction to smart contracts on another chain “ redeem ” Money . To put it simply , On the basis that only one of the two chains supports smart contracts , Through the role of mortgagor , Can complete two-way cross chain operation . The fundamental reason is that the transfer transaction on the chain can be confirmed and verified .

summary ：

Cross chain is a complex topic . It is relatively simple and realistic to realize cross chain through other consensus .HTLC It can realize the atomic operation of both sides of the transaction , But limit the transaction to two parties , Moreover, in order to provide transaction efficiency, both parties need to communicate in advance . Verifying the state of other chains by implementing light client on the chain is the direction of exploration . about PoW chain , To realize the light client on the chain, we need to consider the block header synchronization cost and the main chain confirmation logic .