MRLN envisions a future where secure, private, and spam-free social interactions thrive on the Mina blockchain and aims to redefine user experiences by eradicating spam, preserving user privacy, and fostering a sense of trust and credibility within online anonymous communities. The potential is to utilize MRLN in Ethereum applications leveraging Mina as a ZK layer for anonymization, facilitated by the LambdaClass Mina Bridge. - Integrating LambdaClass Mina Bridge with storage proofs using Herodotus could enable the development of anonymous applications on Layer 2 solutions like Starknet, zkSync, or OPStack chains. This integration would utilize Mina as a ZK layer and MRLN for spam prevention or rate limiting, enhancing privacy and security in decentralized ecosystems. Crafting secure and captivating social applications without compromising user privacy poses a significant challenge in the digital age. The persistent presence of spam and bots continues to disrupt the user experience, spread misinformation, and undermine trust within online communities. Mina’s privacy-native approach provides spammers with a level of anonymity that renders them immune to punishment within anonymous applications. This scenario results in several adverse effects: • Decreased User Engagement: This refers to a situation in which users become less active, participative, or involved in the activities and interactions within an anonymous application on Mina. • Erosion of Community Standards: The erosion of community standards in an application on Mina signifies a gradual deterioration or weakening of the established guidelines, rules, and norms governing user behavior and content on the platform. • Loss of Credibility: In the context of an application on Mina, the “loss of credibility” indicates a decline in the platform’s perceived reliability, trustworthiness, and overall reputation. • Increased Content Moderation Workload: Increased content moderation workload arises when the volume of anonymous-user-generated content on an application on Mina grows to a level that requires more intensive and time-consuming efforts from the moderation team to ensure that the content aligns with community guidelines and standards. Solution • Users register within the system by providing a “secret” value, which they use to prove their membership by storing it in the membership merkle tree. • If a user in the system engages in spam, banning their IP or blockchain address is ineffective since they can still generate proof of their membership. • The only viable method to counter spammers is to remove them from the merkle tree. However, since spammers can re-register and spam again, an economic mechanism is necessary to prevent recurrence. Users stake tokens during registration. • If a user spams, their secret can be immediately recovered by anyone (thanks to Shamir’s Secret Sharing), allowing someone else to generate proof of membership on behalf of the spammer and withdraw their staked tokens, essentially initiating the slashing process. • In addition to spam prevention, the architecture explained below facilitates different rate limits for different users. • MRLN enables users to register by staking once and utilize rate limiting and spam prevention in multiple zkApps. Use Cases • Anonymous Chats • Anonymous Voting • Limit-bid Anonymous Auctions • Anonymous Survey & Feedback Platforms • Captcha • Any on-chain application with human interaction 😌 Potential Partnerships - SocialCap (Community-based attestation protocol) - ZkSnap (Verifiable on/off-chain DAO voting with ballot privacy using storage proofs) - Mogart Network (SocialFi platform running on Mina protocol) - PinSave (Decentralized Pinterest) Architecture • The architecture draws strong inspiration from the RLN on Ethereum implemented by PSE: https://rate-limiting-nullifier.github.io/rln-docs/rln_in_details.html • Understanding Shamir’s Secret Sharing is highly recommended before proceeding with the architecture: https://rate-limiting-nullifier.github.io/rln-docs/sss.html • Protokit will be employed for implementing the following architecture. Read the original proposal > Denis Bas (Discord: d0x471b) https://github.com/0x471/o1js-mrln