Innovative thinking can overcome blockchain technology’s technical challenges



Already in 2017 we have seen the topic of distributed ledger technology (DLT) in financial services widely discussed, with the Depository Trust and Clearing Corporation (DTCC) the latest to commit to the technology. But as interest grows, the questions turn not just to the technology’s theoretical potential, but to its practicalities in financial services environments. Following our previous blog on the broad challenges to adoption, this blog examines the innovative thinking the industry is currently applying to help unleash DLT’s potential.
Privacy – on a blockchain, does everyone see everything?
DLT enables shared management of records and value between parties, without the need for a central authority. This often comes at the cost of privacy. For example, the Bitcoin and Ethereum platforms currently share all data with all participants on the network. For use-cases based around a pseudonymous network such as Bitcoin, this ‘everyone sees everything’ approach can be acceptable, even desirable. However, it’s unlikely to be compatible with the majority of use-cases in financial services, where full visibility of all transactions on the blockchain could reveal private activity.
We’ve seen two general approaches emerge to ensure privacy on DLT: restricted data sharing and encryption.
R3’s Corda platform is a front-running example of the restricted data sharing approach. Transaction data is only made available to those with a recognised ‘need’ to see the data; primarily the parties involved in the transaction, in addition to other actors who may need to view transactions, such as regulators.
Other platforms are focusing on privacy through encryption, but the use of encrypted data introduces its own challenges, such as how participants can validate transactions if the data is encrypted. This is being addressed with techniques such as ‘Zero Knowledge Proof’, under development by firms such as zCash.
Scalability – will blockchain networks be able to scale to meet financial services’ demands?
The question of scalability has two main facets: transaction processing, which is often talked about, and data retention, which is often overlooked.
Many core, high-volume areas of financial services demand processing throughput of the order of thousands of transactions per second (tps): the Visa network, for example, currently achieves around 2,000 tps. In contrast, Bitcoin currently performs at about 7 tps (with Ethereum roughly double that) meaning it is unsuitable for many FS applications, such as post-trade processing, which would require tps in the hundreds. The tps scalability limitations of traditional blockchain networks arise from two sources: the requirement to propagate data in a strict sequence, across all nodes in the network; and the use of proof-of-work type (‘mining’) methods to ensure all transactions are valid.
In addition to its role in privacy, the restricted data sharing approach discussed above offers major scalability benefits. Only a small set of nodes on a network are expected to ‘need’ to see a transaction, reducing the effort and time for data to propagate within the network. It also creates the possibility for unrelated transactions to be processed and committed to the ledger in parallel. It’s worth noting that this approach relies on a move away from the traditional blockchain: there is no single chain of blocks.
Various companies are exploring alternatives to the proof-of-work approach employed in traditional blockchain solutions to validate and achieve consensus on transactions. The objective is to reduce computational effort (and electricity usage), and hence improve tps rates.
Scalability in traditional blockchain networks can also be constrained by the need for data retention. On a global-sharing-based network, every node needs capacity to store a record of all transactions ever committed to the network. While Bitcoin transactions are relatively lightweight, financial services transactions can contain significant amounts of meta-data which will add to the data retention burden. Again, moving away from the ‘everyone sees everything’ approach will help minimise this challenge.
Interoperability – how will one blockchain platform talk to another?
We have previously touched on the topic of standards as a key tenet of interoperability between DLT platforms and other systems, but there are other important considerations in this area.
First is the question of cross-platform identity. In a simple example, a £1m netted cashflow to a bank (“Bank A”) determined on a distributed ledger requires settlement via a conventional payments system. Mechanisms are needed to remove any doubt that the party identified as “Bank A” on the DLT network is legally the same as the party which receives the payment via the payments system. This problem may also arise between two distributed ledgers built on different underlying platforms.
Second is the question of uniqueness. Where distributed ledgers are used to digitally transfer ownership of assets from one party to another, mechanisms are required to avoid “double-spend” issues, where one party might try, fraudulently or otherwise, to “spend” their assets (i.e. use in a transaction) more than once. This situation is further complicated where transactions involve transfer of assets across multiple ledgers, built on potentially different technologies. Resolving this would then depend on a common mechanism operating across each platform, guaranteeing consistency across them.
Right now, there is no definitive answer to these questions as companies and consortia are, rightly in my opinion, more focused on building out individual networks and proving the technology can achieve its potential. There’s no question that DLT networks will be massively more impactful when they can interoperate, and there is activity which will make this challenge easier to solve: the open-sourcing of codebases (IBM’s Fabric, R3’s Corda, Ethereum, Intel’s Sawtooth Lake etc.) helps each company understand how other platforms operate, and protocols such as Interledger (for payments) help with initial development of interoperable solutions. There is no quick fix, and the industry needs to focus on building individual, production-strength networks first before focusing on this challenge.
Security – is blockchain technology really secure enough for financial services?
Security has always been a key consideration when deploying new technology and its importance has increased in recent years with the rise in cybercrime. Furthermore, the scrutiny around security of blockchain networks has been intensified with high-profile hacks in the public blockchain space (such as BitFinex and The DAO). However, these hacks were largely as a result of poor implementations of the technology rather than fundamental weaknesses. As such, they provide timely lessons regarding the need for a full understanding of the technology. It is also worth noting that access to any financial services DLT network is highly likely to be limited to known, permissioned parties, thus reducing, but not completely eliminating, the security risks.
Most DLT networks are leveraging existing security approaches such as robust Public Key Infrastructures (PKI) and secure network messaging. Along with the use of existing industry-standard cryptographic protocols, this approach will facilitate the gaining of acceptance by financial services organisations and reduce time-to-market.
In summary, a range of innovative responses are being explored to address each of the technical challenges described above, leaving little doubt in my mind that industry-strength DLT solutions for financial services will eventually emerge. Different use-cases place different privacy, scalability and security demands on a network, and the extent to which each firm can tackle each nuanced challenge will in turn influence which platforms prove successful, and the timing with which they achieve mainstream adoption.
The likely outcome is an ecosystem of DLT platforms, each designed for different purposes, built on a range of underlying distributed ledger platforms.