Introduction

Many existing frameworks for crosschain message passing embed trust assumptions and a degree of centralization. Offchain committees, mutli-party computation schemas, and proof-of-authority implementations all embed trust assumptions regarding the management of private keys held by entities with privileged roles over the infrastructure. For example, Across relies on 1 centralized dataworker, run by Risk Labs, to post bundles to the optimistic oracle with instructions to administer refunds to solvers. Wormhole Messaging requires supermajority consensus (13/19) amongst a whitelisted set of “Guardians” in order to pass a message. 

Source: Union

Leveraging IBC and the CosmosSDK, Union is architected as a layer 1 blockchain purpose-built to offer a maximally-decentralized modular interoperability protocol that supports the long tail of chains. Union’s implementation seeks to address core issues in existing message passing frameworks; centralization, latency, and cost. Across all aspects of Union’s crosschain workflow, be it relaying, validating, proving, or filling, entry is permissionless, and no single entity holds administrative authority. Union has constructed several improvements upon CometBFT consensus and IBC to offer a low-cost and data-efficient layer 1 to settle crosschain actions. 

The Union Workflow

Union’s underlying framework is built using consensus verification to offer a trust-minimized solution for crosschain messaging and interoperability. Consensus verification allows for the cryptographic proof of a particular piece of state on Chain A being true, and using that proof to process and enforce some action on Chain B.

At the core of Union’s crosschain workflow are three key pillars; 1) CometBLS, a purpose-built consensus mechanism to produce data-efficient signatures from Union’s L1 validators, 2) Galois, a permissionless prover network to package validator signatures and Union’s chain state into a zero-knowledge proof (ZKP), and 3) Voyager, a permissionless relayer network designed to pass data-packets and proofs between source chains, Union validators, Galois provers, and destination chains. 

Union smart contract endpoints are deployed across a number of runtimes, including the EVM, SVM, Move, and CosmWasm. Users seeking a crosschain action (transfer, swap, interact, vote, etc) can interact with a Union smart contract on their source chain. This interaction generates an event, which is monitored for and picked up by relayers on the Union Network. 

Relayers then deliver data packets containing the block headers of the source chains to the Union chain to perform consensus verification. The Union validator set then verifies and produces signatures on the data packet to come to consensus on the state of the source chain. The Union validator set can concurrently come to consensus on the blockheaders passed to Union from all supported networks.

Validators’ signatures are relayed to the prover network, which produces a ZKP containing Union’s chain state. This ZKP is then relayed to the destination chain, which once executed by a light client will enforce the user’s original action. 

CometBLS

Consensus verification requires a distributed set of validators to come to consensus on the state of Chain A and deliver proof that consensus has been reached to Chain B. Existing frameworks for consensus like Tendermint are not viable for crosschain messaging, as the packets produced are data-heavy and require too much computation, resulting in costs and latency.

Instead, Union builds off of Tendermint consensus and CometBFT, offering a purpose-built consensus mechanism called CometBLS. This new mechanism is designed specifically to minimize the data, costs, and latency required for crosschain interactions.

With CometBLS, the signatures and public keys of Union validators are aggregated to produce one aggregated signature with 1 aggregated public key. With this aggregation, message transfers need only contain the 1 aggregated signature, rather than all of the individual components from the entire validator set. With this, onchain computation costs are diminished, as only 1 signature must be verified. Given this implementation, the Union network can scale the number of validators horizontally without compromising performance or cost.  Data packets produced through CometBLS are data-light, allowing for faster and cheaper proving, relaying, and bridging. CometBLS trusts that only 1/3rd of the validator set must act honestly to prevent a malicious action.

Voyager

Within Union’s crosschain workflow, relayers are responsible for delivering data packets with the source chain state to the Union Network, delivering the Union Network’s state to the prover network (Galois, discussed below), and delivering the proofs produced by the prover network to the destination chain. Running a relayer on Union is permissionless. 

Galois

Once consensus has been reached by Union validators, the resulting block header of the Union chain is relayed to the Galois prover network, a purpose-built zero-knowledge consensus proving system. This system can generate ZKPs across 128 validators in under seven seconds. Entry into the Galois prover network is permissionless, and because of its highly-efficient architecture, proofs can be generated using only 5GB of ram on consumer-grade laptops and hardware. Galois then produces a ZKP of Union’s chain state, which is subsequently picked up by relayers and passed to all connected chains.

Source: Union

Subsequently, the ZKP is verified by Union light clients on the destination chain, allowing the chain to have knowledge of both the source chain and Union’s state. Upon verification of the ZKP, the user’s original action on the source chain can be executed on the destination chain.  

Union’s modularity allows it to be easily integrated into existing chains. With previous IBC implementations, a chain would need to hard fork and upgrade entirely to support the IBC module. However, Union has effectively virtualized the full IBC stack, allowing it to be extended to new chains simply through smart contract deployments. Because of the data-light and cost-efficient architecture of CometBLS and Galois’s ZKPs, Union can theoretically support interoperability across thousands of unique chains and runtimes before experiencing scaling constraints.

With regards to latency, Union does not need to wait for a hardcoded number of confirmations before filling a transfer. Instead, as light-clients are used to deliver chain state to Union, Union’s validators can receive the information on a source chains’ state at the moment it has been finalized. With this, Union must only wait for the minimum number of block confirmations necessary to reach finality on the source chain before initializing the transfer workflow, which eliminates the need to wait for an arbitrary number of blocks to pass and overshooting on latency. Additionally, with support for intents (discussed below), users can have access to fast fills provided by solvers that bypass the latency of Union consensus and verification.

Intents

While most crosschain actions may be filled by the Union protocol minting assets on the destination chain through IBC, the protocol supports filling through 3rd party solvers, as well. With intents, solvers can front users capital to provide a fill directly from the solver’s balance sheet. Intents allow users to receive funds at speeds faster than source chain finality, while the solvers that fill them assume finality risk.

Source: Union

Union has partnered with Aori to route intent-based order flow to Aori’s network of solvers. With intent-based orders, users can receive funds on the desired destination chain with less than 1 second latency. Solvers providing fills on Union’s intent-based order flow await completion of Union’s consensus verification flow before receiving a refund on their fill. 

Union recently launched its second public testnet in February, which processed 56M transfers in 2 months. This testnet rolled out gas optimizations to EVM contracts, support for intent settlement, improvements to Galois’ proving latency, and support for Move VMs. Union has launched its developer-only alpha mainnet, with public mainnet expected to launch within the next few months.

Conclusion

Union’s improvements upon Tendermint consensus through CometBLS, coupled with ZK proving through Galois, allow for a broadly scalable, cost efficient, and low latency IBC implementation that is feasibly scalable across every existing blockchain, virtual machine and runtime. Entry is permissionless across relaying through Voyager, proving through Galois, and validating on the Union chain, so that all aspects of Union’s workflow can remain competitive, and no single entity has permissioned or administrative authority. Union’s implementation offers modular crosschain interoperability without the need for trusted intermediaries.  

This research report has been funded by Union.fi Labs. By providing this disclosure, we aim to ensure that the research reported in this document is conducted with objectivity and transparency.  Blockworks Research makes the following disclosures: 1) Research Funding: The research reported in this document has been funded by Union.fi Labs. The sponsor may have input on the content of the report, but Blockworks Research maintains editorial control over the final report to retain data accuracy and objectivity. All published reports by Blockworks Research are reviewed by internal independent parties to prevent bias. 2) Researchers submit financial conflict of interest (FCOI) disclosures on a monthly basis that are reviewed by appropriate internal parties. Readers are advised to conduct their own independent research and seek the advice of a qualified financial advisor before making any investment decisions.