Privacy Protocol: Fixing The World of Reputation via the Blockchain
Abstract
Blockchain-based reputation and review systems face a fundamental tension between transparency and user privacy. This paper presents a privacy-preserving blockchain review system that enables users to submit reviews anonymously while ensuring each review is genuine and unique. We combine zero-knowledge membership proofs and Merkle tree-based snapshots of eligible reviewers with anonymous submission mechanisms. This design lets users prove membership in a group (such as verified purchasers or community members) without revealing their identity, and submit one review each using one-time cryptographic nullifiers.
Our approach improves on existing privacy techniques by offering strong anonymity guarantees, resistance to double submissions, and compatibility with decentralized platforms. We describe the system’s architecture, analyze its security and performance, and compare it to alternatives. The solution demonstrates that blockchain reputation systems can achieve privacy without sacrificing integrity, thus
The Problem
Online reviews shape purchasing decisions and community trust, yet fake submissions, privacy concerns, and centralized moderation plague them. In Web2, platforms like Trustpilot, Amazon, or Yelp can’t reliably verify that each review is genuine, nor can they protect users who fear backlash for honest feedback.
In Web3, complete on-chain transparency risks revealing a reviewer’s entire wallet history, making privacy even harder to maintain. Overall, both ecosystems struggle to confirm a reviewer’s legitimacy without compromising anonymity — leaving an urgent need for a system that ensures one authentic review per user, robust privacy, and fair moderation in a decentralized world.
System Architecture
The flow of a user submission is as follows:-
- Snapshots are computed off-chain. The Merkle tree for each snapshot is computed and the path is stored off-chain while the Merkle root is stored on-chain
- User grabs a Merkle path (off-chain) and uses it as input (along with their wallet address + target token) to a ZK circuit
- ZK Circuit generates ZK proof
- User forwards proof to relayer, which submits it to the smart contract on-chain
- Smart contract verifies proof & review data
- Upon verification, review submission data is stored on-chain
Merkle Tree Snapshots
At the heart of the system is a Merkle tree that accumulates all eligible user identities (as commitments). A Merkle tree is a binary hash tree that produces a single root hash representing all leaves [1]. Each user registers an identity commitment (a hash of their secret identity) as a leaf in this tree. The Merkle root at any given time is a cryptographic fingerprint of the entire set of members; anyone can use the root to verify membership proofs without knowing the individual leaves.
Snapshots: Instead of continuously using a changing Merkle root, the system can take a snapshot of the root at key moments (e.g., when a product becomes reviewable or at a certain block height). This snapshot root is then used for all proofs in that context. By using a fixed root per review context, we ensure consistency: all reviewers of a given item prove membership against the same set, and late-joining users (after the snapshot) would not be eligible for that particular context unless an updated snapshot is taken. Snapshots also simplify proof verification since the smart contract can store a known valid root for each context.
Merkle Proofs vs. ZK Proofs: In a naive design, a user could prove membership by revealing their leaf and a Merkle proof (the series of sibling hashes up to the root). However, that would publicly reveal which leaf (and thus which user) is behind a review, defeating anonymity. Hence, we leverage zero-knowledge proofs to prove the existence of a valid Merkle path without revealing it [2]. The Merkle tree still provides the commitment to the set of identities, and standard assumptions of Merkle trees apply (collision-resistant hash ensures no forgery of membership). The use of Merkle trees means the system’s storage of member data is efficient — only the root needs to be stored on-chain for verification, and updates (adding members) affect O(log n) nodes.
If the member list is dynamic, the tree can be maintained as incremental. Protocols like Semaphore use an incremental Merkle tree allowing new leaves to be added and a latest root computed.
Our design can adopt a similar approach: the Membership Contract could maintain the current root as members join, and record historical roots as snapshots when needed. For security, once a snapshot root is taken, it should be immutable for the context it represents; any later changes in membership would require a new context or snapshot to include those new members. Its current timeframe for each snapshot is daily.
Zero-Knowledge Membership Proofs
Zero-knowledge proofs enable one party to convince another that a statement is true without revealing why it is true. In this system, the critical statement is: “This review author is a member of the eligible set (Merkle tree)”. We use Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge (zk-SNARKs) to make this efficient on-chain. Specifically, each review submission includes a SNARK proof π that attests to two things:
- Merkle Membership: The prover knows a leaf node in the Merkle tree with root R0 and the path from that leaf to R0. In other words, the user’s identity commitment is included in the snapshot Merkle root. This shows the user was in the approved set.
- Knowledge of Secret: The prover actually knows the secret data corresponding to that identity commitment (typically, the secret would be the hash pre-image, like identity nullifier & trapdoor as used in Semaphore [3]). This ensures the user isn’t proving someone else’s membership; they are proving their own membership.
The proof is generated by the user off-chain using their private identity. Modern SNARK libraries (e.g., Groth16 (El), PLONK) can handle a Merkle path verification in the circuit. The circuit (the mathematical representation of our statement) will take as private inputs the user’s identity secret and path, and as public inputs the Merkle root and the nullifier (see next subsection). It will output a proof that can be verified by a smart contract in constant time.
Mathematically, if $H$ is the hash function for the Merkle tree, and $C$ is the user’s identity commitment (leaf), the user proves: “∃ (leaf, path) such that H(path) = R0 AND leaf = C AND C = H(identity_secret)” without revealing path, leaf, or identity_secret. The contract is given R0 (from storage) and uses it in verification, so it knows the proof corresponds to the correct snapshot. We rely on the zero-knowledge property of the SNARK to hide the leaf index and identity. The proof reveals nothing beyond the fact that some valid member submitted the review.
To instantiate this, we can use a SNARK-friendly hash like Poseidon or MiMCSponge for the Merkle tree (as done in Semaphore) to keep the proving efficient. The choice of proving system could be Groth16 (which has very small proofs and fast verification but requires a trusted setup) or a transparent setup system like PLONK/STARK (larger proofs, no trusted setup). These details can be adjusted, but conceptually the system is agnostic to the specific ZK proof technology as long as it can efficiently prove membership in a large set.
Nullifiers
A crucial aspect of our design is preventing a single user from submitting multiple reviews for the same item while preserving their anonymity. We achieve this using nullifiers, a concept borrowed from Semaphore. A nullifier is a cryptographic identifier derived from the user’s secret identity and a context (it is also called an external nullifier in some literature).
For each review context (e.g., a particular product or topic being reviewed), the protocol defines a unique external identifier — this could be as simple as the product ID or a hash of the item name. When a user generates a proof to review that context, they include in the proof a computation of their context-specific nullifier. For example, if a user’s identity contains a private key $k$, they might compute nullifier = H(k || context_id). This nullifier is output as a public value in the proof, meaning the smart contract sees it when verifying the proof, but k remains secret.
One-Time Use: The Review Contract maintains a record (a set) of all nullifiers that have been seen for each context. Upon verifying a proof, it checks that the nullifier is not already in the used set. If it’s new, the review is accepted and the nullifier is recorded; if it’s a duplicate, the proof is rejected (indicating someone tried to submit two reviews with the same identity). Because the nullifier is deterministically derived from the user’s secret, the same user (same identity secret) generating a proof for the same context will always produce the same nullifier. However, to everyone else, the nullifier is just a random 256-bit number — it does not reveal the user’s identity, only that someone (some member) used that nullifier.
Our design permits each user to submit at most one review per context by this mechanism. At the same time, the use of an external context id allows the same user to participate in different contexts without linkability. For instance, if Alice reviews Product X yielding nullifier Nx, and also reviews Product Y yielding Ny, there is no way for observers to tell that Nx and Ny came from the same user — they look unrelated. Only if Alice attempted to review Product X twice would the nullifier repeat, and the second attempt would be blocked. This is exactly how Semaphore allows multiple votes across different polls by the same user with anonymity.
Nullifiers thus provide double-spend prevention in the anonymity set. They are similar to a spent coin marker in mixers: once used, they cannot be reused. The security relies on cryptographic hash properties — an attacker shouldn’t be able to guess or influence another’s nullifier without breaking the hash or the ZK proof. It’s also important that the nullifier truly be unique to each identity: typically it’s derived from a secret identity nullifier key known only to that user. In summary, nullifiers ensure honest usage (one review per user per item) without revealing which user.
Anonymous Review Submission via Relayers
Even with cryptographic anonymity in the proof, a naïve user submission could be deanonymized by observing the transaction’s origin. If Alice submits her proof and review directly from her known blockchain address, observers learn that Alice’s address invoked the Review Contract (even if the proof hides her identity in the context of the ZK system, her Solana address or similar would be visible). To avoid this, we introduce relayers — third-party services that submit transactions on behalf of users, a technique used effectively by similar systems to enhance anonymity.
Role of Relayers: A relayer is a server or decentralized network of nodes that accepts an anonymous submission (containing the proof and review data) from a user off-chain, and then forwards it to the blockchain, paying the gas fees. The relayer can be compensated with a small fee included in the submission (e.g., the user attaches an extra cryptocurrency note to pay the relayer). From the blockchain’s perspective, the relayer’s address is the one calling the contract, not the user’s address. This decoupling means an observer cannot link the review to any particular user’s wallet or identity — the on-chain source is just a relayer that handles many users’ requests.
To preserve privacy, users should send their submission to relayers over an anonymous channel. If done properly, the relayer will not know the IP or origin of the request, and the user’s identity stays hidden. The relayer sees the proof and data, but since it’s zero-knowledge, it learns nothing about which member submitted it, only that the proof is valid. The relayer cannot forge valid proofs on its own, because it doesn’t have the user’s secret. Its job is only to forward data.
Decentralization and Censorship Resistance: We envision a market or pool of relayers to avoid having to trust a single entity. Anyone could run a relayer service that listens for pending review submissions (perhaps via a specialized mempool or off-chain channel) and broadcasts them. Decentralized relaying is an area for further development, but even in a simple form, multiple independent relayer servers can ensure no single point of failure. The system could also allow direct user submission if the user takes care to use a fresh address with no link to their identity and possibly uses an anonymity network — though this is less convenient for average users.
Gas and Fees: Using a relayer implies the user must pay the relayer’s fee. This can be handled by including a payable field in the proof. The specifics are beyond our scope, but numerous designs exist to compensate relayers in a trustless way (atomic swaps, session keys, etc.). The key point is that the presence of relayers ensures unlinkability of the transaction sender, complementing the cryptographic anonymity. Without relayers, a sophisticated observer might correlate the time a proof was generated or the on-chain submission with a specific user’s account activity. Relayers add an additional layer of operational security to our privacy-preserving review system.
Conclusion
This system shows how trust and privacy can coexist in a blockchain-based reputation platform. By using Merkle tree snapshots, zero-knowledge proofs, nullifiers, and relayers, we enable users to leave authenticated reviews without disclosing their identities.
The Merkle tree ensures only valid members can submit feedback, while zero-knowledge proofs hide which leaf belongs to the user. Nullifiers prevent double submissions by the same reviewer, and relayers conceal transaction origins at the network level. This design addresses the failings of traditional Web2 review sites — where fake or manipulative submissions are rampant — as well as the privacy pitfalls of fully transparent on-chain systems.
By limiting on-chain data to Merkle roots and proof verifications, the system remains efficient, and off-chain processing scales well. Each user can prove eligibility for a single review per item, yet preserve anonymity. This approach illustrates that robust privacy and authentic reputation need not conflict.
Future work may optimize proof performance, extend relayer decentralization, or incorporate advanced cryptographic techniques. Nevertheless, the core framework outlined here offers a viable path toward fairer, more private, and more trustworthy blockchain-based reviews.
References
[1] — “Merkle Tree in Blockchain: What It Is and How It Works.” Investopedia, 26 July 2024, https://www.investopedia.com/terms/m/merkle-tree.asp.
[2] — El, Mohammed. “Evaluating the Efficiency of zk-SNARK, zk-STARK, and Bulletproof in Real-World Scenarios: A Benchmark Study.” MDPI, https://www.mdpi.com/2078-2489/15/8/463.
[3] — Semaphore. What Is Semaphore? | Semaphore, https://docs.semaphore.pse.dev/.
