or
or
By clicking below, you agree to our terms of service.
New to HackMD? Sign up
Syntax | Example | Reference | |
---|---|---|---|
# Header | Header | 基本排版 | |
- Unordered List |
|
||
1. Ordered List |
|
||
- [ ] Todo List |
|
||
> Blockquote | Blockquote |
||
**Bold font** | Bold font | ||
*Italics font* | Italics font | ||
~~Strikethrough~~ | |||
19^th^ | 19th | ||
H~2~O | H2O | ||
++Inserted text++ | Inserted text | ||
==Marked text== | Marked text | ||
[link text](https:// "title") | Link | ||
 | Image | ||
`Code` | Code |
在筆記中貼入程式碼 | |
```javascript var i = 0; ``` |
|
||
:smile: | ![]() |
Emoji list | |
{%youtube youtube_id %} | Externals | ||
$L^aT_eX$ | LaTeX | ||
:::info This is a alert area. ::: |
This is a alert area. |
On a scale of 0-10, how likely is it that you would recommend HackMD to your friends, family or business associates?
Please give us some advice and help us improve HackMD.
Do you want to remove this version name and description?
Syncing
xxxxxxxxxx
Grant Proposal: Semaphore Paymaster
Thanks to John Guilding, Jake C-T, Yanis Meziane and Giacomo Corrias for review this proposal.
Project Overview
This project provides a toolkit for web3 developers looking to create dapps that offer a seamless, gasless experience for their users by leveraging their Semaphore group membership—without the hassle of spending excessive time integrating Semaphore and ERC-4337 themselves.
Problem Statement
The decentralized nature of Ethereum is powerful, but it also presents well-known fundamental challenges: onchain activities are not privacy-preserving, and every transaction incurs a gas fee. Various efforts have been made to address these issues. Semaphore is a widely used tool that allows group members to send anonymous signals, while ERC-4337 enables gasless transactions for users.
Although both tools are powerful, integrating them together into a single dapp is particularly challenging. Developers must navigate the complexities of combining these two technologies, which can be time-consuming and require deep technical expertise. This often leads to delays in development and increased costs.
Proposed Solution
To address these challenges, our project aims to provide open-source tools and modular components, including a Semaphore paymaster and frontend elements, specifically designed for building Account Abstraction applications. Our goal is to simplify the integration process, enabling developers to focus on building innovative features rather than getting bogged down by technical hurdles. This toolkit offers a robust and easily integrable base template for developers.
Key Features and Innovation
Paymaster is an extension of the ERC-4337 entry point logic. This feature allows application developers to subsidize fees for their users, enable users to pay fees with ERC-20 tokens, and support various other use cases. Consolidated with Paymaster, ERC-4337 significantly improves the user experience by freeing users from the need to understand and manage gas fees. If the QF Round in Ethcon Korea 2023 had utilized this approach, it likely would not have suffered from the low participation rate. However, it doesn't come without a trade-off: a lack of privacy.
With this proposal, we introduce a paymaster leveraging Semaphore (aka. Semaphore Paymaster). The Semaphore paymaster subsidizes transactions for users who can prove their membership in a Semaphore group. This combination allows for privacy-preserving, gasless transactions, addressing both of the major challenges developers face today.
Use Case and Demonstration
We will demonstrate the use of these tools through a concrete use case that combines the Semaphore paymaster and MACI. This application enables users to prove their identity and vote anonymously, with their gas fees sponsored by the Semaphore paymaster. Our commitment to this goal is reflected in the prototype we delivered at the PSE Hackerhouse during EthCC 2024.
Looking ahead, our timeline includes running an anonymous and gasless voting process for hackathon projects at Ethereum Costa Rica in October. This event will showcase the practical implementation and benefits of our tools in a real-world scenario
Project Details
Core Modules
Semaphore Paymaster
Future Work
Integrate the gatekeeper with other identity verification applications such as Hats Protocol, Gitcoin Passport, or Zupass. These extensions are expected to require minimal effort for off-chain components, owing to the unified interface provided by Excubiae.
Team
Team Members
Team's Experience
Our team consists of experienced blockchain developers with a strong background in Ethereum smart contracts and privacy protocols. We have previously developed and contributed to several open-source projects, including the Semaphore protocol, ZkEmail and various Account Abstraction applications. Our expertise aligns well with the project's objectives, ensuring we have the necessary skills to successfully implement and deliver the Semaphore + Paymaster integration.
Development Roadmap
Milestone 1: Simple Semaphore Paymaster Smart Contract + An Optimization for Executing Batch User Operations.
Estimated Duration: 2 weeks
Full-time equivalent (FTE): 2
Costs:
jihoonsong: $2,400
brolag: $4,800
Total amount: $7,200
We aim to deliver two Semaphore Paymasters:
SimpleSemaphorePaymaster
: This paymaster will sponsor gas for semaphore group members without imposing any limitations on how much gas members can consume.GasLimitedSemaphorePaymaster
: This version will impose a periodic gas limit on how much gas members can consume.In this milestone, we will be designing and implementing the
SimpleSemaphorePaymaster
.Specification and High-Level Design:
At its core, the
SimpleSemaphorePaymaster
has two main components:ERC-4337
Compatible Paymaster contractEssentially, the
Paymaster
contract will depend on aSemaphore
contract to verifySemaphore
membership proofs.Paymaster
Each
Paymaster
will depend on oneSemaphore
group. To this end, thePaymaster
contract will be passed theSemaphore
contract address and aGroupId
. It will sponsor transactions that have a valid membership proof of the predefinedGroupId
.Membership Proof
A typical
Semaphore
membership proof is like this:And we need to have access to the above proof from within the paymaster to be able to verify the membership. For this we ABI encode the
SemaphoreProof
struct and embed it in thePaymasterData
field of theUserOperation
.In the
validatePaymasterUserOp
we decode the attached proof, send it to theSemaphore
contract to make sure the proof is valid. Once the verification passes, thePaymaster
will pay for theUserOperation
. Since theSimpleSemaphorePaymaster
does not impose any sort of limitation, this is the only check that happens.Optimization
In case one wants to use the same AA wallet to execute multiple
UserOperations
, we can verify the membership proof once and store the result to avoid verifying expensive zk proofs each time the user wants to execute aUserOperation
. This can be implemented in various ways:isMember
and will be used in thevalidatePaymasterUserOp
method:UserOperation
of the user. In thepostOp
phase of the paymaster, we can callsetIsMember
automatically, so the user won't need to provide membership proof again.The downside of these methods is that once the user is no longer part of the Semaphore group, there needs to be a mechanism to invalidate the
isMember
flag. This can be implemented by having a fixed expiry date for the flag.Considerations
UserOperation
in themessage
field of theSemaphoreProof
.message
, however to prevent any other issues with reusing a proof more than once, we will return the proofnullifier
in thecontext
field ofvalidatePaymasterUserOp
so that we can mark it as used in thePostOp
phase of thePaymaster
.*In summery we will deliver the following:
SimpleSemaphorePaymaster
ERC-4337
compatible paymaster with described functionality that pays forSemaphore
group members without any limitationsBatchOptimizedSemaphorePaymaster
SimpleSemaphorePaymaster
without proving proofs for eachUesrOperation
SimpleSemaphorePaymaster
Milestone 2: Gas Limited Semaphore Paymaster
Estimated Duration: 2 weeks
Full-time equivalent (FTE): 2
Costs:
jihoonsong: $2,400
brolag: $4,800
Total amount: $7,200
Overview
In this milestone, we aim to implement the gas-limited
Paymaster
that imposes a predefined periodic gas limitation on requests. For example, the period could be one week, and the gas limit could be one million. This means that each member can executeUserOperations
that consume at most one million gas each week. This limit will reset back to one million each week.This implementation will be a continuation of the
SimpleSemaphorePaymaster
, and therefore it will have all the mentioned properties of theSimpleSemaphorePaymaster
. Additionally, it receives the following extra parameters when instantiating theGasLimitedSemaphorePaymaster
:periodDuration
: Defines the gas limit reset period in seconds.startTimestamp
: Timestamp of the start of the first period.gasLimit
: Maximum cumulative gas that can be consumed by each member during each period.Note: All the above parameters are set once during the construction of the contract and will remain immutable.
Proof
Scope
In order to enable and enforce periodic gas limits, we need to make use of the
scope
field inSemaphoreProof
.As a reminder, the
nullifier
is the hash of the user's private key andscope
. This means that if the user uses the samescope
to generate proofs, it will result in the samenullifier
each time.The
nullifier
is usually marked asused
orinvalid
after the first time the proof is used to prevent double signaling.In our use case, the
scope
that the user must use to generate the proof is determined by theGasLimitedSemaphorePaymaster
contract, which will be the active period:This way, all the proofs that a user generates during each period will have the same
nullifier
. We can use this to track the gas consumption of the user and only mark thenullifier
asused
once the gas limit is reached.PRIVACY NOTICE: This means that all the transactions of a user are linked together during each period through the
nullifier
. However, it is still disconnected from the original identity of the user.Putting it all together
The client reads (or calculates) the correct
scope
and generates a proof as before, attaching it to thePaymasterData
. On thePaymaster
side, not only is the proof verified, but thescope
is also checked to ensure it corresponds to the active period. Moreover, thePaymaster
checks if the already consumed gas by the user, plus the gas that the currentuserOperation
is going to use, is still below the period gas limit. If the check passes, theuserOperation
will be sponsored; otherwise, it will be rejected.In the
PostOp
phase of thePaymaster
, the actual gas consumed by theuserOperation
is added to the total gas consumed in the active period for the user (identified by thenullifier
). If the total consumed gas goes above the limit, thenullifier
will be marked asused
and cannot be used anymore until the next period.In summary this milestone delivers the following:
GasLimitedSemaphorePaymaster
ERC-4337
compatible paymaster with described functionality that enforces a periodic gas limitGasLimitedSemaphorePaymaster
Milestone 3: Gatekeeper Inheriting Excubiae and End-to-end test
Estimated Duration: 2 weeks
Full-time equivalent (FTE): 2
Costs:
jihoonsong: $2,400
brolag: $4,800
Total amount: $7,200
Overview
We need a gatekeeper that permits a user with a verified identity to join a Semaphore group. The gatekeeper will be inheriting Excubiae, with the aim of facilitating seamless extension to incorporate other identity verification applications such as Hats Protocol, Gitcoin Passport, or Zupass.
Having end-to-end testing with the gatekeeper and Semaphore paymaster will help us build a more robust system. Furthermore, the end-to-end testing environment can serve as a valuable example for other projects looking to construct their own end-to-end testing environments.
UserOp
that transfer some ETH with gas sponsored bySimpleSemaphorePaymaster
Milestone 4: Gasless Voting Process and Frontend Optimization
Estimated Duration: 3 weeks
Full-time equivalent (FTE): 2.5
Costs:
jihoonsong: $2,800
brolag: $5,600
Total amount: $8,400
Overview
This milestone encompasses the implementation of a gasless voting process for hackathon projects at Ethereum Costa Rica and the optimization of the frontend codebase. Our goal is to provide a seamless, user-friendly voting experience while ensuring the frontend code is maintainable, modular, and scalable. This preparation is crucial for delivering a polished application at the event.
Gasless Voting Process
To support a gasless voting process, all hackathon participants will be whitelisted and can use their verified identities to sign up for a Semaphore group. Additionally, we will implement a frontend-based mechanism to verify if an address is part of the whitelist through a signed message. The process is as follows:
Frontend Optimization
In parallel, we will focus on cleaning up and optimizing the frontend code to ensure it aligns with best practices and is ready for scale.