GIP-57: Should Gnosis DAO support research of a zkSNARK-enabled light client and bridge?

Governance GIPs
,
1

GIP-57: Should Gnosis DAO support research of a zkSNARK-enabled light client and bridge?

  • Let’s do this!
  • Make no changes

0 voters 

GIP: 57
title: Infrastructure for a SNARK-enabled bridge for Gnosis chain and ETH2
author: Uma Roy (@puma314), John Guibas (@jtguibas), Jonathan Wang (@jonathanpwang), with support from 0xPARC
status: Draft
type: Funding
created: 2022-06-28

The current Gnosis bridge is a based on a multi-sig design. However, multi-sig bridges have known weaknesses, particularly their reliance on a relatively centralized set of operators–see the recent Ronin bridge and Harmony bridge hacks, in which hundreds of millions of dollars of funds were stolen by attackers who gained access to multi-sig keys. SNARK-enabled bridges–sometimes called “trustless” bridges–potentially have better security properties. We propose to build prototypes of essential infrastructure for a potential SNARK-enabled bridge for Gnosis to Eth2 bridging.

Abstract

  • Build essential infrastructure that can be used in the future to create and productionize a SNARK-enabled bridge for Gnosis Chain / Eth2. Note that it is not in the scope of this specific grant to take the bridge all the way to production on mainnet—this work will allow us to assess the viability of a production bridge and build out the key infrastructure. Productionization, if it happens, would be a future project.
  • Create a foundation for Gnosis’ ZK roadmap and expertise.

Motivation

To build the components of a SNARK-enabled bridge for Gnosis Chain, an Eth2 compatible light client must be implemented on the EVM. Because the EVM does not have precompiles for the BLS12-381 curve used in Eth2, implementing this directly in Solidity would result in impractically high gas costs. As a result, this approach to bridging was unexplored until it was made practical by recent advances in zero-knowledge proofs.

The 0xPARC community has developed extensive expertise in ZK-SNARKs broadly and has built several advanced ZK circuit primitives which can now enable these types of applications. We believe that we can design a circuit which significantly reduces the gas cost of running a light client on EVM by moving the verification of the aggregated BLS signature and the Merkle tree inclusion proof off-chain.

Specification

Building this SNARK-enabled bridge will require three important components:

  1. A Solidity smart contract which implements the Eth2 light client spec.
  2. A zkSNARK circuit that verifies the aggregated BLS signature of the sync committee, verifies the Merkle tree inclusion proofs with SSZ for serializiation, and verifies the current sync committee from the previous block header.
  3. An operator node implementation which can keep the light client up to date.

Rationale

SNARK-enabled Bridge Pros & Cons

Pros:

  • Security: SNARK-enabled bridges can be safer than centrally-operated multisig bridges. Funds cannot be unilaterally stolen by a small set of coordinated operators or hackers by obtaining a known set of private keys (see the $500mm Ronin bridge hack and the $100mm Harmony bridge hack). Instead, the security of a SNARK-enabled bridge relies on the honesty of a larger and regularly-shuffled sync committee as defined in the eth2 light client spec.

Cons:

  • Operating expense: Our estimates suggest it will cost ~0.008 ETH per light client header update at 40 gwei gas price as well as ~0.008 ETH per withdraw operation on the bridge. The frequency of light client updates is up to the operator. In the most extreme case, updating the light client every 10 minutes for a year would cost ~420 ETH. Updating every two hours would cost ~35 ETH.

Additionally, regardless of what cryptographic mechanisms are used, bridges cannot provide security beyond the consensus mechanisms of the source and target chains. Even with the efficiencies provided by zkSNARKs, such limitations will be governed by the size of potential PoS penalties on either chain.

Implementation

Work Breakdown

Timeline: 10 weeks (July 4 - September 9) for Phase 1 and Phase 2

Phase 1:

The goal of Phase 1 will be to deliver prototypes of the three important components above. In particular, we will deliver a smart contract that implements the Eth2 light client spec with as much computation as possible moved off-chain with a zkSNARK circuit to make gas costs feasible.

The SNARK circuit will do three things:

  • verify the BLS signatures of the sync committee
  • verify the Merkle tree inclusion proofs using SSZ for serialization used in several places in the light client
  • verify the current sync committee from the previous block header

The Solidity smart contract will generally implement the Eth2 light client spec substituting out the BLS signature verification and Merkle tree inclusion proofs with a snark verification, reducing gas costs.

We will also provide an operator node implementation which periodically updates the light client with the proof generated by the SNARK circuit.

Phase 2

