Problem to solve

This project is an On-chain Database of Emergency Security Event Contact, which includes a ZKP-based project identity verification mechanism and an Anti-Spam mechanism for project notification endpoints. It aims to address the specific scenario where white-hat hackers discover critical security vulnerabilities in a project, enabling them to timely notify the project side through this database and mechanism. The project side can effectively block spam and issue alerts only when a potentially genuine vulnerability is found, thus improving alert levels within the team and enabling urgent responses.

For project side

The on-chain database consists of a registration contract, corresponding frontend page, and a set of ZKP-based domain verification tools. We verify the ownership of the project domain to authenticate the project side. The specific mechanism involves the project providing the project domain, owner address, contract address, and contacts. Based on this information, ODESEC generates a challenge and the project creates a subdomain, for example, [challenge].project.com, such as 9940a3585901631fa19b16fcfa63c9a5365a4ac1.bastionfi.xyz. A software running on the server pointed by this subdomain, based on an SSL certificate generated by Let’s Encrypt, will create a ZK proof of the validity of this SSL certificate and its association with the project's subdomain [challenge].project.com. Subsequently, the ZK proof, along with the project domain, project-related contract addresses list, and emergency Telegram contact, is submitted to the registration contract on-chain. The contract will verify the ZK proof's validity, and if successful, will write the provided project domain and emergency contact details into the contract.

For whitehat side

When a white-hat hacker discovers a contract vulnerability, they need to first generate a ZKP of Exploit (Note: This ZKP of Exploit is a previous work we completed but not the main focus of this project; we made upgrades to enable additional checks). They then submit this ZKPoE, vulnerability description, and the project contact details to be notified (obtained from the on-chain database) to the Telegram BOT responsible for notifications. Once the Telegram BOT receives the ZKPoE, it will verify through a ZK Verifier if the specified PoC address has actually exploited funds and if the interacting contracts are in the project's related contract address list. This verification step acts as an Anti-Spam measure. If the ZK Verifier validation is successful, the relevant contents are communicated to the project side, establishing a communication channel between the two parties.

ODESEC Contract

• stores the domain, contact information, and contract address list of the project
• verify the SNARK Proof of ssl certificate for project registration
• contact information of the project can be queried based on the domain name or project contract address

using ssl certificates for project identity authentication

• use getssl tool to obtain free Let’s Encrypt certificates for specific sub-domains like 9940a3585901631fa19b16fcfa63c9a5365a4ac1.bastionfi.xyz
• using @risc0's zkvm technology and @risc0's bonsai service to generate SNARK Proof which can be verified on the chain
• implemented guest code in zkvm using Rust

using ZKPoE(ZKP of Exploit) for message anti-spam

• ZKPoE technology originates from our previous work, this time we have upgraded it to support the test network and generate simpler proofs
• use risc0's bonsai service to accelerate zkp generation
• only valid ZKPoE can allow the project to receive message sent by whitehat

ODESEC CLI tool

• developed using Rust
• has the functionality to generate ssl SNARK proof
• can generate ZKPoE
• can verify ZKPoE and output transaction state diff data

TelegramBot

• provides a unique contact for each project, whitehats need to submit ZKPoE through this contact, and only after successful verification can establish contact with the project
• use the ODESEC tool to verify ZKPoE and obtain state diff data to determine if the POC Address has received additional assets and if the project's contract address is in the state diff. If both conditions are met, the ZKPoE passes the check
• developed using Python

DAPP

• dapp implemented using the schaffold-eth-2 framework
• deployed using Vercel
• used Foundry and Hardhat to complete contract development and debugging