A Privacy-Preserving Transparent Central Bank Digital Currency System Based on Consortium Blockchain and Unspent Transaction Outputs

There is rising global demand for the deployment of a central bank digital currency (CBDC) system to achieve financial stability. However, striking a balance between privacy, transparency, and auditability in such a system is technically difficult. We propose a CBDC system based on a consortium blockchain that adopts a privacy-preserving, transparent unspent transaction output (UTXO) model. The proposed system satisfies the travel rule of payment, unlike existing cryptocurrencies. Unlike the conventional UTXO approach, users use wallet-linked addresses for transactions rather than their actual wallet addresses. Each transacting address is generated using two keys: a random private key computed by the sender and the recipient's public key. The final private key is known only to the recipient, and it is required to spend the UTXO received using the address. Thus, each user holds only a single authorized public key and address, which eases regulatory compliance in the network without compromising anonymity and privacy. To manage the blockchain, the central bank and several certificate authorities execute the energy-efficient Clique consensus algorithm. Only the central bank supplies money to the network. A prototype of the system was implemented using Python-Flask, and it outperformed the state-of-the-art systems by providing a smaller transaction size (665 B) and lower verification time (9 ms).


INTRODUCTION
T HE rapid emergence of blockchain distributed ledger technology (DLT) [1], [2] and numerous cryptocurrencies such as Bitcoin and its competitors, which are not backed by any government, raises concerns about the stability of financial marketplaces and the conservancy of monetary policy. In response, many central banks (CBs) and monetary authorities worldwide have begun to conduct research on central bank digital currencies (CBDCs) [3], [4]. CBDC is a digital form of fiat currency, which is supplied and controlled by the respective CB. Instead of creating physical coins or paper money, the CB issues digital coins with the government's full trust and backing [5]. CBDCs' primary aims are to lower the cost of printing money and to reduce illegal cash flow and tax evasion in financial sectors. They are not, however, meant to replace cash or to imitate cryptocurrencies. Instead, they can coexist with traditional cash and be used in public sectors as they provide swift and flawless monetary flow monitoring as well as cost-effective auditing. Corruption in developing countries can be reduced by adopting CBDCs as the payment method in government-funded projects. A CBDC does not require any trusted third parties (TTPs) to support transparency standards and prevent counterfeiting because it uses the blockchain technology to ensure transaction verifiability [6].
The deployment of a CBDC system presents a number of challenges that must be properly addressed before launch. Citizens can withdraw excessive amounts of money from banks at once to acquire digital currencies, causing a bank run. To avoid this risk, a maximum CBDC purchasing limit must be set. Regulatory compliance and transparency must be ensured without jeopardizing user anonymity and privacy. In the Bitcoin cryptocurrency network, no authorization is required. To preserve anonymity, users hold numerous wallet addresses and use each address only once to receive a transaction [7], [8]. The use of dynamic wallet addresses prevents others from learning a user's balance by tracking their transactions. On the contrary, users must be authorized in a CBDC network by several certificate authorities (CAs) to satisfy know-your-customer (KYC) standards. They should have a single authorized wallet address so that user authentication and prosecution of illegal activities can be easily handled and regulatory compliance can always be ensured. In both the networks, participants must be able to access the transaction ledger and verify the correctness of transactions to be assured that the system is transparent and no transaction is double-spent by any party. However, protecting user privacy while leaving KYC-enabled transaction ledger public and verifiable to the participants is a challenging task. Conversely, keeping the ledger private ensures privacy and auditability but fails to provide transparency. In short, the three basic properties of CBDCs (i.e., privacy, auditability, and transparency) are difficult to satisfy simultaneously. This open challenge demands an advanced cryptographic technique that can fulfill the fundamental CBDC requirements.

Race to CBDC
To date, more than a hundred countries around the world are exploring their own CBDCs, which can be used beyond their territories through low-cost, cross-border payments [4]. The Bahamian Sand Dollar was the first CBDC to support identified domestic transactions. Although this currency is fully auditable, it lacks anonymity that is the main attraction of digital currencies from a user perspective. China is far ahead and almost set to roll out its CBDC, called digital Yuan, nationwide, with a view to becoming a cashless society. The project is currently in its early stages of trials and intends to allow digital Yuan trading beyond China's borders. However, it is not yet known what technical foundation the digital Yuan is built upon. It is also unclear how users would actually own and spend digital Yuan without a blockchain. Despite these concerns, digital money is expected to be China's primary currency for conducting domestic and international transactions if everything goes well. Of the G7 economies, the United States and the United Kingdom are the furthest behind on CBDC development. Nineteen G20 countries are considering a CBDC, with sixteen of them being in the research or pilot stage.

