A Layered Overview of Cross-Chain Technology: What Possibilities Remain for Cross-Chain?
TechFlow Selected TechFlow Selected
A Layered Overview of Cross-Chain Technology: What Possibilities Remain for Cross-Chain?
Cross-chain technology has always seemed to be a controversial yet frequently discussed topic.
Navigating Web3 tides with focused insightsAuthor: Jeffrey Hu, HashKey Capital
Cross-chain technology has always been a controversial yet frequently discussed topic. Especially whenever a cross-chain bridge is hacked, debates about the viability and security of cross-chain technologies flare up again. On the other hand, as technologies like IBC and LayerZero mature, the community’s expectations for the future of cross-chain seem to plateau.
Is this the endgame for cross-chain? Well,
This is not the end. It is not even the beginning of the end. But it is, perhaps, the end of the beginning.
There have been several notable advancements in cross-chain technology over the past few months of 2022. Taking the opportunity of being invited to give several talks on cross-chain topics recently, I’d like to document my observations and thoughts on the current state and trends in cross-chain technology.
1. A Layered Overview of Cross-Chain Technology
1. Understanding Cross-Chain Through Layering
Before diving into these developments, it's worth revisiting the fundamental question: What exactly are we talking about when we discuss cross-chain? What is its essential nature?
Put in today’s popular terms, how do we understand cross-chain using “first principles” thinking?
If the most defining feature of blockchain—what sets it apart from other technologies—is trustlessness, meaning information can be verified on-chain without needing to trust any party (“Don’t trust, verify”), then cross-chain is essentially about how information from one chain can be verified across chains. The information being transferred broadly includes transactions and their validity proofs (typically Merkle proofs).
Accordingly, based on verifiable on-chain data, blockchains can build basic applications such as asset transfers. Similarly, leveraging verified cross-chain information, certain cross-chain applications become possible—for example, transferring tokens across chains via the common lock & mint mechanism (locking assets on the source chain and minting them on the destination chain).
Therefore, depending on what aspect of the “cross-chain” problem a given technology or project addresses, we can classify cross-chain solutions along two dimensions: communication layer and application layer.
2. Classification of Cross-Chain Technologies
Communication Layer
Let’s start with the communication layer. How can information from one chain be verified by another? Based on who performs the verification, there are three main approaches: external validation, local validation, and native validation.
-
External Validation: Cross-chain information is validated by external entities known as validators (also called notaries, gateways, etc.). This approach allows relatively fast connections between heterogeneous chains since only read/write access on each chain is required for the validators. However, the validity of cross-chain information—such as whether a transaction was truly confirmed on the source chain—depends entirely on these third parties. Thus, the overall security relies on the assumption that the validators are honest.
-
Local Validation: Instead of relying on external validators, users directly observe transactions on-chain and use techniques like HTLCs to ensure atomic swaps. This avoids trusting third-party validators and enables quick cross-chain transfers across heterogeneous chains. However, it struggles to support more complex applications such as general message passing or smart contract calls.
-
Native Validation: The blockchain itself independently verifies the legitimacy of cross-chain messages. This is typically achieved by integrating light clients of other blockchains, enabling a chain to track, retrieve, and validate off-chain data and act accordingly (e.g., releasing tokens after cross-chain confirmation). Due to the diversity of heterogeneous chain models, standardized protocols like IBC help simplify design and implementation. This method offers the highest security because no additional trust assumptions are introduced, though development complexity is higher due to the need to implement mutual light clients and potentially full cross-chain protocol stacks.
Application Layer
The underlying communication layer alone isn't sufficient—we also need user-facing applications built on top. In theory, any cross-chain application that doesn't require strong transactional consistency can be constructed upon securely verified cross-chain data. The most common type remains cross-chain token transfers and similar basic transactions.
Thus, the key challenge becomes how to transfer liquidity across chains. Solutions to this problem can be categorized by analogy to trading mechanisms: central counterparty, OTC/P2P, automated exchange (swap), and liquidity aggregation.
-
Central Counterparty: Often used by “official” cross-chain bridges, where designated addresses handle deposit and withdrawal operations—essentially the lock & mint model described earlier. For instance, when a user initiates a transfer, they lock tokens on the source chain, and the bridge mints equivalent tokens on the destination chain.
-
OTC/P2P: Rather than relying solely on official operators, counterparties could be third-party market makers or individual users. For example, a user posts a request for cross-chain liquidity, and a market maker fulfills it by delivering funds on the target chain.
-
Automated Exchange (Swap): Beyond peer-to-peer trades, counterparties can be automated protocols. For example, a user swaps tokens on an AMM on the source chain, and the protocol executes a corresponding swap on the destination chain.
-
Liquidity Aggregation: Similar to on-chain aggregators like 1inch, some protocols aggregate various cross-chain liquidity sources to offer users optimal routes—best prices, lowest fees, or highest liquidity—for cross-chain transfers.
2. What Possibilities Remain for Cross-Chain?
1. Lighter-weight Underlying Protocols
Although IBC is often hailed as the gold standard for cross-chain interoperability, implementing native validation across heterogeneous chains can face practical hurdles—for instance, Ethereum may exceed gas limits when verifying Tendermint block headers involving Ed25519 signatures.
From Relayer to Oracle
The proper functioning of the IBC protocol requires a role known as the relayer. One somewhat “counterintuitive” aspect is that while the relayer can be centralized, it does not need to be trusted. This is because the information it transmits can be independently verified by the destination chain. Hence, unlike in externally validated systems, a malicious relayer cannot alter messages to steal user funds. The relayer thus functions similarly to the physical layer in internet protocols—connecting different networks and transmitting data.
While IBC’s security does not depend on the relayer, the protocol’s liveness does rely on at least one functioning relayer to relay messages promptly.
Since the relayer’s primary task is observing events on the source chain and submitting them to the destination chain—i.e., performing information transmission—this function could alternatively be fulfilled by oracles. That is, oracles evolve from their traditional role of moving data “off-chain to on-chain” to now enabling “on-chain to on-chain” data transmission.
This may partly explain why oracle projects like Chainlink CCIP[1] and SupraOracle are expanding into the cross-chain space.
From Oracle to TEE
What specific data can oracles transmit? LayerZero provides a compelling example. It uses oracles to perform consensus state verification—a core component of IBC—eliminating the need for continuous updates and validations of block headers. Instead, needed information is queried and verified via oracles on-demand.
LayerZero delegates part of the light client functionality to oracles[2]
This significantly reduces on-chain verification costs. The relayer now only needs to deliver the cross-chain transaction and its proof. As a result, LayerZero can quickly connect multiple EVM-compatible chains. However, introducing a third-party oracle adds a new trust assumption (that oracles won’t collude maliciously), slightly reducing system security. Alternative implementations include using Substrate’s “native oracle” off-chain workers for message delivery[3].
To reduce reliance on oracles, another approach involves improving block header synchronization through alternative technologies. For example, LCP Network uses TEE (Trusted Execution Environments) to verify cross-chain transactions[4].
From Merkle Proof to ZK Proof
Beyond transmission mechanisms, recent innovations focus on how the information—and its proofs—are structured. Recall our earlier definition: one of the core pieces of information in cross-chain communication is the validity proof of a transaction. Most existing cross-chain systems use Merkle proofs for this purpose.
Another major class of validity proofs comes from zero-knowledge (ZK) technology—specifically ZK proofs. Advances in ZK tech are gradually turning ZK-based bridges (ZK Bridges) from theoretical concepts[5] into practical reality.
By generating zero-knowledge proofs, high-cost verification tasks—like checking Ed25519 signatures on Ethereum—can be solved efficiently. For instance, Electron Labs implements ZK-SNARKs to verify Tendermint-based chain signatures[6], avoiding expensive signature computations within smart contracts.
Design for implementing IBC on Ethereum using ZK proofs[6]
Other teams actively developing ZK bridges include Succinct Labs, zkbridge[7], Polymer[8], and Mina[9].
Current partial designs for ZK-based cross-chain systems[7]
2. Better Developer Support (General Messaging, Smart Contract Calls)
These improved底层 cross-chain protocols enable better support for general-purpose messaging, including arbitrary smart contract calls. Consequently, many projects are building SDKs and abstraction layers atop them, empowering developers to create multi-chain or omni-chain applications.
Examples include IBC Interchain Accounts[10], Multichain anyCall, Celer IM; or middleware platforms like Spanning Labs that abstract away complexities such as token bridging, allowing app developers to focus on higher-level logic.
3. Application-Layer Liquidity Innovations
Building on cross-chain infrastructure and middleware, there’s room for innovation at the application-layer liquidity level. Recent examples include slAMM[11] (shared liquidity AMM), which uses a Hub chain to coordinate liquidity across multiple “satellite” chains. Cross-chain protocols enable functionalities like moving and settling liquidity across chains.
Design and comparison of dAMM vs slAMM[11]
4. Feedback Effects on Protocol Layer
Cross-chain technology is generally seen as supporting the base layer of blockchain protocols. Yet as it evolves, it may begin to influence the design of blockchain protocols themselves.
Improvements to Consensus
One major impact is on blockchain consensus design.
With the rise of application-specific chains combined with cross-chain connectivity, many app-chains may initially lack robust security. To compensate, they adopt cross-chain validation mechanisms where larger networks provide security for smaller ones—e.g., Cosmos Interchain Security, Polkadot’s relay chain + parachain model.
Beyond this unidirectional model (child chains secured by a parent), newer ideas like Mesh Security[12] propose bidirectional cross-chain validation—where networks mutually secure each other. Still early in development, concrete designs and implementations remain to be seen.
Example of mesh security architecture[12]
Impact on MEV
Another significant area of impact is MEV (Maximal Extractable Value). The MEV economy on single chains is already massive. According to Chorus One[13], cumulative MEV extracted on Ethereum exceeded $1 billion by October 2022.
New cross-chain protocols are beginning to incorporate MEV considerations, potentially reshaping the current landscape. For example, Cosmos 2.0 Whitepaper[14] and Zenith[15] explore market-driven allocation of blockspace through an Interchain Allocator:
-
Consumer chains in shared-security environments offer blockspace
-
Users can bid to reserve opportunities for cross-chain arbitrage or settlement
Closing Thoughts
While much of the blockchain industry’s innovation focus remains on Ethereum-centric advances like ZK, AA, and MEV, recent BUIDL activity in cross-chain protocols—especially in lightweight底层 designs, enhanced developer tooling, liquidity innovations, feedback into protocol design, and particularly ZK bridges—offers exciting new frontiers. Given the rapid pace of development and sheer number of projects, this brief overview inevitably misses some details and may contain inaccuracies—feedback and discussion are welcome!
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
