Connecting isolated islands into continents: a panoramic view of cross-chain technology and application forms

This article is the first part of the whole article, about 14,000 words, the recommended reading time is 35 minutes; the whole article has four parts, which will be published one after another.

Preface

Cross-chain technology is considered the holy grail of the blockchain field and the key technology to realize the interoperability of Wanchain. People often compare its importance with the TCP/IP of the Internet. It is precisely because the TCP/IP protocol suite provides a point-to-point link mechanism that standardizes how data should be encapsulated, addressed, transmitted, routed, and received at the destination, so that the global terminals are connected into a network. It evolved into what we call the Internet today. 

With the rapid development of the blockchain industry, various public chains and permission chains are constantly emerging, and a hundred flowers blossom. However, most chains cannot be connected and interoperable due to technology, ecology, competition and other reasons. This has brought about 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 limitations of blockchain scalability.

In order to connect isolated islands to the mainland, 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 that are currently committed to solving cross-chain problems. There have been many research reports on cross-chain, but this article will try to go deep into the essence of technology based on previous research , identify confusing concepts, grasp the contextual framework, and include the latest developments.

What exactly does the cross-chain need to cross?

Token exchange

Each blockchain has its own native token. Tokens become a carrier of value because they encapsulate certain rights and interests. The tokens in the chain can be exchanged credibly, but the token exchanges between the chains are “separated from the chain as a mountain”. Only by realizing the credible exchange of certificates between chains can the important role of the blockchain as the “Internet of Value” be realized.

At present, cross-chain token exchange can be realized through centralized exchanges, such as depositing BTC to the exchange, changing it to ETH , and then withdrawing it to the ETH wallet. But people are not satisfied with a centralized solution, and hope to be able to directly perform trusted exchanges on the chain. For example, user A wants to use BTC to exchange ETH held by user B. There will be a problem in this process. If the two agree to a transaction , But after A makes a transfer, what should I do if B breaks his promise and gets fat? This requires the use of cross-chain technology, through system matching, so that the two transfers can be synchronized. Atomic swap based on hash time lock is a typical technology to realize this scenario.

Pass through

Token delivery means that the original assets on one chain are circulated to another chain. This cannot be achieved directly, and any token can only be attached to its host chain. Generally speaking, token delivery is achieved by locking the original assets on the source chain, and at the same time issuing an equivalent amount of anchored 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 transmission and token exchange can both solve the problem of value exchange between chains, but the two are not exactly the same thing. If you want to use an A BTC exchange 10 ETH B, a process that permits only achieved through the exchange, but if A wants to get these a BTC Ethernet Square use on, you need to pass through the card. In addition to solving the problem of value exchange, pass-through has additional utility. We can pass tokens to realize the participation of assets on chain A in DeFi applications on chain B, and build a more inclusive open finance. We can also transfer tokens from an expensive chain to an economic chain, saving transaction costs. , Or transfer from a slow chain to a fast chain to achieve expansion, or, from a non-private chain to a private chain, to achieve transaction privacy. It can be said that the problems that can be solved by pass pass are a superset of the problems that can be solved by pass exchange.

Information transfer

Cross-chain in the full sense should actually enable reliable transmission of any messages between chains. Any cross-chain transaction is essentially a combination of a series of cross-chain message transfers. For example, as a type of cross-chain transaction, token transfer is composed of two cross-chain message transfers, which are as follows:

  • The source chain locks the token, and transmits the lock message and its proof to the target chain;
  • The target link receives the information, verifies its authenticity, casts the mapping token, and sends the return receipt back to the source chain.

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

Connecting isolated islands into continents: a panoramic view of cross-chain technology and application forms

Through cross-chain information transfer, one chain can read and verify the state and information of another chain, and the smart contract of one chain can use a certain state and information of the other chain as a trigger condition 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 chain and the chain will be combined into a huge service collaboration network, realizing our expected state of interconnection of all chains.

Overview of cross-chain technology

Some of the current cross-chain technology forms only realize the exchange of tokens, such as hash time locks and cross-chain DEX; others use the establishment of a set of on-chain roles to forward messages and verify status, and some propose a set of communication protocols. Realize the communication between blockchains; some have proposed new system architectures and chain-making protocols to support more blockchain access.

Since the chain and the chain are independent of each other, a direct connection cannot be established, and the chain cannot directly perceive each other’s state changes. Therefore, a communication bridge needs to be built. In the selection of communication bridges, it is generally divided into five major technical forms, namely , atomic swap based on hash time lock, witness, light node side chain, relay chain, shared validator , which will be expanded in section 3.1-3.5 Description:

Connecting isolated islands into continents: a panoramic view of cross-chain technology and application forms

Atomic swap based on hash time lock

Hash time lock is a set of cryptographic methods that can realize trustless cross-chain asset transactions. For example, if I use 1 BTC and your 10 ETH transactions, 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, calculates the hash value of r m=hash(r), and sends the value of m to user B;

At the same time, user A initiates a transaction and transfers 1 BTC to user B. The success of the transaction is conditional. User B must show the password r to succeed, otherwise the transaction will automatically fail if the preset time is exceeded;

After user B sees the transaction initiated by A, he also initiates a transaction and transfers 10 ETH to user A. The success of the transaction is also conditional and requires user A to show r to succeed. After the preset time, the transaction will also be automatic fail. The key here is that user B creates such a transaction that presents the value of r as a success condition, and does not need to get the value of the password r, only needs to know the value of m to create it, and we know that the hash operation is irreversible. Knowing that m cannot be calculated r;

After user A sees the transaction initiated by B, he shows the value of r, so that the transaction initiated by B is successful and obtains the 10 ETH transferred by B, and the value of r is disclosed;

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

Through the above mechanism, transactions on two different chains are coupled into one event, which can only succeed or fail as a whole, and there will be no successful transfer of A to B and a failure of B to A, and vice versa. NS.

Connecting isolated islands into continents: a panoramic view of cross-chain technology and application forms

The realization of this mechanism relies on two technologies, namely “Conditional Successful Transaction” and “Conditional Failure Transaction”. In the above case, the trigger condition for successful transaction is the presentation of the hash preimage r, and the condition for transaction failure is If the original hash image r is not shown for more than a preset time, we can also call it a hash lock and a time lock respectively .

In BTC, the hash time lock can be realized through the CLTV opcode or the CSV opcode. On the Turing complete chain such as Ethereum, the hash time lock can be realized through the smart contract. In fact, smart contracts can achieve far more diverse and complex conditional successful transactions and conditional failure transactions than hash time locks.

We can see that the hash time lock realizes an atomic transaction where both parties across the chain disintermediate, without any trust assumptions. At the same time, we also realize that this transaction method is not user-friendly in terms of user experience, which is mainly reflected in the following three aspects:

  • Both parties to the transaction must be online at the same time and strictly follow the participation process. Therefore, if the transaction initiator cannot find an online counterparty, it must wait.
  • For BTC, the creation of a transaction with a hash time lock is done at the bottom by creating two transactions. Due to the complexity of the underlying mechanism, the transaction process described above is simplified and expressed as a transaction. If the transaction is successful, both transactions must be chained, and an additional fee will be required.
  • 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 them. Especially when the amount is large, the counterparty has a strong incentive to do so, which makes atomic transactions may not be suitable for large transactions.

In addition, in terms of the degree of cross-chain realization, hash time lock has its limitations. It can only realize cross-chain atomic exchange of tokens, and cannot realize the transmission of tokens and more extensive cross-chain information transmission. Therefore, it is used in actual cross-chain applications. It is often used in combination with other cross-chain technologies.

witness

Witness, English as Notary, sometimes translated as notary, is a special role set up to pass cross-chain information and custody cross-chain assets. In 2012, Ripple released the InterLedge Protocol (ILP), which realized cross-chain transfer through a third-party witness for the first time. Since then, the witness mechanism has been successively applied to many cross-chain projects based on BTC-anchored assets.

Different cross-chain projects have different settings for witnesses : the witness may be a single subject, but in most cases there are multiple subjects; the generation of witnesses may be permissive or freely accessible; In order to achieve cross-chain assets, the witness will have to manage an escrow account. The method of managing the escrow account may be independent control or multi-party control; the user’s trust basis for the witness may come from the witness’s own credit or source Yu witnesses made an over-collateralization.

  • Witness generation method