Related Work
Several CBDC project reports are available on the respective CBs' websites. However, CBDC literature is limited. Opare et al. [9] filtered existing CBDC papers and project reports based on some essential parameters and selected only eight project reports. These projects are Jasper, Ubin, Jasper-Ubin, Khokha, Stella, Inthanon, BLOCKBUSTER, and SALT [10], [11], [12], [13], [14], [15], [16], [17]. For real-time gross settlement (RTGS), most projects used Ethereum, Quorum, Hyperledger Fabric, or Corda and conducted inter-bank payment trials with proof of concept prototypes. Ethereum is a public blockchain, which does not ensure user privacy and cannot be controlled by a government. This blockchain is powered by smart contracts, which require the ether cryptocurrency to execute [18]. As a result, an Ethereum-based CBDC system is not cryptocurrency-independent. The same concern applies to the Quorum blockchain because it is a fork (variant) of the Ethereum codebase. The Quorum-based solutions use zero knowledge (ZK) proofs [19] to achieve privacy, but they involve larger transaction sizes and higher latency. The Hyperledger Fabric prototypes enable accountbased transactions at a higher speed. However, the use of private channels for privacy raises scalability concerns because the network complexity for channel management increases as the number of users increases. Corda-based approaches provide the privacy and speed required for a UTXO model, but they suffer from certain resiliency issues. In particular, the inclusion of a centralized notary node that conducts some necessary operations opens the door to a single point of failure in the blockchain network. To protect privacy, transacting parties must generate and store a new private-public key pair for each transaction similar to Bitcoin users. From the CBDC perspective, this requirement complicates regulatory compliance and raises a key management risk.
While the survey took place in 2020, little progress in terms of the number of articles has been noticed from 2020 to present. W€ ust et al. [20] introduced a fully centralized CBDC system, departing from blockchain and combining traditional e-cash and account models. To conduct a transaction in this system, the sender and recipient prove the secret serial numbers of their current account states, which are signed by the CB, using ZK proofs. Then, the amount is immediately deposited to the recipient's blinded account. However, such a centralized system cannot guarantee transparency and data integrity. The distinction between a CBDC and traditional e-cash is limited to privacy only. Zhang et al. [21] substantially improved transaction speed by designing a hybrid model of conventional UTXOs and accounts. They also reduced the consensus time using a hybrid blockchain that combines the proof of authority (PoA) and practical Byzantine fault tolerance (PBFT) algorithms. Their research focused on transaction throughput but did not consider other CBDC properties. A centrally banked cryptocurrency named RSCoin was proposed by Danezis et al. [22], which is based on Bitcoin with improved scalability. Privacy solution for this system was left for future work. A holistic software-based CBDC system, which supports fully private transactions using ZK proofs and addresses regulatory constraints, was proposed in [23] but not implemented. Tinn et al. [24] proposed a P-hybrid CBDC design without any implementation. The design includes ID-linked accounts composed of numerous pairs of secret and public keys. It requires an ID-linked database keeper that is separated from the blockchain and managed by a single or multiple TTP(s) who control(s) the regulation. The identity of a recipient of digital cash and the transacted amount are observed by an authority, but no one, not even the authority, can identify the sender(s). The sender(s) can mint private coins that cannot be publicly linked to the sources. Their approach solves the privacy and auditability issues but does not satisfy the travel rule of payment [25] in which both governing bodies of a transaction know the sender as well as the recipient.
This study aims to develop a partially decentralized CBDC system that can provide low-memory, low-latency transactions without compromising any of the essential CBDC properties.

Our Contributions
The contributions of this work are summarized as follows: 1) A few CBDC papers provide implementations, whereas most focus on CBDC scopes and requirements. We provide a full-scale implementation of CBDC with sufficient experimental data. This can help with ongoing research worldwide for the deployment of blockchainbased CBDC systems. 2) While most existing CBDC and RTGS systems do not provide auditability, transparency, privacy, and resiliency concurrently, our system strikes a balance between these properties.
3) While the other systems suffer from high memory consumption and latency, our system provides a smaller transaction size and lower verification time. 4) We define a security model for our system and prove that the system achieves the desired security properties for a payment network. The proposed CBDC system has the following features: UTXO in consortium network: UTXO-based transactions are conducted in a consortium blockchain network governed by a group of authorities where permission is required to join the network. Energy-efficient consensus: Instead of using energyintensive proof of work (PoW), blocks are managed using the energy-efficient Clique consensus algorithm in which validators know each other. Auditability and travel rule: Unlike traditional cryptocurrencies, only registered users can participate in transactions using authorized wallets, which helps to ensure regulatory compliance. The identity management or user registration is accompanied by several CAs or KYC agents who are approved by the CB. Each CA runs a consensus node for blockchain management and a full node for user access control. Transactions are auditable as they are authenticated before being stored in the blockchain. In case of a court request, the CAs must disclose the identity and balance of a user. This prevents criminals from conducting illegal activities such as tax evasion, money laundering, and smuggling through the network. Transparency or publicly verifiability: Transactions are public within the consortium network. Anyone in the network can read the blockchain and verify the correctness of transactions. Anonymity and privacy: Unlike Bitcoin, ID-linked pseudo-random addresses are used as receiving addresses instead of recipients' actual wallet addresses. This strategy eases the allocation of a single wallet address for each user without affecting their anonymity. Nobody except the corresponding CAs know the sender and recipient of a transaction. Unlike Zcash [26], everybody in the network can observe transacted amounts to ascertain the correctness of transactions. Observing transacted amounts also helps to monitor financial flows and decline a transaction that attempts to transfer an amount exceeding the maximum limit set by law enforcement. As transactions are anonymous in the network, no one can learn a user's wallet balance by tracking their previous transactions. Fund recovery option: If a user claims that they cannot spend their UTXOs because they have lost their wallet private key, their CA informs the CB. If the claim is investigated and found to be true, the CB blacklists the addresses belonging to the orphaned UTXOs and refunds the same amounts to the user's new address. This function is the advantage of a CBDC over a cryptocurrency in which validators are unidentified and do not know each other. The remainder of this paper is organized as follows: The background related to this research is elaborated in Section 2. The proposed system and algorithms are presented in Section 3. A security model for the system is formalized in Section 4. The system's security and privacy are analyzed in Section 5. The implementation results and performance analyses are provided in Section 6. The limitation and scope of the system are mentioned in Section 7. Finally, the paper is concluded in Section 8.

Blockchain
A blockchain is an immutable shared ledger in which transaction data is timestamped and stored in chronological blocks with unique hashes. The blocks are cryptographically connected to one another and can be publicly verified over a distributed network [27]. They are synchronized with the help of a consensus algorithm that allows machines (nodes) to work together [28]. Even if certain nodes fail individually, the network as a whole agrees on a single source of truth [29]. Blockchain data can never be modified, unlike centralized databases, because modifying a block causes the entire blockchain to become incorrect. The main goal of blockchains is to share information without requiring a TTP. Blockchains can be classified into two major categories: permissionless and permissioned. In a permissionless blockchain, any node having a copy of the entire blockchain can become a miner (validator) and participate in consensus, whereas a permissioned blockchain allows a limited number of authorized nodes to participate in consensus and only registered users to conduct transactions.

