CEV Framework: A Central Bank Digital Currency Evaluation and Verification Framework With a Focus on Consensus Algorithms and Operating Architectures

We propose a Central Bank Digital Currency Evaluation and Verification (CEV) Framework for recommending and verifying technical solutions in the central bank digital currency (CBDC) system. We demonstrate two sub-frameworks: an evaluation sub-framework that provides consensus algorithm and operating architecture solutions and a verification sub-framework that validates the proposed solutions. Our framework offers a universal CBDC solution that is compatible with different national economic and regulatory regimes. The evaluation sub-framework generates customized solutions by splitting the consensus algorithms into several components and analyzing their impacts on CBDC systems. CBDC design involves a trade-off between system features - the consensus algorithm cannot achieve all system features simultaneously. However, we also improve the operating architectures to compensate for the weak system features. The verification sub-framework helps verify our proposed solution through empirical experiments and formal proof. Our framework offers CBDC designers the flexibility to iteratively tune the trade-off between CBDC system features for the desired solution. To the best of our knowledge, we are the first to propose a framework to recommend and verify CBDC technical solutions.


I. INTRODUCTION
The recent development in cryptography and distributed ledger technology (DLT) has seen a new form of currency known as Central Bank Digital Currency (CBDC) [1]. More than 85% of central banks worldwide have already started CBDC research [2], [3]. However, most current CBDC research works come from central banks, while only a few scientific papers discuss the CBDC-related research problems. For example, the papers [4], [5] used blockchain networks to provide CBDC services and propose a new consensus algorithm to satisfy CBDC technical features. However, these scientific papers only discuss some specific scenarios and have limitations to extending to a different scenario.
The overall operating architecture [7] and consensus algorithms are core parts of CBDC technical solutions. The overall operating architecture defines different CBDC networks. Consensus algorithms define how the specific CBDC network functions and impacts many CBDC technical features. CBDC technical features [6]  algorithm to form data consistency. For example, China [10] did not use blockchain to design its CBDC prototype, but we still consider the way to form data consistency as one kind of consensus algorithm. Due to diverse national conditions, central banks need different consensus algorithms and operating architectures to satisfy their CBDC technical features.

A. Our Contribution
Our paper reviewed previous CBDC solutions and proposed a framework that provides overall operating architecture and customized consensus algorithms to satisfy different CBDC technical features. Section II shows three CBDC technical features: performance, security and privacy. Compared with previous works, we have the following contributions: 1) We propose a framework to recommend and verify CBDC related technical solutions in consensus algorithms and operating architectures. 2) We are the first to split consensus algorithms into different components, significantly improving the efficiency to design customized consensus algorithms. 3) We improve the CBDC operating architecture to solve the business secrecy issue.
Specifically, we propose an evaluation sub-framework that provides holistic CBDC solutions covering CBDC technical features in Section III-A and build a verification subframework to verify the feasibility and rationality of proposed solutions in Section III-B. Finally, we integrate both sub-frameworks into one framework, called CEV Framework.
The evaluation sub-framework involves the consensus algorithm and operating architecture. Consensus algorithm works for forming data consistency among participants [14]. It impacts many CBDC technical features directly, including performance, privacy and security. For example, the paper [30] studied how blockchain empowers CBDC and proposed a new consensus algorithm to improve CBDC performance. However, consensus algorithms have a highly complex impact on CBDC technical features. In order to better analyze consensus algorithms, we split them into different components so that we can derive the impacts of each component on CBDC technical features.
A trade-off [6] between CBDC technical features exists in implementing consensus algorithms, which means we can not achieve all simultaneously. However, we can improve the operating architecture to compensate for weak CBDC technical features. Our paper uses a new operating architecture to solve the business secrecy issue (details in Section II-B).
The verification sub-framework can guide CBDC designers to verify proposed solutions. CBDC designers need to build a mathematical model for the solution and verify whether it can meet initial expectations on diverse CBDC technical features, like high performance. If they need further adjusting preference on three CBDC technical features, they can go back to the evaluation sub-framework to adjust the previous solution again.
We then introduce a CBDC scenario to demonstrate the CEV framework in Section IV. We used the evaluation subframework to propose customized consensus algorithms and followed the verification sub-framework to build a model and verify related CBDC technical features. We used empirical experiments to test performance and leveraged formal proofs to verify security and privacy. Our framework can give a clear guide to satisfy CBDC technical features for CBDC designers despite different national economic and regulatory conditions (details in Section III.A.1).