The simplest way is to form a permissive witness group, the members are basically fixed, and the joining and withdrawal of the 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 only needs to meet the established conditions, such as mortgage the corresponding assets, to become a witness. Free entry brings additional risk exposure, which may bring malicious witnesses and 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 is randomly selected from the set of qualified witnesses, so that it can increase the number of witnesses. The cost of collusion.

  • The user’s trust basis for the 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 assets in the custodial account. If there is a loss in the custodial assets, the user will receive compensation from the mortgage. Over-collateralization makes the assets under user custody have extremely high security, but over-collateralization brings capital costs to the witnesses, and the capital costs of the witnesses will be converted into high cross-chain processing fees.

Witnesses can also rely on their own goodwill to endorse. Despite the assumption of trust, its advantage is that the cross-chain cost is low, and it can even be free, so it still attracts a large number of users.

  • Asset custody method: independent control address and multi-party control address

The witnesses may each control an independent control address to form an escrow address matrix to accept the user’s escrow entrustment. 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 sharding technology to manage the independent control address. For example, a witness is a family under the chain. In 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 the address, as long as it is an address controlled by a single subject, we call it an independent control address.

In more cases, the escrow address is an address controlled by multiple parties. It may be that all witnesses jointly manage an address, or it may be that the witnesses are grouped together and each group manages an address. In this case, multi-party control techniques such as multi-signature or private key fragmentation must be used.

Multi-signature

Multi-signature, or multi-signature, Muti-Sig in English, 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 to transfer money, 1≤ M≤N.

In BTC, the multi-signature address is a P2SH type of 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 value of N, N≤15; in Ethereum and other blockchains with Turing completeness, multi-signature addresses can be realized through smart contracts, and the value of N can also be infinite.

Private key sharding

Private key sharding technology, also known as distributed key technology, is a multi-party control technology with higher theoretical security. This technology is born out of the secure multi-party computing (sMPC, Secure Muti-Party) proposed by Turing Award winner Mr. Yao Qizhi Computation), combined with Threshold Technology (TSS), can also realize 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 fragment private keys reaches the threshold, the account assets can be operated. In terms of specific implementation, there are multiple technical implementations of private key sharding, which involve complex cryptographic knowledge, so this article will not expand.

The reason why private key fragmentation is more secure is that the fragmentation is constantly refreshed, that is, the fragmentation will be repeated every once in a while, and the fragmentation given to everyone 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 lips are not right, and the complete private key cannot be synthesized.

Signer group member management

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

On Turing-complete blockchains such as Ethereum, the signer group member management rules can be set through smart contract programming. For example, more than 2/3 of the existing signers can sign and agree to approve the addition of new signers. 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, you can only recreate a new P2SH multi-signature address and transfer the assets to the new one. In the address.

Improving in the direction of decentralization. On the
whole, the witness model 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 through various methods to make it decentralized, such as using more decentralized witness access Mechanisms and grouping mechanisms, using more distributed asset custody addresses, etc. As a result, various improvements have been produced. These improvements have brought a certain degree of complexity while achieving decentralization.

Light node side chain

The generation of the side chain stems from people’s efforts to expand the BTC capacity. In October 2014, the BlockStream team released the “Sidechain White Paper” and proposed the “anchored” cross-chain solution for the first time. Pegged, sometimes translated as “wedge”, expresses the readable state of the anchor chain to the anchor chain. This state is also called “anchor chain is the side chain of the anchor chain” “.

People first hoped to reduce the pressure on the BTC main chain by transferring BTC transactions from the BTC main chain to the side chain. The RSK developed by the RootStock team in 2016 is considered to be the earliest side chain of BTC. The essence of side chain technology is to realize the readability of the main chain to the side chain by fusing the light nodes of the main chain on the side chain. This technology can be applied to cross-chain after a slight transformation. We only need to deploy the light node contract of the source chain on the target chain to transform the target chain into the side chain of the source chain, and realize the transformation from the source chain to the target chain. One-way cross-chain.

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

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

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

