ZK-Express

zk-express enables secure, decentralized on-chain verification of off-chain data, addressing the broad need for bridging Web2 and Web3 data without relying on centralized intermediaries. This system leverages zero-knowledge proofs based on the DKIM protocol, providing a trustless method to verify emails and other data on-chain.

A concrete application scenario: suppose a user wants to distribute rewards on-chain based on a developer’s GitHub contributions. Typically, this requires transferring GitHub’s off-chain data onto the blockchain. However, due to the volume and cost of data transfer, there is no available oracle service for that. So most applications resort to a centralized backend service to register and verify data. zk-express allows decentralized contribution tracking by generating zero-knowledge proofs of GitHub data through email, eliminating the risk of tampered data while maintaining trustless integrity.

Our second key value lies in significantly lowering the user entry barriers for using zk-email. Normally, generating zk-email proofs is tedious, involving downloading raw email data, uploading it to a proof-generating service, and then submitting the proof on-chain. zk-express simplifies this by managing a dedicated email account that subscribes to relevant notifications. Upon receiving an email, our system automatically generates the corresponding proof and submits it on-chain. While this process is managed by our service, theoretically, anyone with access to the original email could perform the verification, preventing data tampering. If users trust the email service provider and data source, this setup is inherently decentralized.

To showcase zk-express’s capabilities, we’ve implemented a live GitHub repository tracking system. By simply configuring the repositories for our email bot, the system will track any new issues or pull requests. Upon receiving a notification email, it automatically generates a proof and submits it on-chain for verification, providing a trustless and decentralized way to synchronize GitHub data with the blockchain.

zk-express: bridging off-chain data to on-chain with zero-knowledge proofs.

For this hackathon, my system consists of four main components: the email management module, the proof and verification smart contract (based on vLayer and Solidity), a backend service for proof generation (built with Node.js), and a frontend visualization for GitHub issue tracking (using React) that provides a real-time comparison of activity between two repositories. This visualization helps users quickly see the relative activity and changes over time in both repositories. 1. Email Management Module: Built with Python, this component hosts a Gmail-based bot that subscribes to notifications from specific GitHub repositories and downloads .eml files locally in real-time. 2. Proof and Verification Smart Contract: This contract is implemented using vLayer and Solidity. vLayer significantly simplifies the logic for generating and verifying proofs, abstracting away all the intricate circuit details, which makes it very easy to use. 3. Backend Service for Proof Generation: This backend service, built with Node.js, currently functions as a trigger for proof generation when specific emails are received. This setup can be expanded in the future to allow users to customize their proof requirements for different data sources. 4. Frontend Visualization for GitHub Issue Tracking: The React-based frontend visualizes the issue counts of two selected repositories, allowing users to see and compare their activity levels over time, making it easy to assess and analyze each repository’s engagement.

Partner Technologies: vLayer proved invaluable for our project, greatly simplifying the proof and verification logic by abstracting circuit details, making the integration seamless and efficient.

Challenges and Future Improvements: We encountered some issues with vLayer’s email parsing functionality, particularly with analyzing the email body, so we currently rely on the subject line for processing. I’m considering contributing a fix to improve this in the future. Additionally, we’re exploring ways to allow users to customize the proof generation logic. One approach could involve deploying a separate smart contract for each scenario, where users could fill in specific metadata to tailor the verification process to their needs.