NewsFlash Articles Data Fundraising BlockBeats Pro

Cross-chain technology and application form panorama

Read this article in 90 Minutes

Paka Labs released a 4D report, how will cross-chain technology rewrite the situation of the divided blockchain world?

Original title: "Paka Labs 4D Report (1/4) | Connecting Islands Cheng Dalu: Panorama of Cross-chain Technology and Application Form"
Original author: MIDDLE.X, Paka Labs< /blockquote>
Original editor: Shawn Lin, 1PAR Research

1. Preface

Cross-chain technology is considered to be the holy grail in the blockchain field and the key technology to realize the interoperability of ten thousand chains. People often compare its importance to TCP/IP of the Internet. It is precisely because the TCP/IP protocol cluster provides a point-to-point link mechanism that standardizes how data should be packaged, addressed, transmitted, routed, and how to receive it at the destination, so that terminals around the world are connected into a network. evolved into what we know today as the Internet.

With the rapid development of the blockchain industry, various public chains and permissioned chains are emerging, and a hundred flowers are blooming. However, due to technical, ecological, competition and other reasons, the vast majority of chains cannot connect and communicate with each other, which has led to the fragmentation of users, assets, applications, and data, forming an "island effect". Fundamentally speaking, the main reasons for this situation are: the diversification of user needs and the limitation of blockchain scalability.

In order to connect isolated islands into continents, the industry has actively explored cross-chain technology. This article will explain and analyze the main technical forms of the current cross-chain, and give examples of typical blockchain projects currently dedicated to solving cross-chain problems. There are already many research reports on cross-chain, but this article will, on the basis of previous research, strive to go deep into the essence of technology, distinguish and analyze confusing concepts, grasp the context and framework, and include the latest developments.

2. What exactly does cross-chain need to cross?

2.1 Token Exchange

Each blockchain has its own native token. A token becomes a carrier of value because it encapsulates certain rights and interests. The certificates within the chain can be trusted for exchange, but the exchange of certificates between chains is "separate chains like mountains". Only by realizing the trusted exchange of certificates between chains can the important role of blockchain as the "Internet of Value" be realized.

currently via center The standardized trading platform can realize cross-chain token exchange, for example, recharge BTC to the trading platform, exchange it for ETH, and then withdraw it to the ETH wallet. But people are not satisfied with the centralized solution, and hope to conduct trusted exchanges directly on the chain. For example, user A wants to use BTC to exchange ETH held by user B. There will be problems in this process. If the two agree on the transaction , but after A makes the transfer, what should B do if B reneges on his promise? This requires the use of cross-chain technology. Through systematic matching, the two transfers can be carried out simultaneously. Atomic swap based on hash time lock is a typical technology to realize this scenario.

2.2 Token transfer

Token transfer refers to the circulation of native assets on one chain to another chain. This cannot be achieved directly, and any token can only be attached to its host chain. Generally speaking, pass-through is achieved by locking the original assets on the source chain, and at the same time issuing an equivalent amount of anchor assets that simulate the original assets on the target chain. How to ensure the safety and reliability of this process is a major challenge for cross-chain technology.

Token transfer Both blockchain and token exchange can solve the problem of inter-chain value exchange, but the two are not exactly the same thing. If A wants to exchange 1 BTC for B’s 10 ETH, this process only needs to realize the token exchange, but if A wants to use this 1 BTC on Ethereum, it needs to pass the token. In addition to solving the problem of value exchange, token transfer has additional utility. We can pass tokens to enable assets on chain A to participate in DeFi applications on chain B to build a more inclusive open finance. We can also transfer tokens from an expensive chain to an economic chain to save transaction costs , or transfer from a slow chain to a fast chain to achieve expansion, or transfer from a non-private chain to a private chain to achieve transaction privacy. It can be said that the problems that token transfer can solve are a superset of the problems that token exchange can solve.

2.3 Information Transmission

Cross-chain in the full sense should actually allow any message between chains to be transmitted reliably. Any cross-chain transaction is essentially a combination of a series of cross-chain message transfers. For example, token transfer, as a type of cross-chain transaction, is composed of two cross-chain message transfers, which are:

The source chain locks the pass, and will The locked position message and its proof are passed to the target chain;

The target link receives the information, verifies its authenticity, mints the mapping pass, and sends the receipt back to the source chain.

So we can say, Cross-chain information transfer includes cross-chain token transfer. The problem solved by cross-chain information transfer is a superset of cross-chain token transfer.

 
Through cross-chain information transmission, one chain can read and verify the other The status and information of a chain, the smart contract of a chain can use a certain status and information of other chains as a trigger for execution. Therefore, through cross-chain information transmission, rich cross-chain functions can be realized, such as cross-chain lending, cross-chain crowdfunding, cross-chain payment, cross-chain derivatives, cross-chain DAO, etc. If the blockchains can flexibly call each other's functions and use each other's services, then the chains will be combined into a huge service collaboration network to achieve our expected state of interconnection of ten thousand chains.

