Blockchain technology for smart ticketing

Familiar Issues

Many rail travellers still use paper tickets, but many now purchase tickets via a smartphone application or use a smartcard such as the Oystercard (in London) or ITSO card (several other areas in the UK). Before we describe how blockchain might contribute to an improved rail ticketing system, let us consider a couple of familiar scenarios sometimes encountered by travellers, personified here by the characters of Alice and Bob.

Alice is a frequent traveller on the railway. One day, she buys a ticket at the station, and uploads it to her smartcard. She boards the train, takes a seat, and relaxes. Seeing the inspector approaching, Alice reaches for her pocket to retrieve her smartcard. But alas, it is no longer there; she dropped it on the platform! Because the ticket is stored only on the smartcard, and not additionally on her smartphone, Alice has no way of validating her proof of travel and has to pay a fine.

Bob is travelling from one end of the country to the other to attend an environment conference. Aware of the negative impact of single-use paper tickets, he looks to buy a ticket using a smartphone app. However, the mobile ticket is not valid with some of the companies he uses along the way, so he must buy a paper ticket. This annoys Bob, who is keen to eradicate the waste created by single-use paper tickets.

Situations like these frustrate passengers. Our digital tickets are not perfect; the most flexible ticket option on our railway is still the trusty paper ticket. But we know how wasteful this approach is, and want to cut down on such waste. So how can we achieve smart ticketing for our railways that is truly “smart”?

STUB: System for Ticketing Ubiquity with Blockchains

The Birmingham Centre for Railway Research and Education (BCRRE) is developing the System for Ticketing Ubiquity with Blockchains (STUB). This platform will use the mechanics of blockchain technology to replace the legacy ticketing systems. STUB's purpose is to create a true digital equivalent of the paper ticket: something that is recognised by all passenger train operators across Great Britain, no matter where or how it was purchased, or from whom.

System Design

The current approach to STUB uses Hyperledger Fabric, designed by IBM. This is a “permissioned” blockchain, meaning it maintains an access control layer which ensures certain actions can only be carried out by certain identifiable participants (see figure 1). At the highest level are the organisations: in yellow, the Train Operating Companies (TOCs), in blue the Ticket Vending Organisations (TVOs), and in red external organisations such as the Rail Delivery Group (RDG). These organisations are responsible for maintaining rail and ticketing infrastructures, and accessing the data to produce meaningful statistics.

Figure 1: The STUB platform architecture

A Fabric network consists of channels. Each channel supports a different ledger, so a single Fabric network may host multiple blockchains. Both the network and the channel have a policy, which consists of two key elements: a Membership Service Provider (MSP), responsible for determining the users within the domain; and the rules defining the permissions for these users. The Network Policy for STUB is maintained by the RDG. This allows the RDG control over who may host peers, join certain channels, and initiate transactions. The version of STUB in Figure 1 has one channel (denoted by the dashed line), with the TOC, the TVO, and RDG controlling the channel policy. This means each organisation has a say in who may host nodes and conduct transactions within the channel. Find out more about blockchain nodes and transactions.

Each organisation hosts at least one peer node within the channel; each peer node stores a copy of the distributed ledger (the blockchain) and the smart contracts responsible for dispensing and validating tickets. A smart contract is an executable piece of code which is stored at an account on the blockchain, and invoked by sending requests by transactions to the account. Because the blockchain is immutable, the code remains constant. They are ‘smart’ because they allow for automation of processes on the blockchain platform. Each organisation also has a local MSP for denoting the users of the Fabric network within the organisations (In practice, each organisation has several accounts and nodes, but for simplicity we will assume it is one per organisation).

A TVO offers tickets to passengers from an application. An application in this sense is any terminal where a passenger can buy a ticket via software. These could be hosted in ticket offices, station ticket machines, and the internet, so long as it connects to a node on the blockchain network.

A passenger buying a ticket will also have a STUB account. This will consist of a cryptographic “keypair”: a public and private key used to prove their identity. This information will be wrapped in  a X.509 certificate, which also stores relevant details about the passenger, such as railcard information to link a discount directly with the passenger. The passengers’ account details are stored within the certificate authority and reflected in the Channel MSP, so each organisation may access and validate the passengers’ credentials hosted by other organisations.

Each passenger has a unique STUB account with the information described above. The public key linked with the account acts as the ‘username’ ; it can be stored as a Quick Response (QR) code on a smartphone, or transferred via Near Field Communication (NFC) from a smartcard. To buy a ticket, the passenger enters their public key into the application and verify their identity with their private key. The application communicates with a network node to issue a ticket to the passenger’s STUB account using a smart contract. The node will send a request to add this ticket transaction to the blockchain, and the other organisations will offer their consensus via Fabric’s consensus mechanism, to ensure the transaction is valid. To verify their ticket is valid, passengers merely have to prove the STUB account public key is theirs, by using their private key.

Advantages

Systems like STUB provide technical advantages. The Fabric architecture enables participating organisations to share ticket data and system governance. Fabric offers a high latency of up to 3,000 tps (transactions per second). Research has proven this can be scaled to up to 20,000 tps - more than enough to cope with even the busiest periods of passengers passing ticket validation points (such as gatelines and guards) on the rail network.

It also improves the passenger experience. The passengers’ tickets are not restricted to one organisation or one device; they are available anytime and anywhere on the rail network, on any device. Each organisation has constant access to every ticket on the blockchain, and can check the validity in an instant. The competition between organisations is preserved: the platform maintains the use of existing methods of payment, so that passengers can decide from whom they wish to purchase their tickets. These applications can retain existing payment methods, including cash, card, and bank transfer.

STUB helps to reduce waste. Passengers no longer need single-use paper tickets, as their tickets are stored on the blockchain. The passenger can access their ticket in various ways such as QR Codes, NFC on multi-use cards, and web applications. STUB will always access the passenger’s original ticket.

For Alice, it no longer matters that she has dropped her smartcard, because she can access the same ticket on her smartphone application, and she can immediately notify the network that the smartcard is no longer a reliable point of identity. Bob can feel happier knowing that his trips are not adding unnecessary waste to the environment.

Disadvantages

There are many advantages to this approach. However, it would require an overhaul of ticket validation points. Validating a ticket requires a connection to the blockchain network to obtain the latest transactions on the ledger, requiring a good internet connection and suitable backup protocols.

For passengers, drawbacks include having to provide credentials to sign-up to the system prior to their first use, which may be a stumbling block to some passengers who do not wish to share such information. Passengers also need to obtain one of the methods of access (such as a smartphone or other device), which some will not have or want to have.

Summary

Blockchain presents an opportunity to allow competing organisations to collaborate the fundamental ticketing data without compromising on security or competition. Moving to blockchain technology can benefit GB railway’s passenger and commercial experience.

This system has the potential to expand: into metro networks that do not currently accept mainline tickets; rail networks of other countries; and even into transport domains other than rail. It is the first step towards a cohesive system, and blockchain is the driving force behind it.

This article was written by Joe Preece from The University of Birmingham. jdp225@student.bham.ac.uk