Central bank digital currencies (CBDCs)’ rise to prominence has been accompanied by a growing volume of policy, technical and consultation papers. Global Government Fintech editor Ian Hall delved into one important publication – the Bank of England’s 86-page ‘digital pound technology working paper’ – to highlight some of the technical considerations (and acronyms) facing CBDC architects
Wherever you are in the world, there is an increasing volume of reading materials on central bank digital currencies (CBDCs).
The Bank of England (BoE)’s ‘Digital pound: technology working paper’ is among the most interesting such documents released to date – particularly for the increasing number of public officials worldwide getting ‘into the weeds’ of CBDCs. Its 86 pages explore a series of design principles relating to privacy, security, resilience, performance, extensibility and energy usage.
The paper was published in February alongside a consultation paper – ‘Digital pound: a new form of money for households and businesses?’ (co-published by the BoE and the Treasury) – which triggered front-page headlines in the mainstream media with its perspective that a British CBDC is ‘likely to be needed in the future’.
With the deadline for responses to the consultation approaching at the end of this week (30 June – a date extended from the initially communicated 7 June deadline), both publications are worth reading in full by anyone keen to explore the considerations and unresolved questions that public authorities are tackling.
For those unable to spare the time, Global Government Fintech here highlights sentences and sections from the six design considerations, as well as an ‘illustrative conceptual model’, presented in the technical paper. Our aim is to help you familiarise yourself with some of the technical challenges that you can expect to hear more about as public authorities’ CBDC explorations continue globally.
Global Government Fintech retains the BoE paper’s sub-section headings (e.g. Privacy, Security, etc) and specifies the page numbers to facilitate ease of cross-reference.
PRIVACY
(p20-p24)
Privacy-enhancing technologies (PETs)
The term PETs covers a broad range of technologies designed to support privacy and data protection… further work is needed before any decision can be made on whether or not to use PETs. In the interim, the Bank of England has collated a non-exhaustive list of PETs which might have applications in a CBDC system. The merits and case for use of such PETs, along with others not listed here, will be assessed in the next phase of work.
a) Data minimisation
Data minimisation techniques could give users better control of their data, enabling them to choose which data they share with PIPs and ESIPs [External Service Interface Providers]. Some techniques include:
• Pseudonymisation, which is a procedure that removes information that identifies an individual and replaces it with pseudonyms. Proposed amendments to current data protection legislation require that the pseudonymised data be kept separately from identifying data. Pseudonymisation might be used by PIPs and, in some cases, ESIPs, to protect user personal data in storage and transit.
• Private information retrieval (PIR), which allows a party to search for and retrieve data records from a database, without revealing details about the query or the result to the data controller. PIR might allow users to search for and retrieve their account information without revealing the search parameters and results to their PIPs.
• Attribute-based encryption (ABE), where the ability to read encrypted data is determined by attributes, such as the account ID or email address. The ciphertext and decryption key in ABE are labelled with user attributes, such that decryption is dependent on a match between the attributes of the ciphertext and the decryption key. ABE might be used to secure the transfer of transaction data between users, PIPs, and the Bank, with the ability to decrypt data determined by user attributes of the transaction recipient.
b) Aggregate data analysis
Aggregate data analysis supports the processing of such data, while minimising or avoiding the exposure of personal data. Some techniques include:
• Differential privacy, which introduces statistical noise or randomness to data sets. The calculated injection of noise hides personal data and might enable analysis of group patterns in a data set.
c) Distributed data analysis
Distributed data analysis refers to the processing of distributed data sets by multiple parties in a privacy-preserving manner. Some techniques include:
• Secure multi-party computation (SMPC), which enables multiple entities to jointly process or perform calculations on distributed datasets without sharing data with each other. This technique could minimise sensitive data sharing in the ecosystem and Page 23 ensure that no single entity can see the entire dataset. SMPC might enable PIPs to monitor transactions for money laundering with minimal sharing of data.
• Federated learning, which is a machine learning (ML) technique used across distributed datasets that are held locally by multiple entities. Federated learning might allow PIPs to locally monitor transactions for money laundering, with suspicious events flagged and pushed out to the relevant PIPs. This technique eliminates the need for data sharing in the ML model training process and could be used in combination with other PETs to protect user privacy.
d) Encrypted data processing
Encrypted data processing allows one party to process data held in encrypted form by another party. Some techniques include:
• Homomorphic encryption, which allows parties to process encrypted data without first having to decrypt it. The data remain encrypted at all times, reducing the likelihood of sensitive data disclosure or information compromise in the ecosystem. This technique might help PIPs share and process sensitive data in a privacy-preserving manner, for example for anti-money laundering (AML) compliance.
e) Blind proofs
Blind proofs can be used to verify claims about data without having visibility of the data. Some techniques include:
• Zero-knowledge proofs (ZKP), where one party can prove to another party that a given statement is true without revealing any additional data apart from the fact that the statement is indeed true. Where a user holds multiple wallets across PIPs, ZKPs might be used by PIPs to verify that a user’s CBDC holdings are within set holding limits, without requiring visibility of funds held by the user across wallets. ZKPs might also be used by a PIP to attest to completion of know your customer (KYC) checks without exposing personal data to the Bank and other ecosystem participants.
• Zero-knowledge range proofs (ZKRP), which are used to verify that a secret value is within a certain range. ZKRPs might be used to verify whether CBDC funds are within a set holding limit for the user, without exposing the user’s balance.
SECURITY
(p25-p32)
Security threats would largely be the same as for other retail payment infrastructure, but innovative functionality may present new and additional risks (p26)… the quantum computing threat is an additional layer of risk that the Bank must factor into its CBDC design thinking (p28)… the Bank of England plans to work with partners to undertake research into future threats, such as quantum computing, and evaluate options for a quantum-safe CBDC ecosystem. That work will include producing a framework for evaluating and managing new and emerging risks (p30).
RESILIENCE
(p33-p38)
Current RTGS [real-time gross settlement] and CHAPS [Clearing House Automated Payment System] services have a target uptime of at least 99.95 per cent, and that would constitute a minimum expectation for Bank of England-managed CBDC infrastructure. However, we will explore whether an uptime target of closer to 100 per cent would be appropriate and deliverable (in particular 99.999 per cent).
PERFORMANCE
(p39-p41)
Throughput of approximately 30,000 transactions per second may be necessary. The Bank of England will also explore a more ambitious capacity of approximately 100,000 transactions per second, in order to accommodate future payment needs.
EXTENSIBILITY
(p42-p43)
CBDC must be extensible to support innovation and future payments needs (p42)… Extensibility refers to the extent to which a system allows for the addition of new functionality, or the modification of existing functionality, without impairing existing system functions. An extensible CBDC system would be able to expand or enhance its functionality without impacting the existing components. The following factors might be taken into account in the design of a CBDC system in order to maximise extensibility:
a) Open architecture
b) Composability (‘… a composable architecture focuses on defining building blocks that can be combined to achieve the required functionality of the CBDC system… this represents a move away from inflexible monolithic architectures’)
c) Open source
d) Third-party dependencies
ENERGY USAGE
(p44)
A UK CBDC would be fundamentally different to a crypto asset. It would not use the energy-intensive technologies, such as proof of work, that underpin some crypto assets. (Proof of work is a highly computationally intensive consensus mechanism popularised by cryptocurrencies, most famously bitcoin).
‘ILLUSTATIVE CONCEPTUAL MODEL’
(p45-p80)
The core ledger must achieve very high levels of availability. Potential requirements for availability [include] the need for close to zero downtime. To this end, the ledger would need to be able to withstand any potential failure or outage within the platform, and self-heal. (p49)
Transaction co-ordinators might help to meet performance and resilience targets. Transaction co-ordinators are services which play a critical role in delivering transaction-processing capabilities in distributed databases. They co-ordinate communications across processing nodes to prepare them for receiving transaction data and maintaining communication as they progress through to an atomic commitment. Transaction co-ordinators also guarantee that a consensus is reached across the system…
… a transaction co-ordinator is likely to be one of the most important elements of the ledger design. It would need to be fast, resilient, and incorporate protocols to support atomicity, consistency, isolation and durability (ACID) properties. (p49)
The ‘Blockchain Trilemma’ theory posits that it is extremely difficult for any blockchain protocol to achieve three crucial system guarantees simultaneously: decentralised, scalable and secure…
… a white paper from the UK’s National Cyber Security Centre (NCSC) [in 2021] concluded that distributed-ledger technology (DLT) is only likely to be useful in circumstances where all the following statements are true:
a) Multiple entities need to be able to write data.
b) There is a lack of trust between the entities writing data.
c) There is no trusted central authority that can write data on behalf of the entities.
If any one of the above statements is assessed to be false, then the NCSC considers that a ‘conventional technology, like a database, is likely to be more appropriate’. Based on the Bank of England’s current thinking on requirements for the core ledger, the use of centrally governed, distributed database technologies, might be a more efficient and appropriate approach than the use of DLT solutions. However, the Bank will continue to assess a range of approaches, and continue to monitor ongoing technology developments. (p51)
Alias service
(p54)
• To interoperate with existing payments infrastructures and enhance CBDC functionality, wallets could have aliases.
• To allow for greater flexibility, aliases could be either well known (rarely changed) or disposable (frequently changed).
• Some examples of commonly used aliases are phone numbers, sort code and account numbers, card numbers (primary account number (PAN)) and wallet IDs.
… a CBDC might have both a well-known and a disposable alias.
A well-known alias changes rarely and is something the wallet holder is happy to be shared with, and stored by, third parties. For example, users may choose to link their mobile phone numbers to their wallets so that a messaging service might use their phone numbers to facilitate CBDC payments. A disposable alias, as the name suggests, is used for a short period of time. It is useful where a user wants to be able to conduct a transaction in private and not allow the recipient a record of their identity. For example, when buying groceries or coffee, users may elect to use a disposable alias. Disposable aliases would constantly change, so they may need to be recycled or archived after an appropriate amount of time to reduce the volume of information stored in the alias service. As increased volume could slow the performance of the alias service, managing the scaling and recycling of aliases would be critical. A wallet holder might have both well-known and disposable aliases on their wallet at the same time.
API (application programme interface) layer
(p59)
… more rigorous controls like the Financial-grade API standard would be considered to ensure the highest standards of security controls are in place [Financial-grade API is a security framework developed by the Open ID Foundation providing technical guidance for securely using APIs that utilise financial data].
Devices and payments
(p62)
CBDC should also be accessible via smart cards to support users who do not have a smartphone. Smart cards are plastic cards with an integrated circuit chip, similar to credit or debit cards. There are certain circumstances that may present challenges for smart card payments. For example, where both the payer and the payee are using smart cards, a challenge arises since the cards would require a power source, as well as a way for the user to define the transaction value. While smart cards which contain batteries, screens, keypads and even fingerprint scanners do exist, they are more costly to issue.
Which contactless kernel might CBDC use?
(p65)
In order to support CBDC payments using existing infrastructure, PoS [Point of Sale] devices will require a contactless kernel.
A kernel is a piece of self-contained software which provides payment acceptance devices with the necessary functions to process contactless transactions. There are several different contactless kernels in use today for different scenarios and payment networks. The feasibility study highlighted four possible options for kernels to initiate CBDC payments at PoS:
• Develop a bespoke CBDC contactless kernel.
• License a ‘white label’ kernel from an existing vendor.
• Use an implementation of the proposed EMV Contactless Kernel Specification known as ‘Kernel 8’.
• License an existing payment network’s kernel.
GOT A TASTE FOR MORE? CHECK OUT THE FULL DOCUMENT: ‘Digital pound: technology working paper’ (Bank of England, February 2023)
FURTHER READING
Global Government Fintech’s dedicated ‘Digital Currencies’ section
RELATED ARTICLE Central bank digital currencies: checking out conditions for take-off – write-up of a breakout session on CBDCs at the Global Government Fintech Lab 2023 (18 May) that featured Katie Fortune, senior manager in the BoE’s CBDC unit, among the panel
 facing CBDC architects){kind=link}