LK Venture Research Report: Can ZK Bridge achieve the "end of the cross-chain war"?

The original title "LK Venture Research Report: Can ZK Bridge Achieve the End of the Cross-Chain War"? "

Original source: LK Venture

Today, Ethereum occupies half of the blockchain industry infrastructure, but its main network Dominance 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 cross-chain bridges connecting various blockchain networks have frequent security issues, 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 guarding the rainbow bridge with pictures

Image source: Klugh, Maria Tales from the Far North (Chicago, IL: A.Flanagan Company, 1909)

In Nordic mythology, Heimdallr (Heimdallr) is a mysterious and important deity who is responsible for guarding the rainbow bridge connecting Asgard and Midgard— — Bifrst. 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 important task 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 use of zero-knowledge proof technology in solving cross-chain security and high performance The development space of the bottleneck problem.

TL;DR

- What is ZK Bridge? ZK Bridge is a cross-chain bridge using zero-knowledge proof technology, featuring zero-trust, permissionless, scalable, 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 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 technical solution that allows value and information transfer 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 will the cross-chain bridge 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.

The specific attack schemes can be divided into the following types:

1. Centralized attack : Some cross-chain bridges rely on centralized repeaters or validators 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 the asset double spend. Cross-chain bridges need to design effective preventive measures to prevent double-spending attacks.

4. Replay attack: The attacker may try to replay transactions that have occurred on the source chain on the target chain, thereby trying 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. Attackers may exploit the weaknesses of inter-chain consensus to launch attacks, for example, implement a 51% attack on one chain to affect the correctness of cross-chain bridges.

A list of current mainstream cross-chain bridge solutions

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.

Cross-chain bridge trust map

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 is to use Bitcoin to pay for services using Ethereum. However, running an on-chain light client is expensive due to the large amount of on-chain computation and storage required. Moreover, due to the heterogeneity of consensus algorithms and signature algorithms between different chains, the cross-chain solution is not scalable, and it is necessary to implement light client & relay for each pair of specific two chains.

So far, only the IBC on the Cosmos application chain has realized a large-scale on-chain light client. The reason for its success lies in the standardization of the Cosmos application chain Extremely high, each application chain needs to 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 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 risk, LK Venture investment research team introduces some key schemes according to the trust level from high to low.

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.

Multichain's message verification 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 No pledge is required, and it is relatively fixed. The security of AnyCall is based on the assumption of trust in SMPC nodes.

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 The subject of capital endorsement and reputation endorsement. Currently, there are 19 Guardians in Wormhole, including well-known big companies such as FTX, Everstake, and Chorus One.

Cross-chain solution 2: oracle and relay

Typical projects include LayerZero, The security of the cross-chain process is ensured by separating the transfer of messages and message proofs and the verification of Relayer transfer transactions.

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. The Oracle is responsible for obtaining the block header 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: pledged multi-signature

Increased on the basis of MPC A layer of proof of rights and interests, typical projects include Celer, Axelar, deBridge, Hyperlane, Thorchain.

If you do 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 that PoS bridges have to face is the imbalance of verifiers. In order to alleviate this problem, Axelar adopts a quadratic voting scheme. It will be proportional to the square root of the amount of $AXS pledged by the verifier; Hyperlane adopts the "Verifiable Fraud Proof" scheme, and the joint evil of the verifier will be discovered immediately and Slash will be executed; pNetwork and Bool Network directly require all nodes to pledge the same amount of $AXS Token.

Cross-chain solution 4: Optimistic validation

Using game theory Knowledge, through the game scene between users to increase the risk of users doing evil, typical projects include Nomad, Synapse.

The basic logic of optimistic verification is: on the basis of external verification, set a batch of challengers and a challenge window period to challenge incorrect verification, Validators need collateral, and when they misbehave, challengers 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.

The original cross-chain scheme is over here, but the development of ZKP zero-knowledge proof technology has brought new challenges to the dilemma of safety and efficiency of cross-chain bridges. s solution.

What is ZK Bridge?

