Skip to main content

2 posts tagged with "zkp"

View All Tags

Semaphore - part 1

· 3 min read
Jimmy Chu
Site Author

I have been studying about zero-knowledge proof in the past eight weeks. It is hard to grasp how a software project could integrate zero-knowledge proof. Then, through some community chat groups, I came across Privacy & Scaling Explorations group and one of their projects, Semaphore. Semaphore is a very educational project. In this project, I see how ZKP is being applied (in a fashion I understand) and observe excellent software engineering inside.

Semaphore allows users belonging to a certain group to vote without revealing which member they are, aka anonymous voting. There is also a mechanism to prevent users from double-voting, which is done by posting some "residues" generated by the zero-knowledge proof protocol on-chain.

But what is great about the project is that it is very beginner-friendly, and I say this with great respect. The whole project is architected very nicely. It can even be viewed as a model project for how software and packages are structured in modern-day dApps. I have learned a lot from their software structure and encapsulation.

  • The core software project: Semaphore protocol, with a nice structure of:

    • contracts package - the smart contract that verify the proof generated offchain.

    • proof package - the off-chain logics that generate the ZKP with wasm code generated by an arithmetic circuit.

    • circuits package - contains the arithmetic circuit written in circom that generates and verifies proof.

    • hardhat package - a package that allows developers to deploy the core semaphore contract via hardhat without downloading the semaphore project.

  • A template to see how the protocol can be incorporated into other projects. It consists of:

  • The project leverages the Merkle tree structure to verify that a member belongs to a group, with all the tree leaves being the users' identity commitment. The user will generate a Merkle proof to show that he belongs to the group. The core team implements the Merkle tree structure separately as a Lean Incremental Merkle Tree (with a summary note).

  • The project has excellent documentation and website as well, including as two different packages inside the source code.

Studying the project taught me a lot of optimization tricks I can apply in the zk-battleship codebase. I also saw how they used to save on-chain gas costs, particularly using emitted events to store voting results (the user feedback messages) instead of on-chain storage to reduce gas costs further. This is something that never crossed my mind before.

There are two feature enhancements I can help implement on the current Semaphore basis to further my engineering understanding in zk-app development.

  1. Users can later prove they have voted without revealing their voting option, which can become proof of participation for them.

  2. The voting result is hidden during the voting phase until it ends. In this way, the choices made by late voters won't be affected by the given voting result so far.

On Learning zk-SNARK

· 2 min read
Jimmy Chu
Site Author

Recently I am picking up the knowledge necessary to understand what is going on in zk-SNARK. For those who are not familiar with this term, "zk" stands for zero-knowledge, and "SNARK" stands for succinct, non-interactive, argument of knowledge. What this term means is:

  • zero-knowledge: this is a way for a prover proving "something" to a verifier in such a way that the verifer will not gain any additional knowledge than before the interaction. We will elaborate the "something" in the following bullet points.

  • succinct: the proof is going to be short compared to the actual knowledge, and the verifier will be able to perform the verification quite fast. To be more concrete, if the knowledge m has a length of |m|, the proof may probably be O(log |m|) or even shorter.

  • non-interactive: there won't be rounds of back and forth interactions between the prover and verifier. The prover will only send a single message to the verifier.

  • Argument of Knowledge: This is the "something" mentioned in the first bullet point. Notice that this is not the knowledge itself, but a proof that demonstrate that the prover indeed knows the knowledge.

Yes, this is quite an abstract concept. But what is the most puzzling in this learning journey is that though there are tons of useful online resources, such as:

I CANNOT integrate the theoretical aspect together with its engineering aspect in this domain. For example, the high level concept of a zk-SNARK is a combination of one of the functional commitments with one form of interactive oracle proof (IOP). But in implementing a actual zero-knowledge proof project, how do I actually choose a zk-SNARK scheme with a particular functional commitment and a particular interactive oracle proof?

So now, my learning approach is as follows:

  • Studying in-depth about the source code of the Semaphore project.
  • Meanwhile continue reading rareskill zk-book
  • At the same time, I am also applying for bootcamp program to solidify my understanding and hoping to get hands-on experience of putting zkp knowledge into engineering practice.

To be continued.