Original Author: Cynic
Original source: LK Venture Research
Today, Ethereum occupies half of the blockchain industry infrastructure, but its dominance of the main network is being challenged by many latecomers. One of the general consensuses in the industry is that the future may be a multi-chain coexistence pattern, and cross-chain or even the whole chain is the most critical link in the multi-chain ecology.
However, the security issues of cross-chain bridges connecting various blockchain networks are frequent, and the cross-chain ecology seems to be in jeopardy. The emergence of ZK Bridge (a cross-chain bridge using ZK zero-knowledge proof technology) will effectively solve various defects of the current cross-chain solution and make the interconnection of ten thousand chains possible.
Heimdallr Guards the Rainbow Bridge
Image credit: Klugh, Maria Tales from the Far North (Chicago, IL: A. Flanagan Company, 1909)
In Norse mythology, Heimdallr is a mysterious and important deity responsible for guarding Bifröst, the rainbow bridge connecting Asgard and Midgard. If we compare the Rainbow Bridge connecting different gods and human worlds to a cross-chain bridge, then can zero-knowledge proof technology shoulder the heavy responsibility of guarding cross-chain security, and achieve the myth of "Heimdall" on the Rainbow Bridge? ?
This article is an all-round analysis of the ZK Bridge track by the LK venture investment research team, and strives to look forward to the development space of zero-knowledge proof technology in solving cross-chain security and high-performance bottlenecks.
TL;DR
- What is ZK Bridge? ZK Bridge is a cross-chain bridge using zero-knowledge proof technology, which has the characteristics of zero trust, no permission, scalability and high efficiency.
- Why is ZK Bridge needed? The centralization problem and trust assumption of the current cross-chain bridge lead to insufficient security, and frequent loopholes cause serious losses; while cross-chain bridges that emphasize security are inefficient and costly. ZK Bridge can maintain security, decentralization and high efficiency at the same time.
- How to implement ZK Bridge? Light node scheme based on ZK-SNARK
- Related project introductions: Succinct Labs, zkIBC by Electron Labs, zkBridge by BerkleyRDI.
What is a cross-chain bridge?
Cross-chain Bridge is a technical solution that allows the transfer of value and information between different blockchain networks. By utilizing a series of encryption and protocol technologies, the cross-chain bridge realizes the secure, verifiable and trustless transfer of assets and data, thereby promoting the interoperability between blockchain networks.
Generally speaking, we will divide cross-chain bridges into direct asset cross-chain bridges and more versatile message cross-chain bridges .
Why do cross-chain bridges become the target of public criticism?
As a centralized pool of huge funds, the cross-chain bridge will naturally attract hackers - the benefits of a successful attack are huge. In addition, due to the possible differences in security assumptions between different chains, the code of assets across chains is more complex, and code audits cannot find all loopholes, which is an opportunity for hackers with huge incentives to take advantage of.
Specific attack schemes can be divided into the following categories:
1. Centralized attack: Some cross-chain bridges rely on centralized relayers or verifiers to transmit and verify transactions. This design may lead to a single point of failure, and attackers can destroy the entire cross-chain system by attacking these centralized components.
2. Economic incentive attack: Cross-chain bridges usually need to set up appropriate economic incentives to ensure the honest behavior of validators and relayers. However, designing a suitable incentive mechanism is not easy, and insufficient incentives or imbalanced incentive design may lead to malicious behavior or collusion attacks.
3. Double spending attack: In some cases, the attacker may try to spend the same asset on the source chain and the target chain at the same time, resulting in double spending of assets. Cross-chain bridges need to design effective preventive measures to prevent double-spending attacks.
4. Replay attack: The attacker may attempt to replay transactions that have occurred on the source chain on the target chain, thereby attempting to obtain improper benefits. Cross-chain bridges need to implement certain transaction verification and anti-replay mechanisms to prevent such attacks.
5. Off-chain coordination attacks: Some implementations of cross-chain bridges rely on off-chain coordination, such as state channels or sidechains. Attackers may disrupt the normal operation of the cross-chain bridge by interfering or attacking the off-chain coordination link.
6. Inter-chain consensus attack: Since the cross-chain bridge involves multiple blockchain networks, each network may adopt a different consensus algorithm. An attacker may exploit the weakness of the inter-chain consensus to launch an attack, for example, implement a 51% attack on one chain to affect the correctness of the cross-chain bridge.
List of current mainstream cross-chain bridge solutions
There are no solutions. There are only trade-offs.
There is no solution. Just weigh the pros and cons.
—Thomas Sowell
Thomas Sowell (one of the representatives of the Chicago School of Economics)
The core issue of cross-chain is how to verify the reliability of another chain's message. Different solutions to this problem have resulted, involving varying degrees of trust assumptions.
Trust map of cross-chain bridge
Comparison of technical parameters of current mainstream cross-chain solutions
Light node plus relay is actually the earliest cross-chain solution, and the representative project is BTC Relay , the purpose of which is to use Bitcoin for payment to use Ethereum services. However, running light clients on-chain is expensive due to the large amount of on-chain computation and storage. Moreover, due to the heterogeneity of consensus algorithms and signature algorithms between different chains, the cross-chain solution is not scalable, and light client & relay needs to be implemented specifically for each pair of specific two chains.
So far, only the IBC on the Cosmos application chain has implemented a large-scale on-chain light client. The reason for its success lies in the high degree of standardization of the Cosmos application chain. Each application chain needs to run the Tendermint consensus and abide by the IBC standard . In a multi-chain world with different consensus mechanisms, signature schemes, and virtual machines, on-chain light client verification is difficult to achieve.
In order to avoid the high cost of light nodes on the chain, the current mainstream cross-chain projects move the verification process to off-chain, which also brings different levels of trust assumptions and potential fraud risks. The LK Venture investment research team ranks the trust level from high to low, Introduce some key programs.
Cross-chain solution 1: multi-signature without pledge
Typical projects include Multichain, Wormhole, and Ronin Bridge. These all require a multi-signature MPC implementation, requiring entities to verify transactions, and verify (i.e. sign) their validity. After passing a threshold (often 2/3), the transaction is considered validated.
· In this scheme, each entity needs to run a full node for verification. Of course, there is no actual cost for lying without collateral, but reputational damage caused by dishonesty may lead to greater potential costs, so verification nodes are often associated with fixed off-chain identities to increase the cost of doing evil for nodes.
The message verification of Multichain is guaranteed by the SMPC network. The SMPC network consists of 24 nodes. Messages signed by more than 2/3 nodes are considered to pass the verification. SMPC node members do not need to pledge and are relatively fixed. The security of AnyCall is based on the SMPC node based on the trust assumption.
· Wormhole's trust layer is built using the PoA mechanism, and a group of trusted Guardians (guardians) are responsible for the verification of inter-chain messages. Guardians are specific subjects with capital endorsement and reputation endorsement. Currently, there are 19 Guardians in Wormhole, including well-known large companies such as FTX , Everstake, and Chorus One.
Cross-chain Solution 2: Oracle and Relay
A typical project is LayerZero , which ensures the security of the cross-chain process by separating the message and message proof delivery and verifying the Relayer delivery transaction.
The core design idea of LayerZero lies in the separation of Oracle (oracle machine) and Relayer (relayer). In LayerZero, Relayer is responsible for delivering messages and message proofs, and Oracle is responsible for obtaining block headers from the source chain on demand according to the block where the message is located. , and then the terminal on the target chain verifies the transaction delivered by the Relayer according to the block header obtained by the Oracle. As long as the two do not collude, cross-chain security can be guaranteed.
· It should be noted that although Layerzero calls its technical solution Ultra Light Node (Ultra Light Node), the solution is fundamentally different from Light Client. LayerZero verifies the transaction proof provided by Relayer through the block header provided by Oracle. The verification process occurs at the terminal of the target chain, which belongs to native verification, but the verification of the block header itself is completed by a third-party Oracle network as an external verifier , the verification process happens off-chain.
Cross-chain solution 3: multi-signature with pledge
On the basis of MPC, a layer of proof of equity is added. Typical projects include Celer, Axelar, deBridge, Hyperlane, and Thorchain.
· If doing evil, the validator's pledge will be greatly reduced, which will actually increase the cost of the validator's deception economically.
One of the problems PoS bridges have to face is the unbalanced verifier. In order to alleviate this problem, Axelar adopts a quadratic voting scheme, and the signature weight will be proportional to the square root of the $AXS amount pledged by the verifier ; Hyperlane adopts the "Verifiable Fraud Proof" scheme, and validators who jointly commit crimes will be immediately discovered and executed Slash; pNetwork and Bool Network directly require all nodes to pledge the same amount of Token.
Cross-chain solution 4: Optimistic validation
The knowledge of game theory is used to increase the risk of users doing evil through the game scene between users. Typical projects include Nomad and Synapse.
The basic logic of optimistic verification is: on the basis of external verification, set up a group of challengers and a challenge window period to challenge incorrect verification, and the verifier needs to pledge. When it behaves improperly, the challenger will challenge , and provide proof of fraud. If the challenge is successful, the validator's deposit will become the challenger's bounty.
· The challenge window set by the Nomad project is 30 minutes. For an optimistic verification scheme, it is only required that at least one challenger is honest and has an economic incentive to challenge. Compared with external verification, this is a smaller trust assumption. Under such a trust assumption, no matter how much economic cost the attacker pays, the attack cannot be guaranteed to be successful.
This is the end of the original cross-chain solution, but the development of ZKP zero-knowledge proof technology has brought a new solution to the dilemma of safety and efficiency of cross-chain bridges.
What is ZK Bridge?
ZK Bridge is a cross-chain bridge using zero-knowledge proof technology. It does not introduce trust assumptions, adapts to various homogeneous/heterogeneous chains, generates zero-knowledge proofs off-chain, and is only responsible for verification on the chain, which greatly reduces computing and storage costs on the chain. , has the characteristics of zero trust, permissionless, scalable, and high efficiency.
Let's first give a basic overview of the principle of the light client. Light clients, also known as light nodes, are often presented in the form of light smart contracts on the chain. The basic principle of the light client cross-chain is to deploy the light node contract of the source chain on the target chain to verify the messages from the source chain. If two-way cross-chain is to be realized, it is necessary to deploy the light node contracts of the other chain on the two chains.
Compared with the full node, the light node is a lightweight node, which does not store the sequence of the complete block, but only the sequence of the block header. Despite its small size, the block header contains a cryptographic summary of the complete data in the block. When a light node needs to know whether a transaction is included in the chain, it can perform SPV verification on the transaction through the block header of the block where the transaction is located and the Merkle path of the transaction.
In the figure below, the collection of green squares is the Merkel path of the blue squares.
In order to maintain the source chain light nodes deployed on the target chain, an off-chain agent needs to continuously synchronize the block headers of the source chain to the target chain. Light node contracts make no trust assumptions about off-chain agents responsible for synchronizing block headers. Because light node contracts perform verification of their synchronized block headers, off-chain proxies cannot fool light nodes.
The logic of the light node verification block header is the same as that of the full node and the miner node. It is divided into two parts: validity verification and finality verification.
The LK Venture investment research team believes that for the PoW chain, the validity verification mainly refers to the proof of work of the verification block, and the finality verification is to see whether there are more valid blocks after the block header (in BTC In the chain, it is generally believed that the addition of 6 blocks can confirm the finality of a block, and in Ethereum, it is generally believed that the addition of 25 blocks can confirm the finality of a block).
For the PoS chain, validity verification refers to verifying whether the block is generated by a randomly selected block producer, and finality verification is to see whether the block is signed by a validator with more than 2/3 voting weight. But the light nodes of PoS do not need to verify the validity, only need to verify the finality. Because in the PoS chain, the final block must be valid, but not in the PoW chain.
The implementation of ZK Bridge is the same as the light node plus relay solution, with only slight changes. In ZK Bridge, relayers under the chain still need to monitor the source chain and forward the block information of the source chain to the target chain. But what is forwarded is not only the block header, but also the validity proof generated using the ZK-SNARK algorithm. On the target chain, the light nodes do not verify the validity of the transaction by directly calculating according to the block header, but verify it on the chain according to the validity proof to reduce the calculation burden.
Implementation technology path of ZK Bridge
Why is ZK Bridge expected to end the cross-chain war?
Among the cross-chain bridges that have been deployed and put into use at present, many projects have suffered serious security attacks, and the stolen amount was very huge, which caused large-scale panic at that time. The safety of the bridge is questionable. People increasingly need a safe, zero-trust, and decentralized cross-chain bridge to lay a solid foundation for the future full-chain ecology.
Statistics on the loss of funds and recovered funds of some cross-chain agreements in 2022
Image source: DeFiyield (https://defiyield.info/)
From the perspective of the LK Venture investment research team, ZK Bridge brings a new solution to the dilemma that the safety and efficiency of the cross-chain bridge cannot be balanced, that is, by generating a zero-knowledge proof of the block header under the chain, the source chain block header The correctness is verified by the proof generated by the ZK-SNARK algorithm, so no external trust assumptions are added, and the only trust is mathematics.
Moreover, the verification process of zero-knowledge proof on the chain will significantly reduce computing and storage costs compared with the original light node verification scheme.
ZK Bridge partial project introduction
Succinct by Succinct Labs
Gnosis Chain Omnibridge is a cross-chain bridge between Ethereum and Gnosis, using the mainstream solution of MPC. Gnosis team members hope to explore a cross-chain design that does not rely on centralized entities. Succinct Labs and the Gnosis team cooperate on this, and Gnosis DAO provides grants for R&D.
The verification process of Ethereum mainly includes the verification of the following contents: Merkle certificate of the block header; Merkle certificate of the verifier in the synchronization committee; BLS signature of the correct rotation of the synchronization committee, etc. The core idea here is to use zk-SNARK (Groth16) to generate constant-size validity proofs, which can be efficiently verified on-chain on Gnosis.
Diagram of Succinct cross-chain solution
Image source: Succinct official website ( https://www.succinct.xyz/ )
Succinct Labs' cross-chain solution can transfer any message between any two Ethereum-compatible PoS chains. Currently, the cross-chain demo between Ethereum and Gnosis has been implemented, and the bridge deposit contract is deployed on Ethereum to allow users to save. The bridge deposit will pass the message to the arbitrary message bridge (AMB), and the AMB will store the message in the contract. The Operator is responsible for obtaining proofs from the sync committee, generating SNARK proofs for valid BLS signature verification, and submitting updates to the Gnosis chain light client.
On the Gnosis Chain, after the Ethereum block where the deposit transaction is located is confirmed (usually 2 epochs, about 12 minutes), and the light client has been updated to a block whose height is greater than or equal to this block, the relayer will automatically report to the Gnosis AMB Submit an executeMessage transaction. The executeMessage transaction contains a Merkle proof of storage for the light client's updated slot. During executeMessage, the AMB uses a light client to obtain the Ethereum state root for the requested slot and verifies the Merkle proof of storage to show that the message was sent on the other side of the AMB. The AMB then invokes the receiving smart contract with the calldata specified in the message.
Considering the maturity of the technology stack and the overhead of on-chain verification, the team chose to use the most mature Circom language and the cheapest Groth16 proof system for on-chain verification to generate ZK-SNARKs instead of using the newer and faster PLONK + KZG or FRI.
It is worth noting that although the project is on the test network, its usability is poor. According to the author's test, the number of Succincts tokens on the Goerli test network has decreased after the bridge, but the Gnosis network has not received the token, and the dashboard on the website has no bridge records. And it should be noted that the current cross-chain is one-way. Only from Goerli to Gnosis, not the other way around.
zkBridge by BerkleyRDI
zkBridge proves the correctness of the block header of the remote blockchain through ZK-SNARKs, so no external trust assumptions will be introduced. In fact, zkBridge is secure as long as the connected blockchain and underlying light client protocol are secure, and there is at least one honest node in the block header relay network. Of course, it is worth noting that although at least one honest node can guarantee security, too many dishonest nodes will significantly reduce the availability of the cross-chain bridge, and the light client will frequently reject the incoming proofs and cannot obtain real information.
Diagram of zkBridge cross-chain solution
Image source: https://rdi.berkeley.edu/zkp/zkBridge/zkBridge.html
Specifically, zkBridge is mainly composed of Block Header Relay Network and Updater Contract. In the block header relay network, the relay retrieves the block header from the sender blockchain C1, generates a proof of the validity of the block header, and sends the block header and proof to the updater contract set on the receiver blockchain C2 middle. For the updater contract, once the relevant proof is verified, the corresponding block header of C1 will be stored. Additionally, the updater contract maintains a light client state. Once a new block header is added, the contract updates the light client state just like other light clients on C1, and updates C1's current main chain. The updater contract also exposes a function to applications by which an application on C2 can get a block header at a given height on C1. After obtaining the block header information, the application can do more verification (such as a specific transaction) and build its own application.
In order for the underlying zk-SNARK system to be compatible with on-chain use, fast proof generation and low on-chain proof verification costs are required. The main innovations of zkBridge are:
· deVirgo: Use a distributed method to generate ZK-SNARK proofs without trust assumptions. The deVirgo method greatly improves the time to generate ZK-SNARK proofs off-chain by splitting the computing work and distributing it to more devices.
· Recursive proof: In order to reduce the cost on the chain, zkBridge uses recursive proof to compress the volume of ZK-SNARK proof to about 131 bytes through two recursions. The first step is to generate a deVirgo proof, and the second step is to use the Groth16 proof generator for compression. Groth16 verifiers generate integrity proofs for executing deVirgo circuits.
Batch processing: zkBridge implements a block header update contract, which takes the block height as input and returns the corresponding block header. However, zkBridge does not call the update contract when each new block is generated. The prover can first collect N block headers and generate a single proof. The value of N can be set, the larger N is, the longer the user waits but the lower the operating cost of the system.
At present, zkBridge has implemented an instance of Cosmos Client on Ethereum with Solidity. According to the test, a ZK-SNARK proof of the Cosmos Zone block header can be generated within 2 minutes, and then on the Ethereum side, the verification fee is 230k gas per hour Constant, in comparison, if ZK-SNARK proof is not used, the cost will be 64 Million Gas.
It is important to note that relay network computation will suffer from the same communication complexity as MPC, which will severely impact proof times. The communication complexity of the GKR multi-layer sum check protocol is O(N log2(number of signatures)), where N machines are in the relay network. Even for the case of 32 signatures, there are 32 machines in the relay network, which may lead to a large amount of sequential communication in the network, impairing the performance brought by distributed computing.
zkIBC by Electron Labs
Specifically, zkIBC hopes to simulate the trustless communication protocol used by the Cosmos sovereign chain - Inter Blockchain Communication Protocol (IBC), and extend its use to Ethereum. zkIBC uses ZK-SNARKs for light client status verification, quickly proves transactions on Ethereum, and keeps up with the block generation time of the Tendermint consensus chain.
The main difficulty is that the Tendermint light client used in the Cosmos SDK runs on the Ed25519 curve, which is not supported by the Ethereum blockchain, and it is expensive and inefficient to verify Ed25519 signatures on Ethereum's BN254 curve.
The project roadmap is divided into five phases: research - implementation of ed25519 signature proof - test network - recursive Snark implementation to reduce redundancy - main network. On February 2, 2023, Positron testnet was officially launched to the public, supporting the cross-chain between Near and Ethereum. The current testnet needs to wait about 20-30 minutes to achieve finality, including Goerli network finality (15-20 minutes), ZK-Proof generation (5-8 minutes), Near chain casting (10-20 seconds) .
The project claims to be completely open source, has been tested, the cross-chain process is smooth, the UI/UX is well designed, and it supports two-way cross-chain.
think
When blockchain technology develops to a certain stage, it usually evolves into a philosophy of trade-offs. In the public chain, there is a security-scalability-decentralization trilemma; and in the cross-chain, there may also be a security-efficiency dilemma: the pursuit of efficiency will introduce third-party trust assumptions, resulting in security damage; the pursuit of security, using a completely light node and relay solution will incur high costs on the chain.
But in fact, from the point of view of system design, even the unsecured MPC scheme with the highest degree of trust actually guarantees the security of cross-chain bridges in most cases. The reason why multiple cross-chain bridges have been stolen is because the code is open-sourced in pursuit of transparency, and the hidden loopholes in the complex code give hackers an opportunity.
LK Venture believes that with the continuous advancement of technology, the availability of ZK solutions is gradually increasing. ZK Rollup is expected to be put into large-scale use in the second half of 2023, and ZK Bridge is also in the ascendant. It is hoped that the maturity of ZK Bridge technology can break the current security-efficiency dilemma faced by cross-chains, and realize the vision of Wanchain interconnection.
｜About LK Venture:
Linekong Interactive (08267.HK) is an encryption investment and research institution focusing on the Web3 field, formerly known as Consensus Lab (Consensus Lab), which focuses on investing in cutting-edge infrastructure, trading platforms, technical protocols and financial tools. Polkadot , Filecoin , Casperlabs, Coin98 and more than a hundred projects from North America, Asia, Europe and other countries and regions.
｜Reference materials:
1. zkBridge: Trustless Cross-chain Bridges Made Practical（ https://rdi.berkeley.edu/zkp/zkBridge/zkBridge.html ）
2. Bridging the Multichain Universe with Zero Knowledge Proofs ( https://medium.com/@ingonyama/bridging-the-multichain-universe-with-zero-knowledge-proofs-6157464fbc86 )
3. Exploring ZK Bridges ( https://zkvalidator.com/exploring-zk-bridges/ )
4. Overall Comparison Between Multiple Blockchains ( https://dune.com/springzhang/cross-blockchain-comparison-overview )