The obtained hash value is compared with the corresponding block header hash value in the light node. If they are consistent, it indicates that the transaction actually occurred in the block. If they are inconsistent, it indicates that the transaction does not exist in the block.

Although anyone can submit the transaction details and SPV proof to the target chain, in actual cross-chain applications, there are often special roles to do this, not the transaction initiator. In this article, we call this role Relayer. In addition to 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, like witness, is a specific role set up to deliver cross-chain messages, but Relayer and witness have two differences:

  • Relayer is not responsible for the custody of assets. If the side chain mechanism is used to achieve cross-chain, the tokens locked in the cross-chain process will be custody to a specific custody contract.
  • The trust assumption for Relayer is more relaxed than that of witnesses. We must believe that most of the witnesses are honest, but as long as at least one of the relayers is honest, we can believe that cross-chain messaging is reliable. We will discuss this further in section 3.3.3.

Relayer is called differently in different cross-chain projects. In some projects, the role of Realyer is split, and Relayer (Head Relayer) responsible for transmitting block headers and Relayer (Message Relayer) responsible for transmitting transaction messages are defined as two roles. In some projects, there is no dedicated Relayer role, and the functions of Relayer have been merged into other roles. For example, the validator of the source chain directly assumes the role of Relayer. However, it is inseparable. The technical essence of the light node side chain solution is always: Relayer transmits the block header of the source chain to the target chain, establishes the light node, and then Relayer transfers transaction information from the source chain to the target chain. The block header information on the light node verifies the correctness of the transaction information.

  • 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 to each other . The “source chain” and “target chain” we mentioned in the previous article are also relative concepts. In a cross-chain messaging event, the source of the message is often called the source chain, and the recipient of the message is called the target. chain.

The two parties across the chain can read the information on each other’s chain by burying each other’s light nodes and communicate with each other. This form is called two-way anchoring (Two-Way-Pegging). In this form, two chains Become each other’s side chain. There are Relayer groups in both directions that are responsible for transmitting information to each other. Of course, the two Relayers (B→A Relayer & A→B Reayer) may also be the same group of people, combined into the same role, and are responsible for two-way information transmission.

  • Side chain and sub chain

When it comes to side chains, it is necessary to distinguish from another concept that is easy to confuse, that is, sub chains. The sub-chain does not have its own consensus mechanism and native token, and its security completely relies on the main chain, which is one-way. The side chain itself is an independently operating block chain, and the relationship between the side chain and the main chain is a relative concept and is bidirectional.

Some of the expansion chains of Ethereum are in the form of side chains, and some 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 (the Plasma side chain is another form of side chain, not a light node side chain), while the expansion chain using the state channel and the Rollup method is based on the Ethereum The sub-chain of Fang Fang.

The sub-chain realizes the expansion of the performance of the main chain by moving the transaction from the main chain to the sub-chain, and periodically synchronizing the final state with the main chain. Therefore, the sub-chain is also called the “commit chain”. The name of the sub-chain is closer to its technical essence.

The purpose of the sub-chain is to expand the capacity. The essence of the expansion is to save the resources of the main chain, so the main chain does not spend computing resources to verify the transactions submitted by the sub-chain. The sub-chain itself needs a mechanism to prove the authenticity of the submitted content at the time of submission. Among them, the state channel, Optimistic Rollup, and Arbitrum Rollup use fraud proofs to prove, while Zk Rollup and Validium use zero-knowledge proofs to generate validity proofs.

This one-way information submission interaction between the sub-chain and the main chain is considered to be a form of cross-chain technology in some literature, but Paka Labs believes that although both the side chain and the sub-chain are born in the opposite zone Blockchain expansion efforts, but the technology related to the sub-chain can only be used to create an expansion chain, and cannot be applied to a cross-chain between two independent blockchains, and should not be classified as a cross-chain technology.

  • The advantages of light node side chains

If the witness mechanism focuses on Trust, then the light node sidechain technology focuses on Verify! By verifying transaction information through the block header, its reliability is cryptographically guaranteed, whether the transaction exists, one Experience is known, and there is no doubt.

The block header passed by Relayers cannot be faked, because the light node contract can strictly verify the block like a full node, and the fake block header cannot pass the verification. 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 go through the following steps to verify:

The data structure of the block is grammatically valid;

Verify the proof of work, that the hash value of the block header is less than the target difficulty (confirm that it contains sufficient proof of work);

The block timestamp is two hours ahead of the verification time (allowing time errors);

Verify that the block size is within the length limit, that is, to see if the block size is within the set range;

The first transaction (and only the first one) is a coinbase transaction, that is, a block, and the miner can only reward himself once;

Verify the transactions in the block and ensure their validity: verify whether the MerkleRoot is obtained from the transaction in the block body, that is, the tree root obtained by reconstructing the block Merkle tree to 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 the 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 enough Confirm multiple blocks (for BTC light nodes, just wait for 6 blocks). For BFT-type chains, the light node contract only needs to verify the number of signatures of the block to know whether the block is final.

Only the reorganization of the source chain or the target chain itself will affect the security of the light node contract. The harm that Relayer can cause to the network is at most confined to a collective strike, which causes the network to stop service.

In addition, Relayer is not responsible for managing the assets under custody. A malicious Relayer cannot steal the assets under custody like a malicious witness. Assets locked due to cross-chain are hosted in the contract. If there is no problem with the contract code, the security of the assets in the contract is at the level of the chain where the contract is located.

Because Relayer has harsh conditions for doing evil and is less harmful, Relayer in the light-node side chain does not need to be over-collateralized like witnesses. The issuance of more cross-chain anchored assets can be achieved at a smaller cost.

It can be seen that the light node 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 achieve cross-chain between the two chains. However, some chains do not support smart contracts, and it is impossible to deploy light node contracts and escrow contracts. In this case, we can only take the second place and adopt the witness scheme.

  • The 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 this article, the historical block header size of BTC has not exceeded 60M (height is about 690,000), but the historical block header of Ethereum, which was born later, In total, it has exceeded 5 Gs (about 13 million in height). With the diversified development of blockchains, some emerging blockchains are more focused on high TPS, and the block generation speed is extremely fast, and the volume of the historical block header will be possible. Quickly surpassed Ethereum.

This trend brings challenges to light-node side chains, which are mainly reflected in two aspects:

  1. Larger block headers will make light node contracts cumbersome and occupy huge storage space in the target chain;
  2. The faster block generation speed of the source chain will cause the light node contract to frequently synchronize and verify new blocks.

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

How to do? Back to the Witness Project? But the advantages of light-node sidechain technology are so attractive, we still hope to continue to use it. Is there a way to transform and expand the light node contract without losing its SPV verification ability?

Researchers in the blockchain industry have improved the light node sidechain technology in two directions. The first is to “slim down” the light node contract to make it smaller and not increase linearly with the increase of the block. The second is to “reduce the burden” on the light node contract and move the block verification link to the off-chain. Light node contracts only do SPV verification of transactions.

“Slimming” of Light Node Contracts

We need to understand a new protocol called “FlyClient”, a new type of light node protocol proposed by Benedikt Bunz of Stanford University and others in the paper “FlyClient: Super-Light Clients for Cryptocurrencies”. The Flyclient light node does not need to store all the block headers, but only the latest block header. Through the latest block header, all historical block headers can be “recovered” at any time. This function is implemented through a cryptographic algorithm called “Merkel Mountains”.

Merkle Mountain Range is abbreviated as MMR, which is a variant of Merke Tree. We use the hash values ​​of all historical blocks of a blockchain as leaf nodes. Through the MMR algorithm, Generate an MMR 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 continuously delete historical block headers, and only retain the latest block headers, keeping “lightness”. When a block header needs to be restored, it can be retrieved from the full node through 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 a probabilistic final chain, when the Flyclient light node receives the latest block header passed by the Relayer, there will be an additional verification step, which is to ask the Relayer to randomly provide a historical block header for spot check. This is to prevent a unique new form of fraud against Flyclient light nodes. The specific fraud methods and spot check algorithms are more complicated. This section will not be expanded first. In the subsequent case introduction chapters, we will introduce specific cross-chain projects.

