Using Blockchain Better: The “Source of Truth” Model

Photo by Evgeni Tcherkasski on Unsplash

In recent articles, I described a new way of thinking about blockchain development, particularly for enterprise applications. I wrote about the “false dichotomy” splitting blockchain supporters into mutually opposed (and equally misguided) views of the right way to use blockchain. And I wrote about making blockchain truly useful to businesses by identifying BOAs — business-critical objects and actions — as the basis for blockchain usage.

In both articles, I mentioned that blockchain’s real strength is only realized when a business uses it as a “source of truth”. This model for blockchain usage provides structure for airtight management of BOAs, making blockchain a practical business advantage rather than a buzzword. But in absolute brass-tacks terms, what does a “source of truth” really mean to a business and a developer? Let’s break down a real use-case to see.

A Simple Example Use Case

We want to build an event ticketing application. This application will let entertainment venues create digital tickets for events, it will let users register and buy tickets to events, and it will let the venue check and redeem digital tickets at the door of the event.

This is a relatively simple application, but it is a nice example of a transactional system — one where incorrect management of the flow of an asset (the tickets) will quickly cost our company money and create angry users. To emphasize the point, imagine if instead of tickets we were talking about refrigerated food containers, shares of gold, or prescription drugs. The form of the system is similar, but the stakes get very high indeed!

The Traditional Approach

The most important part of this application to consider is managing the ticketing and redemption correctly. For a traditional, non-blockchain transactional system, I break down the functionality needed into three parts:

• Ticketing System Logic — This part interfaces with the users of the system and is the REQUESTER of transactions such as “Alice would like to redeem a ticket”
• Ticketing Transaction Handler — This part receives requests for transactions and applies the correct ticketing RULES, such as “Alice must have purchased a ticket in order to redeem one”, and passes the result back to the requester.
• Ticketing Database — This part stores the RECORDS of the state of the system, such as “Alice is a known user who has purchased a ticket”, which the rules check and update.

Now let’s run through a single transaction through this system: Alice is at The Spot (our venue) and shows her phone, supposedly with a digital ticket to tonight’s Big Show, to a ticket puncher. The ticket puncher also has a phone that is connected to the Ticketing Application with a Venue Admin login that will give him the thumbs up/down on Alice’s ticket.

Here’s what should happen:

1. Alice shows her digital ticket, letting the system know who she is (alice@email.com) and that she wants to redeem a ticket to the Big Show
2. The Ticketing System Logic validates and translates this into a request to the Ticketing Transaction Handler: REDEEM REQUEST alice@email.com
3. The Ticketing Transaction Handler knows that for this kind of request, it must check in the Ticketing Database if alice@email.com has an entry in the database, and if the ticket status field for that entry is set to “UNREDEEMED”. In this case, both are true.
4. The Ticketing Transaction Handler now does two things. First, it responds to the Ticketing System Logic: “REQUEST OKAY”.
5. Second, the Ticketing Transaction Handler must update the Ticketing Database to correctly show that the ticket status for alice@email.com should now be “REDEEMED”.
6. The Ticketing System Logic can now pass a message to the ticket puncher that Alice’s ticket is indeed good.

So how do we build this? The most critical attribute of this kind of transactional system is that the results must always be correct (avoiding costing the company money and angering users). The really sensitive stuff is happening in steps 2–5 between the Ticketing Transaction Handler and the Ticketing Database. These are the Rules and Records steps where even small errors lead to bad situations. For example, If step 5 fails to happen then Alice will be let into the show, but her ticket will still be available to use again — this is called a “double-spend” error.

Traditionally this means building the Transaction Handler very carefully and building the Database with a lot of redundancy. This may not seem like such a big deal looking at one ticketed show, but imagine if our ticketing application were handling thousands of shows worth millions of dollars in tickets; one coding error in the Transaction Handler could quickly and invisibly create many thousands of bad ticket transactions that could cost our fledgling company dearly. Now imagine building an application to handle transactions of refrigerated food containers, shares of gold, or prescription drugs!

Bringing in Blockchain

Blockchain seems like it might offer a potential solution, but integrating blockchain into our system does not automatically fix the problem we discover. As a business, we don’t hear compelling blockchain stories from either side of the “false dichotomy” argument that I wrote about previously:

The “Dataloggers” suggest simply using blockchain for the bottom-most layer — the ticket database. We would simply write results to the blockchain, such as “alice@email.com successfully redeemed a ticket”. This does deliver useful tamper-proofness via blockchain’s immutable history, but others point out that a simpler append-only database can provide the same functionality. And we still need to build a complex and sensitive Ticket Transaction Handler to avoid errors.

The “Decentralizers” suggest putting all three layers of the application system above into “smart contract” code running on blockchain. In theory this can solve the transaction correctness problem, but in practice implementing the entire application with highly specialized smart contract code is massively impractical and risky to deploy. The application would be able to run entirely on a public blockchain, but what benefit does that offer us?

So how do we use blockchain better to solve our business problem?

The Source of Truth Approach

What we want for our application is an absolutely error-proof and tamper-proof Rules and Records system. The ideal form of this system would accept REQUESTS and correctly process the Rules and update the Records in a single step so that the RESULT can be relied on with absolute certainty. That is, there should be no possibility of receiving a “REQUEST OKAY” unless: Alice did in fact have an account, Alice’s ticket status was in fact “UNREDEEMED”, and if that status was in fact set to “REDEEMED”.

When used correctly, blockchain can provide exactly this kind of error-proof, tamper-proof transactional “Rules and Records” system. The best use of blockchain is to ensure the business-correctness of the transactional part of our application — exactly the sort of thing blockchain was designed to do well. Used in this way, the blockchain system actively prevents business errors and always represents the absolute state of the business. This is what I mean when I refer to a Source of Truth.

We shouldn’t underutilize blockchain, relegating it to the role of low-value database that can as easily be an immutable Source of Untruth as it can Truth. Nor should we try to force everything onto blockchain creating nothing so much as a source of development risk and headache.

BOAs Define the Source of Truth

So how exactly do we “use blockchain correctly” to provide a transactional Source of Truth? In short, we directly model our BOAs (Business-critical Objects and Actions) as blockchain-enforced primitives. That is, rather than just writing data to the blockchain, we structure our use of blockchain so that business-level REQUESTS correspond directly to single-step blockchain transactions.

Blockchain technology is designed to ensure the correctness of these sorts of transactions, either rejecting them as invalid or committing them to its immutable record by the rules set out. With blockchain, Rules and Records may be combined to guarantee the correctness of result and state together. This is exactly how Bitcoin works and why it was revolutionary — but a developer building their own blockchain application must thoughtfully structure their usage to achieve this result.

Okay, let’s make this practical by applying this approach to our ticketing application. First, let’s list out the most basic BOAs for our ticketing business:

Business-critical Objects

• Users
• Venue
• Event (at Venue)
• Ticket Printer (for Event)
• Tickets (to Event)

Business-critical Actions

• Creating tickets (in correct quality)
• Issuing tickets to users
• Redeeming tickets

Now we model these BOAs as blockchain primitives. How precisely we do this depends on the specific blockchain technology selected, but two very common blockchain primitives are useful here: Tokens and Accounts. We can use these nicely for this example. Bitcoin is essentially defined by these primitives, with Accounts (“addresses”) acting as secure containers that hold Tokens (“Bitcoins”), and where there are certain rules for how Tokens are created (“mining”) and how they can be transacted (nobody can double-spend, etc.). Using other more flexible blockchains, we can define our own Tokens, Accounts, and more that can represent the behavior of a wide variety of BOAs.