B. Paper Structure
The remainder of this paper is organized as follows.
In Section II, we present the background of the research and three CBDC technical features. Section III introduces the CEV framework, including an evaluation sub-framework and a verification sub-framework. Section IV gives an example of leveraging the framework to develop a solution and verify it. Finally, we conclude the paper in Section V.

A. Blockchain and Consensus Algorithm
Blockchain has shown many benefits among current CBDC projects worldwide [4], [11], [12], [16], [17]. For example, in cross-border business, peer-to-peer payment could save liquidity and improve efficiency [18]. Research topics about blockchain appear one after another, especially in the performance part [35]- [38], since the performance of blockchain, for example, bitcoin [33], cannot meet today's commercial needs. Besides performance, other CBDC technical features are also undergoing research, like resilience, security and privacy.
Consensus algorithms play roles in many blockchains. Fabric [35] used Practical Byzantine Fault Tolerance (PBFT) [34] which provides fault tolerance while sacrificing part of performance. Corda blockchain protocol aims to satisfy finance and regulatory requirements [36]. Transactions in the Corda platform are recorded only by participants rather than the entire network, which provides high performance and protects privacy while sacrificing part of security.

B. Tiered Architecture and Business Secrecy Issue
Most CBDC pilots have shown a tiered architecture [7] which plays roles in many CBDC projects, including China's E-CNY [13], Sweden's E-Krona [40]. Figure 1 shows a typical tiered CBDC architecture. We define a consensus network as the network which consensus algorithms run.

Fig. 1. A two-tier architecture that consensus algorithms run separately in different consensus networks. The wholesale consensus network involves central banks and tier-1 institutions and handles wholesale transactions between tier-1 institutions and central banks; the retail consensus networks involve retail clients and tier-1 institutions and handle retail transactions between tier-2 households & business and tier-1 institutions.
In a two-tier CBDC architecture, tier-1 institutions directly connect to the central bank (tier-0), and tier-2 institutions directly connect to tier-1 institutions. Tier-1 institutions take the responsibility of distribution 1 in a twotier CBDC architecture. In most CBDC projects, commercial banks become tier-1 institutions. However, it is impossible to let all commercial institutions become tier-1 and responsible for CBDC distribution and circulation 2 because the central bank can not afford too many banks to connect simultaneously. At the same time, it has a potential single point (central bank) failure risk and performance bottleneck. Therefore, in most countries, the most influential banks usually became tier-1 institutions.
The more commercial institutions circulate CBDC, the more areas CBDC services cover. Tier-2 institutions have to connect to tier-1 institutions to provide CBDC services. The two-tier model can mitigate business secrecy-related concerns if tier-2 institutions and tier-1 institutions are non-competitors. However, tier-2 institutions and tier-1 institutions are mostly competitors, and they are reluctant to provide transaction and customer information to their competitors. For example, if all tier-1 institutions are banks, tier-2 banks are worried that tier-1 banks monopolize their 1 Distribution means that an institution helps the central bank issue CBDC and manage CBDC authentication work. 2 Circulation means that an institution provides CBDC-related transfer services.
customer data. The business secrecy issue makes two-tier architecture hard to implement in a CBDC system. Current technical solutions to keep business secrecy, such as homomorphic encryption [15], however, could not satisfy CBDC technical features because it influences performance a lot. Therefore, we propose new operating architectures to improve CBDC business secrecy (details in Section III-A.2).