Flyclient light node truly realizes “compressing elephants into biscuits” , allowing the source chain light node contract deployed on the target chain to be lightly installed and simple, making the side chain cross-chain of the light node more economically feasible. But for most of the current blockchains, the MMR root value is not a fixed part of the block header. Therefore, Relayer must run the full node by itself, calculate the MMR root value, and add the MMR value to the block header and pass it to the light node. . Some newer blockchains already use the MMR root value as a fixed part of the block header. The existing more mature public chains are also proposing a soft fork upgrade to add the MMR root value to the fixed structure of the block header. The blockchain with the inherent MMR value in the block header will be more friendly to cross-chain development.

The “burden reduction” of light node contracts

For light node contracts, 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 made by users, but only with the block generation speed of the source chain. If the source chain produces blocks quickly, the gas consumption of this link may be unacceptably large.

Researchers thought of moving the new block verification link that consumes the most Gas to off-chain. Referring to the expansion plan of Ethereum layer2, zkRelayer and fraud proof have been proposed successively. zkRelayer uses a zero-knowledge proof method to generate a block verification proof under the chain and submit it to the chain. The fraud proof uses a set of economic incentive mechanism to incentivize Relayer to submit the correct block: the challenger always monitors the block submitted by Relayer. 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, the default is the correct block, the light node The contract is directly included without verification.

Relay chain

In order to build a wider cross-chain network, we often need to connect not only two chains, but many chains. If we establish the above-mentioned two-way wedge between each two chains, they will be side chains. , The number of connections and adaptation costs will increase exponentially with the increase in the number of chains. Therefore, the idea of ​​relaying is proposed: to establish a relay chain, all other chains are connected to the relay chain , then The terminal devices at home are all connected to the router. In this way, the cost immediately drops from n(n-1)/2 to n (n is the number of chains).

Connecting isolated islands into continents: a panoramic view of cross-chain technology and application forms

The relay scheme is a variant of the side chain scheme, and it is reasonable to be classified as a technical scheme with the side chain. The relay scheme has high scalability and is currently the most widely used cross-chain scheme. In order to fully expand the relay scheme, this article lists it separately.

Sometimes, in the double-chain cross-chain model, Relayers will operate as a validator of an independent blockchain. The independent chain is considered as a whole to undertake the functions of block header handling and cross-chain message handling, and Relayers is inside it. Reach a consensus on the information to be transported. This type of independent blockchain is often called a bridged 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 the two lies in the difference in their cross-chain communication paths:

Connecting isolated islands into continents: a panoramic view of cross-chain technology and application forms

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

  • Connect existing blockchain

In the relay mode, the validator of the relay chain is often responsible for the relay function and forwarding the messages between the chains. Compared with two-way anchoring, the relay chain mode has more scalability. The chain connected to the relay chain is called an access chain.

In order to connect to the existing blockchain, it is necessary to use a relay chain to adapt the access chain separately. Although the relay chain model has greatly saved connection costs, it still faces the following challenges:

  1. According to the characteristics of different access chains, different adaptation schemes should be formulated to be active and compatible, and the workload is relatively large;
  2. Different chains have different security, which will involve the cross-chain credit issue of different access chains to protect the security of the entire cross-chain network;
  3. New blockchains are emerging in endlessly. If access chains with new features appear, new adaptation schemes need to be developed
  • Communication protocol cluster + chain-making protocol

Compared with active compatibility, there is a more trouble-free way to create a new blockchain chain-making standard. The blockchain developed according to this standard has the same cryptographic primitives, consensus mechanism and communication architecture. It can easily access the relay chain to achieve passive compatibility. The cross-chain duo Polkdot and Cosmos have implemented this idea. Both have created a set of chain-making standards. Polkadot created Substrate, and Cosmos created the Cosmos SDK. Nevertheless, for the existing important blockchains, active compatibility is still required. Both Polkadot and Cosmos have designed heterogeneous cross-chain modules to connect the Ethereum chain and the BTC chain.

Communication protocol cluster + chain-making protocol cross-chain projects are favored, the key reason is that it is expected to solve the cross-chain problem once and for all. Perhaps the vision of Wanchain interconnection that we are looking forward to is ultimately not a network structure, but a tree structure, that is to make a relay chain become the layer0 of the blockchain world, and other chains, including the majority of isomorphic chains , And a minority of heterogeneous chains, access in the form of layer1, layer2…