Consortium Blockchain
A consortium blockchain is a permissioned blockchain that combines public and private blockchain functionalities [30]. It is regulated by a group of validators, each representing a single organization or authority [31]. Consortium blockchains have various advantages over public blockchains such as lightweight consensus, high-speed transactions, low energy consumption, proper regulation, and no illegal activity. PoA, PBFT, Istanbul BFT (IBFT), and Raft are the preferred consensus algorithms for these blockchains. PBFT and IBFT can tolerate a maximum of N=3 faulty nodes among N consensus nodes in a network. In contrast, Raft and PoA can tolerate up to N=2 À 1 faulty nodes [32]. The computational complexity of PBFT and IBFT is Oðn 2 Þ, whereas that of the PoA and Raft algorithms is OðnÞ. Although Raft achieves consensus more quickly than PoA, its consensus nodes blindly follow their leader. While the correctness of a block proposed by the PoA leader is verified by each authority, it is assumed that the Raft leader will always act correctly [31]. Because blocks are not secured by unique hashes on various platforms, Raft necessitates alternative methods of data integrity assurance.

Clique Consensus
Clique, a type of PoA, is a new family of BFT consensus algorithms [32]. In this algorithm, new blocks are directly added to a blockchain after validation. Unlike PoW, there is no competition among the validators for complex mathematical puzzle solving. As a result, low computational power is required to reach consensus. Clique is dependent on a group of N trustworthy nodes called the authorities, each recognized by a unique ID or public key. A majority of the authorities must be honest to ensure network transparency. All authorities continuously monitor each other's activities. Consensus is achieved through a round-robin schedule, assigning the duty of block delivery to each authority in turn.
Unlike Aura PoA that allows only the current leader to propose block, Clique assigns multiple block proposers at a step [33]. The proposers are selected in a sequence that considers the block number and number of authorities [34]. At each step, a leader and N=2 À 2 assistants propose their blocks as shown in Fig. 1a. Thus, after every N=2 þ 1 steps, an authority can propose a block. The leader's block normally prevails because each assistant is halted from submitting a block for a certain amount of time so that the leader's block reaches everyone first. If an assistant has high computational power and better network connectivity than the leader, the assistant's block reaches some authorities earlier than the leader's block. When an authority receives multiple blocks of the same block index, their blockchain intends to deviate into different paths forward. This situation is termed as fork, which must be avoided to maintain the same state of the ledgers managed by individual authorities. A fork is solved using the GHOST protocol [36] or block scoring approach as shown in Fig. 1b. The current leader receives the highest priority. The block proposed by an assistant is always replaced by the block proposed by a proposer who has higher score than the assistant. The replaced blocks are called uncle blocks, which are not included in the blockchain. If an authority proposes an invalid block, the block is rejected and the proposer is voted out by the network's honest majority.
Evaluation of Clique Based on The CAP Theorem [33]: Consistency: A blockchain achieves data consistency when forks are avoided. Due to forks, consensus nodes face difficulty synchronizing their individual ledgers. If consistency cannot be achieved immediately, whether forks are resolved sooner or later (eventual consistency) or are unsolvable (no consistency) must be considered. Clique provides eventual consistency as the authorities resolve the resulting forks at some point using the GHOST protocol.
Availability: A blockchain is available if transactions continuously broadcast by users are processed. By design, Clique allows N=2 À 1 authorities to propose a block with random delays at a step. If the step leader is offline, assistant block proposers propose blocks. Therefore, this algorithm offers a higher availability, which is proportional to N.
Partition tolerance: When partitions occur in a blockchain network, consensus nodes are divided into disjoint groups such that nodes in different groups hold different blockchains. A majority of Byzantine nodes is required to determine the correct blockchain. Therefore, the maximum number of tolerated faulty nodes in Clique is N=2 À 1 if N is even or ðN À 1Þ=2 if N is odd.

Elliptic Curve
Elliptic curve cryptography is used to generate wallet addresses and digital signatures [31]. An elliptic curve over a prime field F p is given by the following equation [36]: where p is a prime number, a and b are coefficients, and x; y 2 ½1; p À 1 with The most popular elliptic curve for blockchains is Secp256k1. For this curve, a ¼ 0, b ¼ 7, and p ¼ 2 256 À 2 32 À 977, which can be expressed as follows [37]: A special point at infinity O on E and some other points EðF p Þ (e.g., Q 1 , Q 2 , and Q 3 ) form a finite, cyclic, abelian group G of order q and generator point G, such that qG ¼ I.
Group G has the following properties: For two given points Q 1 ; Q 2 2 G, it is challenging to determine an integer k 2 Z Ã q such that Q 2 ¼ kQ 1 .

Public Key Generation
A public key Q 2 G is generated through the elliptic curve scalar multiplication (ECSM) operation. The underlying principle of ECSM is to multiply the base point G by a scalar or private key k 2 F q such that Q ¼ kG. It includes elliptic curve group operations such as point addition (PA) and point doubling (PD) [38]. Let us consider two points on E in affine coordinates, such as Q 1 ðx 1 ; y 1 Þ and Q 2 ðx 2 ; y 2 Þ, in the range of ½1; p À 1. The PA Q 1 þ Q 2 makes another point Q 3 ðx 3 ; y 3 Þ 2 G, which is obtained as follows [36]: The PD of Q 1 ðx 1 ; y 1 Þ on E is performed as follows [36]: where g ¼ ð3x 2 1 Þð2y 1 Þ À1 and Q 1 ¼ Q 2 . PA and PD in affine coordinates involve several inversion operations over F p . However, a single modular inversion is equivalent to 80 modular multiplications in terms of latency [36]. To reduce the number of time-consuming modular arithmetic operations, the group operations are performed in projective coordinates by representing the points Q 1 and Q 2 as The formula for projective PA is provided as follows [36]: The formula for projective PD is provided as follows [36]: The ECSM can be performed by adding G to itself k À 1 times such that: If k is expressible as a power of 2, Q can be obtained by doubling G on itself log 2 k times such that: Algorithm 1 demonstrates the binary or double-and-add method for generating a public key from a private key through ECSM. The public key Q is obtained by the sequential operations of PA and PD based on the binary bit pattern of the l-bit private key k. As shown, PD is performed in every iteration, whereas PA is performed only when the current bit of k is 1.

Algorithm 1. Public Key Generation [36]
Curve parameter: Base point G Input: // projective to affine 10: return Q Definition 1. Given an elliptic curve E defined over a finite field F p , a generator point G 2 EðF p Þ of order q, and a point Q 2 hGi. When q is sufficiently large, it is challenging to determine an integer k 2 ½0; q À 1 such that Q ¼ kG. This constraint is called the elliptic curve discrete logarithm problem (ECDLP) [36], [39]. The integer k is the discrete logarithm of Q to the generator G, denoted as k ¼ log G Q.

