Union: ZK light client interop vs multisig bridges with ZK labels
Quote991 words
Argues many bridges labelled ZK that prove a multisig attestation keep the same trust assumptions. Details Union's design: BLS aggregated CometBLS consensus, Groth16 proofs by a permissionless prover, light client verification, and a planned aggregation layer.
Key claims
Proof aggregation could need only 230k gas per block for unlimited chains
BLS signatures are cheaper to prove in ZK than Ed25519 sets
Proving a multisig attestation with ZK does not change user trust assumptions
✨ Trust-Minimized, Sovereign & Permissionless Interoperability ✨
Without seamless, asynchronous cross-chain composability across the modular execution layers that compose the multi-chain future, the modular thesis is doomed to fail. ⚠️
@union_build fixes this and will be huge! 👇
The quoted post below emphasizes an important difference that you should keep in mind as the market is flooded with "ZK-powered" interoperability solutions.
Not every bridge that puts labels like "ZK" or "trust-minimized" on itself is actually more secure than the trusted, multi-sig based bridges that you are already well familiar with.
Interoperability is about proving state or consensus across execution environments. Doing that directly on-chain (like IBC does based on merkle roots and corresponding validator signatures) however is often not feasible on computationally limited chains like Ethereum.
The solution to this, without introducing additional trust assumptions arising from off-chain entities being involved in the process of message verification, is using light client infra and ZK proofs to prove and verify state/consensus in an efficient and secure manner.
@union_build is the real deal here. 🎯
Very strong and ambitious team which is building the sovereign, trust-minimized and permissionless interoperability layer of the modular stack.
More specifically, @union_build's permissionless relayer fetches block headers from the source chain and relays them to the Union chain, which 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 the connected chains.
The Union state is stored in a Merkle tree structure. Built on IBC, it works very similar to the native implementation. However, there is one key distinction of the specialized consensus mechanism @union_build 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 with their size and verification time remaining constant, regardless of the data being proven.
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_build'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. Completely regardless of the VM they are running, the consensus mechanism they are using or the programming languages they support.
@union_build's use of ZK proofs hence makes bridging more efficient and secure as well as accessible than its competitors.
The multisig structure employed by other blockchain bridges (and that some might try to hide behind a ZK mask going forward) creates a centralized point of failure susceptible to hacks.
Since the multisig model relies on validator participation to sign transaction requests, the number of validators tends to be small, thereby reducing the number of keys required to be compromised for a hack to succeed. This risk is exacerbated when a single entity controls the majority of signatures, resulting in an even more centralized structure.
@union_build's ZK proof technology maintains independence from centralized actors and enables a fully trustless multi-chain future without multisig-based message verification and centralization risks.
This future encompasses thousands of heterogeneous chains with varying consensus protocols across different ecosystems, all capable of seamlessly integrating themselves into an IBC-powered, permissionless interoperability layer.
However, in its current iteration, @union_build generates numerous ZK-powered consensus proofs and distributes them across all connected chains. This process introduces significant overhead in proof generation and verification, which escalates with the increasing number of chains.
To enhance the efficiency of the system, the @union_build research team is exploring ways to implement a proof aggregation layer, which consolidates all light client updates across chains into a single proof. This approach will further simplify the proof generation process, requiring only 230k gas per block to achieve full-scale interoperability with an unlimited number of chains.
Already today, @union_build is present across key ecosystems and is positioning itself as the leading interoperability solution for @CelestiaOrg-based (sovereign) rollups.
Thanks to its native IBC support, it is also interoperable with chains across the @Cosmos ecosystem, including @dYdX, @cronosapp, @SecretNetwork, @osmosis or @injective.
Recently, @union_build has also started to expand into the EVM/L2 space, integrating with all major L2s, including @arbitrum, @optimism, @base, @0xpolygon, @LineaBuild, @Scroll_ZKP, @Starknet and @0xPolygon.
The (modular) expansion is real. 🧱✨
Bullish, right? 👀
Definitely. 🚀
But also very different from solutions that verify messages using an off-chain multisig and prove the multi-sig attestation on-chain through a ZK proof.
While this might improve cost efficiency (depending on proving), it doesn't fundamentally change the trust assumptions for the end user.
As the modular expansion continues, place your bets on the teams that build real trust-minimized interop tech.
Teams like @union_build. 💪
Or @citrea_xyz & gg to @0x_orkun for the meme that inspired this 🤝
3 more images on X
What came next · since 08 Apr 2024
Since then
Zero has written 16 more pieces on Union since this one.