Union: ZK light-client interoperability with BLS aggregated consensus proofs
Thread1,044 words
Explains why signature verification makes native IBC infeasible on EVM chains and how Union aggregates headers on a CometBLS chain, using BLS aggregation and Galois ZK consensus proofs so connected chains verify state trustlessly.
Key claims
BLS signatures aggregate and are cheaper to prove in ZK than Ed25519
Voyager relays headers and Galois produces consensus proofs
Trusted-party bridge designs have been prone to exploits
The modular expansion is just getting started and game-changing infrastructure projects are emerging
@dymension is a modular settlement layer (big)
@Celestia is a modular DA layer (bigger)
██████ is the modular interoperability layer (🤯)
Alpha-🧵
1/ I spend 100s of hours doing research to stay ahead of the curve on the leading narratives.
For >2 years already, I have been putting a strong focus on the modular design space.
All with the goal to identify key pain points and the leading projects that address them early.
2/ Examples? 🤔👇
Modular execution layers need scalable DA
> @CelestiaOrg solves this
Modular execution layers need scalable settlement
> @Dymension solves this
3/ The next frontier is scalable interoperability.
This is a challenging task, considering the growing number of L1 & L2 execution layers with different VMs & consensus mechanisms that fragments users, apps and ultimately liquidity.
Maintaining composability is key.
4/ What does interoperability mean?
Interoperability refers to the ability of blockchains to exchange data, which allows one chain to verify statements about another and vice versa.
It enables use cases that span across the borders of otherwise isolated ecosystems.
5/ So how do we prove statements about chain A on chain B?
A great example of how this can be done, is IBC.
IBC is the native interoperability protocol of the Cosmos ecosystem and allows trustless state verification across heterogenous blockchains.
6/ But let's take a step back and think about how blockchains handle state data.
Ideally, you would want to store everything on-chain with extremely high availability and integrity guarantees.
7/ Unfortunately, that is often not feasible due to the scarcity of block space on chains like Ethereum.
To address this, the Ethereum ecosystem developed many alternative ways to store data in a decentralized manner.
8/ More specifically, blockchains like Ethereum use a tree data structure (Merkle Tree) where each node is a hash of the nodes below it.
This enables you to just send a hash instead of the full data you are looking to prove.
But let’s zoom out a bit.
9/ Blockchains are cryptographically connected and secured data structures.
The data is stored in blocks with a unique block header consisting of:
✦ Hash of previous block
✦ Merkle root (state data)
✦ Validator signatures attesting to block validity/consensus (PoS assumed)
10/ Proving the state of one chain within another chain’s execution environment hence becomes equivalent to:
✦ Passing block headers across networks
✦ Verifying the validator signatures
11/ This is exactly what IBC is doing.
IBC-enabled chains pass block headers in IBC Packets through IBC channels to other networks, where a light client verifies the validator signatures.
This allows IBC to prove any kind of statement about the source chain’s state.
12/ Unfortunately, it's not always feasible to verify validator signatures directly within a chain's execution environment.
One example is Ethereum, where a native IBC implementation would not be feasible within gas limits of EVM execution.
13/ This has led to the emergence of approaches that use message verification mechanisms across heterogenous blockchains that rely on trusted third-parties:
✦ Off-Chain Committees / Multisigs
✦ PoS Validator Sets
✦ Optimistic / Fraud Proving
14/ While this has been a feasible way to enable interoperability quickly, it also introduces significant additional trust assumptions.
Those lie outside of the security guarantees that the decentralized validator sets of the blockchains users are interacting with provide.
15/ This can pose risks and requires the user to trust potentially centralized operators.
Consequently, attack vectors arise which have historically made these interoperability designs, or bridging protocols built on top of them, very prone to exploits.
16/ That’s exactly why @union_build’s interoperability solution is specialized on efficient cross-chain consensus verification
Union's permissionless relayer (Voyager), fetches block headers from the source chain & relays it to the Union blockchain.
17/ The @union_build chain serves as an aggregation layer for block headerswhere a crypto-economically secured validator set runs CometBLS consensus.
The Union state is also stored in the Merkle tree structure discussed earlier.
18/ However, there is one key difference to TendermintBFT-based Cosmos chains.
Instead of a set of Ed25519 signatures, @union_build block headers contain a Boneh–Lynn–Shacham (BLS) signature.
A key advantage of BLS signatures is the ability to aggregate signatures.
19/ This means multiple signatures can be combined into a single signature, while providing the same security guarantees.
This also means that BLS signatures are computationally much less expensive to prove within a Zero Knowledge (ZK) circuit.
20/ The resulting succinct ZK proofs are small in size and can be quickly verified even when proving large amounts of data.
This is the key differentiator of @union_build’s interoperability framework.
21/ Direct signature verification within the EVM is not feasible. ZK-Proving Ed25519 signatures is possible, but expensive & slow.
@union_build overcomes these limitations and introduces a novel approach to making IBC interoperability possible across blockchains globally.
22/ Once consensus on @union_build is reached, the permissionless prover (Galois) generates a proof of consensus of the Union block header it receives from Voyager.
The resulting ZK proof is then relayed to the connected chains, where light clients verify the consensus proof.
23/ This unlocks powerful cross-chain use cases, as the @union_build state can be proven in the execution environments of the connected networks.
Consequently, all connected networks are aware of each other's state, which allows for seamless cross-chain composability.
24/ The approach is highly generalizable thanks to its hyper-efficient ZK-powered approach to state verification.
Any chain that can support an on-chain light client and @union_build relayers can fetch block headers, can be integrated into this trust-minimized interop layer.
25/ This combination of trust-minimization (security), scalability and chain-agnosticism positions @union_build to be the interop layer of the modular stack.
Unifying liquidity and enabling powerful multi-chain use cases across execution layers.
x.com/union_build/status/1760016563091189820
26/ Interoperability is the key issue that the modular thesis has to overcome in order to unlock its full potential.
The potential of the ecosystem of highly scalable, potentially app-specific blockchains built on its specialized infrastructure.
Don't fade @union_build anon.
That's a wrap for today! I hope you've found this thread helpful! 🫡
Make sure to follow me @zerokn0wledge_ to stay ahead of the curve on the modular narrative and more on @union_build.
Like/Repost of the below post is also highly appreciated! 🙏👇
16 images on X
What came next · since 29 Feb 2024
Since then
Zero has written 17 more pieces on Union since this one.