Definition 2. For two given points
q , the computation of ðk 1 þ k 2 ÞG is simple, but the computation of ðk 1 k 2 ÞG is difficult without knowing k 1 and k 2 . This difficulty is called the elliptic curve Diffie-Hellman problem (ECDHP) [36].

Address Generation
A wallet address is a 34-character alphanumeric string that is generated using the following equation: First, an uncompressed public key (i.e.,''04 00 jjQ x jjQ y ) is converted into a hash value using the SHA256 and RIPEMD160 hash functions, consecutively. The hash value is then encoded using the Base58Check encoding technique, which has an alphabet of 1-9, a-z, and A-Z excluding 0 (zero), O (capital o), I (capital i), and l (small L) [31].

Elliptic Curve Digital Signature Algorithm
The elliptic curve digital signature algorithm (ECDSA) is used for transaction signing and verification as it is widely used in blockchains. Algorithm 2 presents the signature generation process, which takes a private key k and message M as the input and outputs a two-part signature S. Algorithm 3 describes the signature verification process, which verifies S using M and the corresponding public key Q.

Encryption and Decryption
Encryption is a technique of hiding data so that only authorized parties can understand the information. Decryption is a way to retrieve encrypted data. The original meaningful message sent by the sender before encryption or received by the receiver after decryption is called plaintext. The meaningless data transferred after encryption are called ciphertext. In cryptography, there are two types of encryption: symmetric and asymmetric [36]. In symmetric encryption, the sender and receiver share a common private key to encrypt and decrypt information. However, in asymmetric encryption, they use two different private keys to perform these operations while both parties require each other's public keys. The proposed system adapts asymmetric encryption to encrypt data with high security and privacy.
Algorithm 2. ECDSA Signature Generation [40] Curve parameter: Base point G; curve order q Input: Private key k, message M Output: Signature Sðr; sÞ 1: Select a random integer: v 2 ½1; q À 1 2: Step 1 6: return Sðr; sÞ Algorithm 3. ECDSA Signature Verification [40] Curve parameter: Base point G; curve order q Input: Public key Q, message M, signature Sðr; sÞ Output: True/False 1: Let Alice be the sender and Bob be the receiver. Their private-public key pairs are ðk A ; Q A Þ and ðk B ; Q B Þ, respectively. To send message M using asymmetric encryption, Alice first represents M as a point on E by encoding. Then, she computes an encrypting key using her private key and Bob's public key as follows: She generates a ciphertext using M and Q e as follows: Upon receiving C from Alice, Bob generates a decrypting key using his private key and Alice's public key as follows: Then, he decrypts the ciphertext using C and Q d as follows: Finally, he decodes M to retrieve the original message.

How Does Decryption Work?
To correctly decrypt a ciphertext, the encrypting key must be equal to the decrypting key. In this encryption, and Alice's encrypting key is equal to Bob's decrypting key. Thus, two parties can exchange a secret message without compromising privacy as they do not need to share their private keys.
If the size of M is less than or equal to the size of k A k B G, the asymmetric encryption can be performed using an XOR (È) operation in (12) and (14) rather than PA to reduce computation time and memory consumption.

Unspent Transaction Output (UTXO)
A UTXO is the amount of digital currency that is transferred to a crypto address or that remains after a transaction is completed [31]. When a transaction occurs, outputs are produced as new UTXOs that can subsequently be spent in other transactions. Each UTXO is treated as a token, and there is no principle of a closing balance. An incoming transaction remains a UTXO until it is connected to the input of an outgoing transaction. If the input amount exceeds the sending amount, the excess amount is refunded to a new address of the sender, considering a change. UTXOs can be combined and split up in any denomination to make payments. A UTXO is transferred from one party to another by changing its ownership rather than by reconciling two centralized databases. UTXO models provide various advantages over conventional account models, including the strong security and the ability to execute multiple transactions from the same payer concurrently. Fig. 2 illustrates the conventional UTXO model [41]. Let us consider three users, Alice, Bob, and Charlie, whose wallet address, public key, and private key sets are f A ; Q A ; k A g, f B ; Q B ; k B g, and f C ; Q C ; k C g, respectively. Alice has a UTXO of 20 coins from which she transfers 12 coins to Bob ( B ) and receives 8 coins as a refund to her sending address A . While conducting the transaction Tx 1 , Alice must prove that she owns the input address. To prove her ownership, she must provide her public key Q A and a signature that is generated by signing Tx 1 with her private key k A . If the signature is verified using Q A , her ownership claim is true because she knows the corresponding private key of A . Similarly, Bob transfers 6 coins to Charlie ( C ) from the UTXO received from Alice and receives a refund of 6 coins. Both transactions are recorded on a blockchain, which is public to all participants in the network.
During the first transaction, Alice knows that the address B belongs to Bob. As the transaction data are public, Alice can discover Bob's balance by tracing all transactions related to B , which is a privacy concern for Bob. This issue is resolved by adopting a dynamic-address approach in which the wallet address is changed after each transaction to prevent transaction traceability [7], [8]. Fig. 3 presents an overview of the proposed CBDC system in which the CB and several CAs manage a consortium blockchain L using the Clique consensus algorithm. The CAs also provide KYC services to users and authenticate transactions. Each of them runs a consensus node to manage L and a full node (website or mobile app) to help users in making transactions without downloading L. Transactions in the network are conducted using the following steps:

