Interoperability: Unifying the Modular Multi-Chain Future
Modularity enables novel architectures that allow us to build more performant and use case optimized networks. Rollup SDKs and Rollup-as-a-Service providers, alongside these modular, plug-and-play infrastructure blocks, further abstract the complexity historically associated with building decentralized networks. Combined with the improved funding situation and user access of the bull market, this will lead to a Cambrian explosion of products built on modular infrastructure.
As we head into this rollup-centric multichain future, any use case will have its own state machine in an ecosystem consisting of thousands of use case- or vertical-specific chains. Without interoperability, modularity breaks the composability that led to the initial success of monolithic ecosystems like Ethereum or Solana. As more & more smart contract based applications turn into app-specific execution layers, maintaining the composability across chains and countering the fragmentation of users and liquidity, is key.
Ending off our Modular Scripts series, today we want to highlight the importance of interoperability layers. & for those interested, you can check out our previous Modular Scripts piece, which dives into shared sequencers, here.
Before we begin however, we want to thank Fluent for being the title sponsor for Modular March! Fluent is a zkWasm-based Ethereum that is aiming to onboard the 20M developers across the world into web3. They’re live on private testnet today.
The Basics of Interoperability
Blockchains are sovereign, economic zones that have their own laws, currencies and sometimes even languages. That inherently introduces friction across networks with different network designs and trust assumptions, which run different virtual machines or consensus mechanisms.
To enable these otherwise isolated ecosystems or economies to communicate and exchange value with each other, we need cross-chain messaging protocols. However, the difficulty lies in the fact that it is hard to enable trust between disparate systems. Essentially, you have to prove to one chain that a specific event has happened on another and that the network has reached consensus on that state transition. In other words, we have to prove consensus across the technological borders of blockchain networks.
But let’s take a step back.
First, let’s think about how blockchains handle state data. Ideally, we would want to store everything on-chain, secured on thousands of computers across the globe, with extremely high availability and integrity guarantees.
Unfortunately, this is often not feasible due to the scarcity of block space, as a resource on chains like Ethereum, where storing a 32-byte word typically already costs 20,000 gas (approximately $3 at the time of writing). Storage space is limited and expensive. To solve this problem, the Ethereum ecosystem has developed many alternative ways to store data in a decentralized fashion. While they usually involve a tradeoff between availability and price, data integrity is ensured through the Merkle tree structure that blockchains use to store data.
More specifically, blockchains like Ethereum use a tree data structure (Merkle Tree), where each node is a hash of the nodes below it, which hash different subsets of the data repeatedly. Through the use of Merkle inclusion proofs, Merkle Trees enables you to send a hash instead of the whole data you are looking to prove inclusion/exclusion.
The top-of-the-tree root hash is the only on-chain storage necessity within a light client. Proving a particular value involves showing all associated hashes for combination towards the root. For instance, demonstrating C entails providing D, H(A-B), and H(E-H), significantly trimming the data required to verify a blockchain’s state.
So what are blockchains? Basically, we are talking about cryptographically connected and secured data structures here. The data is stored in blocks, each having a unique block header consisting of:
Hash of the previous block
Merkle root (the state data/information)
Validator signatures attesting to block validity/consensus (PoS case assumed)
While this is not necessarily the basis on top of which all interoperability protocols are built on, it is key to understand the potential that lies in ZK-powered verification mechanisms and why ZK tech is set to disrupt the interoperability space.
Trusted vs. Trust-Minimized Interoperability
Proving the state of one chain within another chain’s execution environment can be achieved by passing block headers between networks and verifying the validator signatures attesting to the validity of the included state root.
IBC-enabled chains pass block headers in IBC Packets through IBC channels to other networks, where an IBC light client verifies the validator signatures, allowing these IBC-enabled chains to effectively prove any statement about the source chain’s state, unlocking powerful cross-chain composability.
But while IBC is a promising solution for trust-minimized cross-chain communication, it is hard to implement on computationally limited blockchain networks like Ethereum, where verifying the entire set of IBC validator signatures on-chain is not feasible due to the gas limit per block. Since trust-minimized interoperability is hard to achieve, many teams have worked on alternative mechanisms to verify cross-chain messages.
They differ in what they verify (e.g. consensus vs. transactions) and how they do that. In the following, we will focus on the latter and discuss some of the most popular approaches on a high-level.
While the above-mentioned IBC falls into the category of trust-minimized interoperability solutions (trust the code), generalizability, cost efficiency and ease of use have led to the emergence of a broad spectrum of “trusted” interoperability solutions that introduce some degree of centralization and hence trust assumptions that lie outside of the security guarantees of the blockchains involved. These have designed alternative ways of verifying that events on the source chain have happened by and handle message verification off-chain (or on a dedicated network).
Let’s have a brief look at some examples of approaches that fall into this category and how they verify messages.
Single Signature: Entirely centrally maintained bridges (e.g. on CEXes) where the operator single-handedly decides on what constitutes a valid message/transaction.
Multi-Sig/MPC: Spreading the verification workload across a number of participants that can conjointly verify messages through a threshold signature scheme (TSS), in some cases with additional MPC security layers.
PoS Validator Sets: Instead of using a multi-sig solution, other teams opt for application-specific blockchains that have proprietary and crypto-economically secured validator sets performing the task of message verification.
Optimistic Verification: Similar to optimistic rollups, messages are optimistically assumed to be valid with verifiers that can initiate fraud proving mechanisms in case of faulty / fraudulent transactions.
Trust minimized solutions like IBC on the other hand sit at the right end of the spectrum:
Direct or ZK-enabled Consensus Verification: Verification of the validator signatures (or a succinct proof of them) within the execution environment of the target chain without any third-party trust involvement or additional trust assumptions.
Modularity has also reached the interoperability space, where separating this verification layer from the transport layer has become increasingly popular, as certain teams specifically focus on building the transport layer, while creating a marketplace for the different approaches on the verification layer. This allows applications to tailor security to align with their specific requirements, taking into consideration a variety of factors such as degree of security, speed or cost. This approach is especially promising in the context of the rollup-centric multichain future outlined above, where use case- or vertical-specific execution layers will likely have very different requirements and where ease of access is key.
Moving Towards Trust-Minimized and Permissionless Interoperability
Interoperability solutions, or rather the (bridging) applications built on top of them, have historically proven to be prone to exploits. Many of the largest crypto heists have happened on multi-chain dApps, where nascent technologies, third-party trust assumptions, and a high degree of complexity have often left room for critical attack vectors.
This is not a feasible basis to build a modular multi-chain future on top of. That is why we need trust-minimized cross-chain communication that is more secure and most importantly, not under the control of centralized actors that base decisions on which networks to support on business considerations. To maintain the permissionless composability that underlies the Ethos of Web3, interoperability needs to be accessible to anyone and permissionlessly attainable. Only with sovereign and trust-minimized cross-chain interoperability can modularity reach hyper-scale and unleash its full potential.
So why don't we do this already? Historically, implementing such a system was a challenging task. However, recent advancements in Zero Knowledge (ZK) proof systems have finally made it feasible. Thanks to succinct ZK proofs, consensus (block headers) can be ZK-proven within the execution environment of the target chain, drastically reducing the computational overhead, and hence making trust-minimized interoperability feasible on chains that were previously not able to support direct consensus verification onchain.
Lagrange: The Parallel Prover for Cross-Chain Consensus & State Proofs
That’s why to conclude with this article, we will have a look at Lagrange, a leader in the ZK-powered interoperability space:
Lagrange's Parallel Prover is a proprietary proving network. It is optimized for verifiable computation over historical storage, receipt, or transaction data from smart contracts at a big data scale and enables seamless interaction between blockchains with cryptographically secure, ZK-powered state proofs.
With Lagrange, a proof can be generated from a single block header, proving both an array of historical storage slot states at arbitrary depths and the result of a distributed computation executed on this state data. Lagrange’s ZK proofs are modular and can also be generated from any block header, even originating from existing cross-chain bridges and messaging protocols, making the solution entirely chain-agnostic. Lagrange state proofs, provided by EigenLayer-based proving network or State Committees, are also agnostic to the transport layer used to relay them to destination chains, which means that any interoperability protocol can integrate with Lagrange’s proving layer.
Lagrange will serve as a permissionless proving layer that blockchains and interoperability solutions can use to generate consensus/state proofs that can then be relayed and verified on-chain across all connected networks. This will unlock powerful cross-chain composability at scale, and if coupled with a proof aggregation layer, can evolve into a solution where a single, permissionless integration allows for trust-minimized interoperability with thousands of chains.
We hope you enjoyed this piece on interoperability, and more specifically, on the importance of trust-minimized interoperability enabled by ZK technologies built by teams like Lagrange. & for those who missed our previous Modular Scripts posts, here’s one on Data Publication layers, here’s all about Virtual Machines (VMs), and here’s our most recent one covering shared sequencer networks. Huge s/out to the author of these pieces, Zero.
& as always, a huge thank you to our Modular March sponsors! 🧱
