Takeaways Challenges: The main obstacles for privacy protocols are interoperability, lack of standards, and developer accessibility. Emerging solutions: POD2 and SelfAttestHub offer different approaches to address these issues, with POD2 focusing on general-purpose cryptography and SelfAttestHub on identity and verifiable credentials. Goals: Both solutions aim to make protocols more modular, composable, and interoperable. Potential synergies: While distinct, POD2 and SelfAttestHub could complement each other in privacy-driven ecosystems. Over the past few months, I’ve explored digital identity, learning from experts, understanding key challenges, and evaluating privacy technologies in current systems. The lack of interoperability, standards, documentation, and developer tools appears to be the main obstacle hindering the adoption of privacy-focused technologies. This is especially true for protocols that fall under what 0xPARC calls "Programmable Cryptography", namely those protocols that mark a shift from specialized cryptographic systems, like public-key encryption and digital signatures, to more general-purpose ones. These include zkSNARKs, MPC, FHE, Witness Encryption, and Obfuscation. That said, it was reassuring to see that many people and organizations are actually already actively working to overcome these challenges. Efforts range from promoting the adoption of specifications to creating comprehensive documentation, improving the developer experience, and establishing format standards. Most importantly, there is a gradual but essential process of abstraction underway, which aims to make these protocols accessible to a broader audience without any background in cryptography, while also enabling a paradigm shift in how we approach them. Instead of treating them as isolated tools, abstraction allows us to think of them as interoperable components that can be combined to create more powerful, multi-faceted privacy solutions.

The names of the milestones are the names of Saturn's first 7 largest moons, from smallest to largest. Milestone 1: Mimas v0.x.0 (Aug 31) The goal of the first milestone is to have a functioning first infrastructure with minimal functionality. Admins should manage their permissioned groups with a simple dashboard and the backend service should provide read-only APIs to generate Merkle proofs or to get group information (e.g. name, size, members). There will be only two components initially: dashboard and API service. Github Milestone: https://github.com/privacy-scaling-explorations/zk-groups/milestone/1 1. Single sign-on Admins should sign-in with Twitter, Reddit or Github (SSO). A session remains active so that they can log-in automatically next times.

What We’re Looking For: (5) Demonstrable experience of full-stack development (preferebly at least 3 years) (5) Expert in JavaScript, Typescript, Node.js, git & command-line environment (5) Experience in React (Nest.js is a plus) and testing techniques (3) Experience with Docker and hosting backend services on AWS (3) Experience with CI/CD tools (e.g. Github Actions) (5) Familiarity with modern software architecture techniques for building modular and testable applications and for creating high quality and efficient code (3) At least basic knowledge of Ethereum and blockchain concepts in general (Blocks, Transactions, SHA3) (2) Basic knowledge of how smart contracts work

Target audience Specific target audience In both cases, the main goal is to provide APIs for developers to enable them to integrate anonymity sets and build privacy-based applications. Specifically, the main target audience for both projects are therefore developers. However, in both cases the target audience changes depending on the components. As we'll see in the Infrastructure section, there's a main component that is the back-end with the APIs (which already includes all the features), and optional add-ons that extend the back-end, abstract the APIs and actually have different targets: end-users or generically project teams. General target audience Broadly speaking, Interep was designed as an anti-Sibyl system based on Semaphore reputation groups. The main audience are web3 enthusiasts who intend to use and export web2 reputation to blockchain. The goal of ZK-Groups is even more ambitious, the idea being to offer a more generic infrastructure to allow people to create their own groups, adaptable to many more use cases. The audience can also be governments, international institutions, non-profit organization and associations. Infrastructure and technologies

What is a Semaphore ID? Semaphore ID is the identity you need to interact with the Semaphore protocol. They are made up of two secret values: Trapdoor and Nullifier, and one public value: Commitment, which is the hash of the secret values. Although Semaphore identities do not use asymmetric cryptography, the secret values are like a private Ethereum key, while the commitment is like an Ethereum address. Semaphore IDs are needed to represent users within groups and to allow them to create anonymous proofs. How am I anonymous? Semaphore uses zero-knowledge technologies which allow you to prove that a statement is true without revealing any information apart from the fact that the statement is indeed true.

The last internal audit covered Semaphore v2.0.0 and focused specifically on contracts and circuits. Since then, circuits have not changed, contracts have been updated with minor features, and several Semaphore JavaScript libraries have been added. New changes Semaphore contracts The latest changes in contracts affect roughly all contracts. v2.1.0 New function to add many members in a single transaction: #131 New function to update group members: #128

Code Semaphore code consists of three parts: Circom circuits, Solidity contracts and JavaScript libraries. Circuits Circuits are very rarely updated, since it would require a new ceremony. Ideally, they should remain the same for years. The Semaphore circuits have no packages. They are not distributed but anyone can see the code in our repository and the Trusted Setup data. Contracts Contracts are updated quite frequently. However, since each change requires a new deployment and old on-chain groups would be lost, it is recommended to make as few changes as possible.

The Blockchain Summer School in Pula was our first experience as teachers and panelists. Despite some difficulties in terms of lessons time scheduling or last minute implementations, the event experience was quite smooth. The organizers were happy about our work and interesting questions and discussions came up. The topics we covered included theoretical/basics concepts on ZKPs, the Circom language, Semaphore, and MPC Phase2 Suite. About 1/4 of the class was able to complete the exercises on Circom and contribute with the Phase2CLI to the ceremony, while almost all participants were able to use the Semaphore boilerplate and generate their proofs. Many of them asked interesting questions, and some also seemed interested in integrating our projects into their academic path or into personal projects. Many other questions covered non-technical aspects, such as how we work, what skills are required in our team, or even questions about the Merge or Ethereum competitors (e.g. Algorand and Cardano). Academic Networking We have been proposed to start research grants probably funded by the Sardinia region on zero-knowledge technologies. This could be a great way for students to start using our technologies during their university path (Master's thesis or P.hD). We are seeing this as potential first step for hiring. Bartoletti was our professor at the University of Cagliari. He was pretty excited after the panel and he's currently studying attacks on DeFi protocols. He's a privacy-oriented individual, so I think we could try to understand if he's interested on ZKPs and possible academic collaborations.

Reputation badges as NFTs Idea Ability to mine an NFT representing the high reputation earned on Web2 platforms "pseudo-anonymously" (no link between Web2 accounts and Ethereum account). What problems can be solved? Attestation for access to services Reputation NFTs could be used to access services that require sybil-resistance. A service requiring these NFTs will be free of bots and fake accounts. For example, faucet services on testnets, which give ethers to developers, can require these NFTs rather than requesting the sharing of addresses on personal Twitter accounts.