DLT Interoperability and More ⛓️#2 ⛓️

In this series, we analyze papers on blockchain and interoperability (and both).

The second edition covers a whitepaper from May 2021

source. https://lavant-garde-france.com/technologie/la-startup-du-protocole-dinteroperabilite-blockchain-layerzero-leve-135-millions-de-dollars-sur-une-valorisation-de-1-milliard-de-dollars/

➡️ Title: LayerZero: Trustless Omnichain Interoperability Protocol
➡️ Authors: Ryan Zarick, Bryan Pellegrino, Caleb Banister

Some terminology:

• Oracle: party or set of parties that exposes information from an external system (e.g., Chainlink).
• Relayer: party or set of parties that redirect information from one system to another (e.g., block headers or traffic information from chain A to chain B).
• Light client: a software system that validates transactions occurring on a chain by validating block headers, using various mechanisms
• The authors use a different notation. In this article, we consider: an oracle provides off-chain information to smart contracts; a relayer redirects information across blockchains.

➡️ Contributions:

• the authors present Layer Zero, a blockchain interoperability protocol
• the authors claim that “LayerZero is the first system to trustlessly enable direct transactions across all chains”, where based on a “messaging protocol upon which native cross-chain transactions are possible”
• assumptions: there is a network of oracles and a network of relayers that are independent. Information carried by relayers can be verified in a trustless manner

💪 Strong points:

• Catch-on problem: exchanging a token for an intermediary token, that then has to be exchanged again for the desired token on the target chain, is a huge pain. Layer Zero addresses one of the limitations of cross-chain decentralized exchanges: it does not require an intermediary consensus layer (which typically implies a protocol-specific token).
• This way, gas is only paid once, in the source chain (the relayers are thus responsible for absorbing cost on the target chain). The cost-saving seems to be the great advantage of LayerZero.
• Layer Zero is generalizable, following the philosophy of IBC, Interledger, or even XCMP. This is because these protocols propose a messaging format (technical layer) that then can be interpreted in a multitude of ways (semantic layer) — for example realizing asset transfers or cross-chain calls. Bridges are application-specific because they have one purpose hardcoded. On the other hand, protocols such as the Open Digital Asset Protocol stand in the middle, by providing semantics for arbitrary asset transfers on arbitrary infrastructure, but not for carrying arbitrary messages

😞 Limitations:

• a problem with Layer Zero will be the problem of many protocols on the space: lack of standardization, as pointed out in “Rafael Belchior, André Vasconcelos, Sérgio Guerreiro, and Miguel Correia. 2021. A Survey on Blockchain Interoperability: Past, Present, and Future Trends. <i>ACM Comput. Surv.</i> 54, 8, Article 168 (November 2022), 41 pages. DOI:https://doi.org/10.1145/3471140”

Therefore, the risk of misunderstandings (and consequently the difficulty of integration) by applications to work with Layer Zero is higher compared to a standardized interface. However, the heterogeneity of solutions and standards is good for the maturation of the ecosystem.

• The paper is ambiguous at times (which is perfectly understandable because the authors are probably more invested in creating the solution): “LayerZero is the first trustless omnichain interoperability layer”; “LayerZero, the first trustless omnichain interoperability protocol” — is it a protocol or a layer? what do the authors mean by trustless? What do the authors mean by omnichain in this context (is it supporting heterogeneous blockchains?)
• “As long as there is no malicious collusion between the Oracle and Relayer, then LayerZero guarantees valid delivery.” — Unfortunately, it seems that it is enough for one party to collude to sacrifice liveness in the protocol. If a relayer constantly sends false messages, although they are not validated, they can bloat the network;
• The assumption that relayers and oracles are independent (as in, non-colluding), assuming that anyone can be a relayer or an oracle is weak at best. Parties would have a lot of incentives to exploit cross-chain bridges, by trying to prove something that did not happen on a source chain by, for example, conducting an eclipse attack. There needs to be some thought on how to avoid those (fraud proofs, collateralization + slashing, or other mechanisms), which are not present in the paper.

🔥 Points of interest:

• “The block header provided by the Oracle and the transaction proof provided by the Relayer are both invalid, but still match. Scenario 2 can only happen if the Oracle and the Relayer collude, as it is statistically impossible to send a transaction proof that can be validated against a block header without knowledge of that specific block header, and vice versa.” — in theory, a false but valid block header can be built and relayed, and validated, as long as there is consensus on that block. However, there are several techniques to counter this, including promoting data availability and fraud proofs
• Depending on the definition, LayerZero does not seem to be the “first trustless interoperability protocol” suitable for heterogeneous blockchains. The scheme seems to be rooted in the assumption that there are independent (i.e., non-colliding) parties advocating for the state of a chain and relaying proofs of that state (typically parties called relayers). A combination of light clients with relayers can obtain a similar result, with the caveat that consensus can be verified, but not the state transitions. It is also possible, in theory, to create light clients for Ethereum 2.0 which accept authenticated Merkle trees, such that anyone could relay. Those would be signed by Ethereum 2.0 validators (the light sync committee), which would advocate for the validity of proofs. In other words, it would implement the scheme that’s proposed here.
• Other techniques allow proving the internal state of blockchains, including private ones. See, for example, the mentioned topic and the area of view integration: “Verifiable Observation of Permissioned Ledgers” (published on ICBC 2021) and “A Survey on Business Process View Integration” (to be published in the Business Process Management Journal 2022)
• As mentioned in the background section, Polkadot relies on mediating cross-chain communication via a relay chain. This mechanism effectively distributes trust in the cross-chain processes, anchored by the validation of validators and the data transmission by collators. We could think of collators as relayers and of the relay chain and the “light client”. At the moment, the usage of the relay chain is necessary. However, in the future, it is predicted that the relay chain will not be needed for cross-chain interaction (parachains will be able to communicate directly with each other).
• Regarding IBC, the authors claim that “(1) IBC runs a full on-chain light node, and (2) IBC only provides direct communication between fastfinality [24] chains”. Now, IBC’s trade-off is more decentralization for more cost, which is why on-chain light clients are needed. This implies programming and deploying a pair of smart contracts per integration, making bridges costly to build and maintain (cross-chain transactions can take a lot of gas). LayerZero has a smart trick that allows being efficient. 2) Technically, it is Cosmos that provides communication across chains with instant finality. However, IBC can support other blockchains. See, for example, Datachain’s project called YUI that builds products on top of their IBC implementations.
• Decentralized oracle networks are in principle more secure, as they are decentralized, but more complex to build and maintain. With complexity also comes the risk of security flaws.
• “The actual exchange protocol is handled by smart contracts on either side of the cross-chain transaction, with LayerZero delivering messages between the two” — it is not clear to me how this differs from, for example, IBC, cost of transactions apart. We have light clients implemented as smart contracts and a set of relayers in between.
• The idea of valid delivery is rooted in the concept of atomic transaction, coming from the discipline of distributed systems. We can try to map an atomic transaction to ACID properties, something we did in the past: “Rafael Belchior, André Vasconcelos, Miguel Correia, Thomas Hardjono,
  Hermes: Fault-tolerant middleware for blockchain interoperability,
  Future Generation Computer Systems”
• On the design, there are four components plus an oracle: Communicator, Validator, Network, and Libraries, following a modular design (very good practice for extensibility. Note that extensibility does not mean that adding a functionality for a new module is trivial).
• The protocol: there is a series of interactions among components called LayerZero endpoints. At ODAP, we call them blockchain gateways. Blockchain gateways have the responsibility of interacting with ledgers and other gateways, which can in its turn interact with other ledgers. Gateways run a protocol to guarantee that a business need is filled. Now, at ODAP our assumption is that blockchain gateways are owned by a VASP and therefore behave nicely, which is fine either on a permissioned setting or if gateways are legally identified. In ODAP, gateways are centralized. In LayerZero, similarly to IBC, they are decentralized, as they are implemented as smart contracts.
• Lightweight clients (and especially super light clients) are the future for efficient cross-chain transactions. Let’s go, cryptographers!

Bonus: we analyze a follow-up whitepaper dated March 2022: ∆: Solving the Bridging Trilemma.

➡️ Contributions:

• The authors claim to “making it possible to directly bridge native assets without sacrificing instant guaranteed finality”. In other words, a bridge having unified liquidity, finality, and leveraging native transactions.
• The authors say “All chains in a network are connected to all other chains in the network via a pair of unidirectional “connections. Each connection is backed by liquidity on the receiving end to facilitate withdrawals by the user as part of the transfer protocol–the amount of available liquidity on the receiving chain can be thought of as the “bandwidth” of the connection.”. This algorithm is based on the notion of a unified liquidity pool, an abstraction for a cross-chain liquidity pool. Liquidity pools (from different blockchains) belonging to the unified liquidity pool can see each others’ balance and act upon it (transferring liquidity, for example).

💪 Strong points:

• The concept of a single transaction to conduct a cross-chain asset transfer is very interesting and has practical applications, namely, cost-efficiency.

😞 Limitations:

• A unified liquidity pool as the underlying technical mechanism to realize single-transaction cross-chain asset transfers will be a super attractive honey-pot.
• Seems that the limitation a unified liquidity pool brings is the need for orchestrating concurrency on the transactions, as there is a higher probability for a unified liquidity pool to get exhausted (comparatively to a normal liquidity pool).
• Similarly, there are a lot of opportunities to explore arbitrage, via race conditions, frontrunning, and back running.
• Similarly, the unified pool does not have unlimited liquidity: the pool can freeze upon moments of uneven demand for a certain token. The authors introduce some balancing mechanisms to address this issue.
• It is not clear how the protocol technically achieves its main claim: how can we achieve an asset transfer with only one transaction? it seems to be one possibility is: user deposits asset A (hoping to exchange for asset B in chain B) in a liquidity pool on-chain A; a relayer transports the proof to chain B, which 1) validates the transfer; 2) releases a corresponding amount of tokens on B to the user. However, this seems to require liquidity balancing across liquidity pools (which effectively form the unified liquidity pool) and that possibly requires more transactions. How pays? The protocol itself? Perhaps it is not very clear because the paper is focused on the rebalancing of the unified liquidity pool.

🔥 Points of interest:

• Interoperability does not compose very well, because we are dealing with complex orchestrations across heterogeneous systems.
• Providing instantly guaranteed finality either implies a pool of tokens, or that an intermediary token representation is created. Seems that the strategy to provide instant guaranteed finality from LayerZero would be an approach that has a two-transaction process doing the conversions “source chain -> intermediary token -> target chain” atomically. The secret seems to be, with one transaction, locking tokens and minting at the same time. While this seems difficult to do with only one transaction, the authors advocate it is possible.
• “our key insight is that it is possible to borrow and return liquidity between these soft partitions if care is taken to prevent overdrafts or race conditions”
• Techniques to keep the unified liquidity pool balanced seem to be similar to ones used in automated market makers operating in one chain.

Note:

• When we did a systematic literature review on blockchain interoperability solutions, we found out that the whitepapers of many solutions did not reflect their implementation. Blockchain interoperability moves so fast that teams might not have the resources to properly update their theoretical materials and documentation.
• While I’m not claiming this is LayerZero’s situation, it might be. Therefore, there is a risk that the current implementation does not match what is written on the whitepaper.

🚀 How does it relate to our work at Técnico Lisboa, INESC-ID, and Blockdaemon? (views are my own and do not necessarily reflect the opinions of my employer)

• Enterprise-grade infrastructure is key to interoperability and, ultimately, blockchain adoption. We want to explore how can seamless, easy-to-use bridges can be built, deployed, and maintained by individuals and enterprises alike.
• This project composes very well with Hyperledger Cactus, one of the key projects in the area. Cactus can provide a robust infrastructure to implement relayers and oracles, that can act as operators to sustain LayerZero.

🚀 What are the implications for our work?

• This work inspires us and makes us think about trustless oracles and more efficient ways to conduct operations done by millions of users every day.