The problem AnonAbuse solves

Hacks and thefts are extremely common in crypto, with billions being lost every year. Many people who hold or work in crypto have been hacked and yet there is still a large stigma attached to it which prevents people from coming forward. This both makes the work of law enforcement officials more difficult by limiting the information they can obtain regarding the facts and circumstances surrounding a hack and also negatively affects the mental health of victims by making them feel ashamed and alone.

We address this problem by creating AnonAbuse, a fully anonymous way for users who have been verifiably affected by a hack to share experiences and information while maintaining their privacy. Users first authenticate their link to an attacker by connecting their wallet and providing a transaction that links their wallet to the attackers wallet. The transaction's inclusion in a block and the link between the attacker and victim is verified using RiscZero's Bonsai. We also apply zkML here to verify that the attacker's address has the characteristics of a honeypot in order to prevent spurious linkages.

Following a successful proof, the user is added to an on-chain registry of addresses which have been affected by a hacker. This registry is used to construct an ecdsa semaphore group using the efficient-zk-ecdsa proof scheme. Once a user is included in this set, they can "signal" information regarding their hack and broadcast them as a member of this verified set without doxxing their specific identity. These data and the associated proof of its validity can be posted to twitter, sent to law enforcement, or even submitted to ChainAbuse via its API.

Our hope is such technology will make it easier for hack and theft victims in crypto to come forward and share vital information that addresses this massive problem in our ecosystem.

Challenges we ran into

During the hackathon, we encountered a challenging issue with reconstructing the transaction trie root from the data to prove the inclusion of the "phishing" transaction. Our team was using Foundry to mock up blocks and expected to generate the correct Merkle Patricia Trie (MPT) roots for the block. However, we ran into a peculiar problem: the roots produced by our trie did not match with what was in the block. We tried using both the ethereumjs library and ZETH for the trie construction, but neither matched the expected roots, and to our surprise, they didn't match each other's outputs either. This inconsistency led us to suspect there might be an issue with the alloy integration.

After a thorough investigation (I wasted 3 hours making sure we didn't mess up the implementation), we discovered that the ethereumjs output was accurate. It successfully generated valid proofs and recreated the proper transaction trie root and proofs for both mainnet and sepolia blocks.