Bringing IBC to Ethereum using ZK-Snarks

[cwgoes]

Very nice! The general approach & revision of the IBC dataflow model all makes sense to me. A few questions on your investigations & alternatives:

• Would switching Tendermint’s signature scheme (secp256k1 or eventually BLS) cut the proving time a lot, or not so much?
• Is the cost of verifying Merkle proofs (required for packets, should be possible to use Ethereum’s sha2 precompile) significant? Do you have any benchmarks of gas required per packet (which would add to the amortised header cost)?
• What about verifying the Ethereum consensus on the other side? Does ETH2 have a cheap light client which you can just use out of the box or would additional work be required (to retain the IBC security model)?

[alexeiZamyatin]

Sounds pretty cool

Would a Flyclient like construction be compatible here to reduce the number of headers needed?

You could then further reduce the number of proofs needed by using contingent transaction aggregation (TxChain: Efficient Cryptocurrency Light Clients via Contingent Transaction Aggregation)

This would just be on top but can significanly reduce the number of headers and tx inclusion proofs you need. Leaving here as possible consensus-level scaling improvements

[weikengchen]

Just to refer to one of our recent works: https://eprint.iacr.org/2022/1145.pdf

If eventually EIP-1962 will be back, then there are ways to cut the constraints significantly as well as to avoid the use of Groth16 setup/large proving key.

Note: this paper does not include the cost of SHA512.

[MicahZoltu]

@garvitgoel

IBC

I feel like this post would be significantly better if you said what IBC stood for at the beginning. It is a new term for me, and the entire post is hard to follow without knowing what it is referring to. Just a single external link, or even just the deacronymed full name would probably be sufficient.

[Wizdave97]

IBC stands for Inter Blockchain Communication Protocol, here’s a link to the spec https://github.com/cosmos/ibc

[garvitgoel]

thank you ser for the feedback. Have added it now to the beginning of the article

[garvitgoel]

Hi @cwgoes thanks for your comments. Here are my answers -

1. Yes, secp256k1 or BLS will produce significant benefits. However, this would require convincing the entire cosmos community to move away from ed25519 and switch to these schemes.
2. We can actually prove the merkle proof within the circuit itself. I will add the benchmarks of gas required per packet here soon.
3. I think eth2 comes with BLS signatures, which are aggregable? We know that folks over at NEAR have a working on-chain eth2 light client.

Hope this helps!

[hu55a1n1]

Cool stuff! How do you plan to address Ethereum’s delayed finality?

[BennyOptions]

Hey @garvitgoel this is certainly an interesting approach. I happened to see this being circulated on twitter and wanted to confirm my understanding.

@garvitgoel

Hence we must find an alternative to verify these signatures cheaply on Ethereum.

Correct me if I’m wrong, but from my understanding of IBC, the key differentiating factor is what you’re proposing to alter here. IBC operates with no trust assumptions outside of the consensus of the two chains interacting with one another (light clients on source/dest chains), while this proposed solution does off-chain verification then submits a zk-proof. It does not appear to verify validator signatures / blockheaders on chain, which impacts some of the core security assumptions of IBC I believe.

Imo the ideal solution would be some changes to the Cosmos SDK to allow for cheaper verification of both blocks and validator signatures on target-networks rather than making any changes to the security assumptions/verification mechanisms. Of course, this is a difficult solution that would take more R&D.

To be clear, I think this is a great idea and use case of zk-proofs. I just think that it’s quite a different solution from IBC. Using zk-proofs for cross-chain communication could be a stand-alone new project imo. Let me know what you think, I could be way off-base here, I just find the topic interesting.

[garvitgoel]

Hi @BennyOptions thank you for the comments. So that’s the thing about ZK-Proofs, they don’t introduce any new trust assumptions. The signatures are still getting validated in a trustless manner since the zk-proof gets verified on-chain.

[BennyOptions]

I see, thanks for the reply. So long as no additional assumptions are introduced, it seems like a viable solution if the cost and latency aspects can be solved. What’s the best place to follow along on your progress?

[garvitgoel]

Hi Benny, will be starting a telegram group soon. Will post the link here itself

[edsonayllon]

What’s the motivation for this? The problem background addresses technical limitations, without addressing why one would want to do this.

[adi_rr]

@edsonayllon IBC is perhaps the most trust-minimized, general-purpose interoperability protocol available today.

Over the past 18 months, nearly 50 public blockchains (and a handful of enterprise chains) have implemented IBC. It has accounted for greater than 50m cross-chain transfers and a USD vol of nearly 60bil. We believe that IBC offers a solution to act as the connective tissue between all blockchains.

A direct IBC connection between two chains requires that both chains have instant finality. Given Ethereum’s double-slot finality and the high costs of on-chain sig verification, an IBC connection from Cosmos chains to Ethereum have been infeasible until now. The use of succinct proofs (as shown above) could offer a solution to this problem.

[bluto658]

Why focus on communication with the Cosmos and not on communication between Ethereum roll ups?

[garvitgoel]

L2<>L2 bridging does not need light clients for trustlessness. Furthermore, the Eth2 light client is based on BLS signatures which are aggregable, which means that the Eth2 light client does not really need Zk-based compression.

[gMoney]

@garvitgoel interesting post. Why does L2 <> L2 bridging not require light clients trustlessness?

[garvitgoel]

Actually, L2 <> L2 bridging can also be solved using this approach.

[bsanchez1998]

@garvitgoel This is fascinating and if implemented could have a significant impact on cross-chain communication. I’m particularly intrigued by your plans to further reduce latency and gas costs using recursive proofs and hardware acceleration since the performance figures are impressive. I would be interested to see how relayers will have to update to fix this, particularly new decentralized relays.

I’m looking forward to seeing the progress of this project.

[garvitgoel]

We have started a telegram group for this. Folks can join here - Telegram: Join Group Chat