Building a framework for tokenization of central bank digital currencies and other financial assets

Since the COVID-19 pandemic, cash usage has been decreasing globally, and digital payments based on cryptocurrencies or existing digital payment systems have become dominant. As a result, new forms of centrally managed digital currencies are emerging alongside cryptocurrencies such as Bitcoin. This cryptocurrency’s notorious volatility has hindered its acceptance globally. More significantly, central bank digital currencies (CBDCs) provide a digital form of central bank money. tokenize The life cycle of commercial bank funds, both on the retail and wholesale side.

In such a central management system, accountability and privacy must coexist, both respecting the need for approved audits. At the same time, the critical nature of the system makes it important to achieve resilience, and the definition extends beyond crash fault tolerance of legacy critical infrastructure systems. A system must be resilient to Byzantine faults so that it can continue to operate even if part of the system is damaged.

Decentralized transaction processing systems, such as distributed ledger technology (DLT), are relevant platforms, but current DLT implementations are generally not sufficiently scalable. Recent work from IBM Research®, which provides a high-performance framework for CBDCs that combines privacy, compliance, and advanced resilience, breaks down these limitations.

What is a central bank digital currency?

A central bank digital currency is a digital currency controlled by a country’s central bank. Like cash, it is designed to store value, serve as a medium of exchange, and represent a unit of account. CBDC is used for both wholesale payments and individual transactions between commercial banks and central banks. In recent years, CBDCs have established themselves as a viable solution to current inefficiencies in financial markets because they can foster innovation, enable more effective inclusion in payment systems, and reduce settlement delays, costs, and counterparty risks.

Currently, more than 130 central banks are actively exploring CBDCs and publishing regular reports on the functional and non-functional requirements of CBDC platforms, including evolving architectural considerations and the results of various CBDC experiments. A handful of central banks have launched CBDC pilots, and the European Central Bank recently began proposing legislation to adopt a digital euro.

CBDC Requirements and Challenges

Although regulation of CBDC systems varies depending on local jurisdiction, the systems share the same functional and non-functional requirements. For example, the significant impact of CBDC infrastructure on money supply means that central banks will need to manage it. However, the robustness and resilience requirements associated with the critical characteristics of CBDC systems require decentralized governance, geographically distributed system deployment, and independent operation of different parts of the system.

Compliance and effective dispute resolution capabilities require transparency, auditability, and non-repudiation. Regulations such as the Anti-Money Laundering Directive (AML) and the Focused Efforts to Combat the Financing of Terrorism (CFT) require the detection, sourcing, and reporting of suspicious payment transactions to the relevant authorities. Alternatively, the EU’s revised Payment Services Directive (PSD2) highlights the importance of fraud detection and dispute resolution. Additionally, CBDC systems must interoperate with existing payments, settlement and liquidity infrastructure, along with other CBDC systems and emerging digital asset systems.

System performance and scalability are critical to system acceptance and use. This is important for wholesale CBDC platforms that want to expand their use for other applications beyond settlement. Retail CBDC systems must be able to compete with existing payment services and accommodate millions of user transactions. This means that at peak times it can handle tens of thousands of transactions per second (TPS).

Payment transaction privacy is also important. Privacy refers to the right of data owners to control who has access to their transaction information. For example, PSD2 states that processing of personal data must comply with the GDPR and the data minimization principles. This limits the collection of personal information to what is necessary to process the transaction. This can be interpreted in many different ways. A conservative approach to data minimization ensures that payment transactions are processed without leaking information about the parties or transaction value. This makes transaction monitoring and auditing more difficult. A permissive approach reveals the amount of the payment and potentially the identity of the payer and recipient.

A progressive CBDC system must accommodate different interpretations of privacy, along with all other requirements, including performance and auditability. As technology evolves, so too do privacy regulations and requirements, and agility must be built-in.

How does the IBM Research platform meet these challenges?

IBM Research has developed a transaction processing framework for fungible financial asset management (most notably CBDC) that addresses all of the aforementioned challenges. Permissioned DLT offers several advantages over other technologies, including the ability to handle privacy, transparency, and resilience to compromised nodes, even though it uses a centralized governance model. It also meets or exceeds CBDC performance and scalability requirements. We further validate these claims by introducing the system architecture and protocols to show that:

• transparent Transactions are processed with strong accountability through a shared ledger that records every transaction processed in the system.
• Resiliency to damaged nodes DLT enables decentralization at each stage of transaction processing and shared ledger evolution.
• high throughput and low latency Transaction processing that exceeds retail CBDC requirements through optimal combination Execution-Order-Verification Transaction processing model introduced by Hyperledger Fabric 1.0, a state-of-the-art Byzantine fault-tolerant consensus protocol (tolerant of corrupted nodes) Two-phase commit rule Principles for high-level parallelism in transaction processing, Principles for high-level parallelism in transaction processing.
• horizontal scalability every Application layer logic Introduced in transaction processing. This is important for applications that use computationally intensive zero-knowledge proofs to provide privacy protection.

In this work, we feature a prototype implementation of the framework as an evolved version of Hyperledger Fabric combined with four CBDC privacy models. Supports standard unused transaction output (UTXO) using standard public key infrastructure (PKI) without privacy; Support for standard UTXOs with accountable pseudonymity/anonymity for traders using self-sovereign identity principles and privacy standards; Supports UTXOs using zero-knowledge proof-based extensions to enhance anonymity and exchange amount confidentiality Untraceable UTXOs using cryptographic means introduced by IBM Research to ensure complete trader (responsible) privacy. We further evaluated the system performance using three consensus protocols. Raft, a conflict-fault-tolerant consensus protocol; SmartBFT, a wild Byzantine fault-tolerant consensus protocol; The new Byzantine fault-tolerant architecture, inspired by the Narwhal and Tusk consensus algorithms, demonstrates state-of-the-art performance and scalability.

Our results show that our prototype implementation can handle up to 80,000 TPS for Raft and SmartBFT for the standard UTXO pseudonymity model, and over 150,000 TPS for our new consensus algorithm. Our results further demonstrate the horizontal scalability of transaction processing computing. In fact, we show that the same numbers can be obtained even in stronger privacy scenarios, using more powerful equipment to hide exchange amounts and individual users’ activities. The performance figures obtained correspond to a CBDC system that provides privacy protection to end users while allowing certified auditors to inspect transaction information and payment components to properly process transactions.

How is this framework relevant or applicable to other forms of tokenized financial assets?

Tokenization is a term that extends to various forms of financial assets. This implies the digitization of business assets, but it also assumes digital systems that support first-of-its-kind requirements for transparency, interoperability, elasticity, and programmability beyond what legacy systems can accommodate. Central bank digital currency is an example of tokenization of central bank money, but we can see tokenization of deposits being extended to commercial banks or commercial bank money (also known as tokenized deposits), various forms of securities (tokenized securities), etc. You can see that.

All of these systems are different in terms of the use cases they address, but they result in similar requirements in terms of accountability, privacy, compliance, resiliency, and programmability. Although each use case will need to be examined in depth to make any real conclusions, the framework proposed by IBM Research is general enough to directly accommodate a wider range of applications for tokenized assets.

Learn more about the IBM Research CBDC Platform