3. Overview of cross-chain technology

Current cross-chain technology forms, some only realize the exchange of tokens, such as hash time locks and cross-chain DEX; some forward messages by establishing a set of roles on the chain, For verification status, some propose a set of communication protocols to realize communication between blockchains; some propose new system architecture and chain-building protocols to support the access of more blockchains.

Because between the chain and the chain Independent of each other, no direct connection can be established, and the chains cannot directly perceive each other's state changes. Therefore, a communication bridge needs to be built. In terms of communication bridge selection, it is generally divided into five categories of technical forms, namely atomic swap based on hash time lock, witness, light node side chain, relay chain, shared validator, which will be expanded in sections 3.1-3.5 Narration:

3.1 Based on hash time Atomic exchange of locks

Hash time lock is a set of cryptographic methods, which can realize trustless cross-chain asset transactions. For example, if I use 1 BTC and your 10 ETH transaction, the atomicity of the transaction can be realized through the hash lock. The principle is roughly as follows:
User A generates a random password r, and calculates the hash value m=hash(r) of r, and converts the value of m Send to user B;

with At the same time, user A initiates a transaction to transfer 1 BTC to user B. The success of the transaction is conditional, and user B must present the password r to succeed. Otherwise, the transaction will automatically fail after the preset time;

After user B sees the transaction initiated by A , and also initiate a transaction to transfer 10 ETH to user A. The success of the transaction is also conditional. User A needs to show r to succeed. If the preset time is exceeded, the transaction will automatically fail. The key point here is that user B does not need to get the value of password r to create such a transaction with r as a success condition, but only needs to know the value of m to create it, and we know that hash operations are irreversible. Knowing m can't deduce r;

User A sees the transaction initiated by B, and presents the r value, making the transaction initiated by B successful, and obtains 10 ETH transferred by B, and the r value is disclosed;

User B also got the r value presented by A in the previous step, so that the transaction initiated by A If successful, get 1 BTC transferred by A.

Through the above mechanism, in two Transactions on different chains are coupled into one event, which can only succeed as a whole, or fail as a whole. It will not happen that the transfer from A to B succeeds, but the transfer from B to A fails, and vice versa.

This mechanism Realization depends on two technologies, that is, "conditional success transaction" and "conditional failure transaction". In the above case, the trigger condition for a successful transaction is to present the pre-hash image r, and the condition for a transaction failure is to exceed the preset time Without showing the hash preimage r, we can also call it hash lock and time lock respectively.

In BTC, the hash time lock can be realized through CLTV opcode or CSV opcode, and in Turing-complete chains such as Ethereum On the above, hash time locks can be implemented through smart contracts. In fact, smart contracts can implement far more diverse and complex conditional success transactions and conditional failure transactions than hash timelocks.

We can see that the hash time lock realizes the intermediary atomic transaction between the two parties across the chain, without any trust assumption. At the same time, we also realize that this transaction method is not user-friendly, which is mainly reflected in the following three aspects:

Both parties to the transaction must be online at the same time and strictly implement the participation process. Therefore, if the transaction initiator cannot be found An online counterparty must wait.

For BTC, creating a transaction with a hash time lock is completed by creating two transactions at the bottom layer. Due to the complexity of the underlying mechanism, it is simplified and expressed as one transaction in the transaction process mentioned above. If the transaction is successful, both transactions must be uploaded to the chain, and additional fees need to be paid.

In actual transactions, there will be exchange rate issues, and the counterparty can choose whether to complete the transaction according to whether the exchange rate is beneficial to itself. Especially when the amount is large, the counterparty has a strong incentive to do so, which may make atomic transactions unsuitable for large transactions.

In addition, in terms of cross-chain implementation, hash time lock has its limitations. It can only realize cross-chain atomic exchange of tokens, but cannot realize token transfer and wider cross-chain information transfer. Therefore, in In actual cross-chain applications, it is often used in combination with other cross-chain technologies.

3.2 Witness

Witness, English is Notary, sometimes translated as a notary, is a special role set up for the transmission of cross-chain information and custody of cross-chain assets. In 2012, Ripple released the InterLedge Protocol (ILP), which for the first time realized cross-chain transfers through third-party witnesses. Since then, the witness mechanism has been applied in many cross-chain projects mainly anchored by BTC.

Different cross-chain project pairs Witnesses have different settings: a witness may be a single subject, but in most cases it is multiple subjects; the generation of witnesses may be permissive or free access; in order to achieve asset cross-chain, The witness will have to manage an escrow account, and the method of managing the escrow account may be independent control or multi-party control; the user's trust base for the witness may come from the witness's own credit, or it may come from the witness's excess mortgage.

3.2.1 How witnesses are generated

