Project Idea: Semaphore + Account Abstraction

[aguzmant103]

No description provided.

[FoodChain1028]

Hi @aguzmant103, is there any detail about this project? I would love to build something with this.

[moven0831]

Hi @FoodChain1028, I've got some ideas about applying Semaphore on AA's wallet recovery. Since a contract-based wallet owner can assign multiple addresses as wallet guardians. We can use Semaphore to register the guardians instead of directly listing them on the smart contract. This alternation can provide privacy if the guardian's address needs to be hidden under some scenarios.

[FoodChain1028]

Hi @FoodChain1028, I've got some ideas about applying Semaphore on AA's wallet recovery. Since a contract-based wallet owner can assign multiple addresses as wallet guardians. We can use Semaphore to register the guardians instead of directly listing them on the smart contract. This alternation can provide privacy if the guardian's address needs to be hidden under some scenarios.

Hi, @moven0831. This idea looks good, yet for now we have to interact the contract-based wallet with another Externally Owned Address; thus the relationship between this address and proof in revealed as a result. A method from me to fix this is using a relayer address for everyone wants to use this service, the user would send their fee (like a transferring fee and everyone need to send the same amount of money here) and proof to the relayer and relayer would do this for the users. To be more specifically, the relayer is more like a mixer box to:

1. verify the identity in the Merkle Tree (As the owner of this AA contract).
2. mix the address to make any proof - user EOA - AA contract unrelated, and thus would preserve the privacy.

[cedoor]

Hey guys, this could also be useful -> https://github.com/saleel/aa-zk-test

Author: @saleel

[saleel]

Thanks for the tag @cedoor. It was an experiment I did a while back, and need to make some changes in that code to make it work correctly.
I am also in the process of doing a write-up on explaining the whole stuff. Planning to do both in the coming weekend.

[FoodChain1028]

Hi, @saleel, is there any chance or anything I can help you with?

[saleel]

I wrote about it here - https://saleel.xyz/blog/zk-account-abstraction/
Here is the repo with sample code - https://github.com/saleel/semaphore-wallet

@FoodChain1028 Above is a reference implementation. There are some minor changes needed in semaphore (mentioned in the blog towards the end) before we can implement a production level semaphore wallet. But feel free to use the code as you wish, and I would be happy to help if you have any questions.

[jimmychu0807]

Hi @cedoor @saleel

I am PSE Core Taiwan fellow. I read through the issue and want to check:

• is this issue still relevant today, or is it just not closed?
• With Add a function to verify proof without storing any nullifier #329 resolved, do you see other major blockers that prevent driving this issue to completion?
• if you still welcome contribution on this issue, may I pick this up and provide guidance/feedback along the way?

Thank you.

[saleel]

I think we still need to:

• remove sub() from gas() calls like here
• Vkey points needs to be constants Change verification key points in contract to constant #330

Both should be doable (though second one might be tricky as Solidity doesn't support array constants). I will check them again by next week and see if we can update.

[cedoor]

Thanks @saleel for listing the missing tasks!

if you still welcome contribution on this issue, may I pick this up and provide guidance/feedback along the way?

@jimmychu0807 of course, I'll assign this issue to you!

[jimmychu0807]

@saleel as seen on the above screenshot, top right (TR) is the geth run with the docker command listed in the bundler repo. top left (TL) is the bundler run with yarn run bundler. Seems I have successfully run it.

Now, in BL, I run yarn run runop --deployFactory --network http://localhost:8545/ --entryPoint 0x0000000071727De22E5E9d8BAf0edAc6f37da032 (shown here) all the executions are reverted (shown in TR). I suspect it is not supposed to be like that, right?

Then when I run yarn test in semaphore wallet (BR), it is running the e2e test as you mentioned in the doc, deploying a few contracts, but failing at the "before all" hook saying cannot estimate gas.

I suspect they all come from the same source. Is there some Geth setting I need to update to run these account abstraction tests?

Thanks.

Update 2024-10-01 05:20 UTC

On running semaphore wallet yarn test, I found that running with hardhat node get different result from Geth node. On Geth node, it fails in the semaphoreContract.addMembers() line in the before hook. In hardhat node, there is a better luck and run further till factoryContract.addStake(). Now I will use hardhat node to further run the test, but at some point need to learn how to run Geth node with right configuration.

---

Another newbie question:

WARN [10-01|03:38:08.080] Served eth_call
conn=192.168.65.1:40046 reqid=102 duration="992.375µs" err="execution reverted"
errdata="\"0x11e6f5a00000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000109ad9ce884bc7289b35959d0eca1049b52a7aba99785c080ba921af8689db37a\""

Given the Geth dev node returns the above message, how can I trace back from which smart contract and which function is it reverted from? I have an impression there is a way to trace it from the first 4 - 6 bytes. Thanks again

---

p.s. I don't mind continue the trouble-shooting conversation in this issue thread, but if any of you want to move this discussion somewhere, let me know where is the best place to discuss this. I expect there will be more of it.

[jimmychu0807]

@cedoor @saleel

The past few days I started picking up on this issue. I read thru EIP-4337, read account abstraction contract code, try running bundler, and also EIP-6900.

A classmate in the core program, @quanxi1, suggests implementing Semaphore wallet in ERC-6900 way (his deck).

As I believe modular smart contract account (MSCA) is going to be more widely accepted, and the plugin system is indeed a very neat way to integrate "Semaphore" component into any smart contract accounts, I am now gearing toward more on adding the Semaphore capability by writing a MSCA plugin module. This plugin will have the LMTs stored inside its storage, so there will be no problem in reading storage.

I will investigate more to tackle this issue from this angle, but would love to hear from you two what you think about this approach.

@quanxi1 feel free to add any insight, and I will also work with you on this.

Thanks.

But I first need to get saleel Semaphore wallet tests run first :)

[saleel]

@jimmychu0807 Thank you for picking this up. If I remember correctly it used to work with both geth and hardhat. For the full e2e test, you need to run the bundler and use the modified Semaphore contracts inside that repo (should be configured that way already).
That "cannot estimate gas" happens when the contract call would be reverted if its ran. Maybe you can parse the hex return error data here (remove the 0x)

suggests implementing Semaphore wallet in ERC-6900
This plugin will have the LMTs stored inside its storage, so there will be no problem in reading storage.

Yea, that would be great. Also consider ERC-7579.

[cedoor]

I don't mind continue the trouble-shooting conversation in this issue thread, but if any of you want to move this discussion somewhere, let me know where is the best place to discuss this. I expect there will be more of it.

I think we can keep it here for now 👍🏽

[jimmychu0807]

Just want to report back on current status (2024-10-08)

• I am still running Semaphore wallet e2e test. Have not run it successfully yet, but progress has been made, and I am tracing code between semaphore wallet and the Bundler RunOp interaction.
• Updated Semaphore wallet to use Semaphore v4, ethers.js v6, @account-abstraction/contracts v0.7, and @account-abstraction/utils latest on this branch.

[jimmychu0807]

@saleel if you have time, I have a favor to ask you. Referring to the Bundler README, could you run on the master branch of Bundler and get to the point to have the simple test below to pass, using Geth dev node?

yarn run runop --deployFactory --network http://localhost:8545/ --entryPoint 0x0000000071727De22E5E9d8BAf0edAc6f37da032

I couldn't, and I am checking with Infinitism team.

Below are the command output and output of geth node (which have executions reverted).

Bundler output:

runOp output:

Geth dev node output:

[saleel]

Did you try to parse the errdata? If its a string message you can decode here

I also see a low balance message in some of your logs..maybe that is the reason?

I tried running the bundler now and faced some issues; looks like there is a missing dependency when deploying contacts (some npm package doesnt have the dist published)..dont have much time to debug; good that you are checking with them. Let me know if you face issues even after setting up geth and bunder with basic tests.

[jimmychu0807]

There are two repeated errdata above:

• errdata="\"0x091cd005a1b9a8ceb62b7ff0190c72c8327ef30713996459410bfc7faf5ef0dd20ce69b6\""
• errdata="\"0x11e6f5a000000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000001c3f67297df3eb3f12a7d33473e90f58885d044b8dd0c12f44d2b7f2fe83aa9fb\""

The first one seems like a string but not parsable using your tool and onlinestringtools, returning me some symbol and error messages.

The second one seems to start with a function selector 0x11e6f5a0. That's all I can tell.

[jimmychu0807]

Current status (2024-10-15)

• Can set up a local environment for running ERC 4337 acct, following Pimlico mock-aa-env example, here.
• Integrate ERC-7579 compatible smart account to setup the dev env here.
• Understand the difference between ERC-6900 and ERC-7579, with its trade-off and the difference in design principle. Start by following Zerodev article, Alchemy response, and Zerodev response to the response.
• I then realized I should probably start with Rhinestone ModuleKit to simplify the setup of the env and I can focus on the smart account module development.

Yes there are some detours taken in the past week, but this is a good research for me and hopefully I will get more done in the coming week.

[cedoor]

@jimmychu0807 thanks for the updates 🙏🏽 Looks like we need to prioritize the following issues mentioned by Saleel:

remove sub() from gas() calls like here
Vkey points needs to be constants #330

Which seem to be a blocker for another AA <> Semaphore grant. Are you planning to work on them? Other community devs might also work on it.

[jimmychu0807]

@cedoor alright, I will work on these two (sub-) issues first then.

1. remove sub() from gas() calls like here
2. Vkey points needs to be constants Change verification key points in contract to constant #330

[cedoor]

Thanks @jimmychu0807, can you create an issue for the first one? I'll assign the second one to you, please add a comment there.

[JohnGuilding]

Hey @jimmychu0807, John here from the ZK Email team at PSE. I have some familiarity building smart account modules as we built our recovery module as an ERC7579 executor. I'm also evaluating the prospective AA <> Semaphore grant @cedoor mentioned.

Just trying to get my head around the approach of integrating Semaphore into a module. Can you explain what the use-case would be? Would this be a recovery module? Would it just be an easy, generic way to use Semaphore for smart accounts? Something else?

[jimmychu0807]

Hi @JohnGuilding, thank you for checking. cedoor did point out to me there is a grant proposal of Semaphore Paymaster. This module I want to build is to focus on having Semaphore group members able to sign a transaction of the smart wallet.

In fact, this idea has been explored by Saleel, and is documented in his blogpost. But it was built at a time when the tool stack was still primitive. I aim to formalize this so it becomes an ERC-7579 compatible module and smart account owners can easily install it. Saleel also pointed out two challenges he saw in current implementation (other challenge section of the blogpost) that restrict Semaphore from directly being used in smart account. They will be solved along the way (one is solved already with #875).

There are also two issues I want to investigate first before formalizing my thought into a grant proposal:

1. Investigate if the semaphore proof/nullifier output can somehow be used by Safe multi-sig module. If this is true, then this can become a semaphore multi-sig wallet. Otherwise it is a 1/N wallet, with N being the number Semaphore group members.

2. If the above is true, and because a smart account signer is sending a HTTP request to the bundler, and the bundler in turn sends the transaction on-chain with paymaster configured to pay for the tx fee. Does this mean we can build a privacy-preserving multi-sig wallet? Privacy-preserving here means the wallet signer address(es) are not exposed out (this is not the case for Safe wallet now and we can use getOwners() to retrieve the wallet signers) because they are replaced by Semaphore group-generated public key.

I am currently investigating them, but will be glad to hear your thought about this direction, and any potential roadblocks you see I will encounter.

Thanks.

[JohnGuilding]

Hey @jimmychu0807 thanks for the additional context.

This module I want to build is to focus on having Semaphore group members able to sign a transaction of the smart wallet.

So would this be like a Semaphore validator where anyone in the semaphore group can sign a userOp for a particular account?

Investigate if the semaphore proof/nullifier output can somehow be used by Safe multi-sig module. If this is true, then this can become a semaphore multi-sig wallet. Otherwise it is a 1/N wallet, with N being the number Semaphore group members.

A semaphore multisig would be cool. For making Safe's compatible with non-ecdsa signers, If you haven't already, I would recommend looking into contract signers via ERC1271. Basically you can add a solidity contract as a signer on a Safe https://docs.safe.global/advanced/smart-account-signatures#contract-signature-eip-1271. Each contract signer would equal 1 signer on the Safe, so you wouldn't use a single contract signer for the whole sempahore group. For an M out of N multisig, you could add each Semaphore member as a contract signer on a Safe. Each Semaphore contract signer could call the verifier, and storing the identity commitment would associate the signer with a specific group member. The scope could be the tx hash or similar.

From my understanding of Safe's, you would need a different owner for each group member to make it M of N, as that's how Safe's count signatures meet the threshold. Maybe you could have a single contract signer that then linked to some separate semaphore multisig logic? So 1 of N Safe but that 1 signer is based on meeting a threshold from semaphore group members. I'm not certain of this idea though without looking into it further. It certainly wouldn't be the native Safe way of doing signers.

One issue with using a Semaphore group like this with a Safe is how do you keep the Safe synced with the Semaphore group. For example, if you removed a signer on the Safe, would you want to remove that member from the semaphore group? And if you removed a semaphore member from a group, you would probably want to remove the equivalent safe owner.

In terms of making this a "Safe multi-sig module" as you described, I'm not sure what that means here. Would this be using safe7579 https://github.com/rhinestonewtf/safe7579? For an analogous way of doing things with a 7579 module, the MultiFactor validator might be useful to look into https://github.com/rhinestonewtf/core-modules/blob/main/src/MultiFactor/MultiFactor.sol

If the above is true, and because a smart account signer is sending a HTTP request to the bundler, and the bundler in turn sends the transaction on-chain with paymaster configured to pay for the tx fee. Does this mean we can build a privacy-preserving multi-sig wallet? Privacy-preserving here means the wallet signer address(es) are not exposed out (this is not the case for Safe wallet now and we can use getOwners() to retrieve the wallet signers) because they are replaced by Semaphore group-generated public key.

I'm not super knowledgable about Semaphore, but I believe in principle you could use Semaphore for a privacy-preserving multisig. @cedoor would you agree here?

[cedoor]

I'm not super knowledgable about Semaphore, but I believe in principle you could use Semaphore for a privacy-preserving multisig. @cedoor would you agree here?

I agree Semaphore can be used for that in principle, but not 100% sure how the Safe multi-sig module works. If the bundler doesn't need any signer addresses but just a Semaphore proof in a HTTP request, then it should be fine!

@jimmychu0807 Regarding the following two issues:

• Change verification key points in contract to constant #330
• Remove sub() from gas() in SemaphoreVerifier.sol #871

The first is done 🙏🏽 Do you still have any blockers for the second one?

[jimmychu0807]

@cedoor getting back to you at #871 (comment)

[jimmychu0807]

@JohnGuilding

So would this be like a Semaphore validator where anyone in the semaphore group can sign a userOp for a particular account?

Yes, it is a Semaphore validator where anyone in the group can sign.

What you mentioned below are indeed issues that I didn't foresee before, i.e there are now contract signers in the Semaphore group, and then synchronizing between the Semaphore group and the Safe signer set, etc. Actually this sounds like an exciting project/research direction.

But for now, it is better for me to be less ambitious and just integrate Semaphore as a ERC7579 validator module so when a user install this module into their smart account, a new Semaphore group is created. The user becomes the admin of the group and he can add more members into the Sempahore group. Any members in the group will be able to sign and send tx on the smart account. This is like a 1 of N mult-sig wallet. This also lay the foundation to ensure Semaphore and related contracts abide to account abstraction validation scope rules (#871).

In the grant proposal, I target to deliver the following:

1. A ERC7579 validator module with Semaphore.
2. The module satisfies the requirements to be listed in moduleRegistry
3. There are end-to-end test code of installing the module, running tests, and uninstalling the module from a smart account.
4. Document the code.
5. A front-end demo that allow users to install this module to their smart accounts on testnet, add users (identity commitments) to the semaphore group, and sign txs.
6. Publish a blogpost to introduce what has been done and give a technical overview of the module.

Will this be a good scope for a grant proposal?

[jimmychu0807]

@JohnGuilding @cedoor
I have made a draft Accelerator Program proposal based on the template. If it looks okay to you, what is the appropriate way to submit this proposal for evaluation? Thanks.

[JohnGuilding]

@jimmychu0807 thanks for the grant proposal. We'll take a look and get back to you :)

[jimmychu0807]

@JohnGuilding would like to follow up with you about what is the next step of the accelerator program proposal. Where should I submit the proposal? Thanks.

[JohnGuilding]

Hey @jimmychu0807, thanks for putting together the proposal.

Myself and @cedoor have spoken about the proposal, and we'd like to suggest changing it. This is for two reasons:

1. The 1 of N design does not seem like the most useful to us. We would like to explore something a bit broader such as an M of N design.
2. We have an existing AA <> Semaphore grant that is starting soon, so want to make sure both grants are sufficiently impactful enough to justify two related grants at the same time.

A really cool idea IMO would be a semaphore multisig which you could configure to be M of N. I know you said this would be more ambitious than you wanted to start off with, but this is an example of something that we would be more onboard with. This isn't to say this is what you have to propose.

Let us know if you have any questions about this :)

[jimmychu0807]

@JohnGuilding I see. Will it sounds better if I break the milestones as follow then:

1. 1 wk: integrate Semaphore in a ERC7579 module validator (the basic 1 of N signing). Work consists mostly on writing contract and test cases.
2. 2-3 wks: explore integrating Semaphore with Safe wallet (M of N signing). Work consists mostly on writing contract and test cases. (I'm not sure the exact time needed yet)
3. 2 wks: building the front-end demo. Work consists mostly on frontend dev and deployment workflow.

If yes, I can update the proposal accordingly.

[jimmychu0807]

Actually, further thinking about it, as the biggest uncertainty is on milestone two, how about we structure the milestones as follow:

1. 1 wk: integrate Semaphore in a ERC7579 module validator (the basic 1 of N signing). Work consists mostly on writing contract and test cases.

2a. explore integrating Semaphore with Safe wallet (M of N signing), but realized it isn't feasible. A writeup will be written with accompanied code/artifact attempted for the integration.

2b. explore integrating Semaphore with Safe wallet (M of N signing), and is able to complete it. (We could assume the time taken to complete 2b > 2a).

3. 2 wks: building the front-end demo. Work consists mostly on frontend dev and deployment workflow.

I will then deliver either 1+2a+3 proposing for grant amount $X, or 1+2b+3 proposing for grant amount $Y. I will be touch basing with you during the milestone 2 so you know if I am facing any roadblock and we can figure them out together. With this structure I am also more incline to deliver 2b, which is what you prefer.

@JohnGuilding what do you think?

[JohnGuilding]

Hey @jimmychu0807,

Yeah I like the addition of 2a and 2b. And I think this is a more appealing grant proposal.

Some other things to consider:

• I think the question of how do you keep a Safe synced with the Semaphore group is one of the more important issues to figure out. So make sure you dedicate enough time to this. Doesn't need to be it's own milestone or anything.
• If it makes sense, I would also consider if it is simple to make the 7579 module M of N. Possibly this would include reusing the logic you build for the Safe. A simple way to do this would be to use the MultiFactor validator which already handles the threshold logic
• Although the most impactful result would be an M of N Semaphore 7579 validator and a M of N Semaphore-based Safe. I'm wondering if this would be too much scope. Another option could be to choose one or the other and just focus the grant on that. E.g. just an M of N Semaphore validator or just a Semaphore Safe. Another option is to integrate a M of N validator into a Safe via Safe7579.

I will be touch basing with you during the milestone 2 so you know if I am facing any roadblock and we can figure them out together.

This is sounds good to me

In terms of applying for this grant, I think you just need to fill out the template mentioned here and submit the application as a github issue. I'm just double checking this though

[jimmychu0807]

Thanks for the suggestion @JohnGuilding. With MultiFactor validator, indeed it looks very feasible of making the Semaphore validator M of N.

I am also very interested in making this work with Safe via Safe7579. Let me make a grant proposal on Semaphore with MultiFactor validator, and I will also explore about the integration of that with Safe7579 along the way, but leaving it outside of the proposal scope for now.

Proposal submitted here: privacy-scaling-explorations/acceleration-program#72