Benchmarks for Poker 2-party computation

Close to practical moon math but maybe not there

The standard approach to supporting real Poker (generally meaning Hold’em) on a blockchain is to use a bunch of zero knowledge stuff to get a secret permutation. A much more practical albeit unpleasant approach is to play hands out as normal and simply cancel any hand which has a duplicate card. You can make that much less unpleasant by doing a 2-party computation beforehand to figure out if there will be any duplicate cards and ‘pre-cancel’ the hand, resulting in a much better practical play experience and very low on-chain cost but with possibly impractical computational requirements of the machines involved. I’ve done some digging into this now and the indications aren’t encouraging but I’ll put my thoughts together here.

For context, here’s what the on-chain protocol looks like:

1. Alice and Bob commit to their 5th images (if you don’t want the 2-party computation you can optimize out half of this step but that’s no big difference.)

2. Alice and Bob reveal their 4th images. Alice calculated her two hole cards from Bob’s 4th image and her preimage and Bob calculates his two hole cards from Alice’s 4th image and his preimage

3. Alice and Bob reveal their 3rd images, used to calculate the 3 flop cards

4. Alice and Bob reveal their 2nd images, used to calculate the turn card

5. Alice and Bob reveal their 1st images used to calculate the river card

6. Alice and Bob reveal their preimages

That’s about 20 sha256 hashes at about depth 6. For my specific case a secure hash function based off BLS12-381 groups could also be used.

It appears to be that a semi-honest protocol can be used as follows: The output of the circuit is Alice’s 5th image (her commit), Bob’s 5th image (his commit), whether a duplicate card happens, and the hash of a combination of Alice and Bob’s preimages, used preventing chicanery. The protocol is run twice, once for Alice to do the calculations and once for Bob. After the calculations are done Alice and Bob send each other MAC challenges about that final value and if the other side isn’t able to generate a good response the hand is cancelled.

Whether this is a reasonable/safe use of semi-honest computation I’m unclear. There’s no harm done if either side can sniff some information as long as it results in cancellation of the hand, and even if one side is able to sniff, say, a single bit of the input of the other side’s preimage that doesn’t help cheating because the whole thing is hashed anyway. If a controlled bit of information from inside the circuit can be sniffed that’s much more of a problem. Feedback on this welcome.

As for benchmarks which need to be met, here are some teetering-on-the-edge benchmarks which need to be met for a Poker protocol to be practical. If all of these are met the protocol is on the edge. If they’re all exceeded by an order of magnitude you’re on easy street:

• No more than 10 seconds of computation time on a standard desktop

• No more than 100 round trips

• No more than 100 megabytes of data transferred each way

Initial digging indicates that number of round trips can be met by selecting the right protocol (assuming semi-honest is okay) but the other two are off by a few orders of magnitude. Again feedback from experts would be welcome.