Response to 0xAkrasia's review

[cryptitalk]

1. Inco mainnet will have async decrypt and reencrypt functions. They suggested we either use call back functions or implement the entire logic in FHE math before decrypting in the last line. Which do you think is better here?
2. I'm not very familiar with sorting algos but since we have a small list, would bubble sort be more gas efficient than a divide and conquer algo?
3. We may need to rewrite the logic of wincheck and paywinners down the road to account for a points system, a pot kept in a multisig, and maybe to let us check other player's moves. I'm still working through what this looks like but hope to have a broader system design laid out for us to discuss soon. No need to do anything on that now, just wanted to bring it to your attention.
4. Is this solution generalizable? Meaning, the game is currently set up to take 8 candidates and pick 4, but can we do 4 candidates and pick 1?

[cryptitalk]

https://multicoin.capital/2024/03/07/the-holy-grail-of-cryptography/

[cryptitalk]

working on 2 & 4, which should not be hard.

I think 3 is doable, that's why I did not test the payment logic in the first version, if the design is finalized, I will do the implementation.

Could you please provide more material on 1? for example, which function in my implementation you are targeting at, and reference docs / papers. @0xAkrasia

[0xAkrasia]

For 1, the decrypt will be async on Inco mainnet. It is async because it must pass through k of n nodes to be decrypted and that takes time. This means the decrypt and reencrypt statements need to be at the end of functions. The revealResult function won't be able to run as is. This can be solved by writing a callback function to finish the logic after variables are decrypted and an event is triggered OR by rewriting the function in FHE math then calling decrypt at the end to reveal the result. A similar issue occurs in wincheck.

[cryptitalk]

quick sort versus bubble sort almost the same gas consumption, I will keep both for reference, use bubble sort as of now for readability.

[cryptitalk]

for question number 4, I changed my contract to take 2 parameters in constructor nCandidates (n<=8), topK (k<=n), in your case n=4, k=1, and it works fine.

We can always extend our use cases to allow n of more than 8, as for now, let's keep 8.

one thing user need to take care of is, for example:

if final solution is 1000(0000), and user voted 1000(1100). even though they guessed right, they will loss as it's their responsibility not to inject noise in the solution, we also need to make sure our front-end would not make such mistake.

[cryptitalk]

regarding 1.

I see some official examples decrypting in the middle of a function:

battleship

blind auction

My guess is, the underlying implementation on protocol layer of decrypt is asynchronous, but interface itself (solidity contract) is synchronous, see this reference, which quotes "A significant limitation of the EVM is that smart contracts are strictly synchronous".

So, we might not need to change the contract at this moment, and our test is passing all the time.

Response to your suggestions:

Solution 1: call back function, this is easy to implement as we can decrypt first, then emit an event, then listen to that event to trigger our follow-on functions (reveal result that involves sorting). The advantage of this method is that it will has much less gas limitations.

Solution 2: FHE compute everything before decrypt, which is very challenging but worth a try, who wants to be the first person that invents the FHE sorting algorithm?

I will upload a solution 1 variant soon.