Remove sub() from gas() in SemaphoreVerifier.sol

[jimmychu0807]

There are lines in SemaphoreVerifier.sol that make gas() calls. GAS opcode is restricted in validateUserOp (along with some other OPCODES). GAS is only allowed if immediately followed by CALL (and similar) opcodes. Semaphore does staticcall(sub(gas(), ...) and there is a SUB in between.

So we need some other way to take the gas cost in consideration.

• related: Project Idea: Semaphore + Account Abstraction #345
• refer also to this blog post (other challenges section):
  https://saleel.xyz/blog/zk-account-abstraction/

[jimmychu0807]

@cedoor this is the issue related to #345.

[cedoor]

@jimmychu0807 thanks 👍🏽

[jimmychu0807]

@saleel currently what is the simplest way to setup a test environment to trigger the issue that validateUserOp() calls SemaphoreVerifier.sol and fails due to having a sub call before gas call (without moving heaven and earth 🙂)?

If this can't be done, I can't reliably know that I have solved this issue.

Does this mean I should get back to setting up the smart-account-module?

[saleel]

Yea, you would need to run the bundler and try to do a userOp with semaphore proof as the verifier. Basically, get the tests in https://github.com/saleel/semaphore-wallet pass with the original Semaphore contract (currently it uses the custom ones I have over there)

[jimmychu0807]

@cedoor replying to your #345 (comment)

To fix this issue, I want to be able to reproduce the error by running the test cases in https://github.com/saleel/semaphore-wallet . But the bundler component needed in the e2e test has updated since then and I have a hard time making all components connect together to trigger the error.

The opcode restriction is outlined at [OP-012]: https://eips.ethereum.org/EIPS/eip-7562#opcode-rules

An alternative is just that I make line from:

success := staticcall(sub(gas(), 2000), 7, mIn, 96, mIn, 64)

to

success := staticcall(gas(), 7, mIn, 96, mIn, 64)

will that cause any security implication?

[thogiti]

@jimmychu0807 @cedoor

Let me add some comments and explain.

Here, sub(gas(), 2000) ensures that 2000 gas units are reserved for the remaining execution after the staticcall. This is a common practice to prevent the called function from consuming all available gas, which could potentially leave insufficient gas for subsequent operations.

In the proposed change, success := staticcall(gas(), 7, mIn, 96, mIn, 64), the staticcall will have access to all remaining gas, potentially consuming the entire gas stipend allocated for the transaction.

Typically, reserving gas helps prevent/reduce reentrancy attacks by ensuring that certain operations can always complete. However, in this specific context:

• The staticcall targets precompiled contracts (addresses 6 and 7), which are trusted and do not contain reentrant logic (as far I can see).
• And, static calls do not allow state modifications, further reducing the risk of reentrancy.
• The functions following the staticcall in this context are minimal and primarily involve memory operations and checks. In most cases, they do not require substantial gas.

I suggest to proceed with the change. Replacing sub(gas(), 2000) with gas() is unlikely to introduce security vulnerabilities in the current context.

However, if future modifications introduce more gas-intensive operations after the staticcall, not reserving gas could lead to unexpected failures.

Few more additional points:

• monitor the gas consumption of the verifyProof function after making this change
• test the modified function with various inputs and gas limits to ensure it behaves correctly under different conditions

[jimmychu0807]

@thogiti thank you for the explanation! With your comment, I take a deeper in the code. And I agree with what you said.

• L#575: this is calling ethereum precompile at address 0x7, elliptic curve scalar multiplication. Yes, it is a pure/view function.

• L#585: This is elliptic curve point addition.

• L#665: This is doing a ecc point pairing, and is pretty much at the end of the function.

Let me make the change and check the difference in gas usage. Thank again for the helpful input!