C. CBDC technical features
CBDC technical features [6] measure CBDC-related considerations for designers and regulators. CBDC white papers presented many differences between jurisdictions regarding national conditions, and central banks focus on different CBDC technical features. For example, Singapore's Ubin [8], and Canada's Jasper [9] focuses on transaction settlement between different countries; China's E-CNY [13] emphasizes the volume of transactions per second in retail transactions. CBDC designers across different jurisdictions have varying approaches to satisfy CBDC technical features.
We rest on the previous research [8], [9], [20]- [29] and extracted following CBDC technical features. To avoid ambiguity, we use specific sub-categories to define the following categories.
1) Performance: Blockchain has many benefits and has been widely used in the wholesale CBDC, but it seldom appears in retail CBDC projects [39]. One key factor is that its weak scalability cannot meet high performance. In CBDC scenarios, millions, even billions of customers may use CBDC, which requires a high performance to handle billions of requests. Therefore, we consider the following features to measure performance. 1) User Scalability: the cost of adding a new customer to a CBDC system. 2) Network Scalability: the capability to handle larger transaction volumes per second(TPS). 3) Latency: the time to complete one transaction.
We used empirical experiments to examine performance in the verification sub-framework and gave an example in Section IV-B.2.
2) Security: Security in a distributed system involves various aspects, including cryptography, secure channels, key management, prevention of double-spending attacks [32]. The prevention of double-spending is one of the basic requirements in a CBDC system and maintains financial stability and reliability. Central banks usually put security as the priority. As one kind of new form currency, CBDC has many security risks. 1) Cyber-Security: capability of protecting against outside attacks, especially double-spending attacks. 2) Resilience: capability of protecting against hardware issues, power or network outages, or cloud service interruption [28].
We used formal proof to verify potential security threats in the verification sub-framework and gave an example in Section IV-B.4.

3) Privacy:
We divide privacy into two aspects, customer privacy and business secrecy [28]. 1) Customer privacy protects customer data against others. 2) Business secrecy prevents business data from leaking to business competitors. second(TPS).
Our evaluation sub-framework improved the current operating architecture to protect business secrecy in Section III-A.2 since the consensus algorithm can not simultaneously achieve all CBDC technical features. We used formal proof to verify privacy protection in the verification subframework and gave an example of Section IV-B.3.

4) Others:
Other CBDC technical features do not conflict with the above ones. Examples include governance [28], functionality, interoperability and offline payments. We believe these requirements can be met or solved independently in the current financial system. For example, offline payment does not conflict with the above CBDC technical features. So we ignored them in the following parts. In future, we can involve more CBDC technical features in the CEV framework if needed.

III. CEV FRAMEWORK
The CEV (CBDC Evaluation and Verification) framework includes two sub-frameworks: an evaluation subframework that provides CBDC solutions and a verification sub-framework that proves the feasibility and rationality of recommended solutions. Figure 2 shows the working procedures of the CEV framework. First, CBDC designers determine preferable CBDC technical features according to their economic and regulatory conditions. Then the evaluation sub-framework firstly determine the operating architecture to ensure how many consensus networks and the relationship between them. Secondly, the evaluation sub-framework recommends consensus algorithms in different consensus networks. Afterwards, The verification sub-framework can guide CBDC designers to build a theoretical model for the solution and carry out experiments and proofs to verify whether the solution meets the original CBDC technical features. Finally, suppose they are not satisfied with the solution. In that case, they can go back to adjust their preference on CBDC technical features, leverage the evaluation sub-framework to update their solutions, and use the verification subframework to check the proposed solutions again.

A. Evaluation Sub-framework
The evaluation sub-framework includes two parts: the consensus algorithm part splits consensus algorithms into different components, and the operating architecture part introduces the overall architecture that consensus algorithms run. Next, we introduce how we recommend consensus algorithms and improve the overall operating architecture.

1) Consensus algorithm:
Consensus networks have diverse implementations of the consensus algorithm. For example, in the operating architecture (figure 1), the central bank can control the wholesale balance of issued CBDC rather than recording every retail transaction to avoid double-spending [32]. The central bank is only responsible for issuance and redemption transactions. If any issue exists in retail transactions, corresponding tier-1 institutions should be accountable. On the other side, the central bank records every wholesale transaction to keep it safe. Then both the wholesale and retail transactions are safe from double-spending from the perspective of central banks.
Consensus algorithms can satisfy different CBDC technical features at different levels with a trade-off [6]. As a result, they have direct but complex impacts on the CBDC technical features in Section II.
We reviewed many consensus algorithms [14], [33], [34], [36], [44], [45] and found that only part of the difference leads to different consensus algorithms and applications. For example, IBFT [44] adopts dynamic set of validators compared with fixed set of validators in PBFT [34]. We base on the differences to split the consensus process into different modules. Then we can better analyze the individual impacts on CBDC technical features. Then we combined different components into one algorithm, resulting in its overall impact. Figure 3 introduces consensus algorithm components. The following steps describe details about the process: 1) Network -Election: a network requires one representative to lead the consensus process before a client sends a transaction request. a) Voting: the system votes for the leaders. Extensive voting mechanisms involve defining the percentage of votes to become a leader and other requirements. RAFT [14] adopts an election timeout in the voting mechanism to determine the network's leader. b) Predetermination: the system predetermines the leaders. For example, the notary node in Corda platform [36] is determined before network deployment. c) Round-robin: A group of nodes take turns as leaders in a certain order. PBFT [34] uses round-robin approach to choose the primary (leader). d) Proposer: the system has no leader. For example, in some public blockchain systems, a proposer collects transactions from users and proposes them to the network via Proof of Work [33], Proof of Stake [45].
2) Client -Request: a client submits its payment request to the network. a) To one: a client sends the request to only one node. A node is a connection point in a communication network. For example, in RAFT, the client sends the request to another node if they receive no response. Furthermore, the "To one" option can leverage sharding [41], [42] to improve system performance. Sharding means multiple nodes process transactions in parallel and interacts with each other in a specific manner, which we discuss in the example of Section IV. b) To all: a client sends the request to all nodes to ensure one node accepts the request in time.
3) Leader / Proposer -Pre-prepare: the leader node or proposer processes the request locally after receiving it.
a) Proof of X: the leader node or proposer leverages one of Proof of X, such as Proof of Work [33], to publish transactions. b) Verification: the leader verifies proposed transactions in a specific manner, like checking the input equals the output.  a) x% backup replies: the leader node receives more than x% backup replies. For example, in RAFT [14], the leader node needs to receive 50% replies before responding to its client. b) x% vote replies: the leader node receives more than x% vote replies then finalizes the transaction. c) Self-decision: the leader node decides the transaction by itself. For example, the notary node in Corda [36] verifies proposed transactions by itself.
Besides consensus process options, we include another two options to improve the overall algorithm: 1) Fixed / Dynamic Validators: validators are non-leader nodes that can participate in consensus. Some consensus algorithms require all nodes to participate in consensus, while others need selected or random dynamic nodes. For example, RAFT [14] and PBFT [34] need all nodes to participate data backup, while IBFT [44] adopts a dynamic set of validators. A dynamic set of validators can provide a higher performance because of more flexible participants. In contrast, fixed validators are easier to implement and more secure. 2) Encryption: CBDC designers can use encryption in every step to secure transmitted information but decrease performance. It is independent of previous options. In most algorithms, consensus algorithms are more associated with achieving consistency and ignore encryption. However, in the CBDC scenario, encryption plays a role, so we include it in the consensus process.
Each component has many extensions, and components have constraints between each other. For example, "proof of X" in the third step is possibly connected with "proposer" in the first step. Table I shows how the above components influence the mentioned CBDC technical features in Section II. We measure the impact through categories of High 3 , Medium 4 and Low 5 . TBA indicates to be further analyzed. Every component has its impact on every CBDC dimension. We measure these impacts by empirical experiments and formal proofs. Different components together can build one consensus algorithm with the same weight. If needed, they could have different weights of impacts on different CBDC technical features.
We have referenced RAFT several times. Here we use the Consensus Process map to describe the RAFT consensus algorithm as seen in figure 4. Then we leverage Table II to show that the RAFT consensus algorithm can provide CBDC systems good fault-tolerance and performance while it takes no privacy protection measurements.
Overall, the evaluation sub-framework can guide CBDC designers to consider related factors, analyze different combinations, and find a suitable consensus algorithm. However, we need a method to judge whether the combination  Fig. 4. Consensus Process of RAFT starts from voting and election timeout mechanism in the leader election. Then a client sends a request to the leader in the network. After the leader's verification, validators make a backup and respond to the leader node. Then this transaction will be regarded as valid when receiving more than half of the notices. meets the expectations. Therefore, we need the verification sub-framework to ensure proposed consensus algorithms are valid and satisfactory.
2) Operating Architecture: We propose two new operating architectures based on current CBDC architectures (figure 1). The operating architecture determines how the network functions at a high level. As mentioned before, a trade-off [6] between CBDC technical features exists that we can not leverage consensus algorithms to provide excellent performance, security, and privacy at the same time. However, we can update the operating architecture to compensate for weak CBDC technical features. In this part, we use business secrecy as an example.
We concluded a three-tier CBDC architecture ( Figure 5) to describe institutions that do not become tier-1 but want to provide CBDC services. The model describes how tier-1.5 institutions provide CBDC services to their customers in the current situation.
Tier-1.5 institutions have to provide transaction information to tier-1 ones for bookkeeping because tier-1 institutions operate the ledgers. Once tier-1 institution records the transaction in the ledger, the transaction becomes valid. However, tier-1.5 institutions will refuse to provide the customer data to tier-1 ones because they are competitors with interest conflict. Some commercial institutions even give up providing CBDC-related services.
To safeguard tier-1.5 institutions from data monopoly, we propose two operating architectures: 1) Use dynamic virtual addresses to keep the identities of  Medium  TBA  High  TBA  TBA  2 Request  To one  High  High  Low  TBA  TBA  Medium  TBA  3 Pre-Prepare  Verification  High  High  High  TBA  TBA  TBA  TBA  4 Prepare  No action  TBA  TBA  TBA  TBA  TBA  TBA  TBA  5    However, tier-1 institutions can infer identity information by analyzing enough token flows and real-world events even though they only know transaction information. To further protect the business secrecy of tier-1.5 institutions, we can make virtual addresses dynamic that tier-1.5 institutions create new virtual addresses to collect changes in transactions. This technical solution can prevent tier-1 institutions from accessing tier-1.5 institutions' customer data further.
There are other methods to improve the operating architecture. For example, figure 7 presents a third-party organization in tier-1 to ensure no competition with tier-1s and tier-2s. However, the operating organization needs a feasible business model to ensure enough money to support its stable operation.

