Starting from LayerZero and Google Cloud, should cross-chain rely on oracle or ZK?

Should cross-chain rely on oracle or ZK? Starting from LayerZero and Google Cloud.

Author | Joey Wu on Blockchain

LayerZero and Google Cloud have announced the integration of Google Cloud as a new cross-chain oracle option on LayerZero. In the cross-chain implementation of LayerZero, the role of the oracle is to verify whether a message has been processed by the source chain for cross-chain message requests. Now, applications built on LayerZero can choose from four different oracle options, including Chainlink, Polyhedra’s zkLightClient, and oracles managed by Polygon and Sequoia.

The latest change is that Google Cloud will replace the oracle managed by Polygon/Sequoia and become the default configuration for applications on LayerZero’s cross-chain solution. This is the first time LayerZero has changed its default configuration since March 2022, making it a significant change for LayerZero. This move may also have an impact on Solana, considering that Google Cloud joined the Solana ecosystem just a few months ago as a validator and core infrastructure provider. This also raises an interesting question about whether the cross-chain security of blockchains may eventually rely on centralized internet giants, which is a topic worth pondering.

Meanwhile, the ZK cross-chain interoperability protocol Polyhedra has recently completed integration with the BNB Layer 2 network opBNB. This protocol, along with LayerZero, is one of the only two cross-chain bridge protocols on the BNB Chain Ecosystem Catalyst Awards list. With the failure of Multichain, there currently seem to be only two mainstream cross-chain routes to choose from: oracle-based cross-chain and zero-knowledge proof (ZK) cross-chain. LayerZero and Polyhedra represent the leaders of these two routes, respectively.

• Blockchain Game Expert Expectations for the Remaining Time of 2023
• Meng Yan Reflection on the Blockchain Industry in the Past Decade How to Generate and Spread Trust Without Relying on Authority?
• Overview of the current situation of cryptocurrencies in the Middle East and North Africa

LayerZero essentially utilizes the principles of light node technology and designs a super light node mechanism to divide the intermediate trust link into two parts through relayers and oracles, in order to achieve higher security at a lower cost.

A light node only saves the headers of all historical blocks and does not store specific transaction information within the blocks. Multiple Merkle Roots of block headers are sufficient to verify whether transactions truly exist in the block using Merkle trees. By running verification on a light node, external roles such as notaries are completely eliminated, achieving a higher degree of decentralization and thereby enhancing security. However, this also means that the cost of cross-chain will be shared by the users with cross-chain demands, which may become relatively high.

An ultra-light node (ULN), as compared to a light node, performs the same verification as an on-chain light node, but does not sequentially retain all block headers. Instead, it streams the necessary block header data on demand through decentralized oracles. Its advantage is that it does not rely on light nodes to obtain block header data streams. However, the cost is the lack of a historical sequential data stream, which means that if both oracles and relayers act maliciously, it may result in the execution of malicious information through verification, thereby reducing security to a certain extent but lowering costs.

In this process, the role of a relayer is to pass the path information required for Receipt and Merkle Proof in the cross-chain message to the smart contract on the target chain for verification. The Receipt contains information such as the execution result of a transaction, the transaction hash, and transaction event logs. The oracle in LayerZero’s cross-chain plays the role of a notary, passing the Blockhash and Block Receiptsroot of the cross-chain request on the source chain to the target chain. The Blockhash is used to inform the smart contract on the target chain which block contains the user’s cross-chain request, while the Block Receiptsroot is used to verify the message passed by the relayer. Therefore, for the sake of interests, the oracle must be extremely trustworthy, as its trustworthiness determines the security of assets.

If there is only one oracle, there is a great risk. In order to prevent this situation, LayerZero implements a strategy where any application can customize its own oracle to support its system. Even if some oracles go down or act maliciously, cross-chain operations can still continue. Market competition has gradually evolved into a variety of choices, forming a multi-to-multi selection pattern, and decentralized mutual supervision systems will be established among various parties. Even if a particular oracle and a particular relay collude, it will only have a certain impact on the specific applications that use both of them.

In addition to security factors, LayerZero also has greater versatility and extremely low protocol access costs, which is an invisible advantage.

Greater versatility. In the current cross-chain protocols, including the IBC protocol in the Cosmos ecosystem and the XCMP cross-chain protocol in the Polkadot ecosystem, in order to verify transactions on other public chains, corresponding light nodes must be deployed on Ethereum. The high gas costs make it difficult for many EVM-compatible chains (such as ETH/BSC/Polygon/L2, etc.) to support the IBC protocol, thus limiting the universality of the IBC protocol. Currently, it can only operate between relatively niche Cosmos ecosystem chains.

Lower developer access complexity. From the beginning, the focus of the LayerZero protocol has been on the design of minimalistic contract access, while the demand potential for cross-chain messages is huge, covering aspects such as cross-chain lending, yield aggregation, and transactions. Due to its ease of use and development, the protocol has already delivered millions of messages on more than 30 chains.

As for ZK cross-chain technology, it addresses the trust issue of oracle cross-chain. By introducing zero-knowledge proof technology, ZK cross-chain does not eliminate relays, but rather delegates the proof process of relays to cryptography, transforming trust in third parties into trust in cryptography. This makes it possible to verify new block headers off-chain and submit the new block headers and their validity proofs (Zk Proof) to the chain, where the ZK Proof can be directly verified on-chain, equivalent to verifying the new block headers. ZKBridge adopts a modular design that separates the program for verifying smart contracts from the core bridge. The core bridge includes relays and update contracts, where relays receive block headers from the previous block and verify their correctness, and the update contract checks and accepts these proofs. Application contracts consist of sender and receiver contracts, deployed on two chains respectively, and these contracts interact with ZKBridge to perform cross-chain operations.

During cross-chain operations, the block header relay node generates zero-knowledge proofs to prove the correctness of the relayed block headers and sends them to the update contract. The update contract maintains the state of the sender blockchain and allows the receiver contract to query block headers. The application contract defines the information to be bridged.

For this purpose, PolyHedra developed a proof system called deVirgo, which is a distributed version of the Virgo protocol aimed at parallelizing the GKR protocol by distributing computations across multiple machines. Although it uses the same cryptographic assumption as Starkware and Polygon Zero, namely ZK-SNARK, its innovation lies in the use of a distributed approach to generate SNARK proofs, i.e., the off-chain generation of ZK-SNARK proofs is split into parallel computations across multiple machines. According to the test data published by PolyHedra, the time it takes to generate an Ethereum full-node proof and recursively verify it using two AMD EPYC ™ 7763 CPUs is less than 12 seconds, far below the block time of Ethereum.

However, this does not mean that ZKbridge is necessarily superior to relay-based cross-chain solutions in terms of performance. Even without considering the test data from Polyhedra, the cost of verification is still a concern. Taking EVM as an example, verifying a ZK proof requires over 500k Gas fees, while verifying a signature with a relay costs less than 30k Gas, which means the final cross-chain cost could be very high. Currently, Polyhedra has only launched the cross-chain functionality for NFTs, and the cost is still within an acceptable range. However, the nature of cross-chain for NFTs is different from that of FTs, so the actual cross-chain cost of Polyhedra still needs further testing.

In addition, Polyhedra has also designed a proof system called LianGuairaPlonk, which is claimed to accelerate existing zkRollup systems. It achieves collaborative verification by allowing distributed nodes to pass a minimal amount of data between them. However, we have not yet experienced this feature in the product.

In the development process of ZK technology, one possible implementation path is to make ZK proofs one of the oracle options. Users can choose different oracles based on their needs. If it involves a large amount of money, they can choose ZK verification; if it involves a smaller amount, they can choose oracles like Google Cloud or Chainlink.

From the perspective of industry development, this is a win-win route for ZK cross-chain protocols like LayerZero and Polyhedra, as well as the entire industry. The liquidity fragmentation problem has spread to the cross-chain field, and if ZK proofs can act as oracles, it is expected to achieve a major consolidation of the currently fragmented liquidity.

References:

https://m.freebuf.com/articles/blockchain-articles/363739.html

https://foresightnews.pro/article/detail/38691

https://www.binance.com/zh-CN/feed/post/889904

We will continue to update Blocking; if you have any questions or suggestions, please contact us!