Users and liquidity are becoming increasingly fragmented across many L1 and L2 execution layers in Web3. A secure means of interoperability to enable communication among these isolated systems is critical.
As fragmentation persists, user experience (UX) suffers. Breaking away from a singular, monolithic chain like Ethereum also means degraded composability. Users, applications, and liquidity are spreading across ecosystems with different network designs, validator sets, and consensus mechanisms. This specialization and optimization of execution layers for specific use cases and features provides the basis for more performant applications but introduces friction to user experience and composability.
For users to seamlessly interact across ecosystems and to unify liquidity across different networks without losing composability among applications, blockchains need to exchange and verify data accurately. Trust-minimized consensus verification, built by Union, addresses this challenge by verifying one chain’s state in the execution environment of another without introducing additional risk or trust assumptions.
A Standard for Trust-Minimized Cross-Chain Consensus Verification
IBC exemplifies state verification across isolated blockchains, minimizing the need for trust in external entities. IBC, designed as a consensus-agnostic, cross-chain messaging protocol for heterogeneous blockchains, aims to be the trust-minimized cross-chain consensus verification standard. Rooted in the Cosmos ecosystem, IBC serves as the native interoperability solution for Cosmos SDK-based chains and has garnered widespread adoption and continues to grow at an impressive rate.
To understand how IBC works, you must know some basic principles of how blockchains handle state data. Ideally, you would want to store everything on-chain, secured on thousands of computers across the globe, with extremely high availability and integrity guarantees.
Unfortunately, it 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 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 to hash different subsets of the data repeatedly. Merkle Trees enables you to send a hash instead of the whole data you are looking to prove inclusion/exclusion of by using Merkle inclusion proofs.
The top-of-the-tree root hash is the only on-chain storage necessity within a light client. Proving a particular value involves presenting 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.
Blockchains are cryptographically connected and secured data structures. 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)
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.
The Status Quo of the Interoperability Landscape
While IBC is a promising solution to overcome the existing friction between blockchains, it is not always feasible to verify validator signatures directly within a blockchain’s execution environment due to computational limitations. One such example is Ethereum, where an IBC implementation would typically not be feasible within the gas limits of EVM execution.
The gas limitations of EMV execution have led to a myriad of approaches aiming to enable scalable means of verifying a certain consensus having been reached across heterogeneous blockchains. Using off-chain committees performing multisig-based message verification, PoS validator sets, or fraud-proving mechanisms have proven to be popular choices. While these have been a feasible way to enable interoperability quickly, they also introduce significant additional trust assumptions outside the security guarantees the underlying blockchains provide. These external trust assumptions can pose risks and require the user to trust potentially centralized operators.
These before-mentioned solutions, further referred to as “trusted,” introduce some degree of centralization or human element. Consequently, attack vectors arise that have historically made these interoperability solutions, or more specifically the bridging protocols built on top of them, very prone to hacks or other forms of malicious value extraction. This is made evident by the many large-scale exploits in the past (including Ronin, Multichain, Horizon, and Wormhole).
Introducing Union
Trust-minimized cross-chain consensus verification must become more efficient to overcome the existing security risks in trusted interoperability designs and establish a genuinely global, trust-minimized interoperability layer - exactly what Union’s interoperability solution is specialized to do. Union expands IBC beyond the borders of the Cosmos ecosystem and provides a global interoperability layer for block header-based consensus verification.
More specifically, Union’s permissionless relayer (Voyager) fetches block headers from the source chain and relays them to Union. The Union chain serves as an aggregation layer where a decentralized, crypto-economically secured validator set reaches consensus through CometBLS on a set of block headers received from all connected chains.
The Union state is also stored in the Merkle tree structure discussed earlier. However, there is one key distinction of the specialized consensus mechanism Union is using. Instead of a set of Ed25519 signatures, as is the case in the context of CometBFT-based Cosmos chains, Union block headers contain a BLS (Boneh–Lynn–Shacham) signature. A key advantage of BLS signatures is the ability to aggregate signatures. Signature aggregation means multiple signatures can be combined into a single signature, while the combined signature provides the same level of security as validating all the individual signatures. Signature aggregation also means BLS signatures are computationally much less expensive to prove within a Zero Knowledge (ZK) circuit. The resulting succinct ZK proofs are small and quick to verify - their size and verification time are constant, regardless of the data being proven. These quick-to-verify proofs are the key differentiator of Union’s interoperability framework. As mentioned earlier, direct signature verification within Ethereum’s execution environment is not feasible. Proving multiple Ed25519 signatures is possible but expensive and slow.
Union overcomes these limitations and introduces a novel, ZK-powered approach to making IBC interoperability possible across all blockchains globally. Once consensus on Union has been reached, the permissionless proving layer (Galois) produces a proof of consensus of the Union block header it received from Voyager. The resulting ZK proof (Groth16) is then relayed to the connected chains, where Union Light Clients verify the consensus proof. Union’s zkIBC unlocks robust cross-chain use cases, as the ability to prove Union consensus in the execution environments of the connected networks means the connected networks are all aware of each other’s state. Any statement about account balances, contract interactions, or other state, can be proven by verifying a succinct proof, resulting in seamless cross-chain composability - all without trusting any centralized third party. As a user, you only trust the code, a.k.a. the consensus protocols of the connected chains.
The approach is also highly generalizable and overcomes the computational limitations of specific blockchains with a hyper-efficient ZK-powered method of proving consensus across chains. Any chain can be integrated into this fully trust-minimized and decentralized, chain-agnostic interoperability layer, as long as it can support on-chain light clients and Union relayers can fetch block headers from it - regardless of the VM they are running, the consensus mechanism they are using or the programming languages they support. Union is paving the way to a more interconnected, secure, and composable Web3.