I knew this part would be a doozy.  First of all, I am a skeptic in terms of the viable use-cases of blockchain technology.  Having gotten stuck in, researched ways to build on and integrate with it, I remain so, although I concede there may be good things to come.

It’s safe in 90% of cases to say that Blockchain probably isn’t the technology you’re looking for. To oversimplify, if you want an immutable, highly-trustable ledger with no central authority, this would be a really good bet.. but, severe energy impact and crippling transaction throughput issues are a very high price to pay.  In fact, depending on what you’re doing with it, the monetary cost could be a very high price to pay, too (see: How Much Does It Cost to Run DApp in 2018).

The bright future would be any way that the system can move away from proof-of-work, which is a part of what Ethereum 2.0 looks to promise.

You can work around the proof-of-work with something like proof-of-authority, but you trade off on the decentralised side.

That aside, let’s do it…

There are a few options for working with blockchain technology. The most obvious ones to me are:

1. Use a cryptocurrency (Bitcoin, Ethereum ETH) as a part of your app. For example, you might accept payment using it, or reward users with it. You might choose this if your users request it, or are scraping the barrel looking to get the “blockchain” tech stamp on your product
2. Use blockchain concepts “from scratch”. At its core, the “blockchain” data structure is a linked list or DAG (directed acyclic graph, like Git uses) with each node (“block” if we want to make things readable here) having a hash signature which includes the hash signature of its parent. You need to add the “distributed” part if you want it.. but if you were to publish hashes publicly, anyone would be able to verify that the chain of blocks hasn’t been tampered with
3. Write and run a DApp (distributed app). In this scenario, you write code and have it execute “on the blockchain”. These Smart Contracts are written most commonly in Solidity, cost the currency of the blockchain to run, and while the functionality and storage on offer is very limited compared to typical applications, can do some very interesting things. Azure and AWS both have offerings here.

For the MegaDemo then?

After much research and experimentation, I settled on writing a DApp for Azure Blockchain Workbench. This gives you a relatively straightforward way of setting up a blockchain in the form of an Ethereum consortium. It’s a private blockchain, but you can authorise and connect other parties’ infrastructure: the other parties would be those you’re looking to share data with.

Blockchain Workbench also gives you:

• A REST API to create smart contract instances, and invoke methods on them
• A database which caches instances, activity logs and other details, and REST endpoints to query these
• A web app to upload and validate Solidity code, view smart contracts, history, invoke methods and so on
• Authentication via Azure AD

With just one party involved here, there is literally negligible to zero advantage of using blockchain. It’s a massive pain to use blockchain as a database in this way, and you’d better be sure that all other parties creating, hooking up, monitoring and validating that everything is correct with their workbench instance and role within the consortium – really know what they are doing too. Is it really worth it? For a very few use cases, maybe, in my opinion.

What will blockchain give us here?

It took a while to get here, sorry. What’s all of this actually going to give us, then? Simply put, the start of a distributed record of gaming sessions, their outcomes and validation statuses. What does that mean? –

• When a game session is played (e.g. Beat Saber song) – all the information about that session, including recorded data, song info, player info, final score – is saved to the blockchain* by an authorised service, in the form of a smart contract instance
• At this point, it’s been added, but is unverified and unauthenticated. The same service can choose to Retract the session. It’s not deleted from the blockchain, just marked as Retracted and nothing else can happen
• Either way, any automated “validation” services see the new session, and run analysis on it. For instance, running our AI process to see if the movement data seems to belong to the user associated with the session. They come to a conclusion, then submit a public Accreditation (“I think it’s valid”) or Discreditation (“I think it’s not valid”), along with some extra metadata and a confidence score
• Anyone with access can view a record of this at any time. So we’ll monitor it and build scoreboards for all of the Beat Saber tracks, and beside them display the results of our analysis (whether they are fraudulent or not)!

* – we don’t save all of the recorded data itself – that’s too much for the blockchain. We store a URL and a hash instead.

This is “fairly” pointless so long as there’s only one consortium member, one submitting service and one validation service. Blockchain adds very little in that case. However, things become more interesting with additional parties and services:

• Different parties can provide scoreboards and records for different games. By connecting to the consortium, they’re helping ensure trustworthiness and reinforcing the distributed nature
• With additional authorised validation services taking part, there’s no single authority saying what’s valid
• If a player or authorisation service is misleading, inaccurate, compromised or simply cheating, the record of everything they’ve done is there forever and can be ignored if desired

So, there we go. This could even become a real thing!

Implementation

It’s taken a lot of effort to get things up and running – writing Solidity and getting authenticated against the workbench API in particular were time consuming. It is hooked up however. Below is a screenshot of a session contract in Workbench – and note that this session is “discredited”, and in fact since switching things up with yet another VR rig for my user account (Valve Index), the AI is way off for me:

For now, the same BeatBrain API/database is keeping track of scores, blockchain status, and acts as a backend for a new songboard UI, which will be a key part of the demo – actually showing the outcome of everything, all in one place. I’m thinking a layout based on “widgets”:

To make a better demo, I’ll have it live-refresh, too.