Understanding the future possibilities of cross-chain Technology: What are the opportunities and advances?
Original title: What Are the possibilities for Cross-chaining in 2023?
The original author: hzw
Cross-chain technology seems to be a controversial, but constantly mentioned technology. In particular, whenever a cross-chain bridge is stolen, the controversy over cross-chain technology will arise. On the other hand, as technologies such as IBC and LayerZero continue to mature, it seems that the community's expectations for a cross-chain future will stop there.
So, this is cross-chain endgame, right? Well,
This is not the end. It is not even the beginning of the end. But it is, perhaps, the end of the beginning.
Cross-chain has seen a number of new developments in 2022 in recent months. Recently, I have been invited for several cross-chain sharing opportunities to record my observations and thoughts on cross-chain technology and trends.
A hierarchical overview of cross-chain technology
1. Understand cross-chain through layers
Before understanding these developments, it is worth recalling the specific question of cross-chain: when we talk about cross-chain, what is the specific nature behind it? How to understand cross-chaining in terms of "first principles", to use the popular term of late.
If the core or most different feature of blockchain from other technologies is detrusting, that is, information can be verified on the chain without trust, then cross-chain is actually how information on a chain can be verified between chains. In a broad sense, the information transmitted includes the transaction and the validity proof of the transaction (generally known as merkle proof).
Accordingly, based on the information that can be verified on the chain, blockchain can build basic types of applications such as asset transfer transactions. Based on the verified cross-chain information, some cross-chain applications can also be built, such as using the most common lock & mint (the source chain is locked and issued on the target chain) to transfer tokens across chains.
Therefore, according to the different problems solved by "cross-chain" technology or project, it can be classified from two aspects: communication layer and application layer.
2. Cross-chain technology classification
Communication layer
Let's start with the communication layer. How can information on one chain be verified by another chain? According to the different verification parties, it can be divided into external verification, local verification and native verification
External verification: Cross-chain messages are validated by external witnesses (also known as notary public, gateways, etc.). In general, this method can connect various heterogeneous chains more quickly, because it only requires witnesses to read and write information on each chain. However, the validity of cross-chain information, such as whether the transaction information is really confirmed in the source chain, depends on witnesses. That is, the security across the chain depends on the assumption of honesty on the part of witnesses.
Local verification: without relying on external witnesses, the user can directly observe the transactions on the chain and work with the counterparty to ensure that the swap transaction can be concluded through HTLC and other technical means. This method avoids the trust of third party witnesses, and can also quickly realize cross-chain transfer on heterogeneous chains. However, the disadvantage is that it is difficult to implement more complex applications, such as universal information transfer and smart contract call.
Native verification: The blockchain itself independently verifies the legitimacy of cross-chain information. Generally, it will be implemented in the form of light client integrated with other blockchains, so that the blockchain can track, obtain and verify information on other blockchains, and take some corresponding actions, such as cross-chain transfer and token release. Because there are many heterogeneous chain models, a kind of cross-chain standard is needed to simplify the design and implementation, such as IBC cross-chain protocol. This cross-chain technique is the most secure because it does not require additional trust assumptions, but it also requires more development effort due to the need to implement light clients on each other's chains, and possibly the need to implement complete cross-chain protocol stacks, etc.
The application layer
It's not enough to have the underlying communication layer; you need to build a user-facing application as well. Theoretically, cross-chain applications that do not require strong transaction consistency can be constructed based on the underlying cross-chain information verified. However, the most common form of transactions should still be cross-chain token transfers and other basic forms. Therefore, the problem is mainly how to solve the transfer of liquidity across the chain. The solutions to such problems can be divided into central counterparty, OTC/P2P, and Swap by referring to transaction types.
Central counterparty: This is usually used in the "official chain bridge", where the official address is responsible for the swap in and swap out operations. lock & mentioned above; The form of mint. For example, when the user initiates a cross-chain on the source chain, the token is locked to an address, and the address is cast on the target chain token;
OTC/P2P: In addition to official exchange duties, counterparties can also be third-party market makers or other users. For example, when a user posts liquidity for a cross-chain transfer, the cross-chain market maker can receive this offer and release liquidity for the user on the target chain.
Automatic Swap: In addition to the transaction between users, the counterparty of the transaction can also be an automatic swap protocol. For example, after the user swaps in on the AMM of the source chain, the protocol swaps out on the target chain.
Liquidity aggregation: Similar to 1inch and other liquidity aggregation protocols on this chain, some protocols are implemented by aggregating the aforementioned cross-chain liquidity to provide inter-chain liquidity aggregation applications, so as to provide users with the best liquidity/best offer/lowest cost cross-chain transfer channels.
Second, what are the possibilities of cross-chain
1. The bottom layer is lighter
Although the IBC protocol is regarded as the gold standard for cross-chain implementation, there may be some practical difficulties in implementing heterogeneous chains, such as Ethereum's signature calculations for natively verifying the Tendermint block header, which may exceed the gas limit.
From relay to prophecy
The role of repeater is required for the IBC protocol to run properly. A somewhat "counter-intuitive" point is that the repeater can be centralized but does not need to be trusted. The reason is that the transmitted information can be independently verified by the target chain, so the repeater cannot tamper with the message to achieve the evil behavior of stealing user funds like external verification. The repeater, which is similar to the physical layer of Internet protocol, connects different networks and transmits information.
Although there is no repeater dependency for the security of the IBC protocol, it does require at least one functioning repeater to ensure liveness of the protocol.
However, the main task of repeater is to observe the source chain information and submit it on the target chain, that is, to complete the process of information transmission. This process, then, can be achieved by means of a prophecy machine. That is, the transmission of information from the prediction machine from "chain to chain" to "chain to chain".
This is probably one of the reasons why many prediction projects, such as Chainlink CCIP[1] and SupraOracle, are moving towards cross-chain implementation.
From the Prophecy Machine to TEE
So, what exactly can be transmitted by the prophecy machine? LayerZero is a good example. It is to verify the consensus status of IBC protocol by means of a predictor, that is, it is no longer necessary to update and verify the block header according to the latest verifier and other changes, but to query and verify the required information by the predictor when needed.
LayerZero leaves some of the work of the light client to the prophecy machine [2]
This can greatly reduce the cost of on-chain verification, while the original relayer, which is responsible for transmitting information between chains, only needs to transmit the cross-chain transaction and its proof. So LayerZero can quickly connect multiple EVM chains. However, due to the introduction of an additional security assumption of a third-party predictor (which requires trust that the predictor will not collude for evil), the system security is reduced to a certain extent. Other possible implementations include off-chain workers, using Substrate as "primitive predictor" [3].
Therefore, one way to reduce the reliance on the predictor is to improve the block header synchronization through other techniques. For example, LCP Network uses TEE (Trusted execution environment) to verify cross-chain transactions [4].
From Merkle proof to ZK proof
In addition to how to solve the transmission of information, there have been some recent explorations of how information (including proof of information) is itself constructed using zero-knowledge proof techniques. Reviewing the definition of cross-chain at the beginning of this paper, one of the core messages to be transmitted by cross-chain is the validity proof of transactions. Current cross-chain implementations typically utilize Merkle proof.
Another big category of validity Proof is ZK Proof corresponding to the current hot zero-knowledge proof technology. The recent development of zero-knowledge proof and other technologies also makes ZK Bridge based on zero-knowledge proof gradually possible from theory [5].
By generating zero-knowledge proof, it can be used to solve the above-mentioned problem of difficult cost of verifying Ed25519 and other signatures on Ethereum. For example, Electron Labs verifies the validity of signatures based on the Tendermint chain by implementing ZK SNARKs proofs [6], so as to avoid high-cost computations related to signatures in smart contracts.
Design of IBC on Ethereum by zero-knowledge proof [6]
Other teams and projects currently developing ZK cross-chain Bridges include Succinct Labs, zkbridge[7], Polymer[8], and Mina[9].
At present, part of the cross-chain design based on zero-knowledge proof [7]
2. Better development support (general information, smart contract invocation)
The above underlying cross-chain protocol can better support the transfer of general information, including smart contract calls and so on. Therefore, many projects have started to do further encapsulation on this basis, providing SDK, etc., to support application developers to develop multi-chain, full-chain (omni chain) applications.
These include IBC Interchain Account[10], Multichain anycall, Celer IM, etc. More user-friendly middleware (such as Spanning Labs, and so on) can also be developed based on these underlying cross-chain protocols to support the development of applications with multi-chain deployments and cross-chain settlement. That is, the previous application layer needs to care about how to transfer tokens across the chain and other work devolved to the middleware or the bottom layer to achieve.
3. Application layer mobility
Based on cross-chain bottom layer, middleware, etc., there can be more innovative design on application layer mobility. For example, the recently proposed slAMM[11] (AMM for Shared Liquidity) coordinates liquidity across "satellite chains" through Hub chains. Among them, the cross-chain protocol can be based on the realization of liquidity in each chain, settlement and other management functions.
Design and Difference of dAMM and slAMM [11]
4. "Reaction" to the protocol layer
Cross-chain is generally considered to support the underlying protocol layer of the blockchain. But as cross-chain technology develops, it may in turn change the future design of the blockchain protocol itself.
Improvements to consensus
The first impact is on blockchain consensus.
Due to the design of application chain + cross-chain, many application chains may not be able to maintain their own security at the beginning of the design, so it is necessary to adopt a certain cross-chain verification method to ensure the security of small networks by large networks. For example, Cosmos interchain security, Polkadot relay chain + parallel chain design, etc.
In addition to the one-way cross-chain verification around the main chain, another possibility is the recently proposed Mesh Security [12], that is, cross-chain verification between networks. As the idea is still relatively early, the specific design, implementation remains to be seen.
Mesh Security example [12]
Impact on MEV
Another big impact is the design of MEV (maximum extractable value). The single-chain MEV industry is already large. According to Chorus One statistics [13], as of October 2022, there have been more than $1 billion of MEV accumulated on Ethereum.
The design of the cross-chain protocol takes into account the design of the MEV, which may have an impact on the current MEV landscape. For example, Cosmos 2.0 white paper [14], Zenith[15] and other block space marketization. For example, with an Interchain Allocator:
Interchain secure (shared secure) consumer chains provide block space
Users buy to ensure lock in cross-chain arbitrage, settlement opportunities, etc
Write in the last
Although the main focus of technological innovation in the blockchain industry is still on Ethereum ZK, AA, MEV, etc., but the recent BUIDL cross-chain protocol, in terms of lightweight underlying protocol, more perfect development support, liquidity application innovation, reaction to the protocol layer, In particular, ZK bridge has a lot of new developments to look forward to. However, due to the rapid progress of technology, many projects, this point of small summary of the inevitable omissions and errors, welcome to contact discussion! There is concern about progress. In the recent cross-chain recent, we have shared several on-chain observations and observations of our own various technologies and dynamics.
Welcome to join the official BlockBeats community:
Telegram Subscription Group: https://t.me/theblockbeats
Telegram Discussion Group: https://t.me/BlockBeats_App
Official Twitter Account: https://twitter.com/BlockBeatsAsia
