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 bankunderground@bankofengland.co.uk 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.
Very thoughtful piece. Your observation about external validators adding computing capacity on demand sounds rather like the way power systems are evolving (very slowly and with many technical challenges) to combine centralised power stations and decentralised solar/wind power at the consumer level.
I covered some of this ground here
https://blog.p2pfoundation.net/fintech-2-0/2016/10/06
In a nutshell, I beleive it is necessary to address the DLT – as I did 18 years ago when creating OilClear (now ICE’s eConfirm and CME’s TradeHub) – through the use of associative – not collective – consensual protocols between people/enterprises rather than machines.
It is necessary only to validate/authenticate what I think of as value messaging within the DLT, which is to say, authenticated amendments in title and transaction data between counterparties only, and not the entire database.
Finally, ‘Proof of (past) Work’ is of null (subjective) value. Promises of future use value (eg land use or energy use) – on the other hand – have objective utility, and promises returnable in payment for utility have subjective exchange value priced against a unit of account. However, promises require a framework of trust, which historically has been provided by banks as trust intermediaries – a capital intensive role which is now obsolete.
Having read your excellent article two important questions remain:
Wouldn’t you agree that ECB’s Target2 and T2S can be qualified as DLT’s?
Wouldn’t you qualify our fiat money system as containing digital (vs. print) money?
What if the validator is the ledger of the business whose loan created the money?digital currency which is a thing-in-itself, a chunk of data like bitcoin rather than a quantity in an account but which is also createable with loans. The data includes information on the loan which created it. Perhaps the software of the money user has a land registry and a list like that at Companies House to verify the authenticity of the credit creator. Maybe we can finish the work of Hayek to make an expansionary currency which isn’t open to money-from-thin-air slight of hand, like exchangeable personal vouchers or self issued credit. Hashing and proxies the money users could be anonymous,the encryption work could be done by each user so there isn’t the scalability blocksize problem. It would just involve the use of credit rating institutions, so not a decentralised currency. Perhaps these would be BoE branches-the job of a loaning bank is to uphold the value of the currency before making profit.