In Phase 2 of the of the grant, we aim to have public-facing polished artifacts and deliverables including the smart contracts and circuits from Phase 1. The artifacts include the following:

  • public open-source repo with smart contract light client and SNARK circuits with clear documentation
  • ZK light client deployed to testnets (Ethereum and Gnosis Chain) with a prototype operator that generates proofs and pings contracts with block headers every 10 minutes
  • public open-source repo with a prototype bridge contract that calls the light client smart contract and a prototype UI that allows for use generating inclusion proofs and bridging funds
  • prototype bridge contract deployed to test nets and example of SNARK-enabled bridging on testnets
  • public blog post explaining what we built: the technical architecture of a SNARK-enabled bridge, high-level technical explanation of circuits and how all the components fit together, and a precise breakdown of both security guarantees as well as risks/limitations/failure modes of a SNARK-enabled bridge.
  • stretch: blog post series diving deeper into technical details of each component

Deliverables

Grant Allocation

The core team that would recieve this grant is part of the 0xPARC organization. 0xPARC is trying out a unique, experimental public-goods collective grant sharing proposal for this project. In particular, the proceeds from this grant will be split 50/50 between the core team and donations to various dependencies the project relies on (i.e. open source circuits, public goods resources) as well as the 0xPARC community.

The reason for this split is this project is only made possible by extensive open-source work by co-dependencies in the 0xPARC and broader ZK communities (such as circom, made by iden3).

This innovative model for grant-funding and support for public goods will also be mentioned in the blog post, as we want this project to push the narrative from both a technical standpoint as well as a community & grant-funding standpoint.

We are requesting a total of $600k (600k USDC) across two project phases: $300k will go to the team and $300k will go to the broader ZK community and public goods (distribution determined by core team). We expect that the project will take around 30 engineering weeks for the core team, in addition to supporting work from various dependencies and public goods that make this project possible. As described above, half of the grant will be distributed by the core team to the broader ZK community and various co-dependencies (which may include prior work by team members, as well as future ZK projects that opt into 50/50). Note that the core team, not GnosisDAO, will be deciding on the distribution of the $300k set aside for broader ZK community and public good contributions.

Phase 1: $120K for Team + $180K Public Goods/0xPARC ZK Ecosystem

The funding for this phase will be paid out in advance of work starting on Phase 1. The deliverables for this phase include the following:

  • [ ] ZK circuit template for BLS signature aggregation and verification
  • [ ] ZK circuit template for SSZ Merkle tree inclusion proofs
  • [ ] ZK circuit for verifying the sync committee form the previous block header
  • [ ] Solidity smart contract for running the light client according to the Eth2 spec on EVM
  • [ ] an operator node implementation which periodically submits new headers and proofs of the ZK circuit to the light client

Phase 2: $180K for Team + $120K Public Goods/0xPARC ZK Ecosystem

The funding for this phase will be paid out after the completion of Phase 1 (as judged by Stefan and Martin of Gnosis) and before starting of Phase 2. The deliverables of this phase include the following:

  • [ ] extensive documentation of all circuits, contracts, and code
  • [ ] ZK light client deployed to test nets on Ethereum and Gnosis Chain with a prototype operator that generates proofs and pings contracts with block headers periodically
  • [ ] prototype bridge contract + UI that can bridge assets from Gnosis Chain to Ethereum
  • [ ] blog post explaining what we built ranging from the technical architecture of a SNARK-enabled bridge and how all the components fit together

For phase 1 payment, the address the funds should be sent to is 0x480B4DE4D6946f477fD38346fA8D3d1B6e3dBB2c

The funds for phase 1 transferred to this address should be 300,000 USDC. (As a note, we previously had a different address provided on this proposal, but switched which wallet we were using for logistical reasons). The funds should be paid out once (for Phase 1) and should be on Ethereum mainnet.

Team

  • Uma Roy
    • Summer resident at 0xPARC. Co-author of ZK-identity apps zkmessage.xyz and cabal.xyz. Co-author of circom-batch-ecdsa.
  • John Guibas
    • Summer resident at 0xPARC. Co-author of circom-batch-ecdsa and has experience building smart contracts for DeFi and infrastructure for blockchain analytics.
  • Jonathan Wang
    • 0xPARC grantee and co-author of circom-pairing. Number theory post-doc and elliptic curve math specialist.

Additional 0xPARC community members will be helping out with implementation. This includes individuals that helped implement many of the most advanced circuit primitives in groth16, including co-authoring of circom-bigint, circom-ecdsa, and circom-pairing.

GnosisDAO Snapshot

https://snapshot.org/#/gnosis.eth/proposal/0x7575919c07e03bbe642b11938501bb6cbc542337f64763f94a00e04ed403cfba

12 Likes
2

This is another easy yes for me. While $600k is a large investment, I think this is easily justifiable from the POV that it prevents a bridge hack:

  • A hack on Omnibridge and xDai Bridge would now cost approximately $90mn
  • This will only increase in the years to come as Gnosis Chain grows
  • This would likely wipe out Gnosis Chain permanently (DAO cannot bail them out)

On a 2-3 year timeline, a validity-proof bridge is critical to ensuring that assets can be bridged over with confidence. We should not end up in a situation like Polygon, where billions of dollars rest in the hands of a few signers.

Longer term, we should deepen our collaboration with 0xParc and Eth R&D. While other ecosystem funds blow their treasuries on parties and swag for Web3 tourists, the Gnosis Chain treasury should be used to build an ecosystem to incubate ZK ideas, which can then benefit the wider Ethereum community once proven. Dark Forest was (and is) a great example of this.

Gnosis Chain has a long history of being a indie chain with cheap blocks for art and experiments - let’s honor that legacy that Igor and his team have built, and that the wider Gnosis community continues.

6 Likes
3

Seems very valuable to me although I am not able to judge about the technical details as I am not educated enough about these. Imho bridging is one of the most important parts of the blockchain infrastructure in the future as no one could feel comfortable to be locked in an ecosystem. Therefore funding research on this is clearly worthwhile.

Regarding the specifications of this proposal I have only one question about:

Is this really meant one way only from gc to ethereum? If so I would like to have an explanaition why, cause both ways seems more appropiate to me.

1 Like
4

Thanks for the proposal @pumatheuma

I very much agree that improving the bridge security and infrastructure should be a main priority for the chain. We are putting a lot of effort into a large and decentralized validator set and this proposal could allow deriving the bridge’s security from this validator set.

I am very excited about it!

6 Likes
5

Huge yes from me on this one!

6

Having such a bridge implemented would be definitely great. So, I am definitely in favor of this proposal!

However, there’s something that’s been bugging my mind. What would be the implications of the Gnosis Chain native tokens such as $HNY and $AGVE (initially minted on GC) and bridged to the Mainnet using the Reverse Omnibridge implementation. Would using another bridge nullify the GC-native tokens bridged to Mainnet? In such a case, and in case we decide to goon with a new bridge implementation and render the current Omnibridge obsolete, what would happen to those who bridged these tokens to the Mainnet?

I know for a fact that these are a bit exceptional cases, but I also know there are at least a few significant parties who would be affected if we render the current Omnibridge obsolete and decide to halt its maintenance. The same goes for the Omnibridge between GC and BSC as well, I remember a few tokens initially minted on BSC using GC-BSC Omnibridge to bridge their tokens out of BSC and to Mainnet.

2 Likes
7

This GIP is only for exploring a prototype of a SNARK-enabled bridge. Replacing (probably more likely augmenting) the current Omnibridge with such a SNARK-enabled bridge would be a significant next step (and probably another GIP), and would require a lot more fleshing out of details on how the bridge will be augmented/replaced, what happens to existing assets, who will be responsible for operating the bridge, etc.

2 Likes
8

Got it. Realistically, I am assuming it would be a 1-2 year timeline for this to be production-ready (if indeed the prototype works without too-high gas costs). Is that intuition correct?

9

Are authors aware of EIP-2537 proposal status? Any comments?

10

Great question. There is a prototype of bidirectional trustless AMB (arbitrary message bridge) between two post-merge EVM networks with Omni extension enabled. It requires EIP-2537 activated (or mocked) on both networks. By the way, our design can use different proof systems (BLS, ZK).

There will be a presentation/ demo of the BLS-based trustless bridge on EthCC 2022-07-20T10:10:00Z

Screen Shot 2022-07-15 at 10.48.31 AM
Screen Shot 2022-07-15 at 10.48.31 AM1600Ă—734 104 KB

We will upload a video and presentation after the talk. The product is built by the former xDai team.

8 Likes
11

Yes, we are aware that there is an EIP for BLS pre-compiles that would solve much of the problem that our SNARK-based solution aims to address and this is a great question! A few thoughts

  • Our SNARK-based solution additionally allows for not having to post the sync committee public keys on chain (and instead only post a commitment to them and verify this commitment as the output of the SNARK) due to the non-forgeable nature of BLS signatures. With this, we’ll save gas on the call data costs of posts 512 48 byte public keys to the chain each 27 hours. There are a few other on-chain computations (like SSZ) that we also plan to put into the SNARK, which will save additional gas vs. a solution just using a pre-compile.
  • The timeline on this EIP seems a bit unclear, and it would be nice to have a shorter-term solution.
  • This methodology of using a ZK-enabled light client can also be generalized for other signature schemes that other chains might use (for example different consensus algorithms that use curves other than secp256k1, which is used for ECDSA, or bls12-381 which is used for BLS) without relying on pre-compiles existing on either chain that is on either side of the bridge.

All this being said, the SNARK-based approach is much more complicated and has a higher surface area for security vulnerabilities (i.e. security issue with SNARK) vs. using a pre-compile! So when the pre-compile comes out, it would be good to do another assessment of the tradeoffs between both systems and reevaluate.

12

I think it’s hard to say what exactly the timeline would look like. The SNARK-based technology we’re using is quite new and our circuit would be one of the largest circuits used in production, so getting that audited would be quite a novel audit. Having the human capital to take the prototype to production and maintain it would be another factor that would effect timelines quite substantially.

Depending on the enthusiasm around getting this bridge into production, the productionalization timeline could range from months (maybe a couple months) to a year or so, is my best guess.

13

It should be very easy for the prototype bridge to go in either direction, I think for simplicity and constraining scope we want to start with Gnosis to ETH, although I think it should be quite simple to do the reverse direction (and we’ll try to get that in the timeframe of the grant, and hopefully likely will).

1 Like
14

It’s awesome to see another implementation of bridging between EVM chains! Please post the video and presentation after the talk, our team will definitely take a look. We’d love to share notes some time as well. Hopefully there will be some common infrastructure components that both teams can collaborate on that come out of this. In the research phase, it’s always productive to have multiple teams in parallel working on different approaches so that the tradeoff space can be more thoroughly understood and teams can learn from each other’s designs.

There are of course tradeoffs between BLS and ZK, that I also mentioned in a previous reply. One other interesting thing to note for ZK bridges is that it enables the possibility of a tornado-cash like deposit/withdrawal scheme for private cross-chain transfers (this doesn’t require a SNARK for the BLS signature verification for block headers, just a SNARK for deposit/withdrawal).

3 Likes
15

here we go:

6 Likes
16

Hello everyone, my name is Max and I work at Connext.network, a trust minimized interoperability protocol. We have been very close to the Gnosis team and appreciate what you guys are doing.

Recently bumped into this proposal and so wanted to contribute to it with some of the research we have been doing recently.

While looking for better bridges is always a good idea, it’s also important to set expectations as to what is feasible and what is not.

Unfortunately, a completely trustless bridge between independent blockchains is not possible. Our research team recently wrote an article that explains some limitations of Validity proofs-based bridges.

Zk-snarks can still be useful in other contexts - for example in Plumo (https:// eprint.iacr. org/2021/1361.pdf) , zk-snarks are used for a signature scheme where signatories do not need to be aware of each other, which could help prevent hacks on multi-signature bridges such as Ronin

By the way - a multi-signature bridge between PoS or PoA chains is as close you can get to a trustless bridge - where you are proving that transactions are processed safely. But you still cannot prove that the originating blockchain actually posted those transactions to its ledger

A better method for preventing the Ronin attack would be to integrate optimistic mechanisms. If there had been a watcher whose job was to compare the transactions between chains, it would have reported fraud before the transaction was finalized.

I would encourage you to look at Nomad.xyz and what they have been pioneering:

Thanks, and keep pushing the space forward :rocket:

2 Likes
17

Hey @maxlomu - welcome to the forum!

The blogpost you are quoting contains reasons why approaches like zkEVM are not enough for trustless bridges. The gist of your post is: you need to do 2 steps:

  1. validate validity of the state transaction
  2. apply a “fork choice” rule (decide which is the canonical chain)

Zk-EVM indeed only does 1). However - in this design we are actually only focussing on 2). We are not proofing that the state transition was correct - however - we are proving that the correct number of validators of Ethereum/ Gnosis Chain have attested to a block. We are literally implementing the same functionally of how a light client would decide about what the correct block is.

Whether this bridge should be called trustless or not is a different debate. The precise answer could be - it has very similar trust assumptions as a light client. I can recommend this bridge risk framework here. In this framework I would classify our approach here as “Light client Verifying Consensus”

1 Like
18

So basically this proposal would be a waste of time and money?

20

Hey @zahary - thanks for reaching out.
First a quick comment - the proposal as already been funded many month ago.

The team has now formed a company to continue to work on this project: find more info here.

With that being said - I think it totally makes sense for you to connect and I agree that those proofs can be useful even for “regular” (not smart contract based) light clients.

1 Like
21

Please check out zkBridge at our website zkbridge.org and our tweets at @zkcollective, where we leverage deVirgo (a distributed version of Virgo) and recursive proof with Groth16 for fast proof generation of block headers (including the signatures) and low on-chain verification cost (at the cost of a single Groth16 verification). It’s the first trustless, permissionless, extensible, and efficient cross-chain bridge, and strong security without any external assumptions is guaranteed by our highly optimized zk-SNARK scheme.

1 Like