The easiest way is to form a permissioned witness group, the members are basically fixed, and the joining and exit of members are reviewed and voted by the current members. This method is relatively centralized, and the more decentralized method is a free access method. Any subject can become a witness as long as it meets the established conditions, such as mortgaging the corresponding assets. Free access brings additional risk exposure, which may bring malicious witnesses, creating the risk of collusion. Therefore, some cross-chain protocols choose to add a random extraction mechanism: each operation is not signed by all witnesses, but a group of witnesses are randomly selected from the set of qualified witnesses. In this way, the number of witnesses can be increased. The cost of collusion.

3.2.2 User's Trust Basis for Witness

Witnesses can gain trust through over-collateralization, which means that the value of the witness’s mortgage must be greater than the value of the account assets in custody. Receive compensation in gold. Over-collateralization makes the assets managed by users extremely safe, but over-collateralization brings capital costs to witnesses, and the capital costs of witnesses will be converted into high cross-chain handling fees.

Witnesses also You can rely on your own goodwill to endorse. Although it contains trust assumptions, its advantage is that the cross-chain fee is low, and it can even be free, so it still attracts a large number of users.

3.2.3 Asset custody methods: independent control address and multi-party control address

The witnesses may each control an independent control address to form a custody address matrix to undertake the user's trusteeship. It should be noted that the independent control address is not necessarily a single-signature address. For security reasons, the witness may use multi-signature and private key fragmentation technology to manage the independent control address. For many companies, the address of the witness may be jointly managed by multiple executives or shareholders of the company through multi-signature and private key sharding. However, no matter what technology is used to manage addresses, as long as they are controlled by a single subject, we call them independently controlled addresses.

More In most cases, an escrow address is an address jointly controlled by multiple parties. It is possible that all witnesses jointly manage an address, or it is possible to divide the witnesses into groups, and each group jointly manages an address. In this case, multi-party control technologies such as multi-signature or private key sharding must be used.

3.2.3.1 Multi-signature

Multi-signature, or multi-signature, English is Muti-Sig, which is a technology in which multiple private keys jointly control an account. Multi-signature technology can realize that an address must be signed by M-of-N signers. Transfer, 1≤M≤N.

in BTC , the multi-signature address is a P2SH type address, the ordinary BTC address is obtained by hashing the public key, and the multi-signature address is based on the script hash. This type of address has a limit on the N value, N≤15; in Turing-complete blockchains such as Ethereum, multi-signature addresses can be realized through smart contracts, and the N value can also be infinite.

3.2.3.2 Private key fragmentation

Private key sharding technology, also known as distributed key technology, is a multi-party control technology with higher theoretical security. This technology was born out of the secure multi-party computing ( sMPC, Secure Muti-Party Computation), combined with Threshold Technology (TSS), can also implement M-of-N signature management. This technology supports splitting the private key of an account into several fragments and assigning them to multiple signers. When the number of signed fragmented private keys reaches the threshold, the account assets can be operated. In terms of specific implementation, there are many technical implementation methods for private key sharding, which involve complex cryptography knowledge, which will not be expanded in this article.

private key The reason why shards are more secure is that the shards are constantly refreshed, that is, every once in a while, the shards will be re-run, and the shards given to each person will change. If a malicious person wants to steal assets by obtaining everyone's shards, he must obtain the private keys of different signers in the same time unit, otherwise the donkey's lip is wrong and the complete private key cannot be synthesized.

3.2.3.3 Signer group member management

Whether it is multi-signature or private key sharding, the signer group cannot be a group whose members are always fixed, so it will involve the increase or decrease of members of the signer group. In the private key sharding technology, it is only necessary to re-shard and distribute the fragments to the new signer group generated after the increase or decrease. In multi-signature technology, there are two situations:

On Turing-complete blockchains such as Ethereum, the management rules of signer group members can be set through smart contract programming, for example, if more than 2/3 of the existing signers sign and agree, You can approve the addition of a new signer, or approve the removal of an old signer.

On BTC, you cannot Edit the signer group members of a P2SH multi-signature address. If a signer’s private key is leaked or needs to be withdrawn, he can only recreate a new P2SH multi-signature address and transfer the assets to the new address.

3.2.4 Improve towards decentralization

On the whole, the witness mode is a cross-chain method that is relatively easy to implement, has strong versatility, and has low adaptation costs. The initial version of the witness model was relatively centralized, but people were not satisfied with it, so they improved it in various ways to make it decentralized, such as using more decentralized witness access Mechanism and grouping mechanism, using more distributed asset custody addresses, etc. As a result, various improvements have been made. While these improvements achieve decentralization, they also bring a certain amount of complexity.

3.3 Light node side chain

The emergence of side chains stems from people's efforts to expand BTC. In October 2014, the BlockStream team released the "White Paper on Sidechains", which proposed an "anchor" cross-chain solution for the first time. Pegged, sometimes translated as "wedge", expresses the readable state of the anchored chain to the anchor chain. This state is also called "the anchor chain is the side chain of the anchored chain. ".

