Blockchains in Transit?
June 2, 2016 - Is there a role for blockchain technology in transit? David Bakker has the answer.
No doubt you are aware of Bitcoin, that grand idea to use the power of cryptography and the distributed nature of the internet to do away with the European Central Bank and the Federal Reserve. Unfortunately, Bitcoin currently seems to be bogged down in the morass called anarchy, which was perhaps predictable given humanity’s earlier experiences with throwing out all trusted authorities. But even as Bitcoin’s future looks less bright now than it did some time ago, blockchains are all the rage, especially in the financial industry. And since the transit ticketing industry is always eyeing the financial industry to see what’s next, it’s natural that our transit customers are asking us if there is a role for blockchain technology in transit. This post is an attempt to answer that question.
What would a ticketing blockchain look like?
Let’s start with the basics and try to describe what a blockchain is. Like with every technology, it’s hard to come up with a description that suites everybody, but I think most people would more or less agree with the following: A blockchain is a database of digital events (or transactions) that is distributed over many parties. Once an event is in the database, it cannot be changed by anybody, but new events can be added. There is no trusted database manager; instead, a new event can be added by any of the participants after consensus has been reached with a majority of other parties. Each participant gives or denies its approval for a proposed new event based on some real-world rules about the relationship between that event and all existing events.
That’s quite a mouthful, and the internet is full of interesting articles explaining each of these elements in detail. But what would a blockchain for public transport look like? I propose that it would replace the database holding the customer accounts in a fully account-based ticketing system. So it would keep track of which customers own which rights-to-travel. (If you have other ideas for a role of a blockchain in ticketing, let me know!)
An interesting question is who would be participating in a ticketing blockchain and how we could implement the main transit use cases. I think there are at least two possibilities:
- A public distributed ledger in which also customers participate directly. Customers could obtain a ‘wallet’ application on their phone in order to use the blockchain. Supposing all systems are always online and connected real-time , all necessary use cases could be implemented by inspecting and/or modifying the blockchain. For example, if a customer buys a right-to-travel from a product retailer, the product retailer would create a transaction in the blockchain to associate that right to travel with the customer’s wallet. If the customer wants to check-in, he creates a check-in transaction on the blockchain. This could be done manually via a wallet GUI, but the wallet application could also be set up in such a way that it creates a check-in transaction automatically if the customer presents the phone to a terminal or gate. Inspection could be done by letting the wallet communicate a wallet identifier to the officer, after which the officer inspects the blockchain to see if a valid check-in transaction was done.
- A private ledger in which only companies such as public transport operators, product owners and product retailers are allowed to propose new transactions. In this case, a check-in transaction would be created on the blockchain by a terminal, after the customer presents some token.
I don’t go into the advantages and drawbacks of these solutions, because I promised to answer a more fundamental question: is a blockchain potentially a useful technology for public transport ticketing systems?
Determining Blockchain Viability: Six Conditions
How do we determine in which situations a blockchain is a viable technology? For that, I refer you to a great article by Gideon Greenspan of Multichain. You should definitely read it for yourself, but basically he says that if a traditional relational database like Oracle and SQL Server can do the job you have in mind, you’d be wrong to use blockchain technology. By nature, blockchains are more complicated than normal databases, and moreover the technology is essentially still experimental. The article lists five conditions that must be fulfilled before you should even start thinking blockchain:
- There is a need for a database that contains ledger-like information (which participant owns (how much of) which asset).
- The database needs to be readable and updateable by multiple parties. In the counterfeit example above: everybody owning one of these valuable items must be able to transfer that ownership to somebody else, and everybody interested in buying such an item must be able to verify that the item is actually genuine.
- There must be a lack of trust between these participants. This means that nobody is willing to a priori accept the addition to the database of a new event proposed by another participant.
- Moreover, there must also not be any third party that is trusted by all (otherwise non-trusting) parties. Or at least, there must be reasons to prefer the absence of such a party.
- As explained above for the case of counterfeit, there must be some real-world logic that allows all participants to objectively determine whether or not a proposed change to the database is allowed.
And in another article, the same author adds an important condition for the use of blockchains:
6. There must not be a high need for confidentiality of the events (or transactions) in the blockchain. This is because by its very nature the blockchain is distributed over many parties. Obviously, blockchain implementations can vary in the number of allowed participants, but there will always be multiple copies instead of just one.
Applying the Conditions
To me, the above looks like a very sensible list. So does a transit ticketing scheme fulfill these requirements? Let’ see.
Condition 1 (Need for a ledger): Yes, but with complications. In any transit ticketing scheme there are assets called rights-to-travel. If the ticketing scheme is account-based, all of these travel rights are digital and are stored in a database. If the communication infrastructure moreover allows real-time communication between terminals and back office, in principle you could use a blockchain.
However, rights-to-travel are a complicated asset, as they come in many types. One common type is a purse, which is easy to handle on a blockchain. But a period pass is more complicated, because a check-in event on such a pass does not link directly to a transfer of ownership (or value) from the passenger to the service provider. Assets are often time-bound or geography-bound. Some other assets are not even a right-to-travel by themselves, but must be used in combination with another asset, such as products giving a reduction during certain periods. To handle these different assets, public transport schemes use a dedicated piece of software called a transit engine. A major question is therefore whether the transit engine could somehow be made part of a blockchain. I come back to this point below.
Condition 2 (Many parties): Yes. Product retailers must be able to add a right-to-travel to the account of a certain customer. Customers can spend these travel rights at a public transport operator, which means that public transport operators must be able to remove or lower the right-to-travel in the customer’s account. (The rules for this of course depend on the exact type of asset, as explained above.)
Condition 3 (Lack of trust): Yes, there definitely is a lack of trust between parties. Public transport operators don’t trust customers, and customer don’t trust other customers. After all, some customers would definitely like to get travel rights for free or to use other people’s travel rights. There may also be a lack of trust between for example product retailers and public transport operators.
Condition 4 (Absence of a trusted third party): Questionable. By its very nature, organizing public transport is a responsibility of governments. That means that governments (via public transport authorities) will always be involved in setting service levels and prices. By and large, the respective authority/government is trusted by all parties involved. (And if it isn’t, they’ve probably got some more pressing problems on their hands!) So if by nature a trusted third party is involved in public transport ticketing, what’s the problem of letting that party be the one that operates (or at least audits and verifies) a standard central database? I don’t see a good answer to that .
Condition 5 (Logic to determine acceptable transactions): This is challenging because of the nature of assets and transactions in public transport. I’ve talked about the complications regarding assets above already. But transactions are similarly complicated. For example, the outcome of a check-out transaction typically depends on a previous check-in transaction. A sale transaction may similarly depend on assets or information already present on the blockchain, for example a reduction-giving product or an indication of age. An extra complication involves the possibility to blacklist the token used by a customer to propose a new event for the blockchain.
It is true that blockchains can contain ‘smart contracts’. This might offer a way to code the rules of a transaction into the transaction itself. As said above, in a ticketing system these rules are carried out by a transit engine. However, I strongly doubt whether it is feasible (or desirable) to incorporate the entire transit engine on a blockchain.
Condition 6 (No high need for confidentiality): Again, challenging. We all know the discussions on privacy. It is unlikely that a privacy commission would allow to publish all transactions done in a public transport system in a public database.
If you made through this lengthy post, I guess my message is clear by now. The prospects for a ticketing blockchain don’t look very promising, given the complicated nature of assets and transactions in public transport, the fact that a trusted intermediary is already there and the industry’s privacy mandates. But it’s early days still, so I may be all wrong. Let’s hear from you if you disagree!