Archetypes for a retail CBDC

Introduction

A CBDC system’s state is the information the system maintains about the supply and ownership of the digital currency. The space of storage and database systems to underpin a CBDC system is vast, with hundreds of technology platforms ranging from general-purpose ones, such as relational databases, to niche ones, such as NoSQL databases for social networks and blockchain systems for cryptocurrencies.

This raises a few questions:

• What types of storage systems could support a retail CBDC system?
• Are certain types of storage systems particularly well suited (or unsuitable) for a CBDC?
• Do blockchain systems present compelling benefits for retail CBDC systems because they are prevalent in cryptocurrency applications?
• Can the large variety of possible system designs be framed and analyzed based on some common design ideas?

After studying a variety of CBDC system designs, we believe it is useful to organize the possible CBDC designs according to a few archetypes that are independent of vendor, platform and technology. These archetypes will be of interest to a technical audience. However, we present them in a manner accessible to non-technical audiences such as policy-makers and members of the general public who can recognize the range of possible system designs and their trade-offs.

Before developing the archetypes, we list some assumptions that define the scope of choices we considered.

A CBDC system must store state and maintain it in a way that preserves the integrity of the CBDC supply. A change in the state happens any time an operation that affects the CBDC supply is conducted, including transactions or issuing additional currency. The change involves updating the system state with the information required to record the settlement for that operation. Regardless of the state’s structure, the CBDC system must ensure that every update to the state is applied in a way that preserves the integrity of the supply. For example, if the state is modelled as a set of account balances, a change in state triggered by a transaction must update the balances of the parties involved in the transaction so that the debits offset the credits exactly and the correct parties—and no others—are debited and credited.

We assume the CBDC system is self-sufficient and contains all the information related to CBDC liabilities. Other designs are possible where some state is held outside the CBDC system.1 Settling CBDC obligations in such systems would require that the parties involved comply with technical and governance obligations outside the system’s control. Such systems are beyond the scope of this analysis.

We assume that a CBDC system must achieve global consistency of updates with near-immediate finality. Consistency is a system property where all read operations must return the most recently written value (Gilbert and Lynch 2002). Some systems sacrifice consistency to achieve high throughput, or transactions per second; in this case, it is possible that parts of the system may not return the most recently written value until some time after an update. A CBDC system must always be globally consistent (i.e., all parts of the system must return the same value on a read operation) and achieve consistency quickly (i.e., return the most recent value almost immediately after an update).2

A range of entities will participate in a retail CBDC system—the central bank, money services businesses (MSBs) such as financial institutions and other private sector participants, end users and merchants. Organizing state in a CBDC system involves deciding how the system state is stored across these various entities. Further, it involves establishing how oversight over a proposed update to that state is provided—in other words, how a proposed update is validated, approved or rejected so the information needed to update the system state can be recorded if the transaction is approved.

Archetypes

In this section, we discuss the options for storing and updating the system state and develop five archetypes:3

• Centralized
• Leaderless
• Macro-partitioned
• Micro-partitioned
• Direct

Centralized

The distinguishing feature of the centralized archetype is that the total system state is within the trust zone of, and controlled by, one entity. This entity would have the power to approve and apply each update or deny it. Users connecting to the system do not hold any state, only credentials that authorize access. An operation, such as a transaction or issuance, could be fully recorded as a change to information within the zone.

Figure 1: Centralized archetype

Figure 1: Centralized archetype

In practice, a CBDC system would not be deployed as a single instance. Instead, it would replicate state, possibly to different geographic sites, for backup and availability. Nevertheless, if the instances are under a single entity’s authority, the system can be considered centralized because it preserves the essential characteristic of the total state controlled by one party.

A system based on a centralized archetype could take other forms, such as a collection of multiple components that operate together as one logical instance and are within the trust zone of one entity. A range of platforms—from traditional databases to purpose-built platforms such as the Guardtime KSI (Eesti Pank 2021)—can be deployed as centralized systems.

Leaderless