B. Verification Sub-Framework
By the evaluation sub-framework, CBDC designers can develop a customized solution. Then the verification subframework works to ensure the proposed solution's feasibility and rationality.
The verification sub-framework contains diverse methods to verify proposed solutions. We divide these methods into two categories: empirical experiments and formal proofs. For empirical experiments, we can simulate a real scenario and test parameters in the full load environment. For formal proofs, we can build a mathematical model and infer related theories and find whether they meet initial expectations.
The verification sub-framework works in the following procedures: 1) Model proposed solutions for further verification. The verification sub-framework can guide CBDC designers to describe the proposed solution mathematically. 2) Follow the built model to conduct empirical experiments to examine performance. 3) Follow the built model to conduct formal proofs, mainly for security and privacy.

IV. CBDC SCENARIO EXAMPLE
Next, we present an example of using the CEV framework. We assume a country with a large population and well-developed technology and communication. The CBDC designers focus on privacy and performance, especially network scalability, latency, business secrecy. Then we leverage the CEV framework to propose a suitable solution for this virtual country.

A. Evaluation
We leverage the evaluation sub-framework to choose the operating architecture and propose several consensus algorithms. In this example, both operating architectures are feasible to improve business secrecy. So we choose figure  6 as the operating architecture. Then the evaluation subframework can propose consensus algorithms for different consensus networks.
Since the example emphasizes performance among the three CBDC technical features. We leverage table 1 to find the combinations with relatively high scores in performance for both wholesale and retail consensus networks.
The recommended consensus algorithm in the wholesale consensus network works, and retail consensus networks work in figure 8 and figure 9, respectively. Table 3 and Table 4 are derived from table 1. Table 3 shows that the recommended consensus algorithm in the wholesale consensus network has a good performance, especially network scalability, but the algorithm may bring a potential security issue. Similarly, table 4 shows that the consensus algorithm in the retail consensus network has a good performance and a potential security issue. Both tables present that the system has relative good privacy. The impact table only provides a rough analysis to CBDC designers, so we need to further verify the proposed solution in the verification subframework and make sure proposed solutions are objective and reasonable.
Specifically, encryption in the third step protects business secrecy from validators because validators only backup encrypted data for tampering with proof in the algorithm. Additionally, "To one / Sharding" in the "client-request" step can improve the system's performance in a tokenbased sharding method. Besides, "Data backup" can increase the resilience of CBDC systems. These impacts on CBDC technical features are derived from the verification sub-framework rather than our subjective idea. Next, we use the verification sub-framework to see whether the proposed solution meets the initial expectations.

