1. Rank the four hashes and provide explanations in four different aspects: gas cost, capacity, proof generation efficiency, and proof size.
When comparing the hash functions SHA256, MiMC, Poseidon, and Pedersen, the following ranking holds true in the various categories:
- SHA256 < Poseidon < Pedersen < MiMC
- MiMC ~~ Poseidon > Pedersen > SHA256
- https://ethresear.ch/t/gas-and-circuit-constraint-benchmarks-of-binary-and-quinary-incremental-merkle-trees-using-the-poseidon-hash-function/7446/3
- https://eprint.iacr.org/2019/458.pdf
- SHA256 < Poseidon < Pedersen ~~ MiMC
- SHA256 is not efficient in zkSNARKS because it does lots of boolean operations whereas the circuit required for a zkCircuit is an arithmetic circuit.
- https://ethresear.ch/t/gas-and-circuit-constraint-benchmarks-of-binary-and-quinary-incremental-merkle-trees-using-the-poseidon-hash-function/7446/3
- https://z.cash/technology/jubjub/
- SHA256 > MiMC > Poseidon ~~ Pedersen
- https://ethresear.ch/t/gas-and-circuit-constraint-benchmarks-of-binary-and-quinary-incremental-merkle-trees-using-the-poseidon-hash-function/7446/3
- https://z.cash/technology/jubjub/
2. In circuits/MerkleTree.circom
, complete the code for the following templates (feel free to add any helper templates for intermediate components and it’s ok to reference existing repos as long as their licenses permit):
https://github.com/Web3-Study-with-Sigrid-Jin/zku-cohort-4-week2/tree/master/Part1
3. How is Tornado Cash Nova different from Tornado Cash Classic? What are the key upgrades/improvements and what changes in the technical design make these possible?
https://hackmd.io/ISJ8sw7HTgysMNe0hW8iTA
https://www.youtube.com/watch?time_continue=2205&v=-N6lI6kD65M&feature=emb_title
https://github.com/ChihChengLiang/poseidon-tornado
![image-20220815135910557](/Users/sigridjin.eth/Library/Application Support/typora-user-images/image-20220815135910557.png)
First, funds are directly linked to a given wallet address. There is no private note or key. Users can access their funds by connecting to the pool with the appropriate address. User can deposit/withdraw arbitrary amounts of ETH, before with Tornado Classic, the user to deposit/withdraw a fixed amount of a given token within each pool.
Second, custody is either acquired by the act of depositing tokens into the pool or by registering in the pool and receiving shielded transfers from another address. In order to accomplish these things, a random area of bytes is computed using the Pedersen Hash, then sends the token and the 20 MiMC hash to the smart contract. The contract is then inserted into the Merkle Tree.
To process a withdrawal, the same area of bytes is splited into two seperate parts: the secret on one side and the nullifier on the other side. The nullifier is a public input that is sent on-chain to be checked with the smark contract and the Merkle tree data and prevents double spending.
Tornado Cash Nova uses Gnosis Chain as a Layer2, which allows for cheaper fees with fast transctions, and it as a L2 is much faster with dealing with Mainnet compared to 3 hours on Polygon.
https://www.youtube.com/watch?v=BaFg4NF_ZOs
Relayers are from the essentials parts of Tornado Cash, they are recommended to be used in order to preserve privacy while paying gas fees to do ETH transfer transactions, because otherwise if user choose to connect with the wallet, this payment of gas fees can compromise the anonymity of the user. They are acting as a third party, for managing the entire withdrawing process.
It is a set of tools that forms a system that allows an authorized user to act on certain information without revealing any information about the user. It is a system that allows any user to signal their endorsement of an arbitrary string, revealing only that they have been previously approved to do so, and not their specific identity. In order for this process to take place, some proofs must be completed. It must be proved that the user is authorized to do the signaling and that they signal is unique, depending on the use case. This is done through smart contracts and circuits utilizing a Merkle Tree.
6. How does Semaphore prevent double signing (or double withdrawal in the case of mixers)? Explain the mechanism in 4-8 sentences.
A Semaphore has multiple mechanisms to prevent double signing or double withdrawal. First is the Merkle tree structure. If any transaction cannot be verified inside of the Merkle tree, then it must false, thus nullifying the possibility of a double sign. Furthermore, the user trying to authenticate is a registered user, meaning that they have a unique authorization token. This token can be used to track the users transactions and understand their true identity and where their tokens have been used.
The users register first their identity by doing an identity commitment, which is equal to the hash of the pk: the user's EdDSA public key, in: identity nullifier, it: identity trapdoor. And then proof the current merkle root, with the generated merkle root of the merkle path with the generated identity commitment.
Then users can do their first transaction safely with an external nullifier, and the contract accepts this transaction because that is the first signal. However, if the users tried to execute another transaction with the same en: external nullifier, the contract will reject it.
7. A lot of applications have already been built based on derivations from Semaphore, such as for voting, survey or opinion, and authentication. Can you suggest two more ideas for ZK applications that can be built upon Semaphore?
Resale transaction verification, social media verification.
https://twitter.com/LuozhuZhang/status/1538166119785111552
https://immutablex.medium.com/ground-up-guide-zkevm-evm-compatibility-rollups-787b6e88108e
https://trapdoortech.medium.com/zkp-zkevm-a9b046789b4e https://hackmd.io/Hy_nqH4yTOmjjS9nbOArgw#Links https://immutablex.medium.com/ground-up-guide-zkevm-evm-compatibility-rollups-787b6e88108e
https://www.youtube.com/watch?time_continue=2205&v=-N6lI6kD65M&feature=emb_title