LayerZero and Google Cloud have announced the integration of Google Cloud as a new cross-chain oracle option on LayerZero. In the implementation of cross-chain on LayerZero, the role of oracles is to verify whether a message has been processed by the source chain in response to a cross-chain message request. 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 marks a significant change for LayerZero since March 2022 and could also have implications for Solana, considering Google Cloud joined the Solana ecosystem as a validator and core infrastructure provider just a few months ago. This also raises an interesting question: Could the cross-chain security of blockchains ultimately rely on centralized internet giants? This is a thought-provoking topic.
Meanwhile, the ZK cross-chain interoperability protocol Polyhedra has recently integrated with the BNB Layer 2 network opBNB. This protocol, along with LayerZero, is one of the two cross-chain bridge protocols listed on the BNB Chain Ecosystem Catalyst Awards. Given the failure of Multichain, it seems that there are currently only two mainstream cross-chain routes available: oracle-based cross-chain and zero-knowledge proof (ZK) cross-chain, with LayerZero and Polyhedra representing leaders in each of these routes.
LayerZero fundamentally utilizes the principles of light node technology and has designed an ultra-light node mechanism. This mechanism splits the intermediate trust links into two parts through relayers and oracles, resulting in higher security at a lower cost.
Light nodes only store all historical block headers, not the specific transaction details within the blocks. Multiple Merkle Roots of block headers are enough to verify whether transactions truly exist in a block using Merkle trees. By running verification on light nodes, external roles like validators are completely eliminated, achieving a higher level of decentralization and thus improving security. However, this also means that the cross-chain costs will be spread to users with cross-chain demands, potentially making them higher.
Ultra-light nodes (ULN), as compared to light nodes, perform the same verification as on-chain light nodes but do not sequentially retain all block headers. Instead, they are streamed as needed by decentralized oracles. The advantage is that they do not rely on light nodes to access block header data streams. However, the cost is the lack of historical order data streams, which means that if both oracles and relayers act maliciously simultaneously, it could lead to malicious information execution through verification, thereby reducing security to some extent but reducing costs.
In this process, the role of relayers is to pass on the path information required for cross-chain messages, such as Receipt and Merkle Proof, to smart contracts on the target chain for verification. Receipt contains information such as transaction execution results, transaction hashes, and transaction event logs. Oracles in LayerZero’s cross-chain act as notaries, passing Blockhash and Block Receiptsroot from the source chain’s cross-chain request to the target chain. Blockhash informs the smart contracts on the target chain which block contains the user’s cross-chain request, and Block Receiptsroot is used to verify the messages passed by the relayer. Therefore, for the sake of security, oracles must be highly trusted because their trustworthiness determines the security of assets.
If there is only one oracle, there is a significant risk. To prevent this scenario, LayerZero allows any application to customize oracles to support the strategies of their systems. Even if some oracles go down or behave maliciously, cross-chain work can still continue. Market competition has evolved multiple choices, creating a decentralized system of mutual supervision. Even if a specific oracle and relayer collude, it will only have a certain impact on specific applications that use both.
Relying on oracles for cross-chain transactions comes with security risks but also offers a significant advantage — notably, lower development complexity. Since the network primarily relies on oracles, theoretically, as long as oracle nodes are decentralized enough, secure cross-chain transactions can be achieved without the need for overly complex technology, similar to how Bitcoin relies on a sufficient number of miners. This is why, to date, LayerZero has successfully implemented asset cross-chain transactions between over 30 chains, including non-EVM public chains such as the IBC protocol in the Cosmos ecosystem and the XCMP cross-chain protocol in the Polkadot ecosystem.
As for ZK cross-chain technology, it addresses the trust issue of oracle-based cross-chain. By introducing zero-knowledge proof technology, ZK cross-chain doesn’t eliminate relayers but rather shifts the proof process from intermediaries to cryptography, transforming trust from third parties to cryptographic methods. However, it’s apparent that implementing this technology can be challenging. If the development complexity is too high, it could hinder the future ecosystem’s growth. Oasis, a privacy computing public chain, serves as a typical example.
However, compared to privacy computing, ZK’s implementation complexity in the cross-chain domain is much lower. When initiating a cross-chain request, you can verify new block headers off-chain and submit them, along with their validity proofs (Zk Proof), to the chain. On-chain, you can directly verify ZK Proof, which is equivalent to verifying new block headers. ZKBridge adopts a modular design, separating the program for verifying smart contracts from the core bridge. The core bridge consists of relayers and update contracts; relayers receive the previous block’s headers and verify their correctness, while update contracts check and accept these proofs. Application contracts consist of sender and receiver contracts, deployed on two chains respectively, and these contracts interact with ZKBridge to execute cross-chain operations.
During cross-chain transactions, block header relayers generate zero-knowledge proofs to prove the correctness of the relayed block headers and send them to update contracts. Update contracts maintain the state of the sender blockchain and allow receiver contracts to query block headers. Application contracts define the information to be bridged.
For this purpose, PolyHedra has developed a proof system called deVirgo, which is a distributed version of the Virgo protocol aimed at parallelizing the GKR protocol by spreading computations across multiple machines. While it uses the same cryptographic assumptions as Starkware and Polygon Zero, namely ZK-SNARK, its innovation lies in using a distributed approach to generate SNARK proofs, splitting the work of off-chain ZK-SNARK proof generation across multiple machines. According to Polyhedra’s published test data, generating an Ethereum full node proof and recursively verifying it using two AMD EPYC ™ 7763 CPUs takes less than 12 seconds, well below Ethereum’s block time.
However, this doesn’t necessarily mean that ZKbridge always outperforms relay-based cross-chain transactions in terms of performance. Even without considering Polyhedra’s test data, the cost of verification remains a concern. For example, in the EVM, verifying a ZK proof costs over 500k Gas, while verifying a relayed signature costs less than 30k Gas, indicating that the final cross-chain fees could be very high. Currently, Polyhedra has only introduced cross-chain functionality for NFTs, and the cost remains within an acceptable range. However, NFT cross-chain differs in logic from FT cross-chain, so Polyhedra’s actual cross-chain costs still need further testing.
Additionally, Polyhedra has designed a proof system called paraPlonk, which is claimed to accelerate existing zkRollup systems. It achieves this by enabling minimal data transfer between distributed nodes to facilitate collaborative verification. However, we have not yet experienced this functionality in a live product.
In the development of ZK technology, one possible path is to make ZK proofs one of the oracle options. Users can choose different oracles based on their needs. For larger amounts, they can choose ZK verification, and for smaller amounts, they can opt for oracles like Google Cloud or Chainlink.
From an industry development perspective, this is a win-win route for LayerZero, Polyhedra, and other ZK cross-chain protocols, as well as the entire industry. Liquidity fragmentation has spread to the cross-chain domain, and if ZK proofs can act as oracles, there is hope for consolidating the currently fragmented liquidity.
Reference:
https://m.freebuf.com/articles/blockchain-articles/363739.html
https://foresightnews.pro/article/detail/38691
https://www.binance.com/zh-CN/feed/post/889904
Follow us
Twitter: https://twitter.com/WuBlockchain
Telegram: https://t.me/wublockchainenglish