B. Verification
Then we use the verification sub-framework to verify the above-proposed solution by building a theoretical model for the solution and following the model to carry out empirical experiments and formal proofs.
We first introduce the sharding method in our experiment. The previous work [41]- [43] discusses account-based sharding and token-based sharding. We here introduce them in a CBDC scenario with two types of transactions involved (shown in figure 10).
Account-based sharding divide users by accounts. In the two-tier CBDC architecture, tier-1 institutions have different wallets and divide users by their accounts. For example, Tier-2 A comes to Tier-1 A 6 when using CBDC because Tier-2 A created its account from Tier-1 A. A cross-shard transaction happens if Tier-2 A transfers its money to Tier-1 B's customers. The cross-shard transaction needs the currency issuer (the central bank) to redeem a token in one ledger and issue a new token in another ledger, which decreases the system's performance a lot compared with single-shard transactions [43]. We use token-based sharding as an example.
Token-based sharding divides users by tokens. If Tier-1 A issues a token to Tier-2 A, Tier-2 A comes to Tier-1 A to initiate CBDC related services because of the token ( figure  11) that Tier-1 A operates. Users only need to contact their token service provider and transfer the token to everyone without a cross-shard transaction in a token-based shard mode. However, token-based sharding needs the central bank and operating institutions to provide a uniform interface to distribute transactions. Because if a customer who use Tier-1 A's token come to Tier-1 B's interface, the uniform interface should distribute the transaction to Tier-1 A.
1) Model: Next, we built a CBDC state machine for the recommended algorithms to see how the proposed solution functions. Figure 12 shows ledger state machine. The model provides a formal description of finite state machine M = (S, V, t). The state machine can describe any state s ∈ S for every moment. It can read input token τ ∈ V and proceed to the next state by different transitions t(s, τ).     Figure 12 shows how the state machine ensures the leader node records the token in the ledger before noticing clients. However, it only covers operations from the leader node rather than validator nodes. The validators in the consensus algorithm do a data backup, which can help to reduce malicious behaviours. We discuss it in Section IV 4 Security. Figure 13 shows data model of leaders' ledgers. Transactions are subject to the leader's ledger. Once a leader updates its ledger successfully, the transaction becomes legal and immutable.  The following mathematical expressions present the token flows rather than transactions. Here we add an assumption that the leader nodes are non-faulty (H) and follow the model procedures. Faulty nodes may behave arbitrarily and be vulnerable to inside and outside attacks. With nonfaulty nodes, we can ensure leader nodes record tokens in the ledger in every transaction: 1) ∀τ. (H ∧p(τ) ⇒ p(r (τ))∧p(c(τ))) 2) ∀τ. (H ∧p(τ) ⇒ p( f (τ))) ∀τ. (H ∧p(τ) ⇒ p(r (τ)) represents that if the ledger has recorded input τ, a non-faulty leader(H) always adds a valid  Predetermination  TBA  High  High  TBA  TBA  TBA  High  2 Request  To one  High  High  Low  TBA  TBA  Medium  TBA  3 Pre-Prepare  Verification  High  High  High  TBA  TBA  TBA  TBA  4 Prepare  No action  TBA  TBA  TBA  TBA  TBA  TBA  TBA  5 Commit  No action  TBA  TBA  TBA  TBA  TBA  TBA  TBA  6 Decide  Self-decision  High  High  TBA  Low  Low  TBA  High  Validators  Fixed  TBA  Low  Low  High  High  TBA  TBA  Total  3  3    The leader has recorded τ T x(τ, x) Transaction with input τ at time x H (τ, x) τ has been spent before x F (τ, x) τ can be spent after x r (τ)

Definition 2. (UTXO) U T X O
Received token in a transaction using τ c(τ) Change token in a transaction using τ f (τ) Received token in a cross-shard transaction using τ The transaction graph to the ledger with inputs of τ and outputs of received token r (τ) and change token c(τ). If the change is 0 (c(τ) = nul l ), p(c(τ)) means no token recorded. ∀τ. (H ∧p(τ) ⇒ p( f (τ))) represents central banks and non-faulty leaders(H) ensure that the receiving ledger record the output tokens in a cross-shard transaction ( figure  15).
Cross-shard transactions will not happen if we split one into several concurrent sub-transactions. However, crossshard transactions match some business scenarios and possibly happen. For example, CBDC users may pay tokens in different ledgers in an atomic transaction. Alternatively, CBDC designers want to control the number of tokens and consolidate tokens from different ledgers to one new token. In a CBDC system, the central bank is responsible for issuing and redeeming tokens, regulating both transactions and ensuring that the new shard records output tokens.
2) Performance: Empirical experiments test user scalability, network scalability, and latency. To ensure experiments are close to reality, we randomly initiate user transactions by different payment methods, including face-to-face transfer, collecting, etc.
We leverage AWS EC2 to deploy CBDC networks and carry out the empirical experiments shown in figure 16. Unfortunately, since the Corda open-source version has limitations on transaction volume, we could not demonstrate an extremely large TPS (transaction per second) in the experiment due to cost control. However, the experiment demonstrates performance improvement in a CBDC system.
Sharding improves network scalability and user scalability. Commercial institutions, including tier-1 and tier-1.5 ones, could become leader nodes or validator nodes and undertake customer due diligence in retail networks.
Deferred regulatory information Fig. 10. Cross-shard transaction describes a transaction with two ledgers involved; single-shard transaction describes a transaction within one ledger.
PI A 100 asdadc3423sdad... Fig. 11. Holder is the identifier to determine which tier-1 institutions that tier-2 customers belong to.
If CBDC is non-fungible, token-based sharding can map every non-fungible token to one leader node when the issuer creates the token. Then tokens can be circulated efficiently in different ledgers in parallel, increasing the performance. However, CBDC is more like a fungible token, and every transaction produces a change. As a result, the token owner has to use several small tokens, which causes additional concurrent transactions. Moreover, if the token owner pays two tokens that circulate in different ledgers simultaneously, it must first initiate a cross-shard transaction and follow a single-shard transaction. The recommended consensus algorithm use sharding to improve performance by parallel running ledgers because cross-shard transactions are less frequent in the token-based sharding method than the account-based one. However, more shards may cause worse performance if each transaction in the retail consensus network needs verification from all parties in the wholesale networks. Therefore, the recommended algorithm makes one tier-1 institution decide transactions by itself, in which more shards do not bring worse performance.
Overall, we prove that the proposed algorithms can increase the system's TPS while not sacrificing latency.
3) Privacy: We provide two updated operating architectures to protect business secrecy. For option two, we designate one operating organization to distribute CBDC because it is not a competitor with other operating institutions such that their data are safe from monopoly.
For option one, the dynamic virtual addresses can prevent tier-1 institutions from knowing tier-1.5 institutions' customer identity. The method is similar to the bitcoin schema. In the bitcoin [33] system, essential facts exist: 1) transactions generate new addresses to collect change; 2) users could have many addresses. Bitcoin uses this method to protect customer privacy from leaking to the public, while our model protects tier-1.5 institutions' data from leaking to tier-1 institutions. However, like the bitcoin schema [47], tier-1 institutions can still obtain secret information, depending on transaction types. We proved potential information leaking for different transactions types in Appendix A-B. Besides SISO transactions, SIDO, MIDO, MISO transactions may expose relationships between inputs and outputs.
Therefore, a more aggressive method to protect user privacy is to create virtual entities. In the CBDC operating architecture, tier-1.5 institutions process transaction data before sending it to tier-1 institutions. tier-1.5 institutions can create virtual entities with virtual addresses in the network and use these virtual entities to create SISO transactions for customers. For example, in a SIDO transaction, tier-1.5 institutions can use virtual entities as the receiver to avoid the connection between payer and payee and then send it to the actual receiver via a SISO transaction. Other types of transactions can also apply virtual entities. Enough virtual entities can help tier-1.5 institutions to hide the direct relationship between the payees and payers.