Another way to organize state is to replicate it in its entirety to multiple identical instances that are controlled by different entities and organized to be leaderless (i.e., no instance is the leader). The crowd of instances collectively provides oversight over each update, ensuring that it is applied by all replicas in the same manner, progressing all of them from the same current state to the same next state. The process to achieve agreement on updates is called consensus, and numerous consensus algorithms are known (Cachin and Vucolic 2017). This is the leaderless archetype, exemplified by systems such as Bitcoin (Nakamoto 2009), Ethereum (Buterin 2014) and Algorand (Chen and Micali 2017).

Figure 2: Leaderless archetype

Figure 2: Leaderless archetype

Since all instances in a leaderless system are copies of the total system state, every update must be applied to all instances. This can lead to a high overhead of communications (Figure 2, solid lines) and duplication of storage and computation. Again, users connecting to the system do not hold any state, only credentials.

A key aspect of leaderless systems is their ability to operate in low-trust environments, so users do not have to trust one state instance or institution. In general, the lower the trust level, the higher the overhead and complexity of consensus required. We assume that most retail CBDC systems will not operate in low-trust environments because institutions performing system roles will almost certainly be required to be granted permission and be trusted by both the central bank and regulators.

The need for strong central bank roles and functions must be assessed against the default posture of leaderless systems. In most jurisdictions, a CBDC system would be required to limit certain functions; for example, the central bank would be the exclusive issuer of the CBDC. This contrasts with leaderless systems where the authority over those functions (i.e., over the technology mechanisms that encode those functions) is shared between multiple entities. Leaderless systems must therefore be evaluated to ensure that there are no security concerns for the roles and functions of the central bank.4

Macro-partitioned and micro-partitioned

An alternative to replicating the system state is to partition it, that is, to divide it into partitions or slices, each controlled by a different entity. Any two partitions (Figure 3, grey circles) would differ from each other, while possibly overlapping in content related to their shared interactions. Each partition may also contain private state that is not shared with other partitions. We call these “partitioned-state systems.” In contrast to centralized and leaderless systems, no instance presents the total system state in partitioned-state systems.

In a partitioned-state system, only some partitions change during an update. The system must ensure that the updates applied to those partitions are valid, that double-spends and fake issuance are disallowed even if owners of those partitions try to collude. A third-party function integrated with all partitions could provide oversight of updates.

One way to implement that third-party function is as a component that communicates with all partitions. Suppose that two partitions are involved in a transaction (Figure 3, solid lines). They would interact with the third party (Figure 3, red circle) to gain its approval and then apply the update to their respective states, while the third party records some shared state.5 Other partitions may not be aware that an update occurred. A third party that holds some shared state and provides oversight may, however, introduce a degree of centralization.

Another way is by distributing that function between all partitions as a decentralized mechanism or protocol. In that case, transacting partitions participate in the oversight protocol to generate state information to prove the validity of the update, which is then shared with all partitions.6

Regardless of the design of the oversight function, it can be considered a protocol and some shared state that all partitions have access to.

Figure 3: Partitioned state

Figure 3: Partitioned state

We describe two archetypes based on the notion of partitioned state: the macro-partitioned and the micro-partitioned.

In the macro-partitioned archetype, MSBs own and operate partitions. The number of partitions would be small (for example, in the dozens), while each partition would be large enough to represent a percentage of the total system state. Further, partitions could be assumed to be always on and connected to other system entities. Many platforms can be configured as macro-partitioned designs, for example, OpenCBDC, R3 Corda and HyperLedger Fabric (Androulaki et al. 2018).

Figure 4: Macro-partitioned archetype

Figure 4: Macro-partitioned archetype

In the micro-partitioned archetype, the number of partitions would be large (in the millions), but each partition would be a small slice of the total state. The function of holding state is pushed out to the edge of the system so that end users (i.e., individuals, merchants and corporations conducting the transactions) maintain the different partitions. Hence, as shown in Figure 5, end users hold system state, not just credentials. For this reason, partitions cannot be assumed to be always on and reachable. Examples of platforms deployable as micro-partitioned designs include TODAQ (Gravitis, Goh and Toliver 2019) and OpenCBDC (MIT Digital Currency Initiative 2022).

