The ICONbet Dapp: Randomization Function and Verifiability
One Dapp is driving the vast majority of transactions on the ICON Mainnet. That’s ICONbet. On its 85th day of operation it passed 2 million transactions. As of that day it had taken in about 32.7M ICX ($5.23M USD) in wagers and paid out 490k ICX ($78.4k USD) to holders of its rewards token. As the first attempt at a DAO (Decentralized Autonomous Organization) on the ICON blockchain the smart contract code includes incentives and governance on top of the game itself. A DAO organizes people in a system that coordinates the transfer of value related to a specific activity and purpose. The working of the business model is a key technical aspect of a DAO which is built into the contracts. Since the DAO approach to businesses is new, ICONbet is a work in progress that we can all learn from as they adjust to their market. We have seen this already as they have made a couple changes to the dividends distribution model which serves to reward frequent players. There are too many details to cover in one article so we will approach it in more bite sized pieces.
There have been a number of reviews and walkthroughs for the one game available on ICONbet (DAOlette), so we will not focus on how to play. It is a Roulette style game with 20 numbered cells that you can bet on, and a ‘bomb’ cell. To get context for the following, please visit the ICONbet site and look through their FAQ and whitepaper, if you haven’t done so already.
We will start with a few fundamentals. At the core of a DAO is the verifiability of transactions on the blockchain that creates ‘Trustless trust’, where every transaction is immutably stored so anyone can verify it. -> You can trust the system, and the record, so you don’t have to know and trust the person you are dealing with. The trick here is that you do need some technical knowledge in order to perform the verification. Fortunately, the ICON blockchain makes this easier than other smart contract platforms like Ethereum or TRON, since the source code for all contracts can be retrieved from the blockchain by anyone. A little later we will step through the verification process for an ICONbet transaction and provide code so you or a coder friend can do it yourself. It should also be noted that I do not know of any full DAO that exists yet. In all cases so far (that I know of) a participant still has to trust the founders in some way. There are good reasons for the founders to behave in a trustworthy manner for the success of the business, but in practice DAOs move incrementally towards full decentralization and autonomy over time and in the early days participants are taking some risk, betting on the integrity of the founding team. We will revisit this question, but in short, it seems that the ICONbet team has so far exercised good judgement, presented a reasonable approach towards decentralization and autonomy, and proven themselves as trustworthy through action in the best interest of the community over the initial months of operation.
The Randomization Function
The core function that gets a lot of attention in ICONbet is the random number generation, which gives the result of your bet. Let’s see if what they are doing makes sense. Downloading the code from the blockchain, https://tracker.icon.foundation/contract/cx1b97c1abfd001d5cd0b5a3f93f22cccfea77e34e#code we can get the random number generation algorithm (reformatted a little to fit):
Since all operations in a blockchain transaction must be deterministic and produce the same result on every node, this is not a truly random number, but a pseudo-random number based on the standard sha3_256 hashing function. Like a random function, sha3_256 will return any number in a range with equal probability, but it will always return the same number given the same seed. So the challenge is to provide a seed that the user cannot know in advance. (If they could know it in advance they could just generate transactions until they got a winner and only send those.)
The ICONbet random function has a seed composed of the transaction hash, the block time and a user seed. Both the transaction hash and the user seed can be known by the user in advance, but the block time is only set when the block is being constructed on the node. On the ICON blockchain, blocks are produced every 2 seconds, but the block time does not fall exactly at 2 second intervals, and it is specified down to microseconds, so there is sufficient indeterminacy that a player could not predict what it would be. The reason to add the transaction hash to this is so that all transactions in a given block will yield different results. The user seed is included so players can add something they feel might be lucky.
The sha3_256 function returns a value in bytes, which is converted to an integer. The five least significant digits are taken from this and divided by 100,000 to yield a number between 0 and 1. This determines where the wheel stops when it spins.
Contract Update
There was some concern within the ICONbet community over an update that was deployed a month ago regarding the fact that the developers could change the code. Note that by its nature, software development will require the ability to update code to fix bugs or allow the deployment of feature upgrades. The questions are how this can be done in the context of a DAO, and how ICON compares with other platforms in support for this. It is true that you cannot ‘update’ a contract on Ethereum, but you can accomplish the same thing by redirecting all the function calls to another contract. Then if you need to make a change you can deploy another contract and change the address you redirect to. You have effectively updated the original contract, but it is not as easy to tell it happened as it is with ICON.
The other question, of controlling this process of updating code through the DAO, is possible, but challenging since code has to be written to allow the DAO members to vote whether to deploy the upgrade. This code is not yet present in ICONbet, but they have indicated an intention to implement such DAO voting features; a possible interesting topic for a future article.
So the real question is what did they do in this update? Why did they feel it was necessary and have they been good stewards of our trust in the platform? We can see that the length of the random number returned by the random function was increased from 3 to 5 decimal places. A little calculation reveals that the 3 decimal places provided insufficient accuracy to return all cells on the wheel with equal probability (Figure 1). On average, the wheel will land on each of 1, 2, 4, 6, 7, 9, 10, 12, 14, 15, 17, 18, and 20, 48 out of 1000 spins, while it will land on the remaining numbers each 47 out of 1000 spins.
Since the house edge is only supposed to be 1.5% this small difference may be significant. How much advantage could a player get? We ran two simulations of bets, one that included only those 13 numbers with a higher chance of winning and another with 13 randomly selected numbers. For each simulation we ran a series of 100,000 bets of 1 ICX each, then took the average over 1000 runs.
This small difference resulted in a loophole that would allow a player to mine the TAP rewards token for less than half the cost. This would not be a killer for the house, since they would still be positive, and we found no evidence that anyone noticed or took advantage of that loophole. A more important consideration is the advantage some players could have taken over others. Any player betting on the higher return numbers could have acquired their ownership stake for half the investment, at the expense of other players who did not take advantage of the loophole. That is a significant unintended advantage. Kudos to the ICONbet team for catching the bug and fixing it.
Verifying Transactions
Another point that has generated some discussion is verification of transactions. No matter how you cut it verifying transactions will require some coding proficiency. Let’s go through the steps so anyone could either do it themselves or take it to a coder friend who could easily help.
First, go to the tracker at tracker.icon.foundation and find the transaction you’d like to verify. Copy the transaction hash and the block height, as shown in Figure 3. You will use these to get the inputs for the random function. Then Click on the Events tab at the bottom, which is where you will be able to see the results of the transaction.
Under the Events tab you will find the Bet Result, as shown in Figure 4. Those are the numbers we will verify.
Now, here is the part where you will need some coding knowledge. Take the code shown in Figure 5 and paste it into your favorite editor. Change the <block_height> and <tx_hash> to the numbers you copied previously (removing the commas in the block height, so it is just a number.)
I like to use a Jupyter Notebook to execute small pieces of code like this. I suggest following the directions on their site to install the Anaconda Python distribution and the Classic Jupyter Notebook.
When you run this code you should get the same results as you saw in the Event Log for your transaction. The code will go out to the blockchain and get the three pieces of information needed to reproduce the random calculation; the block time, the transaction hash and the user seed. Then it does the random calculation and finds the winning number.
Happy Spinning!