The earliest people hoped By transferring BTC transactions from the BTC main chain to the side chain, the pressure on the BTC main chain is reduced. RSK developed by the RootStock team in 2016 is considered to be the earliest side chain of BTC. The essence of the side chain technology is to make the main chain readable to the side chain by fusing the light nodes of the main chain on the side chain. This technology can be applied to cross-chains with a little transformation. We only need to deploy the light node contract of the source chain on the target chain to transform the target chain into a side chain of the source chain and realize the transfer from the source chain to the target chain. One-way cross-chain.

The so-called light node refers to A smaller node that only stores block header information. Light nodes do not store all transactions on the chain, but can verify whether a certain transaction exists on the chain through the block header information. Light node contracts are smart contracts that include light nodes. By deploying the light node contract of the source chain on the target chain, the authenticity verification of the messages from the source chain can be realized. The process is roughly as follows:

When When the source chain A requests to transmit a cross-chain transaction information to the target chain B, the transaction initiator submits the detailed content of the transaction, the block height, and the SPV certificate of the transaction (referring to the Mekre path of the transaction) to B chain;

deployed in B chain The light node contract on the A chain, through the SPV proof, recalculates the hash value of the block header of the trading platform in the block;

Compare the hash value obtained with the corresponding block header hash value in the light node. If they are consistent, it indicates that the transaction did occur in In the block, if they are inconsistent, it means that the transaction does not exist in the block.

Although anyone can submit a request to The target chain submits the transaction details and its SPV proof, but in actual cross-chain applications, there is often a dedicated role to do this, rather than the transaction initiator. We call this role the Relayer in this article. In addition to being responsible for helping users pass cross-chain messages, Relayer also needs to be responsible for passing the block header of the source chain to the target chain to establish a light node contract.

Relayer is like a witness, Both are a specific role set up for passing cross-chain messages, but there are two differences between Relayer and witness:

Relayer is not responsible for hosting assets. If the side chain mechanism is used to achieve cross-chain, the tokens locked during the cross-chain process will be entrusted to a specific in the escrow contract.

For Relayer's trust assumption, More lenient than witnesses. We must trust that the majority of witnesses are honest, but as long as at least one of the many Relayers is honest, we can trust that cross-chain messaging is reliable. We will discuss this further in Section 3.3.3.

In different cross-chain projects Relayers are called differently. In some projects, the role of the Realyer is split, and the Relayer (Head Relayer) responsible for delivering block headers and the Relayer (Message Relayer) responsible for delivering transaction messages are defined as two roles. In some projects, there is no dedicated Relayer role, and the functions of Relayer are merged into other roles. For example, the validators of the source chain directly assume the role of Relayer. However, everything remains the same, the technical essence of the light node side chain solution is always: the Relayer transfers the block header of the source chain to the target chain, establishes a light node, and then when the Relayer transfers the transaction information from the source chain to the target chain, it uses The block header information on the light node verifies the correctness of the transaction information.

3.3.1 Two-way anchoring

What we need to understand is that the relationship between the main chain and the side chain is relative, and the two chains can be side chains. The "source chain" and "target chain" we mentioned above are also relative concepts. In a cross-chain messaging event, the source of the message is often called the source chain, and the receiver of the message is called the target. chain.

Cross-chain parties By burying each other's light nodes, you can read the information on each other's chain and communicate with each other. This form is called two-way pegging (Two-Way-Pegging). In this form, the two chains become each other's side chain. There are Relayer groups in both directions responsible for transmitting information to each other. Of course, the two groups of Relayers (B→A Relayer & A→B Reayer) may also be the same group of people who are merged into the same role and are responsible for two-way information transmission .

3.3.2 Side chain and sub chain

When it comes to side chains, it is necessary to distinguish and analyze another concept that is easily confused, that is, sub-chains. The sub-chain does not have its own consensus mechanism and native certificate, and its security is completely dependent on the main chain, which is unidirectional. The sidechain itself is an independently operating blockchain, and the relationship between the sidechain and the main chain is a relative concept and has a bidirectional nature.

Ethereum Some expansion chains are in the form of side chains, while others are in the form of sub-chains. The expansion chain using the Plasma method and the side chain method is the side chain of Ethereum (Plasma side chain is another form of side chain, not a light node side chain), while the expansion chain using the state channel and Rollup method is the Ethereum Fang's sub-chain.

The sub-chain passes the transaction from The main chain is moved to the sub-chain, and the final state is periodically synchronized with the main chain to realize the expansion of the performance of the main chain. Therefore, the sub-chain is also called the "commit chain". Close to its technical essence.

The purpose of the sub-chain is to Expansion, the essence of expansion is to save the resources of the main chain, so the main chain will not spend computing resources to verify the transactions submitted by the sub-chain. The subchain itself needs a mechanism to prove the authenticity of the submitted content when submitting. Among them, state channel, Optimistic Rollup, and Arbitrum Rollup use fraud proof to prove, while Zk Rollup and Validium use zero-knowledge proof to generate validity proof.

