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

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

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

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?

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

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

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

8 Likes

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.

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.

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

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

here we go:

6 Likes

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

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

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

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

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

Hey @zkBridge team - read your newest paper on zk bridging and would love to learn more, if someone from your team is open to chatting.

A small update from our team:

We’ve now completed a circuit capable of transitioning from one beacon chain header root hash to another:

The cost of processing one update is now down to 330K (getting quite closer to the theoretical minimum of around 250K for verifying a single Groth16 ZK proof). There are only two remaining Solidity computations that can still be moved to the circuit to arrive at the final fully optimized version.

A complete header-to-header transition is also what we needed for creating recursive proofs, so our next primary goal would be developing the one-shot syncing solution.

6 Likes

We have now completed a recursive version of our circuit which can be used by any Ethereum client to implement one-shot syncing capabilities similar to the ones available in the Mina protocol (please see our analysis regarding the limitations of this approach):

In the coming months, we’ll be porting our proof verification contracts to many other blockchains and we’ll be aiming to implement a recursive circuit verifying aggregated signatures from the entire validator set, instead of just the sync committee, which should significantly increase the crypto-economic security of the bridge.

2 Likes

Trying to restore this post, which was unfortunately flagged by the system.

Our light client is now being used in production to secure the Gnosis omnibridge from Ethereum → Gnosis: https://twitter.com/SuccinctLabs/status/1676714807276470272!

An updated address to receive the Phase 2 of the grant is here: 0x1c95dfADB4984267eEccF0Db04399Ee10573e4cB.

2 Likes