RFC - Implementing zk-based Merkle-Patricia Trie inclusion proofs

🐰Hop Ecosystem
1

Hi guys, Z from LimeChain here. Sharing a proposal that we’ve been working on for quite some time and briefly presented over yesterday’s community call.

Summary

This grant proposal seeks funding to develop a generalized Zero-Knowledge-based Merkle-Patricia Trie inclusion proofs (MPTIP) system and all the supporting infrastructure for Hop Protocol. The workings of this system will be showcased through a verification PoC, proving state with Arbitrum, Optimism, or Ethereum as the source or destination network.

Motivation

Hop v2 that is currently in development will support generalised messaging between rollups. Essentially, it provides a data transport layer for other dApps to integrate for their messaging needs, such as communicating with other instances of the dapp deployed on another network or propagating the outcome of a governance Vote between chains. dApps that integrate with Hop for generalised messaging would increase the volume of message transfers between networks leading to increased revenue for the protocol.

Implementing ZK-based Merkle-Patricia Trie inclusion proofs would allow Hop to provide cross-chain state proofs. Performing the State proof verification within a ZK circuit would reduce the data transport costs by an order of magnitude. This enables Hop to provide a competitive and cost-efficient data transport layer for its users without compromising on the security of the transfer. Supporting secure generalised messaging in HopV2 (not only a token transfer protocol as in HopV1) makes Hop more competitive in a saturated bridge / cross-chain communication market.

Why should LimeChain execute this grant request?

LimeChain is a blockchain development company building apps and infrastructure since 2017, working with companies and projects such as Ledger, Coinbase, The Graph, Celo, Polkadot, and others.

Over the past 1 year, the R&D team within LimeChain has been focusing heavily on rollups and interoperability between them, most recently building Rollup.codes, as well as contributing to Optimism (Extractoor and currently working on storing historical blockhash), Polygon zkEVM (implementation of Erigon) and other stuff.

Deliverables

The scope and deliverables are described in a technical document here. We expect to deliver the PoC in 4-5 weeks time after approval of the grant.

Funding Request

We are requesting 500,000 HOP in funding to be split in 2 parts - 50% up front as significant research has already be done and 50% upon delivery to the following address: 0x599F217AD33192a0FEa8673535824EF2f37DE90d

2 Likes
2

I would be in favor of improving the v2 messaging by using ZK circuits to reduce the cost. Not sure how we justify the Hop funding amount though. It would be great if there was some ROI modeling to show estimates of increased messaging revenues.

Also, is there any indication of the costs to run the Prover API?

Finally, if the PoC is a success what would the next steps be, and would further funding be required?

3

I think it could be difficult to model the ROI of a grant like this but I do think this grant will be extremely valuable for Hop. The proposed deliverables will give us what we need to integrate cross-chain storage proofs into the Hop v2 messenger. It will also be an initial step toward introducing zk tech into the Hop stack which will better position Hop to adopt more zk functionality as it becomes more practical.

You raise a good point about the prover server API cost. Generating zk proofs is currently expensive and slow but will likely improve as hardware acceleration gets better and hardware costs come down. I think we will see proof generation networks or services that applications can leverage so they don’t need to run their own servers and the cost will ultimately be born by the application/user/solver.

1 Like
4

Thanks for providing additional context @cwhinfrey!

One more addition on our end - the PoC’s success should be evaluated in the context of the overall success of Hop V2, competitive landscape etc. Like Chris mentioned, it should enable Hop to adopt more zk features, however whether it would be worth it to extend the PoC depends on overall roadmap, protocol traction etc.