Between the sub-chain and the main chain During this period, this kind of one-way information submission interaction is also considered as a form of cross-chain technology in some literatures, but Paka Labs believes that although both side chains and sub-chains were born from the efforts to expand the blockchain, However, technologies related to sub-chains can only be used to create expansion chains, and cannot be applied to cross-chains between two independent blockchains, and should not be classified as cross-chain technologies.

3.3.3 Advantages of light node side chain

If the witness mechanism focuses on Trust (trust), then the light node side chain technology focuses on Verify. The reliability of the transaction information is verified through the block header, and its reliability is guaranteed in cryptography. Whether the transaction exists can be known at a glance, and it is certain. The block header passed by Relayers cannot be falsified, because the light node contract can strictly verify the block like a full node, and the false block header cannot approved. The verification procedure of the light node is exactly the same as the verification procedure of the miner node in the source chain network. Taking BTC as an example, it needs to be verified by the following steps:

The data structure of the block is syntactically valid;

Validate the proof of work, the hash value of the block header is less than the target difficulty (confirmation contains enough Proof of Work);

Zone The block timestamp is two hours ahead of the verification moment (time errors are allowed);

Verify that the block size is within the length limit, that is, check whether the block size is within the set range;

The first transaction (and only the first) is a coinbase transaction, that is, a block, miners only Can reward myself once;

Verify the transactions in the block and ensure their validity: verify whether the MerkleRoot is obtained from the transactions in the block body, that is, the tree root obtained by reconstructing the Merkle tree of the block, and see if it is equal to the hashMerkleRoot value in the block header.

If malicious Relayers collude to do evil , the only feasible way is to pass the block header of a block on a forked chain, but for a healthy network, the forked chain will not become the longest chain in the end, and the light node contract only needs to wait for the confirmation of enough blocks That's it (for BTC light nodes, just wait for 6 blocks). For BFT-type chains, the light node contract only needs to verify the signature number of the block to know whether the block is final.

Only source chain or target chain The security of the light node contract will be affected only if the reorganization of itself occurs. The harm Relayer can cause to the network is at most limited to a collective strike, causing the network to stop service.

Additionally, the Relayer is not responsible for managing Escrow assets, a malicious relayer cannot steal the escrow assets like a malicious witness. The assets locked due to cross-chain are hosted in the contract, and the assets hosted in the contract, if there is no problem with the contract code, its security is at the level of the chain where the contract is located.

Because the conditions for Relayer to do evil are harsh , and less harmful, the Relayer in the light node side chain does not need to be over-collateralized like a witness. More cross-chain anchor asset issuance can be achieved with less cost.

It can be seen that the light node The side chain solution has more advantages than the witness solution in terms of cross-chain cost and security, and is the preferred technical solution to realize the cross-chain between two chains. However, some chains do not support smart contracts and cannot deploy light node contracts and escrow contracts. In this case, the only option is to adopt the witness scheme.

3.3.4 Development of light node technology: "slimming" and "burden reduction"

We know that the block size of BTC is 1M, and its block header is only 80byte. Until the time of publishing this article, the historical block header size of BTC has not exceeded 60M (height approx. 690,000), but the historical block headers of Ethereum, which was born late, have exceeded 5 G (height is about 13 million). With the diversified development of blockchains, some emerging blockchains are more focused on high TPS , the speed of block generation is extremely fast, and the volume of its historical block headers may soon exceed that of Ethereum.

This trend , which brings challenges to the light node side chain, mainly reflected in two aspects:

A larger block header will make the light node contract cumbersome and occupy a huge storage space of the target chain;

The faster block generation speed of the source chain will cause light node contracts to need frequent synchronization and verification of new areas piece.

Both, will It will cause huge gas consumption of the light node contract on the target chain, and in severe cases, it will make it economically unfeasible to use the light node side chain technology to achieve cross-chain.

What to do, back to witness Is there a human plan? But the superiority of the light node sidechain technology is so attractive, we still hope to continue to use it. Is there a way for light node contracts to transform and expand without losing their SPV verification capabilities?

Researchers in the blockchain industry have improved the light node side chain technology in two directions. The first is to "slim down" the light node contract to make it smaller and not grow linearly with the increase of blocks. The second is to "reduce the burden" of the light node contract and move the block verification link off the chain, so that Light node contracts only do SPV verification of transactions.

3.3.4.1 "Slimming" of light node contracts

We need to understand a new protocol called "FlyClient", which was proposed by Benedikt Bunz et al. of Stanford University in the paper "FlyClient: Super-Light Clients for Cryptocurrencies" New light node protocol. Flyclient light nodes do not need to store all block headers, but only need to store the latest block headers. With the latest block header, all historical block headers can be "restored" at any time. This function is realized through a cryptographic algorithm called "Merkel Mountain".

Merkel Merkle Mountain Range (MMR) for short is a variant of Merkle Tree (Merke Tree). We use the hash values of all historical blocks of a blockchain as leaf nodes, and generate an MMR through the MMR algorithm. Root value, and write this value into the latest block header, you can use this value to verify all historical block headers.

