Battle Frog

Frontend uses the Zupass Passport Package (downgrade to version 0.5 for compatibility) for popup selection of user's zk-eddsa-frog-pcd.

User requests a battle ID from the server. zk-eddsa-frog-pcd with the same battle ID will fight each other.

The frogs are committed to the server along with

• Move Score, an aggregate score of the frog's stats is also sent to the server;
• Battle ID;
• An EdDSA proof for all the above (?)

The server receives and validates that:

• the zk-eddsa-frog-pcd is valid (signed by Zupass Server Owner);
• the user's semaphore identity matches that contained in the zk-eddsa-frog-pcd;
• the user has committed the zk-eddsa-frog-pcd to battle;
• the user has committed the battle ID inside the proof.

Then the server submits the proof to an on-chian merkle tree.

We initially wanted to implement MACI in Noir, but found it a bit too difficult. Then we thought about implementing Semaphore, but found it already done.

Then we attended the Zupass Talk just to figure out how they went about implementing Semaphore, and it lead us down a rabbithole about PCD. Around that time, we realized that we are interested in extending Zupass into a game, something like a battle.

We wanted to hide the stats of the frogs so that no information is leaked, but it seems like it cannot be accomplished with Noir alone. As a result, we shifted to a more trusted model, where the server will receive the move score, but will not publish it to the opponent. The rest of the component remain trustless due to the verifiability provided by SNARKs.