4) Security:
We followed the built model and proved that double-spending is possible in single-shard transactions and impossible in cross-shard transactions in Appendix A.
By our proof, we can get that a non-faulty leader prevents double-spending. However, the assumption is the weakest point in the system. The central bank usually does not perform malicious behaviour. So in the wholesale consensus network, the central bank can ensure no fault. However, in the retail consensus network, tier-1 institutions are responsible for their ledger and decide each transaction on its own without validation. No mechanism ensures them non-fault. As a result, double-spending may happen in single-shard transactions.
The design of CBDC is a trade-off [6] between different CBDC technical features, including performance, security and privacy. In this example, one institution decides all transactions by itself, ensuring a high performance but sacrificing security. Although we can not avoid double-spending in realtime in the recommended consensus algorithms, we can increase the cost of malicious behaviours. For example, the recommended consensus algorithm in the retail consensus network chooses data backup from validators and the leader sends encrypted transactions to validators. The validators will undertake data backup. Once the leader node changes the original data, we can use the same encryption method to encrypt data and check data consistency. If the leader node performs malicious behaviour, they will be punished. Therefore, the leader nodes are reluctant to do malicious behaviours because the validators can find them easily. Besides, encryption can prevent the validators from accessing customer data, ensuring business secrecy in the CBDC system. In some cases, third-party auditors can run validator nodes, and it is not necessary to encrypt the data.
On the other side, we can ensure extra verification will not overly influence latency because validators in the network are dynamic, so not all validators need to join the consensus process. Moreover, since the central bank controls issuance and redemption transactions, it knows the balance of money on each ledger so that no extra money comes from retail networks. Figure 17 shows how we iterated the CEV framework. CBDC design involves many trade-offs [6] between different CBDC technical features. We start from a country with a large population, focusing on performance and privacy. Then we use the evaluation sub-framework to propose solutions. Finally, we leverage the verification framework to measure performance, privacy, and security. The proposed solution presents an excellent performance and privacy, but double-spending is possible.