PROPOSED CBDC SYSTEM
1) The sender 2 CA 1 prepares a transaction for the recipient 2 CA 2 on the CA 1 's website using the private-public key pair ðk A ; Q A Þ. 2) Server X encrypts the transaction concatenated with the user identifying parameters k s ; k r ; Q A ; Q B using the private key k X , where k s and k r are two random secrets (auxiliary private keys) required to hide the identity of the sender and recipient, respectively. The encrypted data is sent to the destination server (i.e., server Y) for recipient authentication. 3) Server Y decrypts the ciphertext using the private key k Y and confirms that Q B is a registered public key. Then, it records all the information on its database and broadcasts only the transaction with a signature to the network for validation and storage. 4) The network authorities validate the transaction and store it in L using Clique. Fig. 4 shows the decision-making spectrum of the proposed CBDC system. The left end of the spectrum is fully decentralized system management, which applies to cryptocurrencies where transaction data is stored in a distributed ledger and no authentication is performed. Such networks jeopardize privacy and auditability. The right end of the spectrum is fully centralized system management in which only the respective CB controls transaction processing and data storage. This spectrum applies to conventional fiat currencies, which lack transparency and resiliency. The proposed CBDC system refers to the middle point of the spectrum in which transaction is authenticated with centralized control but validated and stored with decentralized control. Thus, it maintains a balance between privacy, auditability, transparency, and resiliency.

Transaction Mechanism
Fig . 5 depicts the proposed UTXO model for CBDC payments. In the conventional UTXO model, although the privacy issue is resolved using dynamic wallet addresses, the use of multiple private keys raises a key management risk. It is simple to securely handle one or two private keys, but managing a large number of keys is difficult. To preserve privacy, a user stores n addresses, n public keys, and n private keys for n transactions. Leakage of any of the private keys results in a financial loss to the user. If a private key is lost, the UTXO that belongs to the key cannot be spent and will be forever orphaned in the network. As no authority takes care of a user's private keys and a private key cannot be retrieved from its corresponding public key, recovering a lost private key is impossible. In addition, users need a static address in some instances, e.g., receiving restaurant bills from customers, monthly rents from house tenants, electricity bills from consumers, educational fees from students, and medical fees from patients. In such scenarios, restaurant managers, landlords, electricity providers, institution administrators, and hospital managers cannot receive payments using different wallet addresses every time. Our UTXO model resolves these issues because transacting parties use wallet-linked addresses rather than their actual wallet addresses. They create their transacting addresses using random secrets, which are stored in their CAs' servers. However, no CA can spend their customers' funds because they do not have customers' wallet private keys. Thus, each user manages only a single private key, and their transaction privacy and security are not compromised.
As shown in the figure, the transaction chain is initialized by the CB with a block reward (supply) of 50000 coins, and the amount is then distributed among users. The first transaction Tx 1 occurs for a CB-to-user payment. At output 1, the CB transfers 10000 coins to a wallet-linked address of Alice 2 CA 1 . The address is generated by the given equation: where k 1 is a random secret (auxiliary private key) computed by the CB. This key is later stored by CA 1 so that Alice can identify her inbound transaction to spend the UTXO.
From the remaining 40000 coins, a transaction fee of 2 coins is charged as an incentive to the authority who records the transaction on L after validation. The rest of the amount is refunded to the CB's wallet-linked address at output 2.  Tx 2 refers to a user-to-user payment in which Alice sends 3000 coins to Bob 2 CA 2 from the amount received from the CB. From the remaining 7000 coins, 2 coins are deducted as the transaction fee, and 6998 coins are refunded to Alice's new wallet-linked address. To prepare this transaction, Alice first chooses a random secret k 3 . To hide Bob's identity, she multiplies Bob's public key Q B by k 3 and generates a pseudo address in a similar manner to (17). When spending the UTXO received from Alice, Bob requires k 3 because he must sign Tx 3 with the new private key k 3 k B that corresponds to his UTXO address. Therefore, Alice encrypts k 3 and stores the encrypted value in Bob's memo field. The encryption is performed using the following formula: where k 3 is considered the plaintext that is to be encrypted, k 1 k A is Alice's signing key that corresponds to the input public key k 1 Q A , ðk 1 k A ÞQ B is the key that encrypts the plaintext, and C 1 is the resultant ciphertext. Note that the multiplication of k 1 and k A produces a new private key 2 F q , and the multiplication of the resultant private key and Q B generates a new public key 2 G.
Owing to the asymmetric encryption, Bob can decrypt C 1 using his private key to retrieve the plaintext as follows: After preparing the recipient's output, Alice hides her identity using another random secret k 4 . She also encrypts k 4 and places ciphertext C 2 in the refunding memo field. In this case, the encryption is performed by taking her own public key Q A as follows: She defines the output addresses, amounts, CAs' public keys, and encrypted memos. The output positions are automatically shuffled. A draft transaction T is formed including the output list, transaction fee, and current timestamp t. To prove ownership of the input address, a signature is generated by signing T with k 1 k A and included in the input. In case of an insufficient fund, multiple UTXOs are combined. Finally, a complete transaction is created by inserting the input into T . The full transaction format is as follows: According to the travel rule of payment, the transaction must be authenticated by the sending and receiving CAs. Therefore, server X operated by Alice's CA encrypts the data set fk 3 ; k 4 ; Q B ; Q A ; T g and sends the ciphertext T c to server Y run by Bob's CA. The encryption is performed as follows: Upon receiving T c , server Y obtains the plaintext as follows: Then, the server authenticates the recipient by searching the CA 2 's customer list for Q B . If Q B is found to be registered, it checks whether the secrets match the output addresses. Finally, T is signed with k Y and broadcast to the consortium network for validation and storage. Similarly, Bob transfers 1098 coins to Charlie 2 CA 2 in Tx 3 . It is noteworthy that both the servers record the transaction information on their databases so that the transacting parties can easily keep track of their inbound and outbound transactions. If not, they need to download every transaction in the network and decrypt its encrypted memos to identify their transactions, which is a time-consuming process. However, unlike a blockchain, the databases are mutable because they are centralized. Therefore, only the random secrets are stored on-chain after encryption, considering the worst-case scenario (i.e., the consequences of the servers crashing [42]).

