DLT, or not DLT? That is the question – Bank Underground

Simon Scorer

The topics of central bank digital currency (CBDC) and distributed ledger technology (DLT) are often implicitly linked. The genesis of recent interest in CBDC was the emergence of private digital currencies, like Bitcoin, which often leads to certain assumptions about the way a CBDC might be implemented – i.e. that it would also need to use a form of blockchain or DLT. But would a CBDC really need to use DLT? In this post I explain that it may not be necessary to use DLT for a CBDC, but I also consider some of the reasons why it could still be desirable.

CBDC and DLT

At its simplest, a UK CBDC would be a form of widely available, electronic sterling, issued by the central bank (think ‘electronic cash’). It’s important for central banks to determine exactly what might motivate them to ever issue CBDC – the Bank of England has published some research questions considering the potential monetary policy, financial stability, macroeconomic, and financial system impacts, as well as the technological feasibility. A number of other central banks are also considering questions related to CBDC (including Canada, the ECB, Sweden and China). In this post, I focus solely on the technology that might underlie a CBDC.

The motivation will be essential in determining the necessary features, and therefore the technical requirements, of any CBDC. Much of this is still uncertain, although there are a number of high level features that are reasonably safe to assume for any variant of a CBDC, including: scalability, confidentiality, resilience and security.

DLT refers to a family of technologies that use a distributed group of participants to collectively maintain a shared, replicated and synchronised record, without reliance on a single central party or centralised data storage. One specific example of DLT is the blockchain technology that was introduced by Bitcoin over 8 years ago. Traditional centralised systems, by contrast, rely on a trusted central party to maintain the record.

A CBDC might use a form of DLT, or it could be centralised. Various options should be assessed against a number of requirements. The risks and benefits of centralised systems are already fairly well understood, so an interesting area of research is exploring the possible risks and benefits of using DLT for a CBDC.

Permission-less Bitcoin vs Permissioned CBDC?

The most fundamental problem any DLT must solve is in finding a way for a distributed group of validators to agree upon which transactions should be recorded, and in which order – i.e. they need a mechanism to reach consensus on the ledger.

Bitcoin was designed to do this without the need to trust any individual parties, and this resulted in some innovative features. However, the environment in which a CBDC might exist would be fundamentally different. The presence of at least one trusted central party (the central bank) means that many of Bitcoin’s design features would be neither necessary nor desirable for a CBDC.

A ‘permission-less’ DLT, like Bitcoin, is one in which anyone can act as a validator, at any time, without first establishing any credentials. In this scenario, a voting-based process could easily be manipulated as anyone could simply pretend to be multiple entities and rig the vote. A key innovation of Bitcoin was using a ‘proof-of-work’ mechanism to solve the problem of distributed, trust-less, consensus. This incentivises validators to compete to verify blocks of transactions in return for newly minted bitcoins (a process commonly referred to as ‘mining’). An attacker could still pretend to be more than one participant in this process, but they couldn’t fake the computing power needed to solve the proof-of-work challenge. This has resulted in heavy investment in processing power by Bitcoin miners and, consequently, the system requires enormous amounts of energy to operate.

A CBDC, by contrast, would naturally have a trusted party with some degree of central control (the central bank). So if a form of DLT were to be used, this could be a ‘permissioned’ system, where the validators were known and authorised. A proof-of-work mechanism would no longer be needed and simpler, voting-based, consensus mechanisms could be used instead. These approaches have been around for decades (e.g. Practical Byzantine Fault Tolerance), but the risks and challenges of applying them to a CBDC would need to be fully explored.

There would be no mining rewards in a permissioned system, so transaction validators will need an alternative incentive to perform this role. This could involve the collection of transaction fees (like Bitcoin), but there may also be other ways to remunerate participants.

Potential risks and benefits of using DLT for CBDC

Perhaps more significant than how a CBDC could use DLT, is the question of why a CBDC might use DLT. Clearly, there are a number of significant challenges and risks in considering such an unproven technology, not least around whether DLT is capable of the scalability and security needed for a CBDC. I consider several potential risks and benefits of DLT, although many of these are still far from proven.

One possible advantage of using DLT is the high level of operational resilience it might offer by avoiding a single point of failure. This could enable very high levels of availability, which would be of vital importance in any widely available CBDC. The distributed nature of DLT means that if any one of the validators stops working then the system can continue to operate without any interruption. In principle, this could enable the potential to withstand (at least temporarily) even the absence of the central bank – a fundamental difference to existing centralised financial architecture. However DLT does not necessarily offer resilience against every scenario, such as a bug in a system where all nodes are running the same code. Centralised systems also use certain measures to achieve high levels of resilience, for example by operating multiple backups. But DLT might offer a considerably increased level of resilience – and potentially more efficiently and cheaply.

This resilience comes at a cost: you only get the full resilience benefits if you’re willing to allow multiple parties (i.e. transaction validators) to manage transactional data; which raises significant privacy challenges. Many existing DLT systems use pseudonymous ledgers, where individuals are represented by addresses rather than their real-world identities. However, this is not the same as true privacy; a number of studies have demonstrated that a lot of information can be determined by analysing such pseudonymous ledgers. Instead, two broad approaches appear to be emerging to tackle the privacy challenge in financial applications of DLT.

One approach is to not include sensitive data on the shared ledger. Only the counterparties to a transaction see the full details; once they agree a transaction the shared ledger records only partial details, or simply a reference to the deal. However, this approach may limit the extent of any resiliency benefits.

Alternatively, sensitive data could be included on the shared ledger, but be fully encrypted. This presents a significant challenge in asking a group of participants to agree on the validity of transactions, without allowing them to see the full details. Methods are emerging in applying cryptographic techniques to DLTs to enable this (e.g. zero-knowledge proofs). However, the additional encryption will add significant complexity, and raises questions over the potential speed and scalability of any system. It also raises security questions, as cryptographic techniques may weaken over time, meaning it could become possible for participants to decrypt the full ledger at some point in the future.

The operational demands on the central bank might also offer a potential benefit. A CBDC could enable everyone to make payments in electronic central bank money, resulting in a huge increase in the volume of transactions compared to existing real-time gross settlement (RTGS) systems. Central banks may not want to expand their computing or operational capacity to cope with this. DLT might allow multiple firms to provide this computing capacity on demand, and could enable the central bank to set the rules of a CBDC, without the requirement to operate the entire infrastructure.

The cyber-security implications of DLT are another important consideration. DLT might present an increased risk of unauthorised access to data, as more parties have direct access to the system. But could DLT also offer some cyber-security benefits? For example, if a single party is compromised, the consensus mechanism may be able to ensure that the other participants reject any phony transactions.

CBDC research

So, there are a number of challenges, but it could be possible to adapt DLT for permissioned environments, and there might be some benefits in using this to implement a CBDC. However, by adapting DLT in this way, you move further away from the principles for which it was originally designed. Would this type of adapted DLT design be an optimal solution to a CBDC? Or could you achieve all the necessary features in a completely different and potentially much simpler way?

Ongoing CBDC research will benefit from complementary views from numerous disciplines, and there is much scope for future research to inform central banks’ decisions.

Simon Scorer works in the Bank’s Digital Currencies Team, Notes Directorate.

If you want to get in touch, please email us at [email protected] or leave a comment below.

Comments will only appear once approved by a moderator, and are only published where a full name is supplied.

Bank Underground is a blog for Bank of England staff to share views that challenge – or support – prevailing policy orthodoxies. The views expressed here are those of the authors, and are not necessarily those of the Bank of England, or its policy committees.