Proposal: Semaphore ERC7579 Validator Module

[jimmychu0807]

PSE Acceleration Program

• Project: Semaphore ERC7579 Validator Module
  Project Idea: Semaphore + Account Abstraction semaphore-protocol/semaphore#345

Project Overview 📄

Overview

Semaphore is a zero knowledge component that allows users to prove their group membership and send signals without revealing their original identity.

With the recent development of Account Abstraction ERC-4337 and Minimal Modular Smart Account ERC-7579, these advancements allow a smart account to install modules to gain extra functionalities.

The objective of this accelerator program proposal is to develop a Semaphore ERC-7579 validator module so when this module installed, the smart account allows Semaphore group members of that particular account to sign transactions on behalf of the account. We will also achieve multi-sig wallet functionality by requiring a threshold number of Semaphore signatures before a transaction can be validated. This threshold number is configurable by the wallet owner / Semaphore group admin.

One advantage of this setup compared to a normal multi-sig wallet is that signers' privacy is preserved. Semaphore protocol hides which user identity actually signs the transaction, only guaranteeing the signature must come from one of the group members who have not signed before, thus preventing double-signing too. Together with the smart account interaction model that the actor making on-chain transactions is not the Semaphore group member, but a bundler, we are able to deliver a smart account plugin that cannot trace who the original transaction signers with only on-chain inspection.

Project Details

The idea of this project has been explored by Saleel, and is documented in his blogpost. It was built at a time when the tool stack was still primitive. In this proposal, I aim to formalize this and solve semaphore-protocol/semaphore#345. When a smart account owner install this Semaphore ERC-7579 module to a smart account, a new Semaphore group is created. The user becomes the admin of the group and can manage the members inside. Any members in the Semaphore group will be able to send a zk proof of transaction on behalf the smart account. This is like a 1/N mult-sig wallet, with N being the number of members in the Semaphore group. We will also store the signatures to allow it behaves as a M-of-N multi-sig wallet. This module will be built using ModuleSDK framework.

At the end of the proposal, the following will be delivered:

1. Semaphore ERC7579 validator module, making it a 1-of-N wallet.
2. Extend its feature making it a M-of-N wallet.
3. End-to-end test code for testing the following behaviors:
   • installing the module to a smart account
   • admin adding/removing members, switching admins
   • sending transactions with M of N member signatures
   • uninstalling the module from the smart account
4. Inline code documentation.
5. A front-end demo allowing users to install this module to their smart accounts, add members (identity commitments) to the semaphore group, and sending zk proofs, all happening on a chosen testnet.
6. A writeup to introduce what has been done and give a technical overview of the module, and demonstrate the Semaphore group signer privacy is preserved.

Team 👥

Team members

• Jimmy Chu
  Email: jimmychu0807@gmail.com
  Telegram: @jimmychu0807
  Discord: @jimmychu0807

Team Website

website: https://jimmychu0807.hk/

Team's experience

I participated in the PSE Core Program 2024 - Taiwan, and delivered a capstone project of a zero-knowledge Number Guessing Game, built upon Semaphore boilerplate.

I previously worked in Parity as Polkadot developer advocate and CESS as developer advocate advisor. Other prior experience can be seen in my GitHub profile.

Team Code Repos

https://github.com/jimmychu0807

Development Roadmap 🔩

Overview

• Total Estimated Duration: 5 weeks
• Full-time equivalent (FTE): 1
• Expected Start Date:
• Expected End Date:

Milestone 1: M-of-N Semaphore validator module

• Estimated Duration: 2.5 weeks
• FTE: 1
• Estimated delivery date:

Deliverables and Specifications

1. Semaphore ERC7579 validator module

It will be a module in ModuleKit validator. Semaphore and related contracts will be deployed to be used in the validator module. With this module, the smart account behave like an 1-of-N multi-sig wallet.

2. Extend the feature to M-of-N multi-sig wallet

3. End-to-end test code

Both hardhat and foundry test will be written to cover 85% of the Solidity code for unit tests. Local development environment can also be spin up by Docker-compose to run end-to-end test of the module.

