zkWiki
This is a decentralized application that will allow anyone to anonymously post information
Application Type
zkDAO
Proposal Overview
The project allows users can anonymously post a detailed title and a full message, the full message will remain hidden until the user chooses to reveal it. This use case is valid if the full message has top secret information or might endanger human lives but wants part of the story to go public. User can then reveal this information after a while.
Use Cases
Anonymous Whistleblowing
Competitive Landscape
Other whistleblowing website requires you to give up personal information before you are allowed to post, zkWIki doesn’t need any of your information for you to disseminate messages.
Proposal Ask
zkWiki will be established to be community-driven and self-funded by its DAO. To get this up and running, we will be requesting the $15k/year stable basic income to take care of initial development, welfare, and operation costs.
This ask will be in line with the laid down milestones as detailed below:
- launching a feature-complete product on our testnet
- forming a DAO with 5-out-of-9 multisig
- launching on mainnet with audit
- attracting … daily active users (with launch video, full PR promotion)
- attracting … daily active users (with a detailed roadmap, governance process)
Road Map
zkWiki is currently on Harmony Mainnet.
| Objective |
Date |
Status |
| Testnet Launch |
April 25, 2022 |
Done |
| Beta Testing and Fixes |
May 1, 2022 |
Done |
| Mainnet Launch |
May 1, 2022 |
Done |
| Smart Contract Audit |
June 15, 2022 |
Pending |
External links
- zkWiki Application
- zkWIki GitHub Repository
- zkWiki Demo Video
I quite like the idea of this app, but I’m puzzled by why the commitment alone is not sufficient to reveal a message - I assume it’s because you want to allow secret to be reused? But using the message header as identification doesn’t seem like a very good approach as it might clash, too. Some form of message id might be a better identification.
Please also include the circuits in your github repo so we can verify the zk aspect of your application as well.
Other misc. issues: app doesn’t check for correct network, using contract.sendMessage instead of a specific contract function can be sending to a random address on a wrong network
I’ve solved the issue of message header clashing by checking if it doesn’t exist on the smart contract.
Both circuits have been added on github.
Dapp now checks if you are on Harmony Mainnet Network.
Thanks for the feedbacks.
As a zkDAO governor, I am not able to approve this project in its current state for several reasons:
- The application seems not to involve an actual ZKP (despite using a circuit), but rather a commit-reveal scheme that doesn’t properly work (see next point). The Merkle tree in
sendmessage circuit was never used anywhere in the application, and the revealmessage circuit simply performs a MiMCSponge hash without any other component(s) that would constitute a ZKP.
- The reason why the commit-reveal scheme doesn’t work properly is that the
msgBody in your application was never hashed or committed on-chain, it was simply saved in localStorage and retrieved later.
As a result of the above, I think this application fails to qualify for the zkDAO grant at its current stage, and would require a huge revamp in design, architecture, and implementation.
It is recommended that you make all the necessary amendments, especially to make sure to utilize ZKP correctly, in order to qualify for the grant.
I agree with Cathie, the circuits are non-functional and the revealMessage circuit has random js code in it.
Rejected for grant
I also agree with Cathie and reject this grant. Merkle-tree isn’t doing anything and seems to only have been added to have a circuit to show on github. this commit includes js code in a circom file which clearly didn’t even compile added circuits · hakymulla/zkwiki@4b2d194 · GitHub
I uploaded the wrong circuit.circom files, i’ve corrected that now.
thanks for the feedback, will work on it.
1 Like