FlyClient light nodes can be deleted continuously Historical block headers, only the latest block headers are kept to keep "lightness". When a certain block header needs to be restored, it can be obtained from the full node again through the Relayer, and the MMR root value in the latest block header can be used to verify whether the restored block header is correct.

If the source chain is the probability final When the Flyclient light node receives the latest block header delivered by the relayer, it will have an additional verification step, which is to ask the relayer to randomly provide a certain historical block header for spot check. This is done to prevent a new form of fraud specific to Flyclient light nodes. The specific fraud methods and spot check algorithms are relatively complicated, so we will not expand them in this section. In the subsequent case introduction chapters, we will introduce specific cross-chain projects.

Flyclient light node is really realized "Compress the elephant into a biscuit", so that the light node contract of the source chain deployed on the target chain can be light and simple, and make the cross-chain of the light node side chain more economically feasible. But for most of the current blockchains, the MMR root value is not a fixed part of the block header. Therefore, the relayer must run the full node itself, calculate the MMR root value, add the MMR value to the block header and pass it to the light node . Some newer blockchains have already made the MMR root value a fixed part of the block header. Some existing relatively mature public chains are also proposing soft fork upgrades to add the MMR root value to the fixed structure of the block header. A blockchain with an inherent MMR value in the block header will be more friendly to cross-chain development.

3.3.4.2 "Burden reduction" of light node contracts

For light node contracts, the verification of the latest block header is the link that consumes the most Gas. The consumption of this link has nothing to do with the number of cross-chain requests of the user, but only with the block generation speed of the source chain. relation. If the block generation speed of the source chain is fast, the Gas consumption of this link may be unacceptably large.

Researchers I thought of moving the new block verification link that consumes the most Gas to off-chain. Referring to the expansion scheme of Ethereum layer2, two schemes, zkRelayer and fraud proof, have been proposed successively. zkRelayer uses zero-knowledge proof to generate block verification proofs off-chain and submits them to the chain. Fraud proofs use a set of economic incentive mechanisms to encourage Relayers to submit correct blocks: Challengers always supervise the blocks submitted by Relayers , if it is found that a malicious relayer has submitted an incorrect block, the challenger can obtain the deposit of the malicious relayer after verification by the light node. If the block submitted by the relayer is not challenged, it will be the correct block by default. The light node The contract is directly included without verification.

3.4 Relay chain

In order to establish a wider cross-chain network, more often than not, we need to connect not only two chains, but many chains. If the above-mentioned two-way wedge is established between each two chains, each side The relationship between chains, the number of connections and adaptation costs will increase exponentially with the increase in the number of chains, so the idea of relay is proposed: establish a relay chain, and all other chains are established with the relay chain Connection, just like the terminal equipment at home is connected to the router. This immediately reduces the cost from n(n-1)/2 to n (where n is the number of chains).

The relay scheme is a variant of the side chain scheme, and the side chain It is also reasonable to classify it as a category of technical solutions. The relay scheme has high scalability and is currently the most widely used cross-chain scheme. In order to fully explain the relay scheme, this article lists it separately.

Sometimes, in the dual-chain cross-chain model, Relayers will operate as a validator of an independent blockchain. This independent chain is regarded as a whole to undertake the functions of block header handling and cross-chain message handling. Internal consensus is reached on the information to be moved. This type of independent blockchain is often called a bridge chain, but it is not a relay chain. For example, Polygon's PoS bridge and Near's PoA rainbow bridge are just bridge chains, not relay chains.

The key to distinguish between the two, The difference lies in the cross-chain communication path:

The bridge chain can be understood as just a container of Relayers, and its function is still to carry block headers and cross-chain messages, while the relay chain establishes a mutual side chain relationship with each access chain message transfer station. Many literatures do not make a strict distinction between these two concepts, but the essence of the two is completely different.

3.4.1 Connect to existing blockchain

In relay mode, Usually, the validator of the relay chain is responsible for assuming the function of Relayer and forwarding inter-chain messages. Compared with two-way anchoring, the relay chain mode has more scalability, and the chain connected to the relay chain is called the access chain.

In order to connect existing The blockchain needs to use the relay chain to adapt to the access chain respectively. Although the relay chain mode has greatly saved connection costs, it still faces the following challenges:

It is necessary to formulate different adaptation schemes according to the characteristics of different access links, and to do active compatibility, which requires a lot of work;

The security of different chains is different, which will involve the cross-chain of different access chains Trust issues to protect the security of the entire cross-chain network;

New blockchains are emerging one after another. If there is an access chain with new features, a new adaptation solution needs to be developed

3.4.2 Communication Protocol Cluster + Chain Building Protocol
< div>
Compared with active compatibility, there is a more convenient way , is to create a brand-new blockchain chain building standard. The blockchain developed according to this standard has the same Cryptographic Primitives (Cryptographic Primitives), consensus mechanism and communication architecture, and can be easily connected to the relay chain to realize Passive compatibility. The cross-chain duo Polkdot and Cosmos practiced this idea. Both created a set of chain-building standards, Polkadot created Substrate, and Cosmos created the Cosmos SDK. Nevertheless, active compatibility is required for existing important blockchains. Both Polkadot and Cosmos have designed heterogeneous cross-chain modules to connect the Ethereum chain and the BTC chain.

