On-Chain RPS isn't a ZK Breakthrough, It's a Basic Trust
Building Rock-Paper-Scissors with zero-knowledge proofs is a fun exercise, but it overcomplicates what blockchain already solves: verifiable state ...
On-Chain RPS isn't a ZK Breakthrough, It's a Basic Trust
Most of the time, when we talk about zero-knowledge proofs (ZKPs) in Web3, it's in the context of scaling, privacy, or complex computations. Then I see discussions about using ZKPs for something like on-chain Rock-Paper-Scissors (RPS), and it makes me wonder if we're sometimes reaching for the most advanced tool when a simpler one would do.
Implementing RPS on-chain using ZKPs to prevent 'cheating' by revealing moves after the fact is a common case study. The idea is that you commit to your move (e.g., hash it) and then later reveal it, using ZKPs to prove your revealed move matches your commitment without ever showing the move itself until both players are ready. This isn't a bad idea in principle for certain games, but it feels like a very heavy hammer for a very simple nail.
The core problem in on-chain RPS is preventing a player from seeing their opponent's move before committing their own. This isn't new. It’s a basic commitment scheme issue. You hash your move, submit the hash, then after both players have submitted hashes, you reveal the original move. The smart contract verifies that your revealed move hashes to the commitment you sent. If it does, great. If not, you're penalized. This works without any ZK magic.
What ZKPs add, theoretically, is stronger privacy. You could prove that your committed hash corresponds to 'rock' without revealing 'rock' itself until the final reveal phase. But for a game like RPS, where the move is revealed immediately after commitment, what's the privacy gain? The move is public knowledge moments later anyway. The ZKP here often feels like an academic exercise to show what's possible, rather than a practical solution to a genuine problem.
The real trust problem in RPS isn't about hiding your move forever, it's about making sure your opponent can't change their mind after seeing yours. A simple commit-reveal scheme with hashing solves this trust problem adequately. The chain itself provides the immutability and verifiable state transitions. If you commit hash(rock) to the chain, you can't magically reveal paper later without the chain rejecting it.
I think focusing too much on ZKPs for every little problem might distract from where they truly shine: scaling complex computations off-chain, verifying huge data sets privately, or building genuine privacy-preserving dApps where intermediate data never needs to be public. For a two-player game with a three-option choice that resolves instantly, adding ZKPs often increases complexity, gas costs, and development time without a proportional increase in security or privacy that a simpler cryptographic primitive couldn't handle.
We need to be discerning about where we apply advanced tools. Just because we can use ZKPs for something doesn't always mean we should. Sometimes, the elegant solution is the simplest one.