Jointly produced by Tongzhengtong Research Institute × FENBUSHI DIGITAL
Jointly produced by Tongzhengtong Research Institute × FENBUSHI DIGITAL
Special Advisor: Shen Bo, JX
guide
With the vigorous development of the blockchain industry, a variety of public chains, private chains and alliance chains have emerged, and a question naturally arises: how do chains communicate with each other? This report sorts out the meaning and significance of cross-chain and the key issues that need to be solved in cross-chain, reviews the development process of cross-chain technology, and analyzes the main cross-chain models.
Summary
Summary
Cross-chain is to realize cross-chain interoperability of assets, data, etc. by connecting relatively independent blockchain systems. The main implementation forms of cross-chain include cross-chain asset swap and cross-chain asset transfer.
Before 2013, the development of blockchain was mainly concentrated on a single blockchain. Since 2013, cross-chain technology has developed vigorously, and several main models of cross-chain have been proposed one after another.
Risk warning: Quantum computer technology is advancing by leaps and bounds
Risk warning: Quantum computer technology is advancing by leaps and bounds
Table of contents
Table of contents
1 Cross-chain overview
1.1 What is cross-chain
1.2 Why cross-chain
1.3 Cross-chain development history
1.4 Key issues of cross-chain
2 Main modes of cross-chain
2.1 Hash lock: cross-chain asset swap
2.1.1 Background
2.1.2 Basic ideas
2.1.3 Case: Lightning Network
2.2 Notary Mechanism: Relying on a third party to verify transactions
2.2.1 Background
2.2.2 Basic ideas
2.2.3 Case: Interledger Protocol
2.3 Sidechain/Relay: The target chain verifies transactions by itself
2.3.1 Background
2.3.2 Basic idea
2.3.3 Case: BTC Relay
3 Summary
3 Summary
text
text
With the vigorous development of the blockchain industry, a variety of public chains, private chains and alliance chains have emerged, and a question naturally arises: how do chains communicate with each other? This report sorts out the meaning, significance and key issues of cross-chain, reviews the development process of cross-chain technology, and analyzes the main cross-chain models.
1 Cross-chain overview
1.1 What is cross-chain
Cross-chain, as the name suggests, is to realize cross-chain interoperability of assets, data, etc. by connecting relatively independent blockchain systems.
The main implementation forms of cross-chain include cross-chain asset swap and cross-chain asset transfer.
Cross-chain asset swap refers to the exchange of assets on one chain for assets on another chain of equivalent value, and the total amount of assets on each chain remains unchanged. A simple example of cross-chain asset swap is as follows:
Alice exchanges Bob's 50 ETH with 1 BTC. The result of the successful exchange should be that Alice's ETH address receives Bob's 50 ETH, and Bob's BTC address receives Alice's 1 BTC.
Cross-chain asset transfer refers to the transfer of assets on one chain to another chain, the assets on the original chain are locked, and the assets of the same amount and value are recast on the other chain. The total value of assets on each chain changes, but the two The sum of the total asset value of the chain remains unchanged. A simple example of cross-chain asset transfer is as follows:
Alice transfers 1 BTC on the BTC blockchain to the ETH blockchain, then 1 BTC on the BTC blockchain is frozen, and 50 ETH are newly generated on the ETH blockchain.
1.2 Why cross-chain
Break through the performance and functional bottlenecks of the underlying public chain. With the rapid development of the blockchain network, performance has gradually become a major bottleneck restricting the development of the blockchain. By transferring part of the transaction processing to the side chain or off-chain, the performance of the blockchain network can be improved. Some functional innovations can also be realized through the side chain, thus ensuring the security of the main chain.
Realize cross-chain interoperability. A single blockchain system is relatively closed. With the rapid development of blockchain technology, the issue of "interoperability" between chains has gradually become prominent. Specific application scenarios for cross-chain interoperability include but are not limited to cross-chain payment and settlement, decentralized exchanges, and cross-chain information interaction.
1.3 Cross-chain development history
Before 2013, the development of blockchain was mainly concentrated on a single blockchain. Since 2013, cross-chain technology has flourished, and several main cross-chain models (Notary schemes, Sidechains/relays, and Hash-locking) have been proposed one after another.
In May 2013, Tier Nolan proposed "atomic transfers" in the BitcoinTalk forum. Atomic transfers are also called atomic swaps. There is a third intermediate state. This scheme has been improved to become a main mode of cross-chain, that is, the hash lock mode.
In October 2014, BlockStream clearly proposed the concept of sidechains for the first time. Pegged sidechains (Pegged Sidechains) use the two-way peg mechanism to enable encrypted assets to be transferred between the sidechain and the main chain at a certain exchange rate. transfer. In December 2016, BlockStream further proposed Sidechains with Strong Federations, which reduces latency and improves interoperability by introducing multi-signature addresses controlled by multiple parties.
In February 2015, Poon released the Lightning Network (Lightning Network) white paper, based on hash locking to realize asset BTC off-chain transactions.
In October 2015, the Interledger Protocol white paper was released, based on the notary mechanism to realize the conversion of assets between different ledgers.
In May 2016, BTC Relay realized the one-way cross-chain connection from BTC to ETH based on the relay.
In 2017, Polkadot and Cosmos proposed a cross-chain infrastructure relay platform solution.
1.4 Key issues of cross-chain
The two key issues in realizing cross-chain transactions are the atomicity of cross-chain transactions and the verification of cross-chain transactions. By ensuring the atomicity of cross-chain transactions, cross-chain asset swaps can be realized. In practice, it mainly relies on hash locking. Cross-chain asset transfer also requires cross-chain transaction verification.
The atomicity of cross-chain transactions means that cross-chain transactions either succeed or fail, and there is no third intermediate state. A complete cross-chain transaction is composed of multiple sub-transactions. The sub-transactions occur in different blockchain systems and are independent of each other. The atomicity of cross-chain transactions requires that after a sub-transaction is successful, subsequent sub-transactions can also If it succeeds, or the subsequent sub-transaction fails, the previous sub-transaction can be withdrawn.
Cross-chain transaction verification refers to the verification of transactions on another chain. Verification includes two aspects, one is that the transaction has been written into the ledger and meets the finality, and the other is cross-chain data transfer, one chain can verify the transaction status of the other chain.
2 main modes of cross-chain
The atomicity of cross-chain transactions can be guaranteed through hash locking. For the two independent blockchains, in order to achieve cross-chain transaction verification, it has to rely on an external third party for information interaction. According to the scope of work of the third party, it can be divided For the notary mechanism and relay mode.
Under the notary mechanism, a third party is responsible for data collection and transaction verification.
In the relay mode, the third party is only responsible for data collection, and transaction verification is done by the target chain.
2.1 Hash lock: cross-chain asset swap
2.1.1 Background
Hash locking originated from atomic swap. The earliest application was BTC's Lightning Network, which provides a scalable micropayment channel and solves the transaction congestion problem of the blockchain network by transferring some transactions to off-chain.
2.1.2 Basic idea
Simply put, the hash lock mode uses hash locks and time locks to ensure the atomicity of cross-chain transactions, that is, transactions can only be completed if certain time conditions and hash conditions are met. HTLC (Hashed Time-Lock Contract) is a specific implementation of the atomic swap protocol.
Hash lock: Alice performs a hash operation on the key a to obtain H(a), and tells Bob the function H and H(a), and Bob uses H and H(a) to verify the correctness of the key provided by Alice.
Time lock: Taking the BTC system as an example, there are two ways to realize the BTC time lock, one is absolute locking, that is, the retracement transaction does not take effect within a certain time range, and the other is relative locking, that is, relative to a certain time or event-locked transactions.
HTLA (Hashed Time-Lock Agreements, Hashed Time-Lock Agreement) is a generalized agreement of HTLC, proposed by Interledger. Under the agreement, any centralized or non-centralized ledger can use HTLA to realize cross-chain asset exchange regardless of whether it supports HTLC or not.
2.1.3 Case: Lightning Network
The Lightning Network was proposed for the BTC network, and its main network was launched on March 15, 2018. On March 20, 2018, the Lightning Network was attacked by DDOS, and more than 200 nodes were attacked and offline. Since the launch of the Lightning Network mainnet, the number of nodes, channels and network capacity have continued to grow. According to data from BitcoinVisuals, as of April 24, 2019, the number of Lightning Network nodes exceeded 4,200, the number of channels exceeded 38,000, and the network capacity was about $5.75 million .
The two main protocols of the Lightning Network are RSMC (Revocable Sequence Maturity Contract) and HTLC (Hashed Time-Lock Contract). The role of RSMC is to encourage both parties to the transaction to use the channel for transactions as long as possible, and punish the transaction party who actively terminates the channel, that is, the party who voluntarily terminates the channel will receive funds later. With the existence of HTLC, even if there is no payment channel between the parties to the transaction, as long as a payment path can be found, the transaction can be realized.
(1) Create a transaction
Alice and Bob transfer money through the Lightning Network. Both parties take out 0.5 BTC to construct a margin transaction FundingTx, and the output requires multiple signatures from Alice and Bob. At this time, both parties have not signed the Funding Tx, and the transaction is not broadcast to the blockchain.
Alice and Bob respectively construct Commitment Tx: Alice constructs C1a and RD1a, Bob signs and hands it to Alice; Bob constructs C1b and RD1b, Alice signs and hands it to Bob. After both parties complete the signing and exchange of commitmentTx, they will sign FundingTx.
The first output of C1a requires Alice's other private key Alice2 and Bob's multi-signature, and the second output is 0.5BTC to Bob. RD1a is the first spending transaction output by C1a, which is output to Alice 0.5BTC. This type of transaction has a sequence, which prevents the current transaction from entering the block. Only the forward transaction C1a can be packaged into the block after sequence confirmation.
Since C1a and C1b spend the same output, only one of these two transactions can be included in the block. If Alice broadcasts C1a, Bob immediately gets 0.5 BTC (the second output of C1a), and Alice needs to wait for C1a to get sequence=1000 confirmations before getting 0.5 BTC through the output of RD1a. Similarly, if Bob broadcasts C1b, Alice immediately gets 0.5 BTC, and Bob needs to wait for C1b to get sequence=1000 confirmations before he can get 0.5 BTC through the output of RD1b.
(2) Transaction update
The RSMC update process is as follows: Alice pays 0.1 BTC to Bob, and both parties create a new CommitmentTx, that is, Alice creates C2a and RD2a, and Bob creates C2b and RD2b. At this time, the invalid states C1a and C1b need to be discarded.
Alice hands Alice2's private key to Bob, indicating that Alice gives up C1a and accepts C2a. The existence of the sequence in RD1a allows Bob to implement a penalty transaction within a certain period of time after Alice defaults, that is, if Alice defaults, Bob can modify the output of RD1a to himself, that is, form a transaction BR1a, and Alice will face the penalty of losing all her deposit. This mechanism allows both parties to choose to delete the old state and broadcast the updated state.
(3) Transaction closed
Commitment TX is constructed according to the final balance, without setting up multi-signatures and constructing penalty transactions, etc. The hash lock mode realizes cross-chain asset exchange. The total amount of assets on each chain remains unchanged, but the asset holders have changed. Cross-chain asset transfer needs to ensure the authenticity of cross-chain transactions, so it involves implementing Two modes of cross-chain transaction verification: notary mechanism and side chain/relay mode.
2.2 Notary Mechanism: Relying on a third party to verify transactions
2.2.1 Background
In October 2015, the Interledger Protocol (ILP, Interledger Protocol) white paper was released. This protocol was created by Stefan Thomas and Evan Schwartz. Its purpose is to make cross-ledger transactions more convenient. Ripple subsequently introduced this protocol. The reason why it is called cross-ledger instead of cross-chain is because the protocol not only supports decentralized blockchain ledgers, but also supports centralized ledgers of banks and other institutions, which is a broader "cross-chain".
2.2.2 Basic idea
Data collection and transaction verification are performed by one or a group of nodes as notaries. The notary simultaneously tracks the status of the two chains and informs the other party, and both parties to the transaction rely entirely on the notary to verify and implement the transaction.
According to the composition and signature method of the notary, the notary mechanism is divided into three categories. The notary can be acted by one or a group of nodes. A notary is a centralized notary mechanism. In the case of a group of nodes as a notary, it is divided into multi-signature notaries according to the signature method of each node. Mechanism and Distributed Signature Notary Mechanism.
Centralized notary mechanism: A single node or institution acts as a centralized notary. The centralized notary mechanism is a relatively simple model. Similar to the traditional indirect transaction between two subjects through a third party, the notary is compatible with two or more systems at the same time. Its advantages lie in fast processing speed and relatively simple technical structure, but The problem with this method is also obvious, that is, the security risk of the centralized notary.
Multi-signature notary mechanism: Multiple notaries sign together on their respective ledgers to reach a consensus. This mechanism weakens the centralization problem of the centralized notary mechanism, and the security is relatively higher, provided that the transaction chain needs to support the multi-signature function.
Distributed signature notary mechanism: The main difference from the multi-signature notary mechanism is the use of multi-party computing distributed signatures. For cross-chain transactions, the system only generates one key, which is sent to each notary node in fragments.
2.2.3 Case: Interledger Protocol
Interledger Protocol was originally a representative of the notary mechanism and incorporated the concept of hash locking into the development process. Under this agreement, senders and receivers in different ledger systems can conduct cross-ledger transactions through one or more connectors, and the connectors provide services for forwarding data or funds and charge corresponding fees. By providing fund custody for participants in cross-ledger transactions, only when the ledger receives proof that the recipient has received the funds, will the corresponding funds be sent to the linker, and at the same time ensure that when the linker fully implements the agreement, it will Receive funds from sender. There are two ways of transaction custody and execution. Among them, "atomic mode" is a group of notaries selected by participants to coordinate transactions; Safe payment.
2.3 Sidechain/Relay: The target chain verifies transactions by itself
2.3.1 Background
In 2014, BlockStream clearly proposed the concept of side chain for the first time. In October 2014, BlockStream released the white paper "Enabling Blockchain Innovations with Pegged Sidechains", which clearly proposed the concept of side chains for the first time. According to the definition in the white paper, a side chain is a blockchain that verifies data from another blockchain. Anchoring (two-way peg) mechanism, encrypted assets can be transferred between the side chain and the main chain according to a certain exchange rate.
The background of the side chain: the trade-off between BTC innovation and security. On the one hand, with the development of blockchain technology, more and more innovations have begun to appear. Smart contracts and decentralized applications brought by Ethereum and Bitshares are widely sought after by people. On the other hand, BTC needs to be developed in many aspects such as performance and functions. However, due to security considerations, BTC innovation has been relatively conservative; on the other hand, the emergence of a large number of competing tokens and counterfeit tokens has also aroused the concerns of the BTC core development team about development and market fragmentation. The sidechain can achieve performance and functional expansion under the condition of ensuring the security of the main chain, making it an ideal choice for BTC. In this case, Adam Back, Matt Corallo and other BTC core developers jointly initiated the establishment of BlockSream.
2.3.2 Basic idea
In the side chain/relay mode, the target chain does not rely on a third party for transaction verification, but verifies the data from the sending chain by itself. The specific verification methods are different. For example, BTC-Relay uses SPV (Simple Payment Verification, simple payment verification) for transaction verification, Cosmos is through the number of node signatures.
2.3.3 Case: BTC Relay
BTC Relay is a smart contract on ETH that verifies BTC transactions by storing BTC block headers. Since the transaction information of the BTC blockchain is stored in the block header in the form of a Merkle tree, BTC Relay can use the SPV mechanism to verify BTC transactions. The function realization of BTC Relay depends on the relayer to submit the correct block header data, and the relayer who submits the correct block header data in time will be rewarded. BTC Relay enables ETH users to create smart contracts that depend on BTC blockchain events through a relatively simple design, but BTC Relay only implements a one-way cross-chain from BTC to ETH.
2.3.4 Case: Cosmos
In June 2016, Jae Kwon proposed Cosmos, which supports the entry and interoperability of various blockchains. Cosmos consists of two parts: Hub (hub) and Zone (partition). The partition adopts the Tendermint consensus, which can support multiple blockchains, and the number of partitions can be expanded. Transactions between partitions are carried out through the hub in accordance with the IBC protocol (Inter Blockchain Communication Protocol, inter-chain communication technical specification). The IBC protocol defines blockchain registration, data packet format, transaction type, and data packet delivery confirmation process.
The Tendermint consensus process is similar to the BFT consensus. At the beginning, the nodes propose a new round of blocks. The qualified proposal blocks will enter the pre-commit link if they receive more than 2/3 of the votes in the pre-vote (Prevote) link. Official approval (Commit) will be obtained after more than 2/3 of the pre-approval is obtained.
2.3.5 Case: Polkadot
In November 2016, the Polkadot white paper was released, proposing a heterogeneous multi-chain architecture that supports decentralized and trustless interoperability and access of multiple highly differentiated consensus systems. The Polkadot network consists of a relay chain (responsible for coordinating consensus and transactions between chains), parallel chains (Parachains, responsible for collecting and processing transactions), and bridges (Bridges, responsible for connecting other heterogeneous blockchains).
The four types of participants in the network include validators (Validators, responsible for verifying the data of the parallel chain), collectors (Collator, responsible for collecting data of the credit endorsement) and Fisherman (Fisherman, responsible for reporting and proving malicious behavior).
The simple process of Polkadot cross-chain transaction information transmission is as follows:
(1) The collector on the parachain A collects the transaction and verifies the validity of the transaction, and packs the transaction into the block;
(2) The verifier verifies that the block it receives contains only valid transactions, and pays a certain deposit;
(3) After the nominator pays enough deposit for the verifier, broadcast the block to the relay chain;
(4) The verifier reaches a consensus on the relay chain block and transmits the transaction information of the parachain A to the parachain B.
3 Summary
In general, cross-chain technology has developed rapidly in the past few years, and related projects have emerged in an endless stream. Among the existing cross-chain related projects, projects based on the side chain/relay model account for the highest proportion; the number of nodes, the number of channels and the network capacity of the Lightning Network based on hash locking have been continuously increasing since the main network was launched, and the technical feasibility has been compared. Good verification; in addition to the three main cross-chain modes mentioned above, there is another type of project that realizes blockchain access by specifying a series of communication data formats and protocol specifications. This type of project is called a communication protocol cluster project. This type of project will Whether it can become a mainstream cross-chain solution depends to a certain extent on the industry's acceptance of relevant standards and specifications.
Due to some reasons, some nouns in this article are not very accurate, mainly such as: general certificate, digital certificate, digital currency, currency, token, crowdsale, etc. If readers have any questions, they can call or write to discuss together.
Note:
Due to some reasons, some nouns in this article are not very accurate, mainly such as: general certificate, digital certificate, digital currency, currency, token, crowdsale, etc. If readers have any questions, they can call or write to discuss together.
This article was originally created by TokenRoll Research Institute (ID: TokenRoll). Unauthorized reprinting is prohibited. For reprint, please reply to keywords in the background【Reprint】
