Tambola

Demo

About

The problem it solves We wanted to take something familiar and demonstrate the power of blockchain and cryptocurrency to the world. Tambola is a party game played widely in India and other countries. With the pandemic separating families and friends, and people wanting to play together remotely it is difficult to find a trustable tambola platform. With blockchain, all the transactions can be monitored, all events can be observed and even the code can be audited to ensure fairness and trust. With guarantee of how cryptocurrency is handled, it becomes easy to enjoy the game.

How it's made

Challenges we ran into There were three major challenges building this application: 1. Tooling - The development ecosystem is fairly new with no clear IDE of choice and multiple frameworks required for different purposes. Testing ticket generation was fairly challenging, as the debugging tooling would crash often and there was no easy way to test the contract logic. 2. Random number generation - Blockchain networks are a deterministic system, with fixed inputs resulting in fixed outputs. Tambola requires randomness in ticket and number generation. Miners can manipulate the number generation to their advantage if care is not taken. Chainlink was explored as a potential technology for randomness, but it has certain constraints like delay and gas limits that make it challenging to create a good user experience. Since there is human interaction every time a random number needs to be generated, a potential solution is that the contract methods accept a random seed which can be generated on the client side or manually by the caller. 3. Ticket generation - Tambola tickets have certain constraints, i.e. each row can have 5 numbers, each column can have a specific range of numbers and maximum of three, but at least one. These numbers should be sorted from left to right and top to down. These constraints made it difficult to write logic in solidity to ensure tickets are generated with good randomness. With solidity’s limited programmability, and ensuring the gas used is reasonable for this call made it extra challenging. The ticket had to be compressed using bit manipulation, which meant prize computation also had to work with the compressed ticket.