Cross-chain Future

Nov 28th, 2022
Iso Lab

Table of Content


There is no doubt that Ethereum is the most secure blockchain (as of today) with the largest ecosystem. It is foreseeable that Ethereum could become the “Pareto frontier”1 for running blockchain applications, but it is highly improbable that there will be “a blockchain for everything”. When we zoom into specific use cases, not all properties of a blockchain2 have equal importance. The choices made on algorithms and submodules3 lead to vastly different user experiences and security guarantees. The tradeoffs are already manifested in layers 1 blockchains and their distinctive ecosystems today, which capture different types of builders and products.

[1]: Often used in reforcement learning - the best solution for the general case (i.e., under one set of weights for each objective) would no longer be the most optimal when the weights change.

[2]: For example: security guarantees, resistance to censorship, execution speed, transaction throughput, finality time

[3]: Consensus mechanisms, signatures schemes, block parameters (size, time, and more), execution models (ordering, parallelization, and more)

If this trend continues, we should see more blockchains dedicated to different purposes. For example, if we were to think of different blockchains as different cities and users of each blockchain as citizens in each city, we would not want to all live in one dystopian mega-city. Just like cities need roads to connect them, blockchains need bridges to talk to each other, so “citizens” of each chain can freely come and go as they please and experience the best each chain can offer. Therefore, assets and information must be able to flow between any two blockchains freely, safely, and securely.

Thus, we believe the best bridge is the bridge that silently does its job in the background:

It also needs not to be said why we don’t simply bridge assets or information cross-chain using trusted agents, such as Chainlink Oracle or a self-hosted server. It is akin to placing trust in MtGox or FTX - which recently has proven to be a $10 billion mistake.

In other words, the ideal bridge should be “trustless”:

[4]: The security of the source and destination chains, such as the integrity of smart contracts on these chains, the consensus of their validators, and that no more than 1/3 is malicious, among other assumptions

The role of ZKP

In a separate article “What to build next in ZKP”, we showed a few ways ZKP could fix the “bridge problems”5 without getting into too many technical details. We will discuss our solutions to specific problems (with a lot of math and empirical data) in separate documents. Without repeating what we said in other articles, here we want to explain on a high level why we believe ZKP would play a critical role going beyond solving immediate problems.

Regardless of what assets or messages are sent across a blockchain, the destination chain must verify events and messages claimed to have been committed in other chains6. However, the verification is typically not feasible to fully compute on-chain because the computation requires using functions too complex by the chains’ virtual machines (such as EVM) and processing a large amount of input data. To work around this, we have to partition the computation and move some parts off-chain while proving the off-chain computation is done correctly using some known parameters stored on-chain and some off-chain data the on-chain verifier doesn’t care about (except for relevant parts)7. ZKP is the ideal tool for this because8:

Besides verifying computation efficiently, ZKP also plays interesting roles in use cases requiring privacy. where both anonimity and confidentiality10 could be applicable. In practice, both have already been achieved in existing protocols based on a single chain11 using ZKP, which can be used to derive a cross-chain protocol.

We will discuss the technical details of the above three areas in separate technical deep-dive articles.

[5]: Referring to problems of the present day, such as hacks with over $2 billion worth of user funds in 2021 and 2022.

[6]: Strictly speaking, the events and messages are recursively aggregated into Merkle trees (such as block headers) or other checkpoints to reduce the amount of on-chain data and computation. The exact approaches are discussed in our detailed technical articles.

[7]: A simple example is the Merkle tree, where the root is often stored on a chain, and proof of membership of the tree is done by submitting a path of neighbors along with the member (i.e., leaf) to be proved. Verifying ZKP is more complex but with the same principle.

[8]: To give readers unfamiliar with ZKP some context: On a high level, a ZKP is generated by taking public input x, a witness (private information) w, a (publicly known) program q such that q(w, x) = y and produces a proof p. The proof p has properties such that anyone can easily verify y is the output of running q with input x and some unknown witness w. “Easily” means the amount of computation in verification is insensitive to or much less than (in logarithm order to) the size of x, q, and w, and in practice, can be completed using a reasonable amount of gas on-chain. In practice, the form and complexity of the program q are quite limited. It needs to be represented as circuits and not require an absurd amount of computational resources (and time) to generate a ZKP.

[9]: Such as in Circom, and other tools in-development by other teams that directly transform common programming language code, such as RISC0

[10]: Anonymity refers to the ability to trace a bridge transaction to its source. Confidentiality refers to protecting the content of the messages (or assets). See Wei Dai’s Navigating Privacy on Public Blockchains for more discussions regarding these two concepts and how they are typically handled on-chain today, and how ZKP is used.

[11]: Such as Zcash and Tornado Cash (banned by US regulators).

Use cases of the near future

Crypto gaming12 has been a use case on the rise13 despite the ban from large gaming platforms (Microsoft, Steam, and others). One tradeoff game developers have to make is where to store the assets, where to store game states and execute game logic, and where to onboard users. Ethereum is great for storing and trading player assets14, but it is also the least economically feasible to store any state or execute game logic. Other blockchains, such as Harmony, Avalanche, Polygon, and Solana, offer superior execution and storage properties15. Still, the ecosystem would not be as large, the NFT assets become less valuable and tradable, and average users could be more prone to hacks16. For more sophisticated games, the centralization risks on these blockchains could also be a concern, along with other issues such as price volatility, network stability, and players’ trust.

A trustless bridge17 could potentially enable the games to take advantage of the best parts of both Ethereum and a fast chain:

[12]: For a discussion of practical ideas, see “Crypto Gaming: A Most Practical Thesis” by Arad. For crypto-native games, see The Strongest Crypto Gaming Thesis by gubsheep who built Dark Forest with ZKP.

[13]: See also topics and discussions in GAM3R

[14]: Because of its highly liquid NFT marketplaces, mature ecosystems, and toolings

[15]: For example: fast finality, low gas fees, more primitives (VRF, VDF), and larger block sizes

[16]: For example, thefts on out-of-maintenance wallets, such as this $56M incident

[17]: A not-so-trustless bridge could also achieve some of these goals but could open up the game to systematic, catastrophic risks when the bridge is hacked

[18]: This could be important when the stake is high for the game’s outcome, such as in eSports tournaments.

Beyond bridging assets

Beyond making asset transfer cross-chain trustless, fast, and secure, what else should we do to connect the blockchains and help developers build the cross-chain future? To our knowledge, little has been built for cross-chain communication infrastructure, tooling, and standards. Here are some building blocks which could play significant roles in this.

[19]: See Protocol Buffers, a language-neutral, platform-neutral extensible mechanism for serializing structured data

[20]: See ZMQ Messages documentation and guides

[21]: Such as how one could use gRPC to define the services and generate RPC templates for various languages

Existing interchain protocols

Note that IBC protocol already defined standards22 for apps to communicate between blockchains provided that a set of required functions and light clients are implemented (by either the chain, the app, or third parties) as required by the standards. The chains also need to satisfy some essential pre-requisite, such as fast finality. Some proposals in the IBC protocol overlap with some building blocks we enumerated above, and some have well-maintained implementations23. The limitation of the IBC protocol is that little implementation for the core protocol exists outside the realm of Cosmos24. It can be very challenging for applications to implement the protocol for new blockchains and work with low-level requirements, and there is little incentive to do so.

Nonetheless, even though ZKP is not used in the protocol, these proposals, the modular design, and some IBC implementations provide excellent starting points for our building blocks.

[22]: See also specs, third-party technical overview “How Cosmos’s IBC Works to Achieve Interoperability Between Blockchains”, and Cosmos documentations on IBC

[23]: See this list

[24]: i.e., including Tendermint-based blockchains

The framework could also help solve some immediate problems in asset transfer:

[25]: See detailed analysis in this report.

[26]: See the Twitter thread by samczsun for a technical explanation

In the long term, cross-chain interoperability projects today27 could also benefit from these building blocks. For example, as of today, apps based on LayerZero may extend their base layer “LzApp”28 and pass cross-chain messages using smart contract calls defined in the base class, where the message is wrapped inside a byte array. However, defining, processing, parsing, and verifying the messages are left to the developers with little guidance. It is unclear whether there is any length requirement, when the message will arrive, in what order, whether there will be duplicate messages, and how the receiving app could respond to each message. We need far more than just “passing a byte array” to build an effective cross-chain app in production.

[27]: Such as LayerZero and Axelar - though neither is trustless. Their approach is discussed in our other article “What to build next in ZKP”

[28]: See LzApp implementation

Closing Remark

Many technical problems mentioned here warrant a standalone deep-dive article for further discussion (and their relevane to ZKP). We will also write separate articles to discuss the approaches and algorithms we propose to make the trustless bridge work using ZKP and how we solve immediate problems today. If you are interested in working with us, please let us know at

If you’re interested in further discussions on this topic or working together on this subject, please consider joining our group chat or reach out to us at or