The problem news.zeroknowledge.rs solves

Zero Knowledge discussion is silo'd across telegram groups, discord servers, and twitter.

ZK news adopts the community link aggregation hacker-news format for link discussion. However, the zero knowledge community is small; users may not be able to speak their minds freely about projects and tech when accounts are publically attached to reputations/jobs. To that end we implement RLN, a zk-gadget for for anonymous environments, allowing users to submit anonymous comments.

RLN is a project which is using a combination of shamir secret sharing and zero knowledge proofs to do annonimized spam prevention. The way it works, in short, is that for each epoch period the user has a number of secrets which are shares of a polynomial. If the user sends too many shares in a time period they can be deanonymized and slashed. The user also generates a zkp that the shares submitted belong to a registered key and are for the correct time period. Proofs from the RLN JS lib are quite fast, with a user being able to post in less than a second of proof time, even on a phone.

We use RLN to replace the password authentication flow and to therefore enable anonymous postings. When a user wants to submit an anonymous post the produce an RLN proof which 'signs' the hash of their post, then the backend server checks that (1) the proof is valid (2) that its submission does not violate the rate limit. If the rate limit is violated the user is slashed and their account is banned.

In our application we check that the hacker news poster does not submit more than 1 anon post per 12 seconds. Critically because the proofs are processed client side on the user's machine their submission does not leak the account identity of the poster. In future work we would like to explore the idea of a "speedbump" RLN where if the user makes many posts in one epoc their future post speed can be limited.

Challenges we ran into

The RLN js library was direct and easy to add, however the flat rate limit does not match spamming behavior very well. Users often encounter situations where they may need to submit several comments in a row as part of non spam use, so may need higher than 1 per 12 second posting. However bots which spam consistently will max out the flat limit. Therefore to improve the spam prevention a changed RLN which reduces the rate limit depending on how much it is used could be very useful. This drop off behavior matches the spam prevention seen in other websites more closely, but would require circuit and smart contract changes, which we could not implement in the hackathon.