Braindump: Kahoot Clone

[JoshOrndorff]

@AltiMario This PR begins to prototype what an onchain clone of the popular education / classroom game kahoot.it might look like.

The code is based on this transaction lifecycle diagram I came up with at lunch.

This PR should not be merged here. Rather the code is to share ideas. If it is to be kept, it should move to Mario's own project repo. But I thought it might get better review from Tuxedo experts here.

[coax1d]

Would be great to have this to be used at the PBA

[AltiMario]

Hello @coax1d and the whole Tuxedo team, this "Kahoot clone" is Bounder (Bet On Understanding) and is a component of the decentralised e-learning platform I'm building.
I presented the platform at the Hong Kong PBA, have a look
https://docs.google.com/presentation/d/1DwoJDHCmf8IPLnEfao-nlgykQifxMVUhFh4i4UyHYVI/edit?usp=sharing
Bounder is not trivial and I'm applying for the Decentralized Future grant program, I would like your support there if you believe it is a valid project. This is the draft description, let me know your thoughts.
https://docs.google.com/document/d/1vZakz535gO8b0y3IGZ5JAWRKCPNwBTuqKW01feBl3xE/edit

[NadigerAmit]

@JoshOrndorff,
Thanks. I could not understand the writings on the above dig, could you please label it or rewrite it for easy understanding?

[JoshOrndorff]

Yeah, that back-of-the-receipt diagram is pretty rough lol. I wanted to make sure I didn't lose it so I posted it. Here is a legend for the notation. I'm starting to like this notation a lot.

Here is also a somewhat better version of the diagram. It is not only fixing the scribbles, it also changes some things reflecting my more recent thinking. I think we can optimistically allow the question reveals to be off-chain and only require an on-chain reveal when there is some availability problem.

[NadigerAmit]

Hi @JoshOrndorff ,

Thank you for the above dig.
Below is my understanding of the above diagram, Please feel free to correct me.

BounderPiece :
Bounder piece is having below transaction type or operation of constraint checkers :

1. CreateGame operation

Inputs:
Teacher UGL deposit (fee), UGL, game metadata (hash) stored off-chain.
On chain validation - constraint checker :
Creates a new game UTXO with committed questions or hash of questons.
Generates UTXO representing Pending Game.
Outputs:
UGL: UTXO representing Universal Game Logic.
Pending Game: UTXO representing the pending game with committed questions.

Note : The game metadata hash can be a reference to the off-chain information about the game, like question sets, difficulty, etc.

2. JoinGame operation
Inputs:
Student token deposit (bet), pending game.
On chain validation - constraint checker :
Students declare intent to join the game by depositing tokens.
Updates state with participants who have joined.
Outputs:
UGL spent (bet), "joined game" state stored in a student's UTXO.
This will verify the pending game exists and deducts the bet from the student's balance.

3. StartGame operations
Inputs:
UTXO representing the Pending game joined games (student UTXOs representing the participants who have joined.) for the game.
On chain validation - constraint checker :
Initiates the game.
Creates UTXO representing an open game.
Generates answers corresponding to each student.
Outputs:
"Open game" state i.e UTXO representing the ongoing game.
UTXO representing the answers corresponding to each student.

4. Settle Operation:
Inputs:
Student Answers: UTXO represents the answers submitted by students.
Open Game: UTXO represents the ongoing game.
On chain validation - constraint checker :
Validates and settles student responses against correct answers.
Simultaneously handles settlement.
Outputs:
Settled Answers: UTXO representing the settled answers for each student.
Pending Settlement: UTXO representing the ongoing settlement process.

5. CloseGame Operation:
Inputs:
Settled Answers: UTXO representing the settled answers.
Pending Settlement: UTXO representing the ongoing settlement process.
On chain validation - constraint checker :
Completes the settlement process.
Transfers deposits from losing participants to the winners.
Outputs:
Game Results: UTXO representing the results of the game.
Winners' Deposits: UTXO representing the deposits awarded to the winners.

I think it may be difficult to achieve everything on-chain due limitation of storing large quiz content (questions, answers, explanations, images, etc.) directly on-chain looks expensive due to storage fees.

So we can have Hybrid approach:
Off-chain Game Logic:
Develop the game logic (question presentation, answer selection, scoring, etc.) off-chain (e.g., server-based application).
This application will manage interactions with players, track game state, and generate outputs for on-chain transactions.

[JoshOrndorff]

Your summary is close. One misc point: My diagram says "UGC" for universal game creator, not ugl.

---

I want you to carefully consider the use of the word "input". It has one definition that means UTXOs consumed by a transaction. It has another definition that means data that the user supplies to the process. It is important not to mix these up.

For example when you are summarizing the game creation:

Teacher deposit (fee), UGC, game metadata (hash) stored off-chain.

The teacher deposit and the universal game creator are really inputs in the UTXO sense. They are pre-existing state that is consumed by this transaction. However, the game metadata is completely different. It is not previously stored on chain and therefore cannot possibly be an input. The point of this transaction is to put that metadata on chain. It is an output in the utxo sense. (Admitted that it is an input of data from the user).

---

Another thing I noticed is that you mention closing the game outputting a UTXO that represents the results. Why do you want to do this? Once the game is settled and payouts are made, why have this results UTXO always taking up storage? The blockchain itself already keeps a permanent record of the result (and even the entire game play) so there is no need to also keep it in state.