[Semaphore Integration] Issue 4: Finalize Semaphore Verifier Contract Implementation

[evgongora]

The Semaphore verifier contract for Soroban requires zk-SNARK proof verification using BLS12-381 pairing-based cryptography. With the introduction of CAP-0059, Soroban now provides native host functions for efficient operations on BLS12-381, enabling seamless integration of zk-SNARK verification logic.

bls12_381_multi_pairing_check: Performs pairing checks between G1 and G2 points to verify zk-SNARK proofs efficiently.
bls12_381_g1_add: Adds G1 points, which is used in aggregating cryptographic data during proof validation.
bls12_381_g1_mul: Multiplies a G1 point by a scalar to compute necessary cryptographic transformations.
bls12_381_hash_to_g1: Hashes user inputs or commitments to G1 points, enabling secure proof verification.

References:
https://github.com/stellar/stellar-protocol/blob/master/core/cap-0059.md
https://github.com/semaphore-protocol/semaphore/blob/main/packages/contracts/contracts/base/SemaphoreVerifier.sol
https://github.com/semaphore-protocol/semaphore/blob/main/packages/contracts/contracts/interfaces/ISemaphoreVerifier.sol

[Bosun-Josh121]

I am applying to this issue via OnlyDust platform.

My background and how it can be leveraged

software engineering background, backend & smart contract dev who have contributed to similar projects(https://app.onlydust.com/u/Josh-121) looking to make first contribution on this project

How I plan on tackling this issue
Perform the necessary migrations and be sure to work on feedback & recommendations. Can deliver with a day upon assignment

[MPSxDev]

I have experience with contract verifiers, it would be a pleasure to contribute to this issue. I'm from Dojo Coding

[ChrisFernandezVivas]

hi, im from dojo coding, I can migrate this , I don't know about soroban language , but I can learn , thanks

[Dprof-in-tech]

I'm Dprof-in-tech, a fullstack blockchain dev and i wuldlove to work on this issue. The ODHack is an opportunity for me to learn while solving real world issues and i would love to contribute to this project. Thank you

[mimisavage]

Could I try solving this?

[ShantelPeters]

Let me try this one!

[gethsun1]

May I handle this issue?

[martinvibes]

hey sir I'd like to handle this task.
i'm a frontend developer and a blockchain dev
i would really love to contribute to your project
please kindly assign :)

[Jemiiah]

Hello @evgongora Pls I would love the opportunity to work and learn doing this issue and contribute to the repository

[KoxyG]

Hi, I'm Koxy, a blockchain developer with Rust and Solidity experience. Here's my proposed approach for implementing the Semaphore verifier:

My Implementation Strategy is:

• Port the Semaphore verifier from Solidity to Rust, adapting it for Soroban
• Utilize CAP-0059's native BLS12-381 host functions for optimal performance
• Implement the core verification logic with Soroban's pairing operations

I can start immediately and will maintain regular communication throughout the development process.

[blessingbytes]

pls, i would love to tackle this issue.

[kfastov]

Hey, I am Konstantin, also a blockchain developer with experience in Rust and Solidity. I am just starting with Stellar ecosystem and want to try this one if it's available.
I worked with a project that used Semaphore in the past.
I would evaluate the work already done, figure out missing parts, then finish the contract using Solidity code as a reference, adapting it to Soroban, and then cover it with tests.
I will submit a draft PR in 24 hours and will always maintain communication

[Kaminar-i]

I'd be happy to do this.
kindly assign

[evgongora]

@kfastov Assigned! Let me know if you have any questions.

[kfastov]

Hi, @evgongora !
I've conducted some research and encountered a few challenges, so I’d like to get your advice.

1) Compatibility Issue:

The main challenge is that Stellar (with protocol version 22) only supports operations on the BLS12-381 curve. This is different from BN254 (or alt_bn_128), which is commonly used in EVM chains and is the curve on which the Semaphore protocol operates.

While it’s technically possible to adapt the protocol to a new curve, this would mean that it won't be strictly Semaphore protocol anymore, but a fork of it, and proofs would no longer be interoperable across chains. As a result, part of the purpose behind such an adaptation would be lost.

---

2) Adapting the Semaphore Protocol (if we still choose this route):

As mentioned, the Semaphore protocol relies on the BN254 curve, so adapting it to BLS12-381 would require several significant changes:

• Generating New Verification Keys:
  The existing verification keys are based on BN254, so new keys would need to be generated for the contract. This involves modifying the Circom circuit.

  • Specifically, the protocol would need to migrate from the Baby Jubjub companion curve used with BN254 to another curve compatible with BLS12-381, such as Jubjub or Bandersnatch.
  • I couldn’t find any ready-made Circom circuits for these curves, and I don’t have the expertise to implement one myself in the time available.

• Poseidon Hash Function Adaptation:
  The current Poseidon implementation is designed for BN254, so you’d need to find or adapt a version for BLS12-381. Here’s one of available implementations I found: Poseidon for BLS12-381.

---

Do you think it's practical to continue with BLS12-381 route?
I also asked in Semaphore chat, currently waiting for an answer

[evgongora]

Hey @kfastov! This is great insight since we're still researching on how to make it possible thank you for your investigation so far, we would like this to be in a doc, I will be creating an issue a referencing it here would you mind helping us with it? :)

You can show both routes with possible approaches.

[kfastov]

@evgongora Of course, I'll add the investigation results to the doc, and I am ready to help with both routes

[evgongora]

Here it is, apply when available ZencypherSolutions/semaphore-stellar-docs#14