This topic is to discuss the proposal submitted by @chrlyz .Please see below for the details of the proposal and discussion.
18th Sep,2024 Current status: Funded. This proposal is approved for funding. The timelines for this zkApp are longer to deliver as we acknowledge this is a complicated undertaking. The impact and risk are classified as low due to the timelines. The budget is in line with the work proposed. We appreciate the author’s transparency in the proposal regarding timelines and are happy to support the improvements suggested.
08th Sep ,2024 Current status: Under Consideration. Opened for community discussion on :08th Sep, 2024.
This is a continuation of “WrdHom: the auditable social-media platform”, a project that got kickstarted during zkIgnite Cohort 2 and Navigators Season 1, successfully delivering all milestones, and that has kept advancing on its own.
The project is building a social-media platform, where users get auditable and customizable feeds, free of censorship or content manipulation like artificial boosting or deboosting of certain content or accounts, and black-box moderation systems. Providing a credibly neutral platform, where content propagation is fair for everyone, and content, groups, or individuals aren’t treated in a biased way. Also increasing the agency of users, by enabling them to customize their feeds and see the content they want, instead of just prioritizing the content that increases engagement and revenue for the platform to the detriment of its users.
Furthermore, users truly own their accounts by owning their private keys and by storing all the necessary data to power the platform in open and decentralized protocols like Filecoin, while the root state that can only be updated by following the rules established on Smart Contracts and zkPrograms lives on the Mina blockchain. Securing the proper behavior of the platform.
Proposal Overview
Problem
Currently the platform relies on immediate evaluation of every server response by the user’s client. This negatively impacts the user experience, since each time the user’s feed updates, the audit of the response gets triggered, so the user needs to wait until the audit finishes to keep navigating through the feed.
On top of this, since each server response needs to be audited immediately against the current onchain state, it’s not possible for the server to serve content that hasn’t been included in the onchain state, so the user isn’t able to see the most recent content, which depending on how many platform actions need to be proven and how fast the next block is produced, could result in a content delay of dozens of minutes.
Additionally, the current design doesn’t allow users to go back to already audited queries in their feed; and immediate evaluation creates a race condition between the server response and the fetch of the onchain state, which sometimes can result in an audit failure even though the server response was valid.
So overall, the user experience can be greatly improved by addressing these issues.
Solution
To solve these issues we will change the current architecture from immediate evaluation to lazy evaluation, by storing the server responses of a session (in-browser up to a certain amount of data and then giving the option to unload them into a file), so they can be audited later.
We will also decouple the auditing functionality from content navigation, so users get a smoother and faster experience, and are able to see more recent content that hasn’t been recorded onchain yet, but its inclusion has already been committed and it’s just a matter of finishing creating the associated proofs and including them in a future block.
Furthermore, by changing from ephemeral server responses to a more persistent design, we will enable the user to go back to already audited (or to be audited) server responses, improving navigation even further. We also get rid of potential race conditions.
With these changes we also open the door for the implementation of Smart Contracts and zkPrograms that are able to take these stored responses as inputs and generate proofs of invalid responses, rewarding people that are able to prove invalid responses, and therefore creating more incentives for people to audit the platform, which may produce an invalid response at a predictable frequency, to provide a constant reward for consistent auditing.
Impact
Radically improving the user experience of our auditable social-media platform is a further step into delivering a product with the potential for mass adoption in the Mina ecosystem. A unique product that leverages the unique properties of Mina.
Audience
The main audience for this proposal are the eventual end users of the auditable social-media platform, which deserve the best possible user experience, but also the potential developers that could build on top of the open platform.
Architecture & Design
Detailed Design/Architecture
The WrdHom project aims to provide an alternative by building an open, auditable, and accountable platform by default. Guided by the following principles:
Users sign messages to authenticate their actions on the platform. This way users own their digital identity, since they own the keys to their accounts.
These signed messages are the input to zkPrograms that verify signatures, order actions on the platform, and generate proofs to update the state of the platform by following the established rules encoded in the zkPrograms. Then the associated smart-contracts verify that the proofs are valid and timestamp the moment of their inclusion.
The state of the platform is composed of on-chain and off-chain state. Our on-chain state lives in the Mina blockchain, and can be seen as the root of the whole state of our platform. This state is updated through the proofs generated by our zkPrograms, and can be used to verify that the off-chain state is valid.
The off-chain state lives in open and decentralized storage platforms like Filecoin. Data should be stored publicly and redundantly, so users have the guarantee that their data and the platform will remain available.
When users get content from the platform, the server responds with the content and the Merkle Map witnesses associated with each piece of content, so the client uses this to automatically calculate the roots for the state of the platform. The client also fetches the on-chain roots, and compares them with the calculated roots to make sure that the server response is valid according to our settings, and behaves as expected.
Mina also makes it possible to implement native zkApp-specific rollups, so we don’t have to make an on-chain transaction every time a user does something in the platform, which would be slow and expensive. Instead, we merge the proofs that we create to update the on-chain state, into a single proof that can be submitted to the network (e.g. The server receives 1,000 post requests, so it generates 1,000 proofs that then are merged, and the server uses the resulting proof to update the on-chain state for 1,000 posts in a single transaction). These proofs can also be generated in parallel, allowing the platform to scale.
For this proposal we will modify the server and the client. The server will still respond with the Merkle Map witnesses and the content, but also with signed metadata for each response, which will be composed by the query of the user and the block length for which the response should be valid.
The client will quickly verify that the metadata is signed by the server and that it matches its query parameters, to then store each of these responses in-browser up to a certain amount of data and will offer the option to unload them into a file for longer term storage and auditability. Then the user can trigger the heavier auditing of any of these responses later, either by triggering an audit of a response still in the browser’s memory, or by uploading a response from a file.
During an audit, the client will retrieve from an archive node the onchain state at the block length for which each response indicates it should be valid, and perform the audit against them.
The client will also be modified to enable an intuitive and smooth navigation of different server responses through an in-app navigation history, and “go back” and “go forward” arrows. Additionally, we will implement URL Route Params, so users can bookmark and share links, making content easier to save and share, and improving caching and search engine indexability.
Vision
A successful long-term vision for this project would be establishing a popular social-media platform with millions of users. Normalizing the expectations for transparency, auditability, credible neutrality, user-owned identity, resiliency, and composability in our general internet experience. Improving freedom of speech and our collective intelligence for better decision making, free of signal corruption. Creating a better world.
Existing Work
Production Timeline
Around a year for a devnet release, and around 18 months for mainnet.
Budget & milestones
Deliverables
Server with the new functionality to serve auditable responses for lazy evaluation.
Client with the new functionality to lazily audit the server responses, download them into a file, decoupled auditing and navigation, and the ability to navigate through the stored responses, plus being able to bookmark and share queries.
Mid-Point milestones
Server with the new functionality to serve auditable responses for lazy evaluation.
Client able to store and lazily evaluate the server responses.
Project Timeline
3 Months
Budget Requested
30,000 MINA
Budget Breakdown
62.5 MINA x 480 Hours = 30,000 MINA for one Software Engineer for 3 Months
This will cover the running costs of software design, development, and testing.
I’ve been building on the Mina ecosystem since December 2022.
Team Members
Currently the team consists only of the proposer.
Achievements
Successful delivery of all milestones during zkIgnite Cohort 2 and Navigators Season 1.
Risks & Mitigations
One of the major risks for a platform like this is it being abused by some users to post illegal or unwanted content (like spam or unlabeled sensible content), which could bring legal risks to operators and an undesirable environment for users.
To mitigate this risk a moderation system will be developed. Following the ethos of the project, this moderation system will focus on auditability and neutrality, looking for an optimal point that maximizes freedom of speech and minimizes legal risks and content that users don’t want on their feeds.
Another risk is that the smart contracts could get “bricked” if we lose offchain data or it gets corrupted in a way that we can no longer create proofs to keep updating the onchain state. Plus guaranteeing to users the long term availability of their data and the platform is in itself one of the goals of the project.
To mitigate this we will follow a redundant offchain storage strategy supported by decentralized storage networks. This is a risk that many zkApps face, so we will keep an eye on what other teams are doing and work on establishing a solid solution.
Finally, there’s always the risk of bugs or security vulnerabilities in the system, so thorough analysis and testing is necessary. This is why the platform will first launch on devnet for a period, to make sure that we catch any dangerous issues before launching on mainnet, through the feedback of alpha testers, auditors, and bounty hunters.
This proposal is approved for funding. The timelines for this zkApp are longer to deliver as we acknowledge this is a complicated undertaking. The impact and risk are classified as low due to the timelines. The budget is in line with the work proposed. We appreciate the authors transparency in the proposal regarding timelines and are happy to support the improvements suggested.
