Algorand Bet, my first attempt at a DApp

Community Projects
1

It’s been a while since I’ve become thrilled with the whole smart contracts idea, so I’ve looked around and I was struck by how good the Algorand smart contracts ecosystem is. So, I tried to write my first DApp on the Algorand blockchain.

Algorand Bet is a dice betting game, like many others that can be found online. Although, unlike most of them, the whole betting system is managed by a smart contract, so it is completely trustless. The source code of the smart contract is open source, and available on the website.

This is the website to play on the mainnet: https://algorandbet.tk/

And this is to play on the testnet: https://test.algorandbet.tk/

This is to me more of an exercise, since is also the first time that I’m developing a front-end, so feedback is very welcome.

Bonus note: the whole DApp is 100% written in Rust: the back-end uses Rocket and the front-end uses yew. The interaction with the Algorand blockchain is done using algonaut, the Rust SDK for Algorand, so big thanks go to the authors of this library.

2

Hey, nice idea. I must admit I’ve never played these types of things, but it’s good to see more adoption on Algorand. Just thought I’d provide some feedback after a quick look over how it’s working.

The account ALGOBETJIZIHTD4LRSZ3NHICSM2ERMKQZP2IFDNM26WXT6PIWH5YOISSSQ is needed to sign transactions to interact with your game which isn’t a smart contract, and the transaction you present to the user isn’t submitted to the network by the user but rather sends the group ID and signature back to your server. I never have full visibility of the entire transaction before signing which would concern me.

It appears as though you’re doing everything on your server, so there’s still an element of “black box” going on.

3

First of all, thanks for the feedback!

Yes, to make sure that the transaction is valid (i.e. the hash value for the house actually comes from the server) that account “signs” the transaction group with a 0 ALGO transaction to itself.

I see your point that this is a black box element, since you’re signing a transaction in a group but you don’t actually know what other transactions are in that group (and with this protocol is needed that you don’t know them).

I think I came up with a two-steps solution that solves this problem:

  • First, the server sends the hash, an Ed25519 signature for the validity of the hash, and a parametrizable TEAL program that checks the result of the bet, and you parametrize it with the hash, the signature, your number and your address
  • You then sends your bet funds to the address of the contract (in this way you know exactly where you’re sending the funds and the conditions on how they’ll be moved)
  • Then, the server makes a transaction based on the logic of the contract to either withdraw the funds, or to send them and the additional win to your address

The contract would also need a timeout of execution after which the user could retrieve its funds, in case the server dies in the meantime.

Do you think such a protocol would avoid any black boxes?