Another week of improvements to the Hive Stream library and some realisations made along the way whilst building more code-level smart contracts to showcase the functionality and power of Hive Stream.
Complementing the other two example contracts, a third contract showcasing a simplistic coinflip game has been created. Whilst more simplistic in comparison to the other contracts, it sees the addition of how you can incorporate a client and server seed paradigm into your contracts.
When it comes to generating random numbers, the blockchain provides some nicely unique values such as block number, transaction ID's and so forth. However, for added entropy, it is considered best practice to add in the ability for both the user to supply a client-side random seed as well as generating a random seed on the server as well.
We do not do anything overly scientific when it comes to the server-seed in this example, the uuid package provides us with the ability to generate guids which are random enough in combination with a client-seed to generate numbers deterministically but make it all but impossible to game.
Like with the other contracts, comprehensive unit test cases have also been written showcasing the winning and losing aspects of the contract as well as situations where the user would be refunded for sending invalid amounts or currencies.
Whilst working on the coinflip contract I made a startling realising, contracts are great for piece of code that reacts to blockchain events (custom JSON) and do things like sending someone their winnings or dividends, but the one thing that isn't clear is getting results from the contract.
I realised for the coinflip contract if you had a UI that shows the user what the server flip value was, how would you do that? Contracts are not API endpoints that you call and get a result from, they're asynchronous pieces of code. This actually made me think about the best solution for this short of requires users use a backing database like MongoDB.
The first path I went down was using the blockchain as a database. I created a new account called 
Then I realised that in a recent update thanks to the backing storage adapters; SQLlite, MongoDB and JSON file that I already had the pieces I needed. Time-based actions are being stored using this backing, so why not results?
While this aspect is not yet completed, the aim here is to remove the JSON file approach and move towards SQLlite. Given they're both competing local database formats using files with JSON not really being a database, SQLlite and MongoDB will be the two supported approaches locally with MongoDB being the default option.
I wanted this to be ready for this release, but I am a few days away from this being available. This will expose a few new methods for querying the database and getting back results. Meaning the streamer node will now work as both a streamer and queryable database layer (similar to Steem Engine).
Nothing really of specific mention here, but the library is continuously being improved and cleaned. More tests are always being added in and existing pieces of code refactored and removed.
If you would like to contribute to Hive Stream, all contributions are welcomed from developers of all skill levels here on GitHub or if you have a bug or feature request, you can do so here.