C. Framework Iterations
After verification, CBDC designers can return to CBDC technical features to adjust expectations to improve system security. For example, if they need a more secure system, they could continually use the evaluation sub-framework to propose new solutions and use the verification subframework to verify them. In the experiment, if CBDC designers want a real-time check for fault, they can make validators vote for each transaction. Then double-spending will not happen even though the leader node is faulty. The newly proposed solution can also involve more participants voting for single-shard transactions, ensuring no fault in the retail consensus networks. However, it may potentially influence the system's performance. Afterwards, the CBDC designer can return to CBDC technical features again until finding a balance point. The framework presents potential trade-offs in CBDC designs and helps CBDC designers find a balanced solution and meet expectations.

V. CONCLUSION
Our paper proposes a CBDC framework (CEV Framework), including an evaluation sub-framework and a verification sub-framework to design solutions for CBDC systems. Our work proposes an original approach and potentially promotes the evolution of CBDC. Furthermore, to the best of our knowledge, we are the first to propose a framework to provide a holistic solution for CBDC designers according to their jurisdictions' economic and regulatory conditions.
Our paper analyzes CBDC technical solutions by splitting consensus algorithms into different components and improving operating architectures to solve CBDC related issues. Most importantly, we build a verification subframework to prove the feasibility of the recommended algorithms and operating architectures with rigorous and professional empirical experiments and formal proofs. By using the CEV framework, diverse central bank digital currency projects can better design the consensus algorithms and adopt reasonable operating architectures.
The framework could be continuously updated and improved by iterating with the workflow. The main future work is to include more CBDC technical features and solutions into the framework and update the impact table to make it more accurate to propose solutions. Besides, the CEV framework needs a more efficient way to verify proposed solutions. Additionally, the CEV framework can also be used to propose stablecoin solutions.

ACKNOWLEDGMENT
This article is partially based on their work in the Global CBDC Challenge [19], in which they were shortlisted as finalists. Based on the framework in this paper, they built an evaluation and recommendation platform that advocates consensus algorithms and operating architectures for different CBDC designers. This platform can satisfy different national economic and regulatory conditions. The authors wish to acknowledge the other two teammates, Mark Liu and Bing Qu. They also gratefully acknowledge the help of Bo Tong Xu in fruitful discussions. This paper is reviewed by Dr. Philip Intallura, Dr. Bing Zhu, and Dr. Ziyuan Li. They also wish to express great appreciation for their valuable input.

APPENDIX A FORMAL LOGIC PROOF
Here are some temporal logic proofs in the paper. Please see notations in Section IV-B.1.

17.
∀τ. ( With proof by contradiction, we get that a recorded token in the validator's ledger can not be spent twice in different transactions.

Lemma 6.
Assume a leader is non-faulty(H), doublespending will not happen in its shard.
Proof. In a token chain, the issuer creates and issues tokens (a) with the in-degree of 0. For a valid payment transaction, a non-faulty leader ensures itself record the received token and change token in a valid transaction.