Note: The reality is of course more complicated, with Bitcoin’s primitives buried in the protocol definition. Some blockchain technologies (or more generally distributed ledger technologies or “DLT”) allow developers to directly create their own Tokens, Accounts, and associated rules via API. Others require smart contract code to create these primitives. I prefer the former: DLTs that natively think in terms of these primitives and provide the API approach, as it is much easier and more secure to build this way. But either way, the functional result is essentially the same.

Here is our ticketing application system with our Users, Venues, Events, and a Ticket Printer represented as Accounts, shown as rounded rectangles inside our Private Blockchain (although it could as easily be a Public Blockchain if preferred):

In the middle, we have written some “Request Handler” code that controls all of these Accounts, and will talk to the Ticketing System Logic; we can call this our “DLT Middleware”. (This DLT Middleware could also handle other coordinated functions like management of private keys and personal information, but let’s leave those functions for another article.)

Notice also that the Event Account is controlled by the Venue Account. This is done using another common blockchain capability called “multi-signature”, allowing one or more Accounts to control the actions of another according to certain rules. This is useful here so that multiple Events may be associated with a single Venue that is allowed to manage those Events.

So where are the Tokens? What about the Actions? Let’s crank the system up and process an end-to-end user flow:

The Request Handler — the gateway to our ticketing Source of Truth — is taking REQUESTS from the Ticketing System Logic, attempting transactions with the Accounts on our blockchain, and returning RESULTS. From left to right within the blockchain, we have several transactions shown (in purple ALL CAPS):

1. First, we CREATE TICKETS for the Big Show. You may have noticed the purple outline around the Ticket Printer. We created this as a special Account which has exclusive permission to create a certain type of Token — our tickets. In this case our Venue, The Spot, is quite small and so there are only 6 tickets available. We create 6 Tokens inside this Account, ensuring that we can never have an incorrect number of tickets in the system thereafter.
2. Next, Alice buys a ticket with our application. We attempt to have the Ticket Printer ISSUE TICKET by transferring one Ticket Token to the User Account we set up for her (using her email address as a unique identifier). No reason Alice’s User Account can’t have a Ticket Token, so the blockchain accepts the transaction.
3. Now Alice turns up at the door of The Spot with her phone showing that she, alice@email.com, has a ticket to the Big Show. Should the man at the door (the Venue Admin) let her in? The application attempts another transaction: REDEEM TICKET by transferring a Ticket Token from Alice’s User Account (the account associated with alice@email.com) to the Big Show Event Account. We’ve configured the Event Account to only accept transfers of Ticket Tokens for the Big Show. Again, no problems here: The User Account exists, it has the Token in it, and it is going to an Event Account that can accept it. The Token is transferred and Alice is officially in.
4. Now Bob shows up to the show and claims he has a ticket. We attempt the same REDEEM TICKET transaction we did for Alice, but this time there’s a problem. While Bob did register an account for bob@email.com, he never bought a Ticket and so he has no Ticket Token in his User Account. We don’t have to check that; we simply attempt the transaction and the blockchain rejects it as invalid according to the BOAs we’ve encoded. No Token, no transaction, no entry. Sorry, Bob.

All of these transactions are committed or are rejected in a single step, directly corresponding to how we want the actual business to operate with its BOAs. There is no possibility of selling too many tickets, double-spending Tickets that were sold, or incorrectly redeeming a ticket that doesn’t exist.

Conclusion

The ticketing application example may be cheeky, but it conceals a subtle and important difference from the traditional system. Through the creation of our simple system of Accounts, Tokens, and a few basic rules within our blockchain itself, we can now have absolute trust that our blockchain “Source of Truth” represents reality. We did this with minimal specialized code, but the result is a transactional system with enterprise-grade security and reliability.

This is immensely powerful for a small business that wishes to scale up the number, complexity, and value of the BOAs it has to manage in order to disrupt its industry. It’s also highly valuable for the larger enterprise that is hungry for efficiencies and greater security to maintain its market position and profitability. It’s an approach that I expect to be embraced by more developers — and by more creators of DLT — as understanding of the technology matures.