Opening IBC connection to Union

Feature Requests
1

Feature Request: Opening IBC connection to Union

Quick note: Some links are provided as raw texts since it’s not allowed for new users to add more than 2 links.

Summary

Union(https[://]union.build) is an interoperability layer that connects various of ecosystems and execution layers including Ethereum, Scroll, Movement, Berachain and etc. By taking advantage of BLS signatures, various optimizations and ZK technology it is capable of connecting these ecosystems fast and cheap.

In order for Penumbra to expand it’s ecosystem, it needs to connect to Union using IBC. This requires the CometBLS light client to be implemented on Penumbra.

Problem Statement

Although IBC is designed to be chain-agnostic, it was only being used between Cosmos chains and the technical difficulties to expand IBC to computation-limited environments (such as Ethereum) made it hard for teams to do this expansion.

Union took a unique approach to solve this problem by leveraging ZK technology by creating CometBLS - a highly optimized consensus algorithm for ZK proving - and implementing ZK light clients to all of its connected chains.

Proposed Solution

Penumbra can connect to Union by implementing the CometBLS light client. We already have a Rust-based wasm implementation (1) which can be used as an example and a CometBLS ZK-verification library(2) which can be directly imported.

  1. Github: light-clients -> cometbls-light-client
  2. Github: lib -> cometbls-groth16-verifier

Use Cases

  1. Connect to all ecosystems that Union support.

Technical Details

Adding CometBLS light client to Penumbra

Other than the ZK-verification part, the implementation of the light client looks fairly similar to the Tendermint light client. This makes it so that ics23 libraries can be reused for membership verification.

For the ZK part, in our implementation with Cosmwasm(1) we use substrate-bn(2) and the curve operations are being done in the WASM context. Note that this may not be desirable for the execution environments that already provide host functions (or precompiles) for BN254 curve operations. Our NEAR cometbls light client (3) is a good example that uses host functions for curve operations.

  1. Github: lib -> cometbls-groth16-verifier
  2. Docs-rs: substrate-bn
  3. Github: PRs -> #2254 -> light-clients -> cometbls -> near -> src -> verifier.rs

Adding Penumbra light client to Union

Although this implementation will not be on Penumbra, it’s still a required part for this connection to happen. We can go to the technical details on how to do this part afterwards. But Union supports Rust-based light clients written in Cosmwasm, which should make it easier to port it to other Rust-based implementations.

Benefits

Increasing Penumbra’s trust-minimized connectivity to other ecosystems.

Potential Drawbacks

As it said in the Technical Details part, ZK verification part can be tricky.

Note to submitters: Please fill out as many sections as possible to help the development team understand and evaluate your feature request.

2 Likes
2

This sounds really cool! Adding a new client type is probably not too complicated.

What’s the client-ID used for Union’s CometBLS (e.g., instead of 07-tendermint)?

One quick clarification, in re:

Adding Penumbra light client to Union

Although this implementation will not be on Penumbra, it’s still a required part for this connection to happen. We can go to the technical details on how to do this part afterwards. But Union supports Rust-based light clients written in Cosmwasm, which should make it easier to port it to other Rust-based implementations.

Penumbra uses standard CometBFT, so as long as Union is already able to speak IBC to Cosmos-SDK chains, there should be no changes required on the Union side, Penumbra presents exactly the same as a Cosmos-SDK chain over IBC.

3

Another followup question:

Is it correct to understand that on Union, there are ZK-proven light clients of other connected chains (Ethereum, Scroll, Movement, Berachain, etc) that only require proof verification?

In that case, could Penumbra implement transitive clients for direct IBC connections to those ecosystems, by chaining the verification of the other chain’s client proof with Penumbra’s view of the Union state? And could that allow making direct transfers from Penumbra to any of those ecosystems?

4

Yeah that is actually our intended protocol:

This should be live for our mainnet, meaning there is no PFM, but instead a ‘conditional lightclient’ on Penumbra. With that we support a virtualized, direct connection to any ecosystem we support.

1 Like