Consensus Process
The Clique consensus algorithm is used to preserve the blockchain data consistency and prevent double-spending. The network authorities individually store broadcast transactions in a queue called mempool that contains only pending transactions. Before recording a transaction on L, they validate it. Fig. 6 illustrates the transaction validation process. First, the validators check whether the corresponding CAs are registered in the network. Second, they investigate whether the input address appears at an output of a transaction in the blockchain or not. This investigation proves the UTXO validity by ensuring its existence in L. Third, the validators confirm that the input address does not appear at the input of any other transaction in L. This confirmation is required to prevent double-spending a UTXO. Fourth, they confirm the balance sufficiency by observing that the sum of the output amounts and transaction fee is equal to the input amount. Fifth, they verify the input address and signature using the sender's public key. This verification proves that the sender owns the address as they know its corresponding private key. It also ensures the transaction data integrity. If all the validation criteria are satisfied, the transaction is finally added to a list of confirmed transactions that are waiting to be stored in a block.
If the block volume (number of transactions to store per block) is n, a block proposer starts to prepare their block as soon as their mempool is filled up with n pending transactions. After collecting n valid transactions, they generate a new block using Algorithm 4 [31]. As presented in the algorithm, the input is a set of confirmed transactions C T , the previous block hash B À h , and the wallet private-public key pair ðk p ; Q p Þ of the block proposer. First, a Merkle tree fM r ; M h g is generated by hashing the individual transactions in C T using the SHA256 hash function, where M r is the Merkle root and M h is a list of Merkle leaves or hashes. Second, each transaction is identified using a transaction index T i and hash T h 2 M h . Then, block B is formed including block index B i , block hash B h , previous block hash B À h , block nonce B n , timestamp B t , M r , C T , miner's public key B m , block reward B r , and block size B s . The supply amount is considered a block reward, which is a nonzero value only when the block proposer is the CB. Before broadcasting B to the network, the proposer signs it with k p and generates a signature S p . Finally, fB; S p g is broadcast to the network. If the number of pending transactions is less than n, an empty block is broadcast so that other authorities can be informed that the proposer is active, but the number of pending transactions is insufficient. Unlike the Quorum Clique implementation [32], the empty block is not stored in the blockchain to reduce memory consumption. Upon receiving fB; S p g, each authority first authenticates B by verifying S p using B m . Then, they verify each transaction in B and check the correctness of B h . If everything is valid, they store B in L and delete the common transactions between B and their mempool from the mempool. When multiple blocks having the same block index appear, the authorities apply the GHOST protocol to accept the appropriate block as described in Section 2.3.

Algorithm 5. User's Funds Auditing
Input: Blockchain L, user's public key Q and random secrets, CA's database Output: User's wallet balance 1: L k List of random secrets 2 Q stored in the CA's database 2: Define the user's wallet balance: B ¼ 0 3: for i in range(0, lenðL k Þ) do 4: Generate an output address: ¼ B58EncodeðRIPEMD160ðSHA256ðL k ½iQÞÞÞ 5: if matches any output address in L then 6: if has not been used as an input address in L then 7: B ¼ B þ the corresponding output amount 8: end if 9: end if 10: end for 11: return B

Auditing Mechanism
A CA can audit their customer's wallet balance using Algorithm 5. First, they access to their private database and collect the public key and random secrets belonging to the user under audit. Next, they generate an output address using each secret according to the given formula (17). Then, they search L for each output address and check whether it is a UTXO or has already been used. The wallet balance is the sum of all UTXO amounts the user owns.
The computational complexity of all the proposed algorithms is OðnÞ.

SECURITY MODEL
For a CBDC system, the desired security properties include privacy, authenticity, verifiability, and unforgeability. A security model for the proposed system can be defined using games involving a CBDC oracle O CBDC , Type I adversary, and Type II adversary. These adversaries are differentiated with unique capabilities as follows: Type I adversary: This adversary is a malicious user who cannot retrieve the target user's primary and auxiliary private keys but can replace the public key of any user. In addition, this type of attacker cannot access the private key of any CA. Type II adversary: This adversary is a malicious but passive CA who knows the auxiliary private keys of their clients but can neither access the clients' primary private keys nor replace their public keys. Several games [43] are played to justify the security strength of our system, which are described as follows: Game Privacy: This game is played between a Type I adversary A I and a challenger C. We define the privacy property as transaction untraceability. Thus, the ledger L reveals no identifying information about any users other than public information such as the anonymous addresses of transacting parties, public keys of CAs, transaction amounts, fees, and timestamps. In this game, A I tries to link the past transactions of a target user who has a list of transacting addresses L . During the interaction between A I and C, C notes all queries with answers.
Initialization: C defines the Secp256k1 curve parameters fE; p; q; G; Gg and downloads the blockchain L.
Query: A I sends the target user's wallet public key Q U to C. C searches for a list of random secrets L 0 k so that L 0 k and Q U can generate an address list L 0 2 L. At the end of this query, C returns the search results to A I .
Result: A I wins the game privacy if L À L 0 ¼ ;. Game Authentication: This game is also played between A I and C. Authentication is required to ensure transaction auditability. To avoid an audit, A I sends a transaction directly to the network without satisfying the travel rule so that no one can identify the transacting addresses.
Initialization: C defines the parameters fE; p; q; G; Gg. Query: A I sends a transaction T containing two CA's public keys Q X and Q Y to C. C searches for the corresponding private key of Q X or Q Y . If the private key is found, C signs T with the key, generates a signature S, and returns fT; Sg to A I . Finally, A I broadcasts the set to the network.
Result: A I wins the game authentication by avoiding the travel rule if they can broadcast a transaction with a valid signature that is verifiable using the public key of any corresponding CA.
Game Encryption: A I plays this game with C to decrypt a ciphertext transmitted from one CA to another.
Initialization: C defines the parameters fE; p; q; G; Gg.
Query: A I sends a ciphertext C and two CA's public keys Q X and Q Y to C, where the corresponding private keys k X 2 Z Ã q and k Y 2 Z Ã q are unknown. C searches for a decrypting key k X k Y G 2 G. If the decrypting key is found, C decrypts C using the key and returns the plaintext or original message M to A I after decoding.
Result: A I wins the game encryption by observing a secret message between two CAs if they can retrieve the private key of any of the CAs.
Game Unforgeability: This game is played between C and any adversaries (A I or A II ). The adversary tries to tamper with a user's transaction before the transaction is stored in a block.
Initialization: C defines the parameters fE; p; q; G; Gg. Query: A I or A II sends a target transaction T and an address new to C. C replaces an output address of T with new to reroute the recipient's money to the new address. This replacement results in a new signature message M Ã that includes everything about the transaction except the input. M Ã must be signed with the corresponding private key of the transaction input public key Q I 2 G. Therefore, C searches for a private key k i 2 Z Ã q so that Q I ¼ k i G holds. If k i is found, M Ã is signed with this private key to generate a new input signature S Ã . Finally, C returns the signing key k i and the tampered transaction T Ã containing M Ã and S Ã to the adversary.
Result: A I or A II wins the game unforgeability by tampering with a transaction if the new input signature S Ã is verified with the new transaction message M Ã and the old input public key Q I (i.e., verifyðQ I ; M Ã ; S Ã Þ ¼ True).

