Three lessons learned from building a DApp World Cup game on Ethereum Blockchain
In this piece, we focus on Ethereum Smart contracts and how they can be used in the field of sport forecasting.
At BELEM, we wrote a smart contract in Solidity to manage an open, hopefully secure, mutual betting game. A player inputs its forecast for World Cup games from Group phase to Final. The more accurate the prediction, the more points the player gets. Players in the top 1% split all the pool - more precisely we use a square root function to spice things a bit. A player buys a ticket for a fixed price, but can buy several tickets. You have a little chance to win big.
From a high level perspective, the contract is pretty simple :
- Player sends their bet with their prediction for the games
- World Cup happens, results are known
- Players scores are known, top ones get the prize
The job of the smart contract is to enforce that the rules of the games are correctly followed. The rules can be made public in advance, verified and tested by anyone. Once deployed as smart contract however they cannot be changed, or only changed by protocols concluded in advance.
The oracle problem
It’s worth reminding that smart contracts cannot read information from external sources. They can only read data written on the blockchain.
We have a first issue here, how can we ensure World Cup results received by the contract are correct ? We could introduce a multi-party agreement between a set of known trusted entities. For example, famous people could tweet their Ethereum address to register as game results. The game proceeds only if enough validators validate the results. Implementation would be quite straightforward in Solidity :
Note : for this to be fair, validators would need to be identified and registered before the game begins without possibility of changing the set afterwards.
But, here is a question though : if validators can validate World Cup results, why could not they validate the whole game ? Well, they could, but that would probably be less practical. That is really what blockchain is about: separating specific levels of trust in a process. Validators only have to verify the World Cup results are correct and click OK, they don’t need to understand the game or run a blockchain node. As a player, you only trust them for that. For the game rules and your money flow, you trust the smart contract.
We work here under the assumption published results are correct. We consider then the security we can achieve with a smart contract in this setting.
Security
By using a blockchain we get a first (non) free lunch, we can prove our users that:
- Forecasts were actually made before the deadline
- Money was committed : this ensures the prize to win is real
- The rules are known in advance and cannot be changed
- Money cannot be stolen and will only go to winners
- We don’t take a fee
The GAS
For any transaction on Ethereum you have to pay a fee in GAS units. GAS units represent costs for running contract code, reading from and storing data in the blockchain. As a consequence, for any players action in our game, a transaction fee has to be paid. This can be serious downside for DApp. A potential solution for this would be to allow the contract to use its own balance to pay for users initiated transaction, something not yet possible in Ethereum.
For this reason, writing a Smart Contract feels a bit like like hardware programming: you must be very careful about resources you consume. In our game, we faced multiple issues with GAS and other limitations, computing players prediction points was going to cost a non-negligible amount of GAS.
Firstly, we had to think an encoding for predictions data, we packed games scores into bytes32 variables. Even with that, the GAS to play amounts for 0.0018 ETH (or about $1 as the time of writing)
The main issue though was to sort all players scores and find out the best ones. We instead used the smart contract as a verifier. It does compute the score for each player, but only once and to compare it to a provided score threshold. The players with a score above the threshold are the winners, we know all of them and we can verify the number of winners follows the rules.
Finally, if the number of players happens to be large, computing the score would be to expensive to do at once, so we have to split the computation over several blocks.
Overall, we decided to minimize costs for players, assuming that if operations can be trust-less even if they are initiated and paid by contract’s creators, players would rather have their gas at minimum.
Conclusion
We explore Ethereum smart contracts by implementing a sport prediction game. Smart contracts provide several insurances that could easily be applicable to many use cases where parties agree on a set of rules.
Smart contracts provide real benefits but one must keep in mind:
- All this only works provided you trust the underlying blockchain coin (Ether here) has value. Without value, there is no binding. In fact even basic blockchain security could probably not be maintained. Miners would fleet and history could be rewritten…
- Smart contracts are not autonomous, someone or something has to trigger them. Blockchain is more about splitting trust between parties. One party being the smart contract.
- Smart contracts are expensive, for this reason they mostly end up being about verifying some rules and transfer coins. They barely can compute complex things on chain, and even then, there is serious cost for it.
You can find the full code of the smart contract here.
You can test the DApp game here : https://copadelcrypto.com
DISCLAIMER: Remember to use ETH Test Net Money and not real ETH if gambling is restricted in your country.