In the multi-chain architecture of relay chain + access chain, the relay chain is no longer just a bridge, but a hub, which we can call a “chain hub”. While the chain hub undertakes the task of cross-chain message transmission, it also needs to deal with issues such as message routing between chains and message timing.

Shared validator

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

Cosmos’ Hub and Zone establish a typical “two-way anchoring” relationship. 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 cross-chain messaging protocol XCMP does not adopt light-node technology to verify the legitimacy of cross-chain messages. Instead, another method is used. Paka Labs extracts it and calls it “shared verification”. People” are listed as a separate category of cross-chain technology. (More analysis on XCMP and IBC will be expanded in the following example chapters.)

The shared validator scheme refers to a 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 responsible for two groups of roles, namely the collector (Collator) and the validator (Validator). Each parachain has its own collector, but the parachain Without its own verifier, the verification of the block is the responsibility of the verifier of the relay chain. This is equivalent to each parachain giving away 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 needed.

It should be noted that Polkadot did not allow all validators to verify all chains, but adopted a more economical approach. At a specific moment, the validator group of each parachain is different. The validator group of each parachain is randomly allocated by the relay chain and will be re-allocated every certain period of time. Through this random allocation mechanism, It is difficult for a malicious validator set to cooperate with each other. This kind of mechanism can be compared with the military system of the Song Dynasty in ancient China: soldiers are impermanent, and soldiers are impermanent.

Polkadot’s shared validator is essentially a sharding mechanism, which is similar to blockchains that use sharding mechanisms to improve scalability, such as Ethereum 2.0, Harmony, and Near. 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 block chain that can run independently. .

Cross-chain technology understanding framework

There are nearly a hundred active cross-chain projects. Different cross-chain bridges use different cross-chain technical solutions. Projects that use the same type of technical solutions have different designs for system roles, and different names, and have different roles and functions. Split to create more roles, some merge role functions and omit some roles, and some projects use multiple cross-chain technologies. It can be said to be dazzling, but if you understand the essence of cross-chain technology, Then you can get rid of the false and keep the truth, and understand thoroughly. For this, we need a cognitive framework to understand cross-chain technology.

We can start with the problems to be solved across chains:

How to ensure the atomicity of cross-chain transactions

This problem means that a complete cross-chain transaction must be executed successfully or failed as a whole, and there can be no partial success or partial failure. Otherwise, users who use the cross-chain function may face asset losses. There are two ideas to achieve this: one is to couple multiple sub-transactions in a cross-chain transaction through cryptographic means, such as the atomic swap scheme based on hash time lock; the other is to make cross-chain transactions Multiple sub-transactions have strict timing, which has three meanings:

  1. Only sub-transaction 1 is completely successful (completely successful means that the transaction is packaged into the block and form final certainty), can sub-transaction 2, and so on, only sub-transaction 2 is completely successful, can sub-transaction 3 be performed;
  2. If sub-transaction 3 fails, the success status of sub-transaction 2 is retained, allowing users to retry sub-transaction 3 repeatedly;
  3. If sub-transaction 3 always fails, the user can withdraw sub-transaction 2 and sub-transaction 1 successively.

In addition to hash time locks, most of the other cross-chain solutions rely on the latter method to ensure the atomicity of cross-chain transactions. A question is involved here. How to judge that a transaction has formed final certainty? There are many consensus mechanisms for blockchains, but according to their final certainty formation mechanism, they can be divided into two types: provable finality and probabilistic finality. BFT-type blockchains use validators to vote to determine blocks. The determined block is final and cannot be reversed. However, for non-BFT blockchains, the longest chain is considered the final chain, but the longest chain may be changed due to the fork. Therefore, the packaged transaction may be reversed. In the face of this situation, the common method is adopted It is to wait for more block confirmations until the possibility of the exchange being reversed in the block is extremely low.

It can be seen that BFT-type blockchains with provable finality are more cross-chain friendly. Therefore, whether it is Cosmos or Polkadot, their chain-building standards have adopted the BFT-type 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 Related relationship.

How to perceive another chain

A blockchain system is closed and independent to another blockchain system. Each chain is a “Walled Garden”, and it is impossible to directly perceive the transactions and status of the other chain. One chain is an off-chain system to another chain , so the perception of one chain to another is actually a problem of oracles.

Therefore, any cross-chain technology, no matter how it evolves, cannot avoid the role of a ” middleman “. The system and the system are independent of each other. When a cross-chain transaction is initiated, how can the target chain confirm the source chain before issuing the mapped assets? Has the hedging transaction been completed? Between the two chains, a trusted “middleman” will assume the functions of transmitting and verifying cross-chain messages. This intermediary, in the witness scheme, is embodied as a set of witnesses composed of a single agent or multiple agents, in the side chain/relay scheme, it is embodied as a relay set, and in the shared validator scheme, it is a shared validator set. Only the hash time lock technology is non-intermediary in principle, but the transaction initiator and the counterparty need 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 transaction verification link, in the witness scheme, the witness verifies the transaction by running nodes or connecting to other nodes. In the side chain/relay scheme, the source chain light node is deployed on the target chain to realize the verification of the source chain. To verify the authenticity of the message, in the shared validator scheme, the shared validator completes the verification in the source chain consensus process, and the target chain can be trusted unconditionally.

How to safely custody retained assets

The issue of lien asset custody exists in the scenario of cross-chain asset transfer. As mentioned earlier, the essence of cross-chain asset transfer is to keep assets locked 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 escrow addresses, namely independent control accounts, multi-party multi-signature accounts, multi-party private key sharding accounts, contract accounts, and the combination of the first three and the witness mechanism, forming different sub-types of witness mechanisms; In the chain/relay type cross-chain solution, contract accounts are used to custody retained assets. In fact, the side chain/relay solution can also be combined with the non-contract account custody solution, but almost no project is designed like this, because the contract account has higher security, even if the project actually runs like this, it is more likely It is used as a transition plan before the completion of the custodial contract development.

In fact, in the scenario of cross-chain asset transfer, there is another solution that does not require custodial assets, that is, the Burn-Mint solution. The assets on the source chain are no longer locked, but directly destroyed, and then the target Issue anchored assets on the chain. This scheme is only suitable for chains with a high degree of coupling. Otherwise, the burned assets can no longer be cast in the reverse direction, and the assets cannot be returned after cross-chain. This is obviously unacceptable. Polkadot’s parachain is used to cross-chain tokens, using the Burn-Mint mechanism.

How to perform multi-chain adaptation

The side chain solution for multi-chain adaptation is the relay solution. Through the relay chain, it establishes a mutual side chain relationship with the access chain, which is more suitable than the establishment of this relationship between access chains. The cost of distribution is much lower. Nevertheless, the relay chain is actively compatible with multiple heterogeneous access chains, which is still very troublesome. It needs to be adapted separately. It is better to set up a set of communication standards and chain-making standards from top to bottom to allow more new chains Become a homogeneous chain that can be directly passively compatible.

The witness scheme and the hash time lock scheme are more versatile than the side chain/relay chain scheme. The former can be compatible with the new access chain by setting up an escrow account on the new access chain, while the latter is Only the access chain supports the hash lock and time lock functions to be compatible.

The shared validator scheme is only applicable to homogeneous cross-chains, and cannot be actively compatible with existing heterogeneous chains. If compatibility is required, other cross-chain schemes must be adopted.

summary

Through the above cross-chain technology overview 5 categories:

  1. Atomic swap based on hash time lock
  2. Witness mechanism
  3. Light node side chain
  4. Relay chain
  5. Shared validator

And the 4 dimensions of the understanding of cross-chain technology:

  1. Cross-chain transaction atomicity
  2. Cross-chain message verification
  3. Asset custody
  4. Multi-chain adaptation

We can basically 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.

 

Posted by:CoinYuppie,Reprinted with attribution to:https://coinyuppie.com/connecting-isolated-islands-into-continents-a-panoramic-view-of-cross-chain-technology-and-application-forms/
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.

Like (0)
Donate Buy me a coffee Buy me a coffee
Previous 2021-09-06 13:24
Next 2021-09-06 13:28

Related articles