# Some notes regarding the implementation of Unirep so far

###### tags: `Unirep`

### Some bugs left unsolved
- ethers.js does not seem to be able to parse the events correctly if there are dynamic arrays declared in the event and the dynamic arrays are not declared as the last elements of the events
- for example I have to do it like this for it to work: https://github.com/NIC619/UniRep/blob/cc099c54921b318eb5350446cea0c5d61b0cbe69/contracts/Unirep.sol#L116-L117
- it also could be the problem with the testing environment(`hardhat`) not correctly producing the event data
- I will reproduce it in the testnet and find out

### Some questions about the implementation detail
- In cli commands and `UnirepState`/`UserState`, there are some part that I'm not sure if I should let the program throw error and shut down or just logging the error message and continue running
- for example: https://github.com/NIC619/UniRep/blob/cc099c54921b318eb5350446cea0c5d61b0cbe69/core/UserState.ts#L302

### Some not-urgent problems found during implementation
- how a user receive graffiti preimage from attester is undefined
- currently in `ProveReputation` circuit I required that user prove that he knows the graffiti preimage
- if a user can pick which epoch key to process first during same epoch and if an attester attest to two of the user's epoch keys in that epoch, then the order these epoch keys are processed will affect the reputation the user received
- currently all epoch keys are processed in one snark proof and processed in deterministic order so it should be fine for now
- during installation of some of the dependencies, npm suggests there are a number of vulnerabilities within
- might be a good idea to run `npm audit` for possible solutions if time permitted

### Some possible problems regarding privacy
- If a user receive no attestations in one epoch, his user state root would remain the same and so is the global state tree leaf
- if an observer see this, he can thus tell that the user has transition from one epoch to another epoch
- which is probably not much of a problem
- since the nullifers of processed attestation have to be revealed so everyone else can update their nullifier tree, observer can tell how many attestations a proof has processed by looking at the number of non-zero nullifiers outputed
- and combining with the fact that how many attestations are submitted under an epoch key is public in the Unirep contract
- this can possibly gain observer some advantage on learning which proof is processing which epoch keys

### Planned future work
- Move epoch trees into one (global) epoch tree