Archetypes for a Retail CBDC

0

Analysis

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

Privacy

Confidentiality refers to the amount of detail system entities know about user transactions. It also covers an institution’s knowledge of data from other institutions. A strong privacy posture means that user data is only visible to the user and the number of institutions needed.

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

In direct systems, only the parties involved in the transaction record the settlement. The direct archetype therefore offers users 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 their behavior, such as remaining offline for long periods of time.

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

Compliance

Compliance refers to the ease with which entities in the system can collect enough data to meet legal requirements such as anti-money laundering regulations. A strong compliance posture means 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 opposing policy goals – the easier one is to achieve, the more difficult the other.

In centralized and leaderless archetypes, operators can access the total state of the system. In these systems, it is relatively simple to include mechanisms in the design that allow regulators to collect the necessary compliance information.

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

Visibility

Visibility refers to the extent to which the central bank can see the supply status of the CBDC. In general, greater visibility allows the central bank to learn more about the state of its liabilities and to exercise stronger surveillance.

In systems where operators have access to the total state (the centralized and leaderless one), visibility is strong because it is impossible for an entity to alter the state (say, corrupt the CBDC supply) without the central bank is not aware of it. The combination of high visibility with the right controls can enable the central bank to enforce rigorous integrity checks on procurement.

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

In high-visibility systems, technology could potentially do the heavy lifting to ensure integrity. This eases the regulator’s burden of monitoring private entities. In contrast, in low-visibility systems, the burden may rest on non-technical means of regulating private entities.

Scalability

Scalability refers to how efficiently a system’s throughput can be increased as demands on the system increase.

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

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

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

Resilience

Resilience refers to the ability of a system to avoid loss of service and loss of data in the event of a failure. Species are considered very resilient as they can function even during natural disasters. In addition, the loss of one person’s liquidity does not compromise the system or affect the assets of others or their ability to transact.

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

The loss of an individual’s information in the direct archetype does not affect another’s assets or ability to transact. Therefore, like cash, it is very durable. Additionally, it is the only archetype capable of offline settlement (discussed later), making it the most resilient to outages such as natural disasters.

The centralized state and partitioned state archetypes employ oversight functions or mechanisms. These functions, if logically located in an entity, may have single points of failure. If so, they must be designed with adequate redundancy as their loss can bring the system to a halt.

Extensibility

Extensibility refers to how basic system functionality can be enhanced to support richer services. In retail CBDC systems, this refers to how private sector entities 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 a primitive operation, basic payment. We are looking to extend the system by providing another operation, loan repayment, which combines a base payment from a lender to a borrower with a second base payment in the opposite direction at some point later the reverse amount being the original amount plus a given interest. . We describe two forms of extensibility and discuss them in the context of archetypes.

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

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

In other words, the CBDC system has full knowledge of the loan payment extension (i.e. its logic and parameters) and guarantees that it will perform as specified.

Another way is to add the loan payment as an extension built outside of the central CBDC system. In the loan repayment example, an external service provider would maintain the logic and parameters of the loan repayment transaction. The CBDC system would only offer basic payment (and some locking or escrow functions, as needed). Users would connect to the service provider to participate in a loan. The service provider would make automated base payments on the CBDC system for the initial payment and, some time later, the refund. The CBDC system would not be aware of the loan repayment transaction, so it would not be able to answer questions about the due date or repayment amount. In this model, the CBDC system has no visibility into the extensions and therefore cannot guarantee their accuracy or execution.

Share.

About Author

Comments are closed.