4. Inline code documentation

All public functions of the module contract will be documented according to NatSpec format.

Milestone 2: Front-end demo, deployment scripts, and writeup

• Estimated Duration: 2.5 weeks
• FTE: 1
• Estimated delivery date:

Deliverables and Specifications

5. Front-end demo & deployment scripts

A front-end demo will be able to spin up locally with a single yarn command. Because it relies on existing EntryPoint singleton and Paymaster contract to work, the locally running front end will need to connect to a testnet in order to execute all the functionality of the module.

Deployment scripts will be developed for front end being deployed to Vercel hosting and smart contracts deployed on a chosen testnet.

6. Writeup

A writeup will be submitted for review giving a technical overview of the project, and demonstrate the Semaphore group signer privacy is preserved.

Additional Information ➕

• Thanks @JohnGuilding for the proposal feedback in the issue thread.

• Currently exploring integrating Semaphore in ModuleKit in repo: https://github.com/jimmychu0807/rhinestone-modulekit-tut

[JohnGuilding]

Nice thanks for proposing this @jimmychu0807 :)

The proposal in general looks good to me.

admin adding/removing members, switching admins

Does this point imply that the module can be kept in sync with the semaphore group? Just want to make sure that this is covered in this proposal. E.g. removing group member can be reflected in smart account, and deciding if removing validator would want to be reflected in semaphore group

[jimmychu0807]

Does this point imply that the module can be kept in sync with the semaphore group? Just want to make sure that this is covered in this proposal. E.g. removing group member can be reflected in smart account, and deciding if removing validator would want to be reflected in semaphore group

Yes, the module is kept in sync with the semaphore group members. Only the zk-proof from the group members are counted as a valid "signature" for the smart account transaction.

[jimmychu0807]

@JohnGuilding Would like to know what is the next step of the application? And what is the general timeline of when I hear back from the vetting committee if the application passes? Thanks.

[JohnGuilding]

Hey @jimmychu0807, thanks for getting back.

Yes, the module is kept in sync with the semaphore group members

Great :)

Would like to know what is the next step of the application? And what is the general timeline of when I hear back from the vetting committee if the application passes?

So we will take a look at the application and get back to you, and if there is anything else you need to do we will also let you know! Due to Devcon we are pretty busy right now, so there will be a delay getting back to you unfortunately. I'm not sure what this timeline would be but it would be sometime after Devcon week (11th-17th) - so towards the end of November.

[jimmychu0807]

Hi @JohnGuilding, would like to follow up on this proposal. Wonder if PSE team have a chance to look into the proposal? I am aware Thanksgiving and Christmas are coming up. Will highly appreciate if a more definitive progress can be made on the proposal evaluation before Christmas 🤞 Thank you!

[JohnGuilding]

Hey @jimmychu0807 thanks for your patience with this. Some feedback:

Next, MultiFactor validator will be integrated to work with Semaphore validator to make it behave as a M of N multisig wallet.

Can you explain a little bit more how the 1 of N validators would be used with the multifactor validator? I am thinking that you would need some mechanism to make sure the same identity commitment on validator A did not also approve via validator B. Thus not really making it M of N.

If each validator represented a single identity commitment, then that might be an option.

This module will be integrated via ModuleSDK to demonstrate the composibility of ERC-7579 modules.

Is this possible? Will Rhinestone accept PRs into module sdk for unaudited modules? Maybe there is another path in integrating this into Rhinestones tooling if so.

Both hardhat and foundry test will be written to cover 85% of the Solidity code for unit tests.

Small side note: I personally had an issue running forge coverage in a modulekit template repo before when I was building a module. If using modulekit, might be worth checking forge coverage works. Not a huge issue though can just manually review test coverage worst comes to worst.

[jimmychu0807]

Next, MultiFactor validator will be integrated to work with Semaphore validator to make it behave as a M of N multisig wallet.

Can you explain a little bit more how the 1 of N validators would be used with the multifactor validator? I am thinking that you would need some mechanism to make sure the same identity commitment on validator A did not also approve via validator B. Thus not really making it M of N.

I have a deeper look at the code of MultiFactor. The "factor" here is other validator that have registered successfully in an on-chain registry (validator that complies to ERC-7484 with a ValidatorID assigned). So actually now I think we don't need multi-factor validator to implement 1/N or M/N signatures/commitments functionality. We just need to store the valid commitments for the particular tx. Once we reach the required number of commitments, the tx is good to go.

I would wish to apply the semaphore validator to be a ERC-7484 compliance module, but it likely requires code audit on our side.

Is this possible? Will Rhinestone accept PRs into module sdk for unaudited modules? Maybe there is another path in integrating this into Rhinestones tooling if so.

I didn't mean to send a PR to their code repo, but using ModuleSDK framework to have Multi-factor validator and Semaphore validator work together in a smart account wallet. But now I realize/believe I don't need a multi-factor validator to make M/N multi-commitment in Semaphore validator to work.

But I can still try this setup with multi-factor validator, with say an Ownable validator, in a smart account.

[JohnGuilding]

So actually now I think we don't need multi-factor validator to implement 1/N or M/N signatures/commitments functionality. We just need to store the valid commitments for the particular tx. Once we reach the required number of commitments, the tx is good to go.

Right so using a single validator, where you store all the commitments for a semaphore group, with it's own threshold logic?

I didn't mean to send a PR to their code repo, but using ModuleSDK framework to have Multi-factor validator and Semaphore validator work together in a smart account wallet.

Got it makes sense

But I can still try this setup with multi-factor validator

I would say this isn't necessary if not using multifactor validator for semaphore group

[JohnGuilding]

One advantage of this setup compared to a normal multisig wallet is that signers' privacy is preserved. Because of the smart account interaction model, the original transaction initiator sends http/RPC requests to a bundler, and the bundler in turn sends the transaction on-chain with paymaster configured to pay for the tx fee. So we won't be able to trace who the original transaction initiator is.

The way this is worded makes it sound like the 4337 flow is what is providing privacy here for a normal multisig wallet. I would say it is the combination of semaphore + an entity (in this case the bundler) acting as a relayer. Could you tweak it slightly to account for this?

[jimmychu0807]

@JohnGuilding

Right so using a single validator, where you store all the commitments for a semaphore group, with it's own threshold logic?

Right, this is my thinking. Let me try this out in the coming weeks.

I have edited the proposal, added your suggestion and removed the reference to MultiFactor validator.

[JohnGuilding]

Thanks a lot @jimmychu0807, I'm happy with the content of this proposal. Will inform the acceleration program team on discord

[jimmychu0807]

Weekly Report - 2025-01-04

On milestone I:

1. The basic code structure is there. Key logic is on SemaphoreMSAValidator.validateUserOp() on validating the userOpHash matches with the signature signed by EDdsa signature on L#335-337. Once it pass the validation, the key logics happen on initiateTx(), signTx(), and finally executeTx().

2. Currently the EdDSA signature verification is done with a quick cheat using Foundry ffi calling external javascript semaphore-identity, which comes from my own Semaphore Identity package cli extension. Eventually this verification signature part need to be implemented in Solidity.

3. Basic test cases are implemented

   • to verify the Semaphore contract is deployed properly - test/Semaphore.t.sol
   • to test the validator module is installed in smart account properly - test_onInstall*
   • to test initiating a transaction by non-member and invalid signature do indeed being rejected test_initiateNativeTransfer*.

4. In test, Foundry ffi is being extensively calling semaphore-identity script. I figure it is okay to use external script in testing, and could be keep it that way.

Currently my goal is to get the good workflow to pass: able to get a transaction stores in the contract storage, aggregate the signature count, and finally get it executed. Then I will perform more error handling in the code and optimize the code style. Hopefully could get this done in coming 1-2 weeks.

Relevant code repo:

• https://github.com/jimmychu0807/semaphore-msa-validator
• https://github.com/jimmychu0807/semaphore/tree/identity-cli (mostly the packages/identity/src/cli.ts)