DICE response to Dan Larimer's suggestions...

DICE response to Dan Larimer's suggestions...

Words by Max (Dice Team)

Screen Shot 2018-12-13 at 11.52.56 pm.png

I just went through Dan's article and would like to say thanks to him for giving us some precious suggestions.

To conclude, Dan gave us two suggestions in order to reduce CPU cost for us and ease stressful CPU of EOS network.

1, Merge all the contracts so that we don't need inter-contract action. Now, we separate the contract to put game logic in a game contract (like baccarat logic to betdicebacca and sicbo logic in betdicesicbo), some core logic into betdicegroup (divs, referral, contest, etc) and users interested balance in a independent contract (betdicegiver for divs, etc)

2, Let user to deposit first then play in BetDice and withdraw once they are finished.

Firstly, the reason that we separate the codes into different contract is actually the same reason Dan gave. With this modular design, we can separate logic and codes into different contracts so that it is better for security. When we update logic of Baccarat, it won't touch anything with Sicbo. It is especially easier and safer when we need to develop in a high speed with devs in a short period of time. Another reason is that, it is easier for our users to track what is happening inside the transaction especially when we have investors here. You can easily know the amount of a transaction split into different parts for different purposes (betdicegiver for divs, betdicehouse for bankroll, etc) with the normal transfer action so that everything is clear and transparent. Of course, we can just do it in a table record but I don't know if DICE community would like this or not but this can be done easily. Maybe we can take out betdicegiver/betdicehouse/betdicesaver and move all of them to table record so some inline actions can be reduced. I have suggested this before in the chat. This is the tradeoff, grouping the contracts can reduce CPU but the point is to what extent should we group it and is it worth it to do so.

Secondly, in a traditional online casino, they usually ask the users to deposit money to the casino and play with the coins issued by them (the same as online gaming). After that, users can just withdraw anytime when they want to leave the casino. We think that users won’t like this design as they would like to transfer the money out of their wallet only when they need to place a bet as the safest place to hold your money in your wallet rather than the casino one.

EOS is great as it has the fastest transaction in the World and so we think that we don't need to design in this way. We can change it anytime as it is much easier for us to manage and develop if the money is stored on our side (just like the divs now). In that way, we can save a lot of CPU (mainly us, but not the user as the user will still need to run an action to place a bet but its just not a transfer action) as you know we have rented ~7M CPU and it is still not enough. Whenever user places a bet, what we need to do is modify the value in our contract table which is really great in terms of efficiency.

Also, I would like to give out some facts here.

From https://bloks.io/account/betdicegroup, we only use 23.9 m in 24 hours to handle all bets in our whole sites which there are 1440 minutes in a day.

From https://labs.eostitan.com/#/actions-summary -24-hours, you can see that we are not dominant in the number of actions. Also, the most complex transaction stated by Dan is consuming 2818μs which is ~2.8ms while the max execution time in EOS network in 30ms.

I am open to the design and can change it anytime. We just want everybody here to go in the same direction.

Please feel free to leave us some comments and opinions so that we can make a plan for what to do next.

PixEOS: New Tokenized Art And Game Platform on EOS

PixEOS: New Tokenized Art And Game Platform on EOS

EOS FOR IDIOTS: How To Change Your EOS Active Key Using Greymass

EOS FOR IDIOTS: How To Change Your EOS Active Key Using Greymass