FB Pixel

How are rock-scissors-paper and Ethereum scalability related?

Rock-scissors-paper game is a well-known game in the world. When two people play this game, the important thing is that both of them have to disclose their selection concurrently. However, it seems infeasible to create something concurrent with smart contract and make it work. This case study is good for brainstorming Ethereum Privacy and in my point of view, Ethereum Privacy will be the next challenge of Ethereum community after Ethereum Scalability.

Ethereum Scalability

The game

In Rock-scissors-paper game, concurrency helps two people, who try to compete the other, to hide their selection and be impossible to change it when disclosed. In summary, we need a protocol that assures 2 factors:

  1. Two competitors cannot gain any knowledge about the selections in advance.
  2. At disclosing phase, two competitors cannot change their selection.

Fortunately, Two-round protocol is the solution we are looking for. Two-round protocol has two main phases. The first one, submitting phase, each member of game must submit their hash of selection and wait for the competitor submitting. Coming to disclosing phase, after 2 competitors submitted their hash of selection, they can submit their raw selection without any encryptions. Both of them must calculate again the hash of the otherโ€™s selection to make sure it not changed.

As you can see, submitting phase helps 2 competitors take the proof of competitorโ€™s selection without any knowledge about the real selection. Finally, the disclosing phase is the phase that verifies the selections and decides who would win.

At this moment, if youโ€™re a type of sensitive personย ๐Ÿ™‚ you will see that it owns a big problem here.

Problem: Assume the selection is presented as a string and has one of three values which areย rock, scissors, paper. So the hashes (Keccak256) of them are:

The hash is actually irreversible but the number of values is two small, so they can make a bruce-force attack easily.

For example, Victor โ€” victim โ€” is the first person submit his hash of selection in submitting phase and Alice โ€” attacker โ€” tries to guess Victorโ€™s selection and make a selection to compete Victor. Assuming that Victor choseย rockย and submitted:ย 10977e4d68108โ€ฆย to smart contract. Alice just waits for Victorโ€™s submission, gets Victorโ€™s hash, looks for value correspond with the hash. It is feasible for Alice to know that Victorโ€™s selection isย rockย and then she submits hash ofย paperย to compete Victor.

Yeah, there you areย 👉. The content above is just a kind of warming-up and this problem is actually what I would like to brainstorm and understand how fun of privacy.

Privacy problem of rock-scissors-paper game

To solve this problem, we need a thing that totally hides the decisions but still assures that would be unchangeable. It may have a lot of solutions but in this article, I just have presented two solutions I got.

One solution bases on mathematic and it uses modulo in detail. The other bases on an idea used in zkSNARK, it uses secret number (Note that itโ€™s not a zkSNARK instance).

The solution based on mathematic

Letโ€™s change the game a little bit. We wonโ€™t useย rock,ย scissorsย andย paperย to present the selections any more. Instead of that, we will useย nย withย mod(3) = {0, 1, 2}ย asย {rock, scissors, paper}ย respectively. And the important thing thatย nย is a secret-random number.

Assume that Victor choosesย rock, in order to do that he has to choose randomย nย so thatย n mod(3) = 0.

For example:
n = 13714425016816510474524816299716591239769767123746972631
n mod(3) = 0

In submitting phase, Victor hashesย nย and submits this hash to smart contract. Obviously, Alice has no idea which number Victor chose and submitted by the bruce-force attack. To verify Victorโ€™s selection, Alice just only gets Victorโ€™sย nat disclosing phase and make a verification.

The solution is based on secret number

If you have never gotten any knowledge about zkSNARK, you can take a look at my previous article here.

Ethereum Scalability

And the idea using secret number is in โ€œZero-knowledge proof with a game for computersโ€ย part.

In this solution, we donโ€™t need to change the original game but we would change the protocol.

Every time Victor or Alice wanna submit their hash of selection, they have to pick a secret-random numberย sย and from now, the hash is the hash of combination of the selection andย s. At disclosing phase, Victor and Alice have to disclose secret-random numberย sย as well as their selection to be possible to verify each other.

For example:

ย 

As you can see, it is infeasible to Alice bruce-force the secret number which Victor chose. Otherwise, whatโ€™s happen if Victor wanna change his selection? When Victor changes his selection, he also finds another secret numberย sย so that new hash of combination is the same as submitted hash of original combination. Theoretically, it is impossible to Victor as well.

Conclusion

Generally, everything we got stuck are just thoughts in a box. We may focus too much on concurrency and forget concurrency is just like a solution in real life for two original requirements of the game.

In addition, privacy is not only needed to medical documents, KYC systemsโ€ฆ but also games on blockchain. In every field, privacy is existed in different forms but the importance of privacy is undeniable.

Let us know what you think about this article and how it can be applied to Ethereum scalability. Or if you have your own theories about Ethereum scalability. Drop us a line in the Kambria Telegram Channel.

Author