communication protocol cluster +The cross-chain projects of the chain-building protocol are optimistic, the key reason is that it is expected to solve the cross-chain problem once and for all. Perhaps the Wanchain interconnection vision we are looking forward to is ultimately not a network structure, but a tree structure, that is, let a certain relay chain become the layer0 of the blockchain world, and other chains, including the majority isomorphic chain , and the minority heterogeneous chains are connected in the form of layer1, layer2....

In the relay chain+ In the multi-chain architecture of the access chain, the relay chain is no longer just a bridge, but a hub, which we can call "chain hub". While undertaking the task of cross-chain message transmission, the chain hub also needs to handle inter-chain message routing, message timing and other issues.

3.5 Shared Verifier

Cosmos and Polkadot, which are also communication protocol clusters + chain-building protocols, both contain the idea of relay, but with a little attention we find that the difference between the two is huge.

Cosmos Hub A typical "two-way anchoring" relationship is established with Zone. Cosmos' cross-chain messaging protocol IBC still relies on the light node contract built in the receiving chain to perform SPV verification on cross-chain messages, but Polkadot's In the cross-chain messaging protocol XCMP, light node technology is not adopted to verify the legitimacy of cross-chain messages, but another method is adopted, which is extracted by Paka Labs and called "shared verifier". Listed as a separate category for cross-chain technologies. (More analysis on XCMP and IBC will be launched in the subsequent example chapters.)

The shared validator scheme refers to the scheme in which multiple chains share the same set of validators, and these common validators are responsible for verifying cross-chain messages. Polkadot decouples the collection and verification of blocks into two functions, which are in charge of two groups of roles, namely the collector (Collator) and the validator (Validator). Each parachain has its own collector, but the parachain Without its own validators, block validation is the responsibility of the relay chain's validators. This is equivalent to that each parachain transfers a part of the consensus process to the relay chain. Therefore, Polkadot's parachains can interact like different partitions of the same blockchain, and no additional trust mechanism is required.

It should be noted that wave Instead of having all validators verify all chains, the card takes a more economical approach. At a specific moment, the verifier group of each parachain is different. The verifier group of each parachain is randomly assigned by the relay chain, and will be reassigned every once in a while. Through such a random assignment mechanism, let It is difficult for a malicious validator set to join forces to do evil. This mechanism can be compared to the military system of the Song Dynasty in ancient China: soldiers have no permanent generals, and generals have no permanent soldiers.

Pokacard’s shared verifier It is essentially a sharding mechanism, similar to Ethereum 2.0, Harmony, Near and other blockchains that use sharding mechanisms to improve scalability. But the difference is that the shard chain and the beacon chain are integrated for life, while Polkadot’s parachain can be decoupled from the relay chain at any time, and coupled at any time. When decoupled, the parachain is a blockchain that can run independently .

4. Understanding framework of cross-chain technology

There are nearly a hundred active cross-chain projects today. Different cross-chain bridges use different cross-chain technical solutions. Projects using the same type of technical solutions have different designs for system roles and different names. Splitting roles and functions to create more roles, and merging roles and functions to omit some roles, and some projects use multiple cross-chain technologies comprehensively. It can be said that it is dazzling, but if you understand cross-chain clearly The essence of technology can be thoroughly understood by eliminating the false and retaining the true. For this, we need a cognitive framework for understanding cross-chain technology.

We can get from Let’s talk about the problems to be solved across the chain:

4.1 How to ensure the atomicity of cross-chain transactions

This problem refers to that a complete cross-chain transaction must be executed successfully or fail as a whole. There cannot be partial success and partial failure Otherwise, users who use the cross-chain function may face asset losses. There are two ways to achieve this: one is to couple multiple sub-transactions in a cross-chain transaction through cryptographic means, such as an atomic swap scheme based on hash time locks; another method is to make cross-chain transactions Multiple sub-transactions have strict timing, and timing includes three meanings:

Only when subtransaction 1 is completely successful (full success means that the transaction is packaged into the block and forms finality), subtransaction 2 can be carried out, and so on, only subtransaction Sub-transaction 3 can only be carried out when transaction 2 is completely successful;

If sub-transaction 3 fails, the success status of sub-transaction 2 will be kept, so that users can retry sub-transaction 3 repeatedly;

If sub-transaction 3 always fails, the user can withdraw sub-transaction 2 and sub-transaction 1 successively.