ZK Bridge is a cross-chain bridge using zero-knowledge proof technology, does not introduce trust assumptions, adapts to various homogeneous/heterogeneous chains, and generates zero Proof of knowledge, the chain is only responsible for verification, which greatly reduces the calculation and storage costs on the chain, and has the characteristics of zero trust, no permission, scalability, 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 to full nodes, light nodes are lightweight nodes that do not store the sequence of complete blocks, but only the sequence of block headers.

Although the block header is small in size, it 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 target chain The deployed source chain light nodes need an off-chain agent 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 workload proof of the verification block, and the finality verification is to see Whether there are more valid blocks added behind the block header (in the BTC chain, it is generally believed that the addition of 6 blocks can confirm the finality of a block; in Ethereum, it is generally considered that the addition of 25 blocks Appending 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 refers to the Whether the block is signed by validators 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 solution of light node plus relay, 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.

ZK Bridge's implementation technology path

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 is very large. At that time, it caused a large-scale panic, and today everyone still has doubts about the safety of the major cross-chain bridges. People increasingly need a safe, zero-trust, and decentralized cross-chain bridge to lay a solid foundation for the future full-chain ecology.

Partial cross-chain protocol loss funds and recovery funds statistics in 2022

Image source: DeFiyield (https://defiyield.info/)

< /p>

In the view 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 correctness of the source chain block header 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 proofs on the chain will significantly reduce computing and storage costs compared with the original light node verification scheme.

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. Gnosis team members hope to explore a cross-chain design that does not rely on centralized entities. Succinct Labs and the Gnosis team collaborate on this, and Gnosis DAO provides grants for R&D.

The verification process of Ethereum mainly includes the verification of the following content: the Merkle proof of the block header; the Merkle proof of the verifier in the synchronization committee; the BLS of the correct rotation of the synchronization committee signature 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.

Succinct cross-chain solution diagram

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. The cross-chain Demo between Ethereum and Gnosis is currently 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), which stores 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 Gnosis Chain, 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 After a block whose height is greater than or equal to this block, the Relayer will automatically submit an executeMessage transaction to the Gnosis AMB. 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 get 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.

For the consideration of technology stack maturity and on-chain verification overhead, the team chose to use the most mature Circom language and the cheapest Groth16 proof system for on-chain verification to generate ZK-SNARKs without 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 in the Goerli test network has been reduced 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 through ZK-SNARKs The correctness of the block headers of the remote blockchain, so no external trust assumptions are 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.

zkBridge cross-chain solution diagram

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, and compresses the volume of ZK-SNARK proof to about 131 bytes through two recursions. The first step generates deVirgo proofs, and the second step uses the Groth16 proof generator for compression. Groth16 validators 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 of the Cosmos Zone block header can be generated within 2 minutes -SNARK proof, then on the Ethereum side, the verification fee is a constant of 230k gas per hour. 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, hurting the performance brought by distributed computing.

zkIBC by Electron Labs

Specifically, zkIBC Hope to simulate the trustless communication protocol used by the Cosmos sovereign chain - Inter Blockchain Communication Protocol (IBC), and extend the 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. Verifying Ed25519 signatures on Square's BN254 curve is expensive and inefficient.

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, 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 for finality, including Goerli network finality (15-20 minutes), ZK-Proof generation (5-8 minutes), Near chain minting (10-20 seconds) .

The project claims to be completely open source, after testing, the cross-chain process is smooth to use, the UI/UX is well designed, and it supports two-way cross-chain.

Thinking

Blockchain technology has developed to a certain stage , often 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 cross-chain in most cases Bridge security. 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 will gradually increase, ZK Rollup is expected to be put into large-scale use in the second half of 2023, and ZK Bridge will also 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.

｜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 Comaprison Between Multiple Blockchains (https://dune.com/springzhang/cross-blockchain-comparison-overview)

欢迎加入律动 BlockBeats 官方社群：

Telegram 订阅群：https://t.me/theblockbeats

Telegram 交流群：https://t.me/BlockBeats_App

Twitter 官方账号：https://twitter.com/BlockBeatsAsia