LK Venture Research Report: Can ZK Bridge Achieve the "Final Outcome of the Cross-Chain War"?
The emergence of ZK Bridge will effectively address various shortcomings of current cross-chain solutions, making the interconnection of thousands of chains possible.Author: LK Venture
Today, Ethereum occupies a significant portion of the blockchain industry infrastructure, but its dominance is being challenged by many newcomers. One of the prevailing industry consensus is that the future may be characterized by a multi-chain coexistence, where cross-chain and even full-chain connectivity is the most critical aspect of the multi-chain ecosystem.
However, the security issues of cross-chain bridges connecting various blockchain networks are frequent, and the cross-chain ecosystem seems precarious. The emergence of ZK Bridge (a cross-chain bridge using ZK zero-knowledge proof technology) will effectively address various shortcomings of current cross-chain solutions, making the interconnection of thousands of chains possible.
In Norse mythology, Heimdallr is a mysterious and important deity responsible for guarding the rainbow bridge connecting the realm of gods (Asgard) and the human world (Midgard) — Bifröst. If we liken the rainbow bridge connecting different realms to a cross-chain bridge, can zero-knowledge proof technology take on the crucial role of safeguarding cross-chain security, achieving the myth of "Heimdall" on the rainbow bridge?
This article provides a comprehensive analysis by the LK Venture research team on the ZK Bridge track, aiming to explore the development potential of zero-knowledge proof technology in addressing cross-chain security and high-performance bottlenecks.
TL; DR
What is ZK Bridge? ZK Bridge is a cross-chain bridge that uses zero-knowledge proof technology, characterized by zero trust, permissionless, scalable, and high efficiency.
Why is ZK Bridge needed? The centralization issues and trust assumptions of current cross-chain bridges lead to insufficient security, with frequent vulnerabilities causing significant losses; while cross-chain bridges that prioritize security tend to be inefficient and costly. ZK Bridge can maintain security, decentralization, and high efficiency simultaneously.
How to implement ZK Bridge? Based on a ZK-SNARK lightweight node solution.
Related project introductions: Succinct Labs, zkIBC by Electron Labs, zkBridge by BerkleyRDI.
What is a Cross-Chain Bridge?
A cross-chain bridge is a technological solution that allows for the transfer of value and information between different blockchain networks. By utilizing a series of cryptographic and protocol technologies, cross-chain bridges enable the secure, verifiable, and trustless transfer of assets and data, thereby promoting interoperability between blockchain networks.
Generally, we categorize cross-chain bridges into direct asset cross-chain bridges and more versatile message cross-chain bridges.
Why has the Cross-Chain Bridge become a target?
As a centralized pool of substantial funds, cross-chain bridges naturally attract hackers — the rewards for successful attacks can be enormous. Additionally, due to differing security assumptions between chains, the code for asset cross-chain transactions is more complex, and code audits cannot uncover all vulnerabilities, providing hackers with opportunities driven by significant incentives.
Specific attack schemes can be categorized as follows:
Centralized attacks: Some cross-chain bridges rely on centralized relayers or validators to transmit and verify transactions. This design can lead to single points of failure, allowing attackers to compromise the entire cross-chain system by targeting these centralized components.
Economic incentive attacks: Cross-chain bridges typically need to establish appropriate economic incentives to ensure the honest behavior of validators and relayers. However, designing suitable incentive mechanisms is challenging, and insufficient or imbalanced incentives may lead to malicious behavior or collusion attacks.
Double-spending attacks: In some cases, attackers may attempt to spend the same asset simultaneously on both the source and target chains, resulting in double spending. Cross-chain bridges need to design effective countermeasures to prevent double-spending attacks.
Replay attacks: Attackers may attempt to replay transactions that have already occurred on the source chain on the target chain to gain illicit benefits. Cross-chain bridges need to implement certain transaction verification and anti-replay mechanisms to prevent such attacks.
Off-chain coordination attacks: Some implementations of cross-chain bridges rely on off-chain coordination, such as state channels or sidechains. Attackers may disrupt or attack the off-chain coordination process to undermine the normal operation of the cross-chain bridge.
Inter-chain consensus attacks: Since cross-chain bridges involve multiple blockchain networks, each network may employ different consensus algorithms. Attackers may exploit weaknesses in inter-chain consensus to launch attacks, such as executing a 51% attack on one chain to affect the correctness of the cross-chain bridge.
Overview of Current Mainstream Cross-Chain Bridge Solutions
The core issue of cross-chain is how to verify that the messages from another chain are reliable. Various solutions have emerged to address this issue, each with different levels of trust assumptions.
Light nodes combined with relayers were actually the earliest cross-chain solutions, represented by projects like BTC Relay, aimed at using Bitcoin to pay for Ethereum services. However, due to the need for extensive on-chain computation and storage, running on-chain light clients is costly. Moreover, the heterogeneity of consensus algorithms and signature algorithms between different chains makes cross-chain solutions non-scalable, requiring a dedicated light client & relay implementation for each specific pair of chains.
To date, only the IBC on the Cosmos application chain has implemented large-scale on-chain light clients, with its success attributed to the high standardization of Cosmos application chains, where each application chain must run the Tendermint consensus and comply with the IBC standard. In a multi-chain world with different consensus mechanisms, signature schemes, and virtual machines, on-chain light client verification is challenging to achieve.
Current mainstream cross-chain projects, to avoid the high costs of on-chain light nodes, have moved the verification process off-chain, which also brings varying degrees of trust assumptions and potential fraud risks. The LK Venture research team introduces some key solutions based on the level of trust from high to low.
Cross-Chain Solution 1: Non-Staked Multi-Signature
Typical projects include Multichain, Wormhole, and Ronin Bridge. These require multi-signature MPC implementations, necessitating real-time verification of transactions and validating (i.e., signing) their validity. Once a threshold is reached (often 2/3), the transaction is considered verified.
In this solution, each entity needs to run a full node for verification. Of course, the lack of staking means there is no actual cost for lying, but the reputational damage from dishonesty could lead to greater potential costs, so verifying nodes are often associated with fixed off-chain identities to increase the cost of malicious behavior.
The message verification of Multichain is secured by an SMPC network, consisting of 24 nodes, where messages signed by more than 2/3 of the nodes are considered verified. SMPC node members do not need to stake and are relatively fixed, with AnyCall's security based on trust assumptions of SMPC nodes.
Wormhole's trust layer is built using a PoA mechanism, with a group of trusted Guardians responsible for verifying inter-chain messages. Guardians are specific entities backed by capital and reputation. Currently, there are 19 Guardians in Wormhole, including well-known companies like FTX, Everstake, and Chorus One.
Cross-Chain Solution 2: Oracles and Relayers
A typical project is LayerZero, which ensures the security of the cross-chain process by separating the transmission and verification of messages and message proofs from the relayer.
The core design philosophy of LayerZero is the separation of Oracles and Relayers. In LayerZero, the Relayer is responsible for transmitting messages and message proofs, while the Oracle fetches the block header from the source chain as needed based on the block containing the message. The terminal on the target chain then verifies the transaction transmitted by the Relayer based on the block header obtained from the Oracle. As long as the two do not collude, cross-chain security can be guaranteed.
It is important to note that although LayerZero refers to its technical solution as Ultra Light Node, the solution is fundamentally different from Light Client. LayerZero verifies the transaction proof provided by the Relayer using the block header provided by the Oracle, with the verification process occurring at the terminal of the target chain, which is a form of native verification. However, the verification of the block header itself is completed by a third-party Oracle network acting as an external verifier, with the verification process occurring off-chain.
Cross-Chain Solution 3: Staked Multi-Signature
This adds a layer of proof of stake on top of MPC, with typical projects including Celer, Axelar, deBridge, Hyperlane, and Thorchain.
If malicious behavior occurs, the staked amount of the validator will be significantly reduced, effectively increasing the economic cost of deception for validators.
One issue that PoS bridges face is the imbalance of validators. To mitigate this issue, Axelar adopts a quadratic voting scheme, where the weight of signatures is proportional to the square root of the amount of $AXS staked by the validator; Hyperlane employs a "verifiable fraud proof" scheme, where collusion among validators will be immediately detected and lead to slashing; pNetwork and Bool Network directly require all nodes to stake the same amount of tokens.
Cross-Chain Solution 4: Optimistic Validation
Utilizing game theory knowledge, this approach increases the risk of malicious behavior among users through gaming scenarios, with typical projects including Nomad and Synapse.
The basic logic of optimistic validation is: based on external verification, a batch of challengers and a challenge window period are set to challenge incorrect validations. Validators need to stake, and when they behave improperly, challengers will raise challenges and provide fraud proofs. If the challenge is successful, the validator's stake will become the challenger’s reward.
The challenge window period set by the Nomad project is 30 minutes. For optimistic validation schemes, it only requires at least one challenger to be honest and have economic incentives to challenge. Compared to external verification, this represents a smaller trust assumption; under such a trust assumption, attackers cannot guarantee success regardless of the economic cost they incur.
Originally, cross-chain solutions would end here, but the development of ZKP zero-knowledge proof technology has brought new solutions to the security and efficiency dilemma of cross-chain bridges.
What is ZK Bridge?
ZK Bridge is a cross-chain bridge that uses zero-knowledge proof technology, introducing no trust assumptions, adaptable to various homogeneous/heterogeneous chains, generating zero-knowledge proofs off-chain, and only responsible for verification on-chain, significantly reducing on-chain computation and storage costs, characterized by zero trust, permissionless, scalable, and high efficiency.
Let’s first provide a basic overview of the principles of light clients. Light clients, also known as light nodes, are often presented on-chain in the form of light smart contracts. The basic principle of light client cross-chain is to deploy the light node contract of the source chain on the target chain to verify messages coming from the source chain. To achieve bidirectional cross-chain, it is necessary to deploy each other's light node contracts on both chains.
Compared to full nodes, light nodes are lightweight nodes that do not store the complete sequence of blocks but only the sequence of block headers.
Although the block header is small, it contains a cryptographic summary of the complete data in the block. When a light node needs to know whether a certain transaction is included in the chain, it can perform SPV verification on that transaction using the block header of the block containing the transaction and the Merkle path of that transaction.
In the diagram below, the collection of green squares represents the Merkle path of the blue square.
To maintain the light node of the source chain deployed on the target chain, off-chain agents need to continuously synchronize the block headers of the source chain to the target chain. The light node contract does not have trust assumptions regarding the off-chain agent responsible for synchronizing the block headers. This is because the light node contract will verify the block headers it synchronizes, and the off-chain agent cannot deceive the light node.
The logic of light node verification of block headers is no different from that of full nodes and miner nodes, divided into validity verification and finality verification.
The LK Venture research team believes that for PoW chains, validity verification mainly refers to verifying the proof of work of the block, while finality verification checks whether more valid blocks have been appended after the block header (in the BTC chain, it is generally believed that 6 blocks appended can confirm the finality of a block, while in Ethereum, it is generally believed that 25 blocks appended can confirm the finality of a block).
For PoS chains, validity verification refers to verifying whether the block was generated by a randomly selected block producer, while finality verification checks whether the block has been signed by validators with more than 2/3 of the voting weight. However, PoS light nodes do not need to verify validity; they only need to verify finality. This is because the final block in a PoS chain is always valid, whereas this is not necessarily the case for PoW chains.
The implementation of ZK Bridge follows the same process as the light node plus relayer solution, with slight variations. In ZK Bridge, off-chain relayers still need to listen to the source chain and forward the block information of the source chain to the target chain. However, 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 node does not verify the validity of transactions by directly calculating based on the block header but verifies it on-chain based on the validity proof, reducing the computational burden.
Why is ZK Bridge expected to end the cross-chain war?
Among the currently deployed cross-chain bridges, several projects have suffered serious security attacks, with stolen amounts being substantial, causing widespread panic at the time, and to this day, there remains skepticism about the security of various cross-chain bridges. There is an increasing need for a secure, trustless, and decentralized cross-chain bridge to lay a solid foundation for the future full-chain ecosystem.
In the view of the LK Venture research team, ZK Bridge provides a new solution to the dilemma of balancing security and efficiency in cross-chain bridges, by generating zero-knowledge proofs for block headers off-chain, where the correctness of the source chain block header is verified by the proof generated by the ZK-SNARK algorithm, thus not introducing any external trust assumptions; the only trust is in mathematics.
Moreover, the verification process of zero-knowledge proofs on-chain will significantly reduce computational and storage costs compared to the original light node verification solutions.
Introduction to Some ZK Bridge Projects
Succinct by Succinct Labs
Gnosis Chain Omnibridge is a cross-chain bridge between Ethereum and Gnosis, using the mainstream MPC solution. The Gnosis team members hope to explore cross-chain designs that do not rely on centralized entities, leading to a collaboration between Succinct Labs and the Gnosis team, with Gnosis DAO providing grants for R&D.
The verification process on Ethereum mainly includes the verification of the following: Merkle proof of the block header; Merkle proof of validators in the synchronization committee; correct rotation of the synchronization committee's BLS signatures, etc. The core idea here is to use zk-SNARK (Groth16) to generate a validity proof of constant size, which can be efficiently verified on Gnosis.
Succinct Labs' cross-chain solution can transmit any message between any two Ethereum-compatible PoS chains. Currently, a cross-chain demo between Ethereum and Gnosis has been implemented, where a bridge deposit contract is deployed on Ethereum to allow users to deposit. The bridge deposit will pass messages to the arbitrary message bridge (AMB), which stores the message in the contract. The Operator is responsible for obtaining the proof of the synchronization committee, generating a SNARK proof for valid BLS signature verification, and submitting updates to the Gnosis chain light client.
On the Gnosis Chain, once the deposit transaction in the Ethereum block is confirmed (usually 2 epochs, about 12 minutes), and the light client has been updated to a height greater than or equal to that block, the Relayer will automatically submit an executeMessage transaction to Gnosis AMB. The executeMessage transaction contains a Merkle storage proof for the updated slot of the light client. During executeMessage, the AMB uses the light client to obtain the Ethereum state root of the requested slot and verifies the Merkle storage proof to show that the message has been sent on the other side of the AMB. Then, the AMB calls the receiving smart contract using the calldata specified in the message.
Due to the maturity of the technical stack and the on-chain verification overhead, the team chose to use the currently most mature Circom language and the cheapest on-chain verification Groth16 proof system to generate ZK-SNARKs, rather than using the faster PLONK + KZG or FRI.
It is worth noting that although the project has launched on the testnet, its usability is poor. According to the author's tests, the Succinct token on the Goerli testnet decreased in quantity after crossing the bridge, but the Gnosis network did not receive the tokens, and there were no bridge records displayed on the dashboard of the website. Additionally, it should be noted that the current cross-chain is unidirectional, only allowing transfers from Goerli to Gnosis, but not vice versa.
zkBridge by BerkleyRDI
zkBridge proves the correctness of the block headers of remote blockchains through ZK-SNARKs, thus not introducing any external trust assumptions. In fact, as long as the connected blockchains and the underlying light client protocol are secure, and there is at least one honest node in the block header relay network, zkBridge is secure. Of course, it is worth noting that while at least one honest node can guarantee security, too many dishonest nodes can significantly reduce the usability of the cross-chain bridge, as the light client will frequently reject incoming proofs and fail to obtain real information.
Specifically, zkBridge mainly consists of the Block Header Relay Network and the Updater Contract. In the block header relay network, the relayer retrieves the block header from the sender blockchain C1, generates a validity proof for the block header, and sends the block header and proof to the updater contract set on the receiver blockchain C2. For the updater contract, once the relevant proof passes verification, the corresponding block header from 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 the current main chain of C1. The updater contract also exposes a function to applications, allowing applications on C2 to retrieve the block header of a given height from C1. After obtaining the block header information, applications can perform further verification (e.g., specific transactions) and build their applications.
To ensure compatibility of the underlying zk-SNARK system with on-chain usage, fast proof generation and low on-chain proof verification costs are required. The main innovations of zkBridge are:
deVirgo: A distributed approach to generating ZK-SNARK proofs without trust assumptions. The deVirgo method significantly improves the time to generate ZK-SNARK proofs off-chain by splitting the computational workload and distributing it to more devices.
Recursive proofs: To reduce on-chain costs, zkBridge uses recursive proofs, compressing the size of ZK-SNARK proofs to about 131 bytes through two rounds of recursion. The first step generates the deVirgo proof, and the second step compresses it using the Groth16 proof generator. The Groth16 verifier generates a completeness proof for executing the deVirgo circuit.
Batch processing: zkBridge implements an updater contract for block headers that takes block height as input and returns the corresponding block header. However, zkBridge does not call the updater contract for every new block; 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 system operating cost.
Currently, zkBridge has implemented an instance of a Cosmos Client on Ethereum using Solidity. Tests show that a ZK-SNARK proof for a Cosmos Zone block header can be generated within 2 minutes, and the verification cost on the Ethereum side is a constant of 230k gas per hour. In comparison, without the ZK-SNARK proof, this cost would be 64 million gas.
It should be noted that the relay network's computation will suffer from the same communication complexity as MPC, which will severely impact proof generation time. The communication complexity of the GKR multi-layer summation check protocol is O(N log2(number of signatures)), where N is the number of machines in the relay network. Even for a case with 32 signatures and 32 machines in the relay network, it may lead to a large amount of sequential communication in the network, damaging the performance brought by distributed computing.
zkIBC by Electron Labs
Specifically, zkIBC aims to simulate the trustless communication protocol used by Cosmos sovereign chains — the Inter Blockchain Communication Protocol (IBC) — and extend its use to Ethereum. zkIBC uses ZK-SNARKs for light client state verification, quickly proving transactions on Ethereum to keep up with the block time of the Tendermint consensus chain.
The main difficulty lies in the fact that the Tendermint light client used in the Cosmos SDK runs on the Ed25519 curve, while the Ethereum blockchain does not support this curve, making it 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 - testnet - recursive Snark implementation to reduce redundancy - mainnet. On February 2, 2023, the Positron testnet officially launched to the public, supporting cross-chain transactions between Near and Ethereum. The current testnet requires about 20-30 minutes to achieve finality, which includes finality on the Goerli network (15-20 minutes), ZK-Proof generation (5-8 minutes), and minting on the Near chain (10-20 seconds).
The project claims to be fully open-source. Tests show that the cross-chain process is smooth, with good UI/UX design, and supports bidirectional cross-chain transactions.
Thoughts
As blockchain technology develops to a certain stage, it typically evolves into a philosophy of trade-offs. In public chains, there exists a trilemma of security, scalability, and decentralization; while in cross-chain, there may also be a dilemma of security and efficiency: pursuing efficiency introduces third-party trust assumptions, compromising security; pursuing security with fully light node and relayer solutions incurs high on-chain costs.
However, from a design perspective, even the highest trust non-staked MPC solutions generally ensure the security of cross-chain bridges in most cases. The reason multiple cross-chain bridges have been hacked is precisely due to the pursuit of transparency through open-sourcing code, where hidden vulnerabilities in complex code provide hackers with opportunities.
LK Venture believes that with continuous technological advancements, the usability of ZK solutions will gradually increase, and ZK Rollup is expected to see large-scale use in the second half of 2023, with ZK Bridge also on the rise. It is hoped that the maturity of ZK Bridge technology can break the current security-efficiency dilemma faced by cross-chain solutions, realizing the vision of interconnecting thousands of chains.