In addition to the hash time lock, Most other cross-chain solutions rely on the latter method to ensure the atomicity of cross-chain transactions. This involves a question, how to judge a transaction has formed final certainty. There are many kinds of consensus mechanisms in the blockchain, but according to its finality formation mechanism, it can be divided into two types: provable finality and probabilistic finality. In BFT-type blockchains, blocks are determined through validator voting, and are called Confirmed blocks are final and cannot be reversed. However, for non-BFT blockchains, the longest chain is considered to be the final chain, but the longest chain may change due to forks. Therefore, the transactions that have been packaged may be reversed. Faced with this situation, the generally adopted method It is to wait for more block confirmations until the possibility of the transaction platform being reversed in the block is extremely low.

It can be seen from this that it can The BFT-like blockchain that proves finality is more friendly to cross-chains. Therefore, whether it is Cosmos or Polkadot, its chain-building standards all adopt the BFT-like consensus mechanism. It should be noted that BFT is only a way of final confirmation and is part of the consensus mechanism. Although BFT-type blockchains are generally PoS consensus, non-BFT-type blockchains are generally PoW consensus, but there is no absolute consensus. related relationship.

4.2 How to perceive another chain

A blockchain system is closed and independent to another blockchain system. Each chain is a "Walled Garden" and cannot directly perceive the transactions in another chain and its state. One chain is an off-chain system for another chain, so the perception of one chain for another chain is actually an oracle problem.

Therefore, any No matter how the cross-chain technology evolves, it cannot avoid the role of a "middleman". The systems are independent of each other. When a cross-chain transaction is initiated, how can the target chain confirm the lock-up transaction of the source chain before issuing the mapped assets? It's done. A trusted "middleman" will be responsible for the transmission and verification of cross-chain messages between the two chains. The intermediary, in the witness scheme, is embodied as a single-subject or multi-subject witness set; in the sidechain/relay scheme, it is embodied as a Relayer set; in the shared validator scheme, it is a shared validator set. Only the hash time lock technology is intermediary-free in principle, but requires the transaction initiator and counterparty to be online at the same time. In order to improve the experience, we need an intermediary to act as a public counterparty, or we call it liquidity provider.

In the process of transaction verification, In the witness scheme, the witness verifies the transaction by running the node or connecting to other nodes. In the sidechain/relay scheme, the authenticity of the source chain message is verified by deploying the source chain light node on the target chain. In the shared validator scheme, the shared validator completes the verification in the consensus process of the source chain, and the target chain can be trusted unconditionally.

4.3 How to Safely Manage Lien Assets

The problem of custody of retained assets exists in the scenario of cross-chain asset transfer. As mentioned above, the essence of cross-chain asset transfer is to let assets be locked up in the source chain and generate simulated assets on the target chain. Then the custody security of retained assets is an important part of cross-chain security.

There are four Types of custody addresses are independent control accounts, multi-party multi-signature accounts, multi-party private key shard accounts, and contract accounts. The combination of the first three and the witness mechanism forms different subtypes of witness mechanisms; In the continuous cross-chain solution, the contract account is used to manage the retained assets. In fact, the sidechain/relay solution can also be combined with the custody solution of non-contract accounts, but almost no projects are designed in this way, because contract accounts have higher security, even if some projects actually operate like this, it is more likely It is a transitional solution before the development of an escrow contract is completed.

Actually, cross-chain assets In the transfer scenario, there is another solution that does not require custody of assets, that is, the burn-mint (Burn-Mint) solution. The assets on the source chain are no longer locked, but directly destroyed, and then the anchor assets are issued on the target chain . This solution is only applicable to chains with a high degree of coupling, otherwise burned assets cannot be reverse-forged, and assets can never be returned after cross-chaining, which is obviously unacceptable. Polkadot’s parallel chains use the Burn-Mint mechanism to carry out cross-chain tokens.

4.4 How to do multi-chain adaptation

The solution for multi-chain adaptation of the side chain scheme is the relay scheme. In this relationship, the adaptation cost is much lower. Even so, it is still very troublesome for the relay chain to be actively compatible with multiple heterogeneous access chains. It needs to be adapted separately. It is better to establish a set of communication standards and chain building standards from top to bottom once and for all, so that more new chains Become an isomorphic chain that is directly and passively compatible.

Witness Program Compared with the hash time lock scheme, it is more general than the side chain/relay chain scheme. The former only needs to set up a escrow account on the new access chain to complete the compatibility with the new access chain, while the latter only needs to accept The in-chain supports the hash lock and time lock functions to be compatible.

The shared validator scheme is only It is suitable for homogeneous cross-chains, and cannot be actively compatible with existing heterogeneous chains. If compatibility is required, other cross-chain solutions must be adopted.

4.5 Summary

Overview of 5 categories through the above cross-chain technology:

Atomic exchange based on hash time lock
Witness mechanism
light node side chain
relay chain
Shared Validators

And the four dimensions of cross-chain technology understanding:

Atomicity of cross-chain transactions
Cross-chain message verification
Asset custody
Multi-chain adaptation

We can basically be accurate Grasp the context of a cross-chain solution and form a framework understanding. In the following chapters, we will give examples and technical analysis of current typical cross-chain projects.

Original link





















Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia