Previous review: https://hackmd.io/-Qk1NJ2HRN-24LaTp63z2Q
Spec: https://hackmd.io/nYlm7qHhTA-h8JJz3-uCLw
Brief walkthough of Unirep circuits: https://hackmd.io/AwY04HMvRLipbmB-xoU5jQ
Some notes regarding the implementation of Unirep so far: https://hackmd.io/d5KTcXQiSdu_0F2_v25RQw
Milestones: https://hackmd.io/FFpqfj-0RxGPG80GRtTRug
attesterSignup
The readme has this instruction:
It worked only after I removed attest
from the command:
nic sorry about the typo!
Consider using a URL-safe scheme like base64url or hexadecimal to serialise data like proofs and Identity
data. e.g. instead of:
consider using a format like this:
An example of encoding an epoch key proof using base64url:
nic Feedback applied at commit: https://github.com/NIC619/UniRep/commit/29bf9c7c6b47a5fd2f7346890475936d67ebdf2a
verifyEpochKeyProof
I followed the steps in the readme but I had some trouble verifying my epoch key proof:
Maybe this error came about because I didn't recompile the contracts after I regenerated the snark verifying keys and verifier contracts.
I'm also not sure what my epoch key is - the readme gives a value of 88
but I saw 18
in the output.
nic
epk
is computed from identity nullifier, epoch number and noce, so it could be thatgenUnirepIdentity
generates a new identity, hence a differentepk
.
nic Feedbacks regarding Unirep smart contracts are applied at commit: https://github.com/NIC619/UniRep/commit/ea5b9a44ee72e563b4b34c1146f746f7efc3614f
contracts/SnarkConstants.sol
, contracts/Poseidon.sol
, contracts/UnirepParameters.sol
, contracts/DomainObjs.sol
, contracts/ComputeRoot.sol
, contracts/UserStateTransitionVerifier.sol
, contracts/ReputationVerifier.sol
, contracts/EpochKeyValidityVerifier.sol
, contracts/IncrementalMerkleTree.sol
, contracts/Hasher.sol
No comments
contracts/SafeMath.sol
Consider adding the OpenZepplin contracts to package.json
and importing the files from node_modules
. I'm not sure if Hardhat allows this easily but here is how to get the Solidity compiler to look at the correct directories: https://github.com/appliedzkp/maci/blob/master/contracts/scripts/compileSol.sh#L23-L28
contracts/Address.sol
Consider importing this from a node_modules
installation of the OpenZepplin contracts.
contracts/Unirep.sol
immutable
(if we use a version of Solidity that supports it).nic in the current implementation, the lazyledger approach is taken and so
- proofs are verified offchain and
- trees are updated offchain.
If everyone has processed all Unirep transactions (whether succeed or fail) in the same order, they should derive the same global state trees, epoch trees and nullifier tree.
ecrecover
directly.nic Feedbacks applied at commit: https://github.com/NIC619/UniRep/commit/4938371c389825e765a283a06abbe3f5399fa785
nic An attester can choose to not verify an epoch key and just attest to it, and this attestation will be processed (assumes that the user can prove that this is his epoch key). I suppose this indiscretion of attester is acceptable as this wouldn't hurt the system as a whole but the attester's own credit.
Or an attester can even attest to a random junk value, however, since no one can prove that he owns the epoch key, i.e., the random junk value, the attestation will not be processed.
hashAttestation()
function in DomainObjs.sol
.require
statement consumes gas, consider swapping lines 283 and 285.contracts/OneTimeSparseMerkleTree.sol
This file isn't referenced anywhere - is this intended?
circuits/identityCommitment.circom
identity_pk
is actually IdentityCommitment.identity_pk
doubled thrice. Consider renaming this circuit and the identity_pk
signal name to something else to make the naming clearer.nic Line 7 feedbacks applied at commit: https://github.com/NIC619/UniRep/commit/a898e53afd2ee9b03efd8dd4b33074094ff5a44d
nic hmm.. I'm not sure about it. I copied them from Semaphore here
wj Oops, never mind!
circuits/proveReputation.circom
, circuits/userStateTransition.circom
and circuits/processAttestations.circom
There is some circuit code regarding calculating quotients and remainders and performing range checks that they are correct. This code looks similar across these three files, so it might be good to create a circuit that abstracts away these operations. Check out the modulo circuit here: https://github.com/agajews/circom-dsl
nic Line 7 feedbacks applied at commit: https://github.com/NIC619/UniRep/commit/0a955bc0d33eae070a360963761e148904a9dfc1
I tried to use the modulo circuit in https://github.com/agajews/circom-dsl but ran into a few problems so I currently just move the duplicated circuits into one circuit:
IsNegative()
circuit is used, and in IsNegative()
circuit a sign()
circuit is used, but sign()
cirucit compares the input with cosntant 10944121435919637611123202872628637544274182200208017171849102093287904247808
which is a value between 2^252
and 2^253
, but the output from poseidon hash function could be larger than this constant and hence be taken as a negative value and result in wrong modulo.MultiRangeProof
in agajews's modulo circuit but I did not find an example in the codebase or the circomlib codebase. I guess it' just a circuit that perfomrs range checks on given inputs but not sure about it.circuits/proveReputation.circom
, circuits/processAttestations.circom
, circuits/userStateTransition.circom
Looks good. I'll take a another look next week.
circuits/verifyHashChain.circom
No comments.
circuits/poseidon/poseidonHashT3.circom
No comments.
circuits/poseidon/common.circom
No comments.
circuits/poseidon/poseidonHashT6.circom
No comments.
circuits/hasherPoseidon.circom
No comments.
circuits/verifiyEpochKey.circom
nic yes, though I just hardcoded this limit in the circuit as the highest possible nonce wasn't specified in the spec. But there's another system parameter
numEpochKeyNoncePerEpoch
outside of circuit that would limit the actual number of possible nonce in the system (which is currently set to2
).
epoch_key_depth
(which is 8 for the test circuit) bits for LessThan
, but uses LessThan
to check epoch_key
. Could a user pass in an epoch key that is larger than ? Even though genEpochKey()
in test/utils.ts
adjusts the epoch key to be mod 2 ** _epochTreeDepth
, consider checking whether it's possible for a user to bypass this.nic currently the circuit would check that
epoch_key
input should be less than2 ** epochTreeDepth
circuits/incrementalMerkleTree.circom
No comments.
circuits/sparseMerkleTree.circom
No comments.
nic Feedback applied at commit: https://github.com/NIC619/UniRep/commit/95d64f80ceda4dd3670c14ce2f546942a8b5e5b0
npm run test
NODE_OPTIONS=--max-old-space-size=4096
. Otherwise some circuit-related tests will run out of memory. Consider adding it to the testing shell scripts and package.json
commands.testCLI.sh
And: