<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=752538731515435&amp;ev=PageView&amp;noscript=1">

A Blockchain Story

It’s July 5th, I’m on the phone with Tony Sebion, a Director at Omni and the company idea guy, and I have no idea what Solidity is or how a Smart Contract really works. The conversation was lengthy and detailed but the gist was this: Tony drafted Kevin Brey and myself to build his social object/technical proof-of-concept for That Conference - an Ethereum blockchain-based betting application with a commercial music streaming device, smart contracts to broker the game, and a mobile-friendly app for users to register, place bets, watch the game, and win cryptocurrency. Simple, right? Yeah, right. It’s a month before our go date and I don’t understand half of the words in my description.

Building software isn’t trivial, really ever. Now consider the month deadline with zero code, zero user stories, zero understanding of the Solidity language, EVM (Ethereum Virtual Machine) environment, development tools, etc. coupled with a crude understanding of how tech’s ultimate buzzword - blockchain - even works. At one point I think I muted the call and laughed out loud to myself (sorry, Tony, you rock), because there was hardly a path in my mind that brought us to a successful launch. But somehow, we found a way.

Somewhere on this page should be an architectural diagram, so I’m going to just gloss over the details, but basically there are a few things we had to build before we could even see if our product idea was possible. Big thanks to Microsoft for putting out a BaaS (Blockchain as a Service) template for Azure that we leveraged heavily to run our private network for the game. That’s right, no real ether exchanged here. After the network was running and we roughly understood why and how, we wrote the first iteration of the Wager contract, or the code that brokered our game on the blockchain. The first pass was a nightmare, and Kevin and I had to spend a bunch of time talking time/space complexities in order to re-write the entire thing from scratch. Basically, the code was so inefficient that the entire game would grind to a halt after 15 or so rounds. Not great considering the 500-600 estimated rounds throughout the conference.

architecture ver2 (002).png

Once we were able to take off our big-O hats and get back to programming in abstractions, we had to build a service to write the currently playing song, on song change, to our contract so that we knew when to pay out correct bets. This was pretty straightforward, and Kevin did a great job building this out to the nines which you can check out here. This was a simple Node.js app running as a systemd service on a Raspberry Pi 3.

Finally, the client. We picked Angular + Google Material + web3.js for a static content app that wouldn’t require us to get another server running. Angular gave us a rich user experience and all the frills of modern web dev, Material made things look pretty on a phone and gave us a standard to follow, and web3.js is the real secret sauce of the whole thing. The core Ethereum team built web3.js as a way for JavaScript to talk to a blockchain directly - no intermediary server required. This was awesome, but has it’s share of problems I could write an entire blog about.

So, on the Friday before the conference we packed everything up and prepared for the worst. Of course someone would break it, I thought. Of course the network will fall off midway through. Of course this thing won’t scale to 100+ users. Again, it did, well kind of. We had a few curious peers poke holes in the network and on two occasions the network did drop completely. Oops!

Ultimately, though, the thing worked, our power users seemed to enjoy it, crypto-anarchist types found it interesting and wanted to talk about the tech. In a four-week development cycle, certainly there are things we would have liked to have cleaned up, optimized, secured, and prettied up, but I think we did the most with what we had - two devs with very little knowledge on the tech and a bunch of hard work. I’d do it again in a second. Congratulations to our grand prize winner, and a sincere thank you to everyone who hung out with us at the booth to talk about 70s Rock music, the game itself, crypto-currency, Bitcoin fork drama, and whatever else happened in that crazy weekend. But a special thank to Tony Sebion, who just makes things happen, and could probably talk me into some crazy professional decisions if given enough time in a conference room, and Kevin Brey, who is an insanely clever and talented developer who made this happen as much as anyone else. Check out future posts on more specific aspects of our Blockchain Consultancy, Rockchain technical details, Smart Contract development, and whatever else I feel inclined to ramble about.

Travis Crowe

About Author Travis Crowe

Travis Crowe is a former Software Engineer with Omni. He worked as a full stack developer who was passionate about web development and automation. On any given day, he was writing C#, Java, JavaScript, Python, and/or various flavors of SQL. Travis graduated from Northern Michigan University with a bachelor's degree in Political Science and a minor in Computer Science. You can follow Travis on Twitter @traviscrowe and on Github at github.com/traviscrowe.


Omni’s blog is intended for informational purposes only. Any views or opinions expressed on this site belong to the authors, and do not represent those held by people or organizations with which Omni is affiliated, unless explicitly stated.

Although we try to the best of our ability to make sure the content of this blog is original, accurate and up-to-date, we make no claims of complete accuracy or completeness of the information on this site/s to which we link. Omni is not liable for any unintended errors or omissions, or for any losses, injuries, or damages from the display or use of this information. We encourage readers to conduct additional research before making decisions based on the information in this blog.