Definition 3:
In O CBDC , if no adversary has nonnegligible advantage to solve the ECDLP and ECDHP, then transactions in the CBDC network are privacy-preserving, auditable, nonrepudiable, and unforgeable.

SECURITY AND PRIVACY ANALYSES
Theorem 1. The proposed CBDC system is secure against Type I and Type II adversaries in O CBDC with the notion that the ECDLP and ECDHP are unbreakable.
Proof. From all the games in O CBDC , it is clear that the only way to break the security strength of the proposed system is to solve the ECDLP. The simplest algorithm for solving the problem is an exhaustive search in which one computes the sequence of points G; 2G; 3G; 4G; ::: until Q is encountered. It requires approximately q PAs in the worst case and q=2 PAs on average. The fastest algorithm known for solving the ECDLP is the parallelized version of Pollard's rho algorithm [36], whose expected running time is roughly ffiffiffiffiffi ffi pq p =ð2mÞ PAs, where m is the number of machines working in parallel. No mathematical proof exists that the ECDLP is intractable. It is theoretically possible but practically difficult to solve the ECDLP over a sizable prime field [31]. The elliptic curve parameters should be carefully chosen with a sufficiently large curve order (e.g., q ! 2 160 ) to resist these attacks so that the attacker requires an infeasible amount of computation. Boneh et al. [44] revealed that if the ECDLP cannot be solved in subexponential time, then the ECDHP is also unsolvable. On our computer (CPU: Intel Core i5-10400 @ 2.9 GHz, RAM: 64 GB), a PA takes 8 ms. From this viewpoint, even if 10000 computers with these specifications are combined to solve the ECDLP over a 256-bit F q , it will take 3Â10 34 PAs % 7.65Â10 21 years or infeasible time. t u Theorem 2. A sender cannot claim ownership of their transferred UTXO using the random secret they generate for a recipient.
Proof. Recall the transaction Tx 2 in which Alice multiplies Bob's public key Q B by a random secret k 3 to hide his identity. To spend the UTXO received from Alice, Bob must sign the spending transaction with k 3 k B 2 F q . Although both parties know k 3 and k 3 Q B 2 G, Alice does not know k B and k 3 k B 2 F q . To provide a valid signature, she must retrieve either k B from Q B or k 3 k B 2 Z Ã q from k 3 Q B 2 G, which she cannot do due to the ECDLP or ECDHP. Consequently, she cannot spend Bob's UTXO. t u Theorem 3. All participants can view and verify network transactions.
Proof. All participants (i.e., CBs, CAs, and users) can observe cash flows over the network and investigate the validity of any transactions. As presented in Fig. 6, to check the correctness of a transaction, the participants first confirm that the corresponding CAs are network-registered. Next, they confirm that the transaction input address is the destination address of any other transaction and has not already been used. Then, they determine whether the balance is sufficient. Finally, they verify the input signature using the input public key. Proof. Let Alice 2 CA 1 , Bob 2 CA 2 , Charlie 2 CA 2 , and Dave 2 CA 3 be four users in the network. Alice, Charlie, and Dave are Bob's merchants, and z ¼ f B 1 ; B 2 ; B 3 :::; B jzj g is Bob's transacting address set. We need to prove that Alice cannot learn Bob's wallet balance B B . For proof, we can classify Bob's incoming and outgoing transactions into seven categories: Alice to Bob: T AB , Charlie to Bob: T CB , Dave to Bob: T DB , Bob to Bob (change): T BB , Bob to Alice: T BA , Bob to Charlie: T BC , and Bob to Dave: T BD , where each transaction is represented as a tuple of the transacting address and amount (i.e., fðx; yÞ : x 2 z; y 2 Rþg).
A UTXO is spent only once; thus, Bob's UTXOs can be represented as follows: His wallet balance can be calculated as follows: where a fee of 2 coins is applied per outgoing transaction. From (23) and (24), it is clear that Alice cannot learn Bob's wallet balance unless Bob has no transaction other than T AB and T BA . Proof. We need to prove that CA 1 cannot learn Bob's wallet balance B B as Bob is not CA 1 's client, whereas CA 2 knows B B . For proof, we refer to (23) and (24 Proof. Double-spending means spending the same UTXO in different transactions. Suppose, a user broadcasts transactions T i and T j with a common UTXO for two recipients A and B . We can consider two cases for a block volume of n transactions per block: i < j < n: In this case, T i and T j are stored in the same block. When the transactions simultaneously request validation from an honest authority, the authority rejects both double-spending transactions. i < n j: In this case, T i and T j are stored in different blocks. However, the earlier transaction is accepted, and the later transaction is rejected.
When an honest authority observes that T j contains a UTXO previously spent in T i 2 L, the authority rejects T j . t u In cryptocurrencies, no one knows the identity of transacting parties. Therefore, these networks pose a higher doublespending possibility. In contrast, no users in the CBDC network attempt to double-spend a UTXO because their identities are known to their CAs. If anyone is accused of doublespending, their UTXOs are confiscated by the network authorities so that the funds can no longer be spent.
Theorem 7. The proposed system is resistant to man-in-the-middle (MitM) attacks.

Proof. A MitM attack occurs when an attacker stands
between two parties of a transaction. The attacker changes the transaction output address to reroute the recipient's money to the attacker's wallet. However, the proposed system is resistant to this type of attack because transactions are unforgeable in the network. t u Theorem 8. The proposed system is not vulnerable to Sybil or 51% attacks.

Proof.
Despite the improved level of security provided by blockchains, a 51% or Sybil attack poses a severe threat to a permissionless network [29]. If malicious consensus nodes from the same organization acquire more than half of the network's mining power, they can override a transaction and alter a block by adding a new branch of blocks, which would appear as the network's longest blockchain. In the proposed system, however, such an attack is impossible because validators come from distinct organizations, know each other, and are accountable for any misconduct. t u Theorem 9. The proposed system is less prone to distributed denial of service (DDoS) attacks.  Table 1 presents the overall performance of the system. The transaction size was only 665 B, and the block size for 90 transactions per block was 59 KB. The average transaction generation time, which covers preparation, encryption, and transmission, was 34 ms. The average transaction authentication and verification times were 13 and 9 ms, respectively. The average latency required to generate and validate a block was 0.84 and 1.72 s, respectively. The data rate was 510 Kbps. In the experimental environment, the system achieved a throughput of 26 TPS. Fig. 8 shows the variation in transaction confirmation time for variable transaction arrival rates. When the transaction arrival rate is equal to the transaction throughput of the system (26 TPS), transaction waiting time in the mempool is negligible. Therefore, in that scenario, the confirmation time of a transaction is almost equal to the average block time (3.4 s) of the network. When the transaction arrival rate is 50 and 100 TPS, the mempool expands by 24 and 74 TPS, respectively. As a result of large queue size, the confirmation time of a higher-indexed transaction increases substantially as it waits in the queue for a long time as per the first-in-first-out service [30]. For example, the transaction Tx 3000000 takes a day to be confirmed when the transaction arrival rate is 100 TPS, whereas it is confirmed immediately after being broadcast when the transaction arrival rate is 26 TPS.   focused only on Quorum. However, their reports do not provide sufficient experimental data [12], [15]. The primary limitation of these two RTGS systems is their insufficient transaction throughput, which cannot fulfill user demands. W€ ust et al. [20] implemented a DLT-free centralized CBDC system named Platypus. ZK proofs based on the Pedersen commitments were used to verify transactions without affecting user privacy, but these proofs resulted in a larger transaction size. However, the transaction size was reduced to 672 B by using zk-SNARKs with a trusted setup. Although their system requires less time to generate a transaction, it is three times slower than our system while verifying transactions. It should be noted that transaction verification time is more important than transaction generation time in a blockchain network; users can wait a few seconds to generate a transaction, but validators need to verify thousands of transactions within a short time. As their system is centralized, it is more prone to cyber attacks. In addition, they did not mathematically verify the regulation mechanism although it was performed on encrypted values, which can also be false. Tinn et al. [24] introduced ID-linked addresses for privacy-preserving CBDC transactions. In their approach, the recipient of a transaction cannot know the sender unless they communicate with each other after making the transaction. In our system, the receiving CA of a transaction stores the sender's identity in a private database during authentication. By logging onto the CA's website, the recipient can easily determine who sent the transaction.

Performance Comparison
The Clique consensus algorithm is faster than IBFT. Although Raft provides fast consensus, Raft followers blindly trust their leader. As it is a voting-based algorithm, it requires extra latency to elect each term leader. Furthermore, in the Quorum Raft network, an on-chain block can be rewritten by modifying transaction inputs and recalculating the block hash. As a result, other means of data protection are required to ensure the blockchain data integrity. Overall, our system provides the smallest transaction size and lowest verification time, independent of a consensus algorithm. In any consensus process, a smaller transaction helps avoid network overhead, and a lower verification time increases the transaction processing speed and throughput. None of the other systems satisfy the travel rule of payment. In contrast, the proposed system satisfies this rule as the corresponding CAs of a transaction observe the sender and recipient while authenticating the transaction.

LIMITATION AND SCOPE
One limitation of the proposed system is its lower throughput (26 TPS) compared with traditional centralized payment systems like Visa, which achieves a throughput of 1700 TPS. This limitation is a challenge for any CBDC system that uses DLT. As most CBDC systems are built on the blockchain technology in which transactions are stored in a distributed ledger through a consensus-based decision-making process, they require more time to confirm transactions than a conventional payment system that stores transactions in a  centralized database without using any consensus algorithm. However, transaction speed must be compromised to avail of the advantages of DLT. The current average throughput of the Bitcoin and Ethereum cryptocurrencies is 3 and 13 TPS, respectively. Digital currency systems are not comparable with fiat currency systems. Furthermore, the experiment in this study was conducted using virtual machines working with a single-core processor and 8 GB RAM only. If faster processors and higher memory were utilized, a higher throughput would be achieved. In addition, transaction speed can be boosted by employing high-speed hardware technology such as application specific integrated circuit or field programmable gate array for digital signature verification. A hardware implementation is faster than a software implementation [38]; our system was implemented on a software platform. Nevertheless, even if a blockchain-based CBDC system cannot meet the demands of all citizens, its applications can be limited to public sectors only in order to monitor cash flows and reduce corruption in a country. The money supply policy is left to the choice of the CB. This study provides technical solutions for CBDC payments without considering economic policies that differ across countries. The CB will decide the supply amount based on the government's economic policy. The proposed CBDC system only supports domestic transactions. As part of future work, we plan to establish a bridge between two CBDC systems for enabling cross-border payments (crosschain interoperability).

CONCLUSION
A UTXO-based CBDC system with its full-scale implementation, which provides privacy-preserving, auditable, and transparent digital currency payments in a consortium blockchain network, was proposed in this paper. To protect privacy in the conventional UTXO model, the recipient must provide the sender with a new public key each time they receive a payment. This requirement poses an issue when the recipient is any public service provider who prefers a static public key for receiving mass transactions simultaneously without revealing the wallet balance. Managing a large number of private-public key pairs is also difficult and risky. The proposed UTXO model addresses these concerns by enabling users to receive transactions using a fixed public key while preventing others from learning their wallet balances. Therefore, this model is more convenient than the conventional UTXO model. Furthermore, when each user holds only a single authorized wallet address, ensuring regulatory compliance in a CBDC network becomes easier. Compared with the existing CBDC and RTGS systems, our system provides additional functional features and a better balance between transaction size and speed. We believe that worldwide CBs will find this study useful for their ongoing CBDC pilot projects.