In general, a platform designed to be deployed as a micro-partitioned system could also be deployed as macro-partitioned (by having institutions maintain custody of the state of end users). The reverse may not be feasible.

Figure 5: Micro-partitioned archetype

Figure 5: Micro-partitioned archetype

Direct

An alternative partitioned-state system—the direct archetype—is one in which transacting partitions directly provide their own oversight.7 That is, transacting parties would communicate between themselves, without involving other parties, to exchange and record settlement information in their respective partitions. The technology and protocols would preserve integrity of state, even though the update is not overseen by a third party.

The direct archetype is the only one that achieves cash-like person-to-person transactions, where one party can interact with a second and settle a transaction without involving a third party, as shown in Figure 6.

Figure 6: Direct archetype

Figure 6: Direct archetype

The lack of third-party oversight has security implications. To our knowledge, achieving a design for a direct archetype requires using secure, tamper-resistant hardware to maintain and update the state.8 Secure hardware-based solutions have been deployed at a relatively small scale in closed-loop systems, such as university campuses and public transit. However, it is unknown whether their security can be hardened sufficiently to support a general-use fiat currency system at the scale of a national population. The worst-case risk is that a compromised partition could be used as a sort of printing press to issue CBDC fraudulently without the central bank finding out.

Figure 6 shows partitions in a direct archetype being operated by end users because this is the most likely scenario. However, a direct archetype-based system with institutional partitions is also possible. We do not describe this separately, but all direct archetype-based systems must address the same security concerns and maintain state within tamper-resistant hardware.

Table 1: Summary of archetypes

Analysis

In this section, we analyze the five archetypes and compare their privacy, compliance, visibility, scalability, resilience, extensibility, and online and offline payments.

Privacy

Privacy refers to how many details the system entities know about user transactions. It also covers how much one institution knows about the data of other institutions. A strong privacy posture means that user data are visible only to the user and as few institutions as required.

In leaderless systems, all institutions can see the total system state, so the potential for a breach of user privacy is quite high. Further, the data of one institution are visible to other institutions. The default privacy posture of leaderless systems is therefore weak. Efforts have been made to address this with privacy-enhancing technologies such as zero-knowledge proofs. But whether these technologies are ready for mass market deployment at scale and what trade-offs they bring are unclear.

In direct systems, only the parties involved in the transaction record the settlement. The direct archetype therefore provides users with the strongest privacy. Even if such a system requires users to periodically share data with a system entity, users may be able to influence their privacy through behaviour for example, by remaining disconnected for extended periods.

In general, archetypes that allow end users rather than institutions to hold information (the direct and micro-partitioned) can more easily achieve higher privacy.

Compliance

Compliance refers to the ease with which system entities can collect sufficient data to satisfy legal requirements such as anti-money laundering regulations. A strong compliance posture means that the required data can be collected more easily. In contrast, a weak posture means that data collection is difficult or infeasible. Compliance and privacy are policy goals in opposition—the easier one is to achieve, the harder the other is.

In both centralized and leaderless archetypes, operators can access the total system state. In those systems, it is relatively straightforward to include mechanisms in the design for regulators to gather the necessary compliance information.

The lack of an intermediary in the transaction flow makes it difficult to reliably collect the data required for compliance. This is the case in the direct archetype. In other archetypes, the oversight or validation authority could be designed to enforce the required compliance.

Visibility

Visibility refers to the extent to which the central bank can see the state of the CBDC supply. In general, higher visibility allows the central bank to know more about the state of its liability and to exercise stronger oversight.

In systems where operators have access to the total state (the centralized and leaderless), visibility is strong because it is impossible for an entity to modify the state (say, to corrupt the supply of CBDC) without the central bank becoming aware of it. Combining high visibility with the right controls can allow the central bank to enforce strong integrity checks over the supply.

If the transactions are not visible to the central bank and operators cannot see transactions, the central bank may not notice attempts to modify or corrupt the CBDC supply. This is a drawback of the direct archetype, where transactions can be finalized without third parties.

In systems with strong visibility, the technology could potentially do the heavy lifting of ensuring integrity. This lessens the regulator’s burden of overseeing private entities. In contrast, in systems with weak visibility, the burden may fall on non-technical means of regulating private entities.

Scalability

Scalability refers to how efficiently the throughput of a system can be increased as the demands on the system grow.

A weakness of the leaderless archetype is that the high degree of replication of state and compute hampers performance. Systems that replicate the state almost always mitigate the overhead by reducing the instance count of validators or using techniques such as sharding to break up the data into smaller chunks (Buterin 2021) to minimize the degree of replication, for example.

Because the direct archetype allows parties to finalize updates without a third party, these systems could in theory scale limitlessly, much like a cash system. In practice, however, some bottlenecks would occur around distribution and renewal and refresh operations, which would place upper bounds on scalability.

It is important to note that operations with certain money representations, such as UTXO, may scale more easily than those with different money representations, such as account balance (Buterin 2016). Therefore, while the choice of architecture influences a system’s scalability, the choice of the money representation is also important and must be considered in an overall scalability design. We discuss representations of money later.

Resilience

Resilience refers to a system’s ability to avoid loss of service and loss of data if a failure occurs. Cash is considered highly resilient because it can function even during natural disasters. Further, the loss of one person’s cash does not compromise the system or affect others’ holdings or their ability to carry out transactions.

The leaderless archetype achieves high resilience by replicating system state fully to multiple instances. If a few instances are lost, the system state can be fully recovered from other instances. Further, its resilience is stronger than that of other archetypes because users are not bound to specific MSBs. However, this comes at the cost of weak scalability.

The loss of an individual’s information in the direct archetype does not affect the holdings or ability to transact of another. Therefore, like cash, it is highly resilient. Also, this is the only archetype capable of offline settlement (discussed later), which makes it the most resilient to outages such as natural disasters.

The centralized and partitioned-state archetypes employ oversight functions or mechanisms. These functions, if localized logically in one entity, can present single points of failure. If so, they must be designed with adequate redundancy because their loss can halt the system.

Extensibility

Extensibility refers to how the system’s basic functionality can be enhanced to support richer services. In retail CBDC systems, it refers to how entities in the private sector could design and offer innovative services on the core CBDC platform.

We illustrate this discussion with a simple example. Consider a CBDC system that supports one primitive operation, the basic payment. We seek to extend the system by offering another operation, the loan payment, that combines a basic payment from a lender to a borrower with a second basic payment in the reverse direction a given time later, the reverse amount being the original plus some given interest. We describe two forms of extensibility and discuss them in the context of the archetypes.

The first form of extensibility is to add the new operation to the CBDC system. In our example, then, the loan payment is added as a second operation to the core CBDC system. The system executes, settles and records all parts of a loan payment as it does for basic payments. Users could query the system for details, for example:

• When is the repayment due?
• What is the repayment amount?

In other words, the CBDC system has complete knowledge of the loan payment extension (i.e., its logic and settings) and guarantees its execution as specified.

Another way is to add the loan payment as an extension built outside the core CBDC system. In the loan payment example, an external service provider would maintain the logic and settings of the loan payment operation. The CBDC system would offer only the basic payment (and some locking or escrow functions, as required). Users would connect to the service provider to participate in a loan. The service provider would perform automated basic payments on the CBDC system for the initial payment and, a specified time later, the repayment. The CBDC system would not be aware of the loan payment operation, so it would be unable to answer queries about the repayment due date or amount. In this model, the CBDC system does not have visibility into extensions and so cannot guarantee their correctness or execution.

Figure 7: Two forms of extensibility

Figure 7: Two forms of extensibility