Groth16/ZK DID Specification W3C DID Core Specification, which defines how DIDs are structured and resolved. A DID consists of three parts:Scheme: Always did. Method: Identifies the DID method (e.g., did:example:123456 where example is the method). Method-Specific Identifier: Identifies the unique entity within the method. 1. Purpose of the DID Method The main purpose of this DID method is to ensure compliance with W3C standards for verifying proofs generated by zk-SNARK protocols like Groth16. It aims to support both on-chain and off-chain verification processes. This DID method can be used either on-chain (EVM) or off-chain (server-side verification).

First of all, this was an amazing experience to have the chance to work in person with other projects focused on building on top of snarkified signatures. It was a moment of deep sharing and work and I thank the organizers to have enabled that. Project Overview The project we worked on with Saleel was born from a reflection that started back in December '23 at ETHIndia when hackers presented their Anon Aadhaar + Semaphore project. We believed it could significantly enhance end-user privacy by obscuring actions linked to one's identity, addressing the unresolved issue of not being able to hide your Anon Identity from the signature issuer. However, Semaphore has inherent constraints as it uses randomness as the identity seed and commits it to a Merkle Tree representing group membership. In our case, the identity is based on the government signature. We had to find a solution to retain the Merkle Tree commitment structure with a twist—specifically, how the leaf is committed to the group. The main challenge was balancing UX and security. Brainstorming together for two weeks provided a fantastic opportunity to explore potential solutions to these issues. Learnings My main learnings stem from the side research I conducted during the residency. I finally completed "MoonMath," which provided a deep dive into SNARKs and Groth16, giving me a better intuition about constrained systems and the translation of Circom to R1CS to polynomial commitment. I am now eager to learn more about Plonk and Halo2. Additionally, discussions with others enriched my understanding, particularly around Binius, MPC, and FHE. Project Synergies During the residency, we found significant synergies with other zk projects. Early discussions with the Proof of Passport team revealed common challenges, leading to a shared solution that integrated our diverse approaches. Conversations with the zk-email team, who have more experience with our common stack, also proved incredibly enlightening.

Last month, we decided (Anon Aadhaar) to switch from Mopro to the PolygonID stack (WitnessCalc + RapidSnark) for our mobile library. This post aims to outline the different reasons behind our choice. AppStore The main blocker was our inability to make a release on the AppStore, due to the requirement of a dynamic library to embed the WASM needed for witness calculation. Performance PolygonID introduced a native C++ witness calculator, which significantly sped up the witness calculation and also addressed the above issue. However, the PolygonID stack seems to be faster even in proof generation. Benchmark for Anon Aadhaar circuit: