Design Walkthrough for a gaming leaderboard on Corda.

October 19, 2020

How you can use Corda in specific problem spaces?

Photo by Markus Spiske on Unsplash

 

When new hires start at R3, we’re often asked to build an introductory CorDapp as part of our onboarding. When we think about blockchains, it’s not always obvious to think about where or how to use them or apply them to our problems. I’d like to walk you through a similar thinking process about how to use a blockchain in a decentralized context.

Let’s start with a basic fact, when we use blockchains, we create an immutable record of the truth of what happens. This record is created when peers to a transaction agree to that transaction. In Corda, these transactions are ideally only shared between parties to that transaction.

The context I picked at the time was actually for tracking wins and losses in online games. If an immutable system is created with wins and losses recorded, this naturally brings about bragging rights for someone who can keep a good ratio. This gaming use case sounds intuitive enough for a blockchain. Most games have clear winners and losers, and storing them is often done anyway in centralized systems that are not always right for the job.

Most games are really played on a one to one basis. One person wins, and their player credentials are updated with the new win. So how does this play out in the blockchain context?

Well, each player gets their own Corda node (or logically isolated Corda account!) and then use it as an entity within a game transaction when playing a game with someone else. One transaction to start a game, and another to end it and specify the winner. That Seems straightforward enough?

Remember that blockchains are an immutable record of the truth

Clarifying Some Abstractions

So if you’re unfamiliar with the fundamental Corda abstractions for smart contracts, I’d highly recommend taking a look at this blog post on our developer introductory workshops.

Transactions in Corda follow the UTXO model for blockchain transactions. Practically, when a game is started, we could create our game with one transaction (between the other player and ourselves) and then have a second transaction to update it after the game ends.

So let’s start with a basic diagram of how this might work:

Image for post

The basic design for our game tracking CorDapp

Typically blockchain applications have a protocol of broadcasting transactions to everyone on the network. In Corda, every transaction is only shared with the nodes that actually need to know that information. So we run into some different features and issues.

So what if you wanted to create a leaderboard? How would that work? Here are two (of many) possible solutions:

  • Make a Corda observer node that observes all transactions on the network
  • Make the leaderboard node a party to every transaction

If your instinct was for a single node to observe all transactions without being a part of them, you’ve got the right idea.

This is where a Corda observer node can be quite powerful. Observer nodes are designed for watching and collecting transactions in a stream and can often be used to simulate regulators’ roles.

Image for post

Example Corda network using observer nodes

We now have a theoretical design for a CorDapp that can create and end games. We also have a leaderboard mechanism to be digitally available for anyone on the network with access to the observer.

One last piece of this design you may want to think about is how we actually ensure the games are resolved the way the nodes say they are?

There are plenty of times where you’d want to introduce outside facts (like a stock price or the outcome of a game) into your transaction. This is where we need to do some additional thinking.

Let’s make sure the nodes are being honest

If there’s one thing the video game industry loves to do, it’s to hack tools designed for gamers. In a system where credibility is the product, the prize can be quite valuable. We just have to do two more things. We need a way to ensure the facts reported in these transactions are valid. We also need a way to ensure the facts reported are actually true.

We could do some basic things with contract rules to ensure that legitimate things are happening here for starters. I’ll outline some here to get the idea across:

  • Validating a timestamp in a contract, let’s say that the last game played was at least 3 minutes ago. If you report winning two hundred games all at once, that’s probably false.
  • Validating that the actual amount of time that the game lasted was over 60 seconds. Most games are at least longer than a minute.
  • Validating that the games played are not being instantly forfeited or run in some obvious computational way to game the system.

Image for post

Our final Corda network design

The other aspect I mentioned was to make sure that the facts reported are actually true. Ignoring the epistemological problems here, it’s actually a perfect use case for Corda Oracles. These are essential services designed to report real facts about the world external to your Corda network.

Of course, if given a choice, both players would say that they won. This is where we need oracles to help with determining what the facts are. The oracle could contact the game server and analyze what happened within the actual game session to determine whether a given fact is true, given all evidence available to it. It’s quite a powerful tool when used well.

Image for post

Photo by Nikita Kachanovsky on Unsplash

If you’re curious about this and want to try your hand at building the game tracking system I’ve outlined here, I’d highly recommend looking at our documentation on the Corda core concepts, States, Contracts, and Flows.

If you could get through this article, I have no doubt that you’re a significant gamer. I’m sure you’d be an epic blockchain developer as well.

Good luck on the quest.

Want to learn more about building awesome blockchain applications on Corda? Be sure to visit https://corda.net, check out our community page to learn how to connect with other Corda developers, and sign up for one of our newsletters for the latest updates.

— David Awad is a Developer Evangelist at R3, an enterprise blockchain software firm working with a global ecosystem of more than 350 participants across multiple industries from both the private and public sectors to develop on Corda, its open-source blockchain platform, and Corda Enterprise, a commercial version of Corda for enterprise usage.

Follow David on Twitter here.

Share: