Original author: MIDDLE.X, researcher at Paka Labs
Original editor: Shawn Lin, founder of 1 PAR Research
Thanks:
Buffalo, Bifrost System Architect
Robin Wei, Technical Education Specialist, Darwinia
Xu Liucheng, technical director of ChainX
Consulting assistance was provided during the writing of this article
first level title
1 Introduction
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.
first level title
secondary title
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 exchanged credibly, but the exchange of certificates between the 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.
secondary title
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.
secondary title
2.3 Information transmission
The full sense of cross-chain 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 certificate, and transmits the lock-up message and its proof 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.
Therefore, we can say that 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.
first level title
3. 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; some forward messages and verify status by establishing a set of roles on the chain, and some propose a set of communication protocols. Realize communication between blockchains; some propose new system architectures and chain-building protocols to support access to more blockchains.
secondary title
3.1 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 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 sends the m value 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, 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, he also initiates a transaction to transfer 10 ETH to user A. The success of this 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 cannot deduce r;
After user A sees the transaction initiated by B, he 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 obtained the r value presented by A in the previous step, making the transaction initiated by A successful and obtaining 1 BTC transferred by A.
Through the above mechanism, transactions on two different chains are coupled into one event, which can only succeed as a whole, or fail as a whole. There will be no situation where the transfer from A to B succeeds, but the transfer from B to A fails, and vice versa. Of course.
The realization of this mechanism depends on two technologies, that is, "conditional success transaction" and "conditional failure transaction". If the pre-hash image r is not produced beyond the preset time, we can also call it hash lock and time lock respectively.
In BTC, hash time locks can be implemented through CLTV opcodes or CSV opcodes, and on Turing-complete chains such as Ethereum, 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 the participation process is strictly enforced. Therefore, if the transaction initiator cannot find an online counterparty, it 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.
secondary title
3.2 Witnesses
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 projects have different settings for witnesses: 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 realize 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 from Witnesses are overcollateralized.
3.2.1 Witness generation method
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 Witnesses
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 under custody. If the assets under custody are lost, the user will get compensation from the deposit. 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 can also rely on their own goodwill to endorse. Although there is a trust assumption, 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
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.
In more 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 that 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 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 sharding
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.
The reason why private key sharding is more secure is that the sharding is constantly refreshed, that is, every once in a while, the sharding will be done again, 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 the signer group members can be set through smart contract programming. For example, more than 2/3 of the existing signers sign and agree to approve the addition of new signers. Or approve the removal of an old signatory.
On BTC, the signer group members of a P 2 SH multi-signature address cannot be edited. If a signer’s private key is leaked or needs to be withdrawn, a new P 2 SH multi-signature address can only be recreated, and the Assets are transferred to the new address.
3.2.4 Improvement towards decentralization
secondary title
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. Anchor (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 ".
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 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 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 the B chain;
The light node contract of chain A deployed on chain B, through SPV proof, recalculates the hash value of the block header of the block where the exchange is located;
The obtained hash value is compared with the corresponding block header hash value in the light node. If they are consistent, it means that the transaction did occur in the block. If not, it means that the transaction does not exist in the block.
Although anyone can submit transaction details and their SPV proofs to the target chain, in actual cross-chain applications, there are often dedicated roles 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, like witness, is a specific role for passing cross-chain messages, but there are two differences between relayer and witness:
Relayer is not responsible for the custody of assets. If the side chain mechanism is used to achieve cross-chain, the tokens locked during the cross-chain process will be escrowed in a specific escrow contract.
The trust assumptions for Relayers are looser than for 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.
Relayers are called differently in different cross-chain projects. 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 for each other. 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.
By burying each other's light nodes, both parties across the chain can read 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 chains. 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 it from 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.
Some of Ethereum’s 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 expands the performance of the main chain by moving transactions 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 capacity 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.
This one-way information submission interaction between the sub-chain and the main chain is also considered a form of cross-chain technology in some literature, but Paka Labs believes that although both side-chains and sub-chains were born in the same area Block chain expansion efforts, but sub-chain related technologies 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 (verification)! The transaction information is verified through the block header, and its reliability is guaranteed in cryptography. You know it, you know it for sure.
The block header passed by Relayers is also impossible to falsify, because the light node contract can strictly verify the block like the full node, and the false 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 be verified by the following steps:
The block data structure is syntactically valid;
Verify the proof of work, the hash of the block header is less than the target difficulty (confirmation contains enough proof of work);
The block timestamp is two hours earlier than the verification time (time errors are allowed);
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) is a coinbase transaction, that is, a block, and miners can only reward themselves 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, 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 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 enough Confirmation of multiple blocks is enough (for BTC light nodes, just wait for 6 blocks). For BFT chains, the light node contract only needs to verify the signature number of the block to know whether the block is final.
Only when the source chain or the target chain itself is reorganized will the security of the light node contract be affected. The harm Relayer can cause to the network is at most limited to a collective strike, causing the network to stop service.
In addition, the relayer is not responsible for managing the custody assets, and a malicious relayer cannot steal custody 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.
Since the conditions for Relayers to do evil are harsh and less harmful, Relayers in the light node side chain do not need to over-collateralize like witnesses. More cross-chain anchor asset issuance can be achieved with less 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 realize the cross-chain between the 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 The development of light node technology: "slimming" and "burden reduction"
We know that the block size of BTC is 1 M, and its block header is only 80 bytes. Until the time of publishing this article, the historical block header size of BTC has not exceeded 60 M (height is about 690,000). The sum of historical block headers has exceeded 5 G (height is about 13 million). With the diversified development of blockchain, some emerging blockchains are more focused on high TPS, and the speed of block generation is extremely fast. The volume may soon surpass that of Ethereum.
This trend has brought challenges to the light node side chain, which is 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 frequently synchronize and verify new blocks.
Both of these will cause a huge gas consumption of the light node contract on the target chain, and in severe cases, it will become economically unfeasible to use the light node side chain technology to achieve cross-chain.
what to do? Back to the Witness scheme? 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 sidechain 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 is a new light node protocol proposed by Benedikt Bunz et al. of Stanford University in the paper "FlyClient: Super-Light Clients for Cryptocurrencies". 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".
Merkle Mountain Range (MMR) for short is a variant of Merke Tree. We use the hash values of all historical blocks of a blockchain as leaf nodes, and through the MMR algorithm, Generate an MMR root value and write this value into the latest block header, which can be used to verify all historical block headers.
The FlyClient light node can continuously delete the historical block headers and only keep the latest block headers to keep it "light". 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 a probabilistic final chain, 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 checks. 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.
The Flyclient light node truly realizes "compressing the elephant into a biscuit", allowing the source chain light node contract deployed on the target chain to be light and simple, and making 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. If the block generation speed of the source chain is fast, the Gas consumption of this link may be unacceptably large.
secondary title
text
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, the relationship of mutual side 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 connected to the relay chain, then It is the same as connecting the terminal equipment at home with the router. In this way, the cost immediately drops from n(n-1)/2 to n (where n is the number of chains).
The relay scheme is a variant of the sidechain scheme, and it is reasonable to classify it with the sidechain as a technical scheme. 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, and Relayers is inside it. Reach a consensus 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 the two lies in the difference in their cross-chain communication paths:
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 is a message transfer station that establishes a mutual side chain relationship with each access chain. Many literatures do not make a strict distinction between these two concepts, but the essence of the two is completely different.
3.4.1 Connecting existing blockchains
In the relay mode, the validator of the relay chain is often responsible for assuming the Relayer function 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 to the existing blockchains, it is necessary to use the relay chain to adapt the access chains 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 chains, and to do active compatibility, which requires a large workload;
The security of different chains is different, and it will involve the cross-chain credit granting of different access chains 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
Compared with active compatibility, there is a more trouble-free way, which is to create a brand-new blockchain chain building standard. The blockchain developed according to this standard has the same Cryptographic Primitives, consensus mechanism and communication architecture. It can be easily connected to the relay chain to achieve 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.
The cross-chain project of communication protocol cluster + chain-building protocol is 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 to make a certain relay chain become the layer 0 of the blockchain world, and other chains, including the majority isomorphic Chains, and the minority heterogeneous chains, are connected in the form of layer 1, layer 2….
secondary title
3.5 Shared validators
Cosmos and Polkadot, which are also communication protocol clusters + chain-building protocols, both contain the idea of relaying, but with a little attention we find that the difference between the two is huge.
Cosmos' Hub and Zone establish a typical "two-way anchor" 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 use light node technology to verify the legitimacy of cross-chain messages, but uses another method, which Paka Labs extracted and called “Shared Verification People", listed as a separate category of cross-chain technology. (More analysis on XCMP and IBC will be carried out in the subsequent chapters with examples.)
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 Polkadot does not allow all validators to verify all chains, but adopts 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.
first level title
4. Understanding framework of cross-chain technology
There are nearly a hundred active cross-chain projects today. Different cross-chain bridges adopt different cross-chain technical solutions. Projects using the same type of technical solutions have different designs and different names for system roles. Splitting, creating more roles, merging role functions, omitting some roles, and some projects using multiple cross-chain technologies comprehensively, it can be said that it is dazzling, but if you understand the essence of cross-chain technology clearly, Then you can eliminate the false and preserve the truth, and understand thoroughly. For this, we need a cognitive framework for understanding cross-chain technology.
We can start with the problems to be solved across chains:
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 sub-transaction 1 is completely successful (full success means that the transaction is packaged into a block and forms finality), sub-transaction 2 can be carried out, and so on, only when sub-transaction 2 is completely successful, can sub-transaction 3 be carried out;
If sub-transaction 3 fails, keep the success status of sub-transaction 2, allowing users to retry sub-transaction 3 repeatedly;
If sub-transaction 3 always fails, the user can withdraw sub-transaction 2 and sub-transaction 1 successively.
Except for hash time locks, 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 that a transaction has formed finality? 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 being reversed in the block is extremely low.
secondary title
text
A blockchain system is closed and independent to another blockchain system. Each chain is a "Walled Garden" and cannot directly perceive the transactions and their status in another chain. 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 cross-chain technology, no matter how it evolves, cannot avoid the role of a "middleman", and the systems are independent of each other. When a cross-chain transaction is initiated, how can the target chain confirm the identity of the source chain before issuing the mapped assets? Has the locked position transaction been completed? 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.
secondary title
4.3 How to Safely Custody Lien Assets
The issue 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, which 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 chain/relay 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.
secondary title
4.4 How to perform multi-chain adaptation
The solution for multi-chain adaptation of the side chain scheme is the relay scheme. Through the relay chain, the relationship with the access chain is established as a side chain one by one. Compared with the establishment of this relationship between the access chains, it is more suitable. The distribution 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.
The witness scheme and the hash time lock scheme are 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 is It is compatible only if the access chain supports the hash lock and time lock functions.
secondary title
4.5 Summary
Overview of 5 categories through the above cross-chain technology:
Atomic Swap Based on Hash Timelock
Witness Mechanism
Light node side chain
relay chain
shared validator
Atomicity of cross-chain transactions
Cross-chain message verification
asset custody
multi-chain adaptation
And the four dimensions of cross-chain technology understanding:
We can basically accurately 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.
IOS
Android