Display: CGV Research Author: Cynic
Nowadays, Ethereum occupies half of the infrastructure of the blockchain industry, but its dominant position in the mainnet is being challenged by many latecomers. One of the industry consensuses is that multiple chains will coexist in the future, and cross-chain or even full-chain will be the most critical link in the multi-chain ecology. However, cross-chain bridges connecting various blockchain networks are plagued with security issues, and the cross-chain ecosystem seems to be in jeopardy. The emergence of ZK Bridge (a cross-chain bridge using zero-knowledge proof) will effectively solve various defects of the current cross-chain solutions and realize the interconnection of all chains.
Heimdallr guards Rainbow Bridge Image source: Klugh, Maria Tales from the Far North (Chicago, IL: A. Flanagan Company, 1909)
In Nordic mythology, Heimdall is a mysterious and important god who guards Bifröst, the Rainbow Bridge connecting Asgard to Midgard. If we compare the Rainbow Bridge connecting Asgard and Midgard to the cross-chain bridge, can zero-knowledge proof shoulder the responsibility of guarding cross-chain security and serve a role like the invincible Heimdallr on the Rainbow Bridge?
This report presents the comprehensive analysis of the ZK Bridge by the Investment & Research Team of CGV Research, and strives to explore the development potential of zero-knowledge proof in solving cross-chain security issues and removing high-performance bottlenecks.
TL; DR — What is ZK Bridge? ZK Bridge is a cross-chain bridge using zero-knowledge proof, with zero-trust, license-free, scalable, and efficient features. — Why do we need ZK Bridge? The current centralization and trust assumption of cross-chain bridges lead to poor security, frequent vulnerabilities, and serious losses; while cross-chain bridges that emphasize security are low in efficiency and high in cost. ZK Bridge can simultaneously maintain security, decentralization, and efficiency. — How to implement ZK Bridge? A light node solution based on ZK-SNARK — Related project introduction: Succinct Labs, zkIBC by Electron Labs, zkBridge by BerkleyRDI.
What is a cross-chain bridge? Cross-chain bridge is a technological solution that allows for the transmission of value and information between different blockchain networks. By using a series of crypto and protocol techniques, the cross-chain bridge has realized the safe, verifiable, and trust-free transfer of assets and data, thus promoting interoperability between blockchain networks.
Generally speaking, we divide cross-chain bridges into direct asset cross-chain bridges and universal message cross-chain bridges.
Why has cross-chain bridge become a target of criticism? As a centralized pool of huge funds, the cross-chain bridge is naturally attractive to hackers — the benefits brought by successful attacks are huge. Besides, security assumptions may differ between chains, the code of assets across chains is more complex and code audits cannot identify all vulnerabilities, thus providing opportunities for hackers who are driven by huge incentives.
The specific attack schemes are divided into the following types: Centralized attacks: Some cross-chain bridges rely on centralized relays or validators to transmit and validate transactions. This kind of design may lead to a single point of failure, and attackers can destroy the entire cross-chain system by attacking these centralized components.
Economic incentive attacks: Cross-chain bridges usually require setting appropriate economic incentives to ensure the honest acts of validators and relays. However, it is not easy to design appropriate incentive mechanisms, and insufficient or imbalanced incentive designs may cause malicious behaviors or collusive attacks. Double-spend attack: In some cases, attackers may attempt to spend the same asset on the source and target chains, resulting in double spending of the asset. It is necessary to design effective preventive measures for cross-chain bridges to prevent double-spend attacks.
Replay attack: Attackers may attempt to replay transactions on the target chain that has already taken place on the source chain to obtain improper benefits. It is necessary to implement transaction validation and anti-replay mechanisms for cross-chain bridges to prevent such attacks.
Off-chain coordination attacks: Some implementations of cross-chain bridges rely on off-chain coordination, such as state channels or side chains. Attackers may disrupt the normal operation of cross-chain bridges by disrupting or attacking off-chain coordination.
Inter-chain consensus attack: As the cross-chain bridges involve multiple blockchain networks, different networks may adopt different consensus algorithms. Attackers may exploit the weaknesses of inter-chain consensus to launch attacks, such as implementing a 51% attack on a single chain to affect the correctness of cross-chain bridges.
Overview of current mainstream cross-chain bridge solutions There are no solutions. There are only trade-offs. — — Thomas Sowell
Thomas Sowell (a representative of the Chicago School of Economics) The core cross-chain issue is how to verify the reliability of messages from another chain. Different solutions have been proposed to address this issue, including different levels of trust assumptions.
Trust graph of cross-chain bridges
Comparison of technical parameters of current mainstream cross-chain solutions
The combination of light nodes and relays is the earliest cross-chain solution, represented by BTC Relay, which aims to use Ethereum services by paying Bitcoin. However, due to a large amount of on-chain computing and storage, it is expensive to run on-chain light clients. Moreover, due to the heterogeneity of consensus algorithms and signature algorithms between different chains, the cross-chain solution is not scalable. Therefore, it is necessary to implement the light client and relay for each pair of two specific chains.
So far, only IBC on the Cosmos application chain has achieved large-scale on-chain light clients. The success lies in the extremely high-level standardization of Cosmos application chain, and each application chain needs to run the Tendermint consensus and comply with IBC standards. In a multi-chain world with various consensus mechanisms, signature schemes, and virtual machines, it is difficult to verify on-chain light clients.
Current mainstream cross-chain projects shift the verification process off-chain to avoid the high cost of on-chain light nodes, causing different levels of trust assumptions and potential fraud risks. The Investment & Research Team of CGV Reserach introduces some of the key solutions according to the level of trust, from high to low.
Cross-chain solution 1: Multiple signatures without pledges
Typical projects include Multichain, Wormhole, and Ronin Bridge. These all require the implementation of multi-signature and MPC, which require entity verification of transactions and verification (i.e., signature) of their validity. After passing the threshold (often 2/3), the transaction is considered to be validated.
In this solution, each entity needs to run the entire node for verification. There is no cost for lies without pledges, but reputational damage caused by dishonesty may lead to greater potential costs. Hence, the verification of nodes is often associated with fixed off-chain identities to increase the cost of doing evil.
Multichain’s message verification is guaranteed by the SMPC network, which consists of 24 nodes. Messages signed by more than 2/3 of nodes are considered to pass verification, and SMPC nodes do not need to pledge and are relatively fixed. AnyCall’s security is based on the trust assumptions of SMPC nodes.
The trust layer of Wormhole is constructed using the PoA mechanism, with a set of trusted Guardians responsible for verifying inter-chain messages. Guardians are specific entities endorsed by capital and reputation. Currently, Wormhole has 19 Guardians, including well-known large companies such as FTX, Everstake, and Chorus One.
Cross-chain solution 2: Oracle and relayer
A typical project is LayerZero, which ensures cross-chain security by separating the delivery of messages and proof of message from verifying the delivery transaction of relayer.
The core design idea of LayerZero is the separation of oracle and relayer. In LayerZero, relayer is responsible for delivering messages and proof of message, while oracle is responsible for obtaining block headers from the source chain as needed according to the block where the messages are located, and then the terminal on the target chain verifies the transactions delivered by relayer according to the block headers obtained by oracle. As long as the two do not collude, cross-chain security can be guaranteed.
It is worth noting that although Layerzero calls its technical solution as Ultra Light Node, the solution is fundamentally different from light client. LayerZero verifies the proof of transaction provided by relayer through the block header provided by oracle. The verification occurs at the end of the target chain and is the native validation. However, the verification of the block header is completed by a third-party oracle network as an external validator, and the verification process occurs off the chain.
Cross-chain solution 3: Multiple signatures with pledges
On the basis of MPC, a layer of proof of equity has been added. Typical projects include Celer, Axellar, deBridge, Hyperlane, and Thorchain.
If evil is committed, the validator’s pledge will be significantly reduced, effectively increasing the validator’s cost of deception in economic terms.
A problem that PoS Bridge faces is the imbalance of validators. To alleviate this problem, Axellar adopts the quadratic voting scheme, where the signature weight will be proportional to the square root of the $AXS pledged by the validator; while Hyperlane adopts the “verifiable fraud proof” scheme, where the validators’ joint wrongdoing will be immediately detected and Slash will be executed; pNetwork and Bool Network directly require all nodes to pledge the same number of tokens.
Cross-chain solution 4: Optimistic validation
The knowledge of game theory is used to increase the risk of users’ evil through the game scenarios between users. Typical projects include Nomad and Synapse. The basic logic of optimistic verification is to set up a group of challengers and a challenge window period based on external verification to challenge incorrect verifications. The validator needs to pledge, and when the behavior is inappropriate, the challenger will challenge and provide proof of fraud. If the challenge is successful, the validator’s pledge will become the challenger’s reward.
Nomad has a challenge window period of 30 minutes. In terms of optimistic verification, it requires that at least one challenger is honest and there are economic incentives to challenge. Compared to external verification, this is a smaller trust assumption, under which attackers cannot guarantee the success of attacks, no matter how much economic cost they pay.
All traditional cross-chain solutions are mentioned above, but the development of ZKP has brought new solutions to address the dilemma of the safety and efficiency of cross-chain bridges.
What is ZK Bridge?
ZK Bridge is a cross-chain bridge that employs the zero-knowledge proof, without introducing trust assumptions. It adapts to multiple isomorphic/heterogeneous chains, generates zero-knowledge proof off the chain, and is only responsible for verification on the chain, thus greatly reducing the cost of computing and storage on the chain. It has zero-trust, license-free, scalable, and efficient features.
Let’s first provide a basic overview of the principles of light clients. 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 is to deploy the light node contract of the source chain on the target chain to verify messages from the source chain. If we want to achieve bidirectional cross-chain, we need to deploy the light node contract of the other chain on both chains.
Compared to full nodes, light nodes do not store sequences of complete blocks and only store sequences of block heads. 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 simplified payment verification (SPV) on the transaction through the block header of the block where the transaction is located and the Merkle path of the transaction.
In the following figure, the collection of green squares is the Merkle path of blue squares.
To maintain the light nodes of the source chain deployed on the target chain, it is necessary for the off-chain agent to continuously synchronize block heads of the source chain with the target chain. The light node contract has no trust assumption for the off-chain agent, which is responsible for synchronizing block heads. Given that the light node performs validation on its synchronized block headers, the off-chain agent cannot deceive the light node.
The logic of the light node’s validation of block head is no different from that of the full node and mining node. It is divided into two parts, namely effectiveness validation and finality validation.
The Investment & Research Team of CGV Research argues that for the PoW chain, verification of effectiveness mainly refers to verifying the proof-of-work of the block, and the verification of finality is to check whether effective blocks are appended behind the block header (in BTC chains, an append of 6 blocks is generally considered to confirm the finality of a block, while in Ether, an append of 25 blocks is generally considered to confirm the finality of a block).
For PoS chains, verification of effectiveness refers to verifying whether a block has been generated by randomly selected blockers, while verification of finality refers to whether the block has been signed by validators with voting weights of more than 2/3. There is no need to perform the verification of the effectiveness of the light nodes of PoS, but it is necessary to verify their finality. Because in the PoS chain, the final block must be valid, while in the PoW chain, it may not be valid.
The implementation of ZK Bridge follows almost the same process as the light node and relay solution, with slight changes. In ZK Bridge, the relay off the chain is still required to monitor the source chain and forward the block information of the source chain to the target chain. It not only forwards the block header, but also the proof of validity generated using the ZK-SNARK algorithm. On the target chain, light nodes do not directly verify the effectiveness of transactions based on block headers, but rather verify them on the chain based on proof of validity, thus lowering the computational burden.
The implementation roadmap 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, many of them have suffered serious security attacks, with a huge amount of money stolen, causing large-scale panic at the time. Today, people still hold a skeptical attitude toward the safety of major cross-chain bridges. There is an increasing need for a secure, zero-trust, decentralized cross-chain bridge to lay a solid foundation for a full-chain ecology.
Statistics of funds lost and funds returned of some cross-chain protocols in 2022-Image source: DeField（https://defiyield.info/ )
The Investment & Research Team of CGV Research deems that ZK Bridge has brought new solutions to address the dilemma of safety and efficiency of cross-chain bridges. Specifically, by generating a zero-knowledge proof for the block header off the chain, the correctness of the source chain’s block header is verified by the proof generated by the ZK-SNARK algorithm. In this way, no external trust assumptions are added, and the only thing we trust is mathematics.
Moreover, the verification process of zero-knowledge proof on the chain significantly lowers the computing and storage costs compared with the original light node verification.
Introduction to some projects of ZK Bridge
Succinct by Succinct Labs
Gnosis Chain Omnibridge is a cross-chain bridge between Ethereum and Gnosis, using the mainstream solution of MPC. Team members of Gnosis want to explore cross-chain designs that do not rely on centralized entities, and Succinct Labs and Gnosis collaborate on this, with Gnosis DAO providing R&D grants.
The verification process of Ethereum mainly includes the verification of Merkle proof of block headers; Merkle proof of validators in the sync committee; and the correct rotation of the BLS signatures of the sync committee. The core idea is to use zk-SNARK (Groth16) to generate a proof of validity with constant size, which can be efficiently verified on Gnosis on the chain.
Illustration of Succinct cross-chain solution- Image source: Succinct’s official website（ https://www.succinct.xyz/ )
Succinct Labs’ cross-chain solution is capable of transmitting any message between any two Ethereum-compatible PoS chains. Currently, a cross-chain demo has been implemented between Ethereum and Gnosis, and a bridge deposit contract has been deployed on Ethereum to allow users to deposit. The bridge deposit passes a message to the ambient message bridge (AMB), which stores the message in the contract. The operator is responsible for obtaining proof from the sync committee, generating SNARK proof for valid BLS signature verification, and submitting updates to the light clients of Gnosis Chain.
On Gnosis Chain, the Ethereum block where the deposit transaction is located is confirmed (usually 2 epochs, about 12 minutes). After the light client is updated to a height higher than or equal to that block, the relayer will automatically submit an executeMessage transaction to Gnosis AMB. The executeMessage transaction contains Merkle storage proof for the updated slot of the light client. During executeMessage, AMB uses the light client to obtain the Ethereum state root of the requested_slot and verify the Merkle storage proof to show that the message has been sent on the other side of AMB. Then, AMB uses the calldata specified in the message to receive the smart contract.
Given the maturity of the tech stack and the overhead of on-chain verification, the team chose to use the most mature Circom 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 has been tested on the testnet, its usability is poor. According to the test by the author, the number of Successs tokens on the Goerli testnet has been reduced after passing through bridges, but the Gnosis network has not received tokens, and the dashboard on the website has no bridge records. It is also important to note that the cross-chain becomes unidirectional. In other words, it can only go from Goerli to Gnosis, not the other way around.
zkBridge by BerkleyRDI
zkBridge proves the correctness of the block headers of remote blockchains through ZK-SNARKs, therefore it does not introduce any external trust assumptions. In fact, zkBridge is secure as long as the connected blockchains and basic light client protocols are safe, and there is at least one honest node in the block header relay network. Of course, it is worth noting that although 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 proof and fail to obtain real information.
Illustration of zkBridge cross-chain solution-Image source: https://rdi.berkeley.edu/zkp/zkBridge/zkBridge.html
Specifically, zkBridge mainly consists of the block header relay network and updater contract. In the block head relay network, the relay retrieves the block head from the sender blockchain C1, generates a block head validity proof, and sends the block head and proof to the updater contract set on the receiver blockchain C2. 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 feature to the application, through which the application on C2 can obtain block headers of a given height on C1. After obtaining the information regarding block header, the application can perform more validations (such as specific transactions) and build its applications.
To make the underlying zk-SNARK system compatible with on-chain usage, it is necessary to quickly generate proof and reduce the cost of on-chain proof verification. The main innovations of zkBridge include: DeVirgo: It adopts the distributed method to generate ZK-SNARK without trust assumptions. Besides, it significantly increases the time for generating ZK-SNARK off the chain by splitting the computational work and allocating it to more devices. Recursive proof: To reduce on-chain costs, zkBridge uses recursive proof to compress the volume of ZK-SNARK to around 131 bytes through two iterations. The first step is to generate the deVirgo proof, and the second step is to use the Groth16 proof generator for compression. The Groth16 validator generates and executes a proof of integrity for the deVirgo circuit.
Batch processing: zkBridge implements an update contract for block headers, which takes block height as input and returns the corresponding block header. But zkBridge does not call the update contract when the new block is generated. The prover can first collect N block headers to generate a single proof. The N value can be set. The larger the N value is, the longer the user waits, but the lower the system operating cost.
At present, zkBridge has implemented an instance of Cosmos Client on Ethereum using Solidity. According to testing, it can generate a ZK-SNARK of Cosmos Zone block header within 2 minutes. Then, on the Ethereum side, the verification cost is a constant of 230k gas per hour. By comparison, if ZK-SNARK is not used, the cost will be 64 million gas.
It should be noted that relay network computing will suffer from the same communication complexity as MPC, which will seriously affect the time for proof. 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 if there are 32 machines in the relay network with 32 signatures, it may cause numerous communicating sequential processes in the network, which damages the performance of distributed computing.
zkIBC by Electron Labs Specifically, zkIBC hopes to simulate the trustless communication protocol — Inter Blockchain Communication Protocol (IBC) used in Cosmos, and expand its use to Ethereum. ZkIBC uses ZK-SNARKs to verify the light client state, quickly prove transactions on Ethereum, and keep up with the block generation time of the Tendermint.
The main difficulty is that the Tendermint light client used in the Cosmos SDK runs on the Ed25519 curve, which is not supported by Ethereum. Besides, it is expensive and inefficient to verify Ed25519 signatures on Ethereum’s BN254 curve.
The project roadmap is divided into five stages: research — implementation of ed25519 signature scheme — testnet — implementation of recursive Snark to reduce redundancy — mainnet. On February 2, 2023, the Positron testnet was officially launched to the public, supporting the cross-chain communication between Near and Ethereum. The current testnet requires approximately 20–30 minutes to achieve finality, including Goerli network finality (15–20 minutes), ZK Proof generation (5–8 minutes), and Near chain casting (10–20 seconds).
The project claims to be completely open source, tested, smooth to use across chains, well-designed UI/UX, and supports bidirectional cross-chain.
Reflections
At a certain stage of development, blockchain technology usually evolves into a philosophy of trade-offs. The public chain suffers from the trilemma in terms of security, scalability, and decentralization; the cross-chain communication faces the dilemma of security and efficiency: the pursuit of efficiency leads to the introduction of third-party trust assumptions, resulting in security damage; while the pursuit of security by using the completely light node and relay causes high on-chain overhead.
But, from the point of view of system design, even the unpledged MPC with the highest degree of trust can ensure the security of cross-chain bridges in most cases. The reason why many cross-chain bridges were stolen is due to the pursuit of transparency and open source code. The hidden vulnerabilities in complex code provide hackers with opportunities to exploit them.
CGV Research holds that with the continuous progress of technology, the usability of ZK solution gradually increases, 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. We hope that the maturity of ZK Bridge can break the dilemma of security and efficiency faced by cross-chains, to realize the interconnection of all chains.
References:
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）
Disclaimer: The information and materials presented herein are from public sources and the Company makes no warranty as to their accuracy or completeness. Any descriptions or projections of future conditions are forward-looking statements, any recommendations and opinions are for reference only and do not constitute investment advice or implication to anyone. The strategies that the Company may adopt may be the same, opposite, or unrelated to those that readers speculate based on this report.
About Cryptogram Venture (CGV): Cryptogram Venture (CGV) is a Japan-based, fully compliant crypto industry research and investment institution. With a business orientation of “research-driven investment,” it has participated in early investments in FTX, Republic, CasperLabs, AlchemyPay, The Graph, Bitkeep, Pocket, and Powerpool, as well as the Japanese government-regulated yen stablecoin JPYW. At the same time, CGV FoF is an LP for funds such as Huobi Venture, Rocktree Capital, and Kirin Fund. It has established Web3 hackathons and industry summits as brand events under its umbrella. From July to October 2022, it initiated Japan’s first Web3 Hackathon (TWSH), which received joint support from the Japanese Ministry of Education, Culture, Sports, Science and Technology, Keio University, SONY, SoftBank, and other institutions and experts. CGV has branches in Singapore, Canada, and Hong Kong.