Initial hand refactor

[eerkaijun]

Context (Problem, Motivation, Solution)

This PR is an alternative to the other PR, which is to verify the initial hand proof on-chain. It uses a different approach to the other PR, where in this PR, the player first has to commit a salt hash, and using that salt hash to generate randomness when drawing initial cards (relevant issue).

Describe Your Changes

Updated the initial.circom circuit to draw random indices in circuit instead of off-chain. Updated the corresponding verification contract and Game.sol.

Checklist

• [x] I have performed a self-review of my code
• [x] I ran make lint and fixed resulting issues
• [x] I ran the relevant tests and they all pass
• [x] I wrote tests for my new features, or added regression tests for the bug I fixed

Testing

Have updated the circuits and contracts test to make sure they work.

[eerkaijun]

With this approach, I think the game flow might need to change a bit though. Currently, (if I understand correctly), a player can joinGame anytime, and during joinGame, the same transaction also means the player is drawing the initial cards. So essentially player1 can first join and draw cards, and player2 can come later. With committing salts, we want both players to first commit their respective salts, before any of them can join a game, I think?

[eerkaijun]

@norswap since I previously merge master into initial-hand-verification, I think we can't rebase anymore due to non-linear commits. Seems like the repo disabled "Create a merge commit" option, which I think is the easiest option for this.

[norswap]

With this approach, I think the game flow might need to change a bit though. Currently, (if I understand correctly), a player can joinGame anytime, and during joinGame, the same transaction also means the player is drawing the initial cards. So essentially player1 can first join and draw cards, and player2 can come later. With committing salts, we want both players to first commit their respective salts, before any of them can join a game, I think?

Not necessarily, however, we need each player to commit their salt before they draw cards. Otherwise they can just pick a salt of their choice to draw the cards that they want.

If verifying constraints were cheaper, we could mandate the salt to be the encryption of the public randomness with the player's private key, which we could verify in a circuit. I think that's much too expensive today however.

[norswap]

I've:

• removed the linting (just dropped the linting commit)
• removed the changes to the lockfile (dropped the last "fix conflict" commit)
• relinearized everything, it was surprisingly easy, here's how you do it

Pushed the result at initial-hand-refactor-rebased. Let me know if it's all good, we can force-push it to this branch and merge that!

[eerkaijun]

Okay just checked and tested it out, initial-hand-refactor-rebased looks good to me. Let's merge that then?