A Low-Cost Cross-Border Payment System Based on Auditable Cryptocurrency With Consortium Blockchain: Joint Digital Currency

Due to the involvement of a large number of intermediaries across different time zones in the correspondent banking process, existing interbank payment systems cannot provide cost-effective cross-border transactions. They also suffer from lack of transparency and long transaction delays. These issues can be solved by designing a cryptocurrency in an auditable manner using a permissioned blockchain where a group of authorities can govern the network. In this article, we propose a low-cost, seamless cross-border payment system based on an auditable cryptocurrency that enables unspent transaction output-based transactions in a consortium blockchain network. To manage the blockchain, participating countries execute the energy-efficient proof of authority consensus algorithm with equal rights. Unlike conventional cryptocurrencies, dynamic decentralized identifiers (DIDs) are used as transacting addresses so that self-manageable authentication can be performed on-chain without any interaction with a trusted third party. The identity of transacting parties is known to respective DID issuers only. This approach enables peer-to-peer transactions while protecting user privacy and ensuring transparency without jeopardizing auditability. For user convenience, multi-party computation and multi-signature protocols are also provided. The system was implemented in Python, and the transaction mechanism was tested. This paper can help with ongoing research on blockchain-based cross-border payment solutions worldwide.


INTRODUCTION
C RYPTOCURRENCY has become a buzzword worldwide due to its swift emergence and popularity. It is a digital currency based on blockchain distributed ledger technology (DLT) [1]. There are numerous cryptocurrencies in use today, where the majority of them are fully decentralized and non-auditable. Anyone can connect to the networks and conduct anonymous transactions without having to comply with any regulations. Absence of auditing enables bad actors to engage in criminal activities such as money laundering, transferring illegitimate assets, smuggling, and terrorism. Because their identities are concealed in the network, they can continue their illegal activities [2], [3]. As a result, governments are getting concerned about the evolution of these virtual currencies since citizens cannot be stopped from utilizing them in illegal ways. Some countries such as Algeria, Egypt, Morocco, Bolivia, Ecuador, Bangladesh, Pakistan, and Nepal have already prohibited their citizens from using Bitcoin. According to Wikipedia, Bitcoin is illegal to trade in the banking sectors of several countries, including China, Taiwan, Russia, Canada, Colombia, Cambodia, Saudi Arabia, Iran, and Jordan. These prohibitions, on the other hand, deprive citizens of their legal rights to use the digital currency. A cryptocurrency's utility is not limited to illegal activities; rather, it paves the way for seamless (24/7) cross-border payments with minimal resources. Therefore, an auditable cryptocurrency system that could lead to digital currency legalization by proper monitoring of cash flows is urgently needed.
Blockchain is an immutable shared ledger that keeps a record of transactions in a tamper-proof and append-only manner. In this emerging technology, verifiable transaction data across a distributed network are stored in synchronized chronological blocks that are cryptographically connected to each other [4]. The data can never be modified or altered once they have been stored because changing data in any block renders the entire blockchain to become incorrect, and such efforts are rejected by active nodes in the network. The two major types of blockchains are permissionless blockchains and permissioned blockchains [5]. In a permissionless or public blockchain, anyone can become a miner (validator) and perform transactions. In contrast, a permissioned blockchain allows a limited number of nodes to participate in consensus and only registered users to conduct transactions. The concept of a blockchain originated with Bitcoin, which is a decentralized cryptocurrency network introduced in 2008 by Satoshi Nakamoto (pseudonym) and launched in 2009 [6]. The mechanism behind Bitcoin is referred to as unspent transaction output (UTXO) [1] in which there is no principle of a closing balance, and each transaction is considered a token. The transfer of a UTXO from one party to another is accomplished by transferring its ownership instead of reconciling two databases. UTXO models have several advantages over the traditional account models, including the fact that UTXO-based transactions are highly secure and that multiple transactions from the same payer can be processed in parallel.
Because blockchains operate on large-scale distributed networks, assessing their performance and security is critical [7], [8]. The use of different consensus algorithms impacts the system's overall performance (i.e., security and throughput) [5], [9]. Consensus algorithms are protocols that allow humans or machines to work together in a decentralized environment. Even if some entities fail individually, all entities in the system collectively agree on one item (single source of truth) [10]. The algorithms are designed to ensure that the system remains fault-tolerant even in the presence of some faulty nodes. A well-established consensus algorithm is proof of work (PoW), which is mostly used in permissionless blockchain networks to prevent 51% or Sybil attacks and double-spending [11], [12]. If a single entity controls half of the computational power in the system, they can control the consensus and override a transaction. PoW combats this threat at the cost of high computing power. This algorithm consumes a significant amount of energy, which adds to CO 2 emissions and global warming. If it is replaced with proof of stake to conserve energy, the rich will grow richer and the poor will become poorer. Unlike permissionless blockchains, permissioned blockchains do not require energy-intensive consensus algorithms to maintain network safety [9]. Blocks are certified by a prioritized group of authorities, allowing any wrongdoing to be identified and malicious nodes to be voted out [5]. Transactions can be observed by all participants or only a subset of them, depending on the level of privacy desired. The most popular algorithms for consortium blockchains, a category of permissioned blockchains, are proof of authority (PoA), practical Byzantine fault tolerance (PBFT), Istanbul BFT (IBFT), and Raft [13], [14]. While PBFT and IBFT can tolerate up to N=3 faulty nodes in a network comprising N consensus nodes with a computational complexity of Oðn 2 Þ, the fault tolerance degree and computational complexity of both Raft and PoA are N=2 À 1 and OðnÞ, respectively. The higher complexity of PBFT-like protocols results in higher latency than Raft and PoA. Although Raft provides higher throughput than PoA, Raft followers blindly trust their leader. The Raft leader is assumed to always act correctly (honestly) while the correctness of a block proposed by the PoA leader is checked by each authority. In some platforms, Raft requires other means of data integrity assurance because blocks are not protected by either unique hashes or signatures.
An auditable cryptocurrency built on a consortium blockchain would not only enable cross-border payment, but it would also save energy and preserve the environment's purity. A consortium blockchain eliminates the possibility of double-spending since miners must be authorized and users must be registered in the network. Transactions are significantly faster because the number of nodes participating in the consensus process is limited [15]. However, it is technically difficult to ensure privacy and transparency in an auditable cryptocurrency. If the transaction ledger is transparent and verifiable to participants, user privacy is jeopardized. Keeping the ledger confidential, on the other hand, provides privacy and auditability but fails to provide transparency. In a Bitcoin-like UTXO model, privacy is achieved by conducting anonymous transactions using crypto addresses rather than the real-world identity of transecting parties [1]. This type of anonymity, however, is compromised when a user reveals the real-world identity of their pseudonym to a merchant while sending or receiving a transaction. The merchant is able to track past transactions associated with the pseudonym and discover the user's current balance. This issue is solved by applying a dynamicaddress technique in which the wallet address is changed after each transaction to reduce transaction traceability [16]. To maintain anonymity, users keep multiple wallet addresses and use each one only once to receive a transaction or refund. Even if this solution is used, user authentication will still be a problem. Authentication in a centralized system is accomplished by communicating with an authentication server. However, a decentralized platform does not employ such a server since the network is controlled by numerous peers and there is no single point of failure. Furthermore, an authentication server affects the system's resiliency and increase transaction latency. To enable serverless authentication, decentralized identifiers (DIDs) [17], [18] can be used in place of conventional wallet addresses. Dynamic DIDs, in which each DID is used only once to receive a transaction, can be used to disable transaction traceability, ensuring that no one other than the DID issuer can learn about user balance unless the user uses a static DID for every transaction.
A major drawback of cryptocurrencies is that they pose high key management risks. Unlike conventional banking systems, there is no password (key) recovery option. If a user loses their private keys, they cannot spend their inbound transactions belonging to the keys, and the funds will be forever orphaned in the network [3]. This can bankrupt a wealthy cryptocurrency user in a matter of seconds, with no chance of recovery because a private key cannot be retrieved from its public key. This concern, however, can be alleviated by implementing a refunding protocol. A miner can add the lost private keys' corresponding addresses to a blacklist and refund the equivalent amounts to the victim's new DIDs. With the agreement of the network's other miners, the miner can be paid the refunding amounts through excess block rewards. As a result, the blacklisted DIDs can no longer be used, but no one loses anything. Since an auditable cryptocurrency is governed by a group of known authorities, such a protocol can be implemented in this system. In contrast, a non-auditable cryptocurrency cannot provide the fund recovery service because the network is fully decentralized and the consensus nodes are unidentified.
The primary goals of this research study are fourfold: 1) To legalize digital currency from a global perspective and provide low-cost cross-border payment by enabling regulatory compliance in cryptocurrency transfer while maintaining privacy, transparency, and resiliency. 2) To reduce energy consumption in cryptocurrency mining and preserve the environment's purity by using a lightweight consensus algorithm. 3) To mitigate financial risks and uncertainty in cryptocurrency by enabling a refunding protocol. 4) To strike a balance between transaction size and speed by designing an efficient transaction model.

Related Work
Most cryptocurrency-related papers did not focus on auditability and cross-border payment. Only a few papers regarding auditable cryptocurrency were documented. A conditional anonymous payment system based on blockchain was proposed in [19], where a central certificate authority (CA) provides certificates to users. Transactions are conducted using smart contracts in a private Ethereum chain. The existing ether cryptocurrency is used as a payment method. Several managers are in charge of monitoring network transactions. Although Ethereum smart contracts do not provide user privacy, the system achieves privacy through a dynamic-address approach. However, dynamic addresses are enabled at the expense of resiliency. Because each transaction requires direct interaction with the CA, there is a server bottleneck and a single point of failure to consider. Furthermore, account models are less secure than UTXO models and cannot support parallel transaction processing. In [20], the authors introduced an auditable decentralized confidential payment system that utilizes noninteractive zero-knowledge (ZK) proofs [21]. Compared with other existing ZK proofs, their ZK proofs are lightweight, which would solve the scalability and low throughput issues. However, no details about the blockchain and consensus algorithm used in their system were reported. The problem with ZK proofs in enabling auditability is that transacting amounts are encrypted, making it impossible to observe money flows over the network. A regulatory authority can only be certain that the amounts do not exceed the maximum limit while the exact values are not shown. As a result, users' total funds cannot be audited unless they provide the authority with their private keys. Although users can present their total funds using ZK proofs, this is not reliable because dishonest users are able to avoid audit. The authors in [22] proposed a fully-auditable, privacy-preserving, UTXO-based cryptocurrency, adopting ring signatures and long-term traceable addresses. They also skipped the details of their blockchain implementation. Although the ring signature-based UTXO model provides guaranteed privacy, it causes scalability and low throughput issues because of heavyweight transactions and higher computational complexity. In [23], a privacy-preserving token management system was proposed, with a prototype implementation built on top of Hyperledger Fabric. To enable auditability, information about a transaction (i.e., sender, receiver, and values) is encrypted using the public keys of the auditors of the sender and receiver. This is problematic because the receiver cannot decrypt the transaction without their auditor's private key. They must rely on their auditor to learn about their inbound transactions. To transfer a token, a user must first contact the certifier, who will determine whether the transaction, which includes the token, is valid. The certifier must sign the token for it to be transferable. This approach introduces a single point of failure and affects resiliency. To audit a particular user, an auditor tries to decrypt every transaction in the ledger using their private key and the user's public key, which is a time-consuming process and infeasible solution. Overall, the system poses a higher computational complexity and lacks transparency and resiliency. In [24], the authors proposed an intelligent cross-border transaction system based on consortium blockchain with smart contracts. Numerical experiments were carried out using Shenzhen and Hong Kong transactions. They did not, however, clarify the transaction verification scheme and took no steps to ensure privacy and transparency. A compact-sized anonymous and auditable distributed payment system was reported in [25]. N number of banks transact with one another via MiniLedger, a common mutable transaction ledger, modeled as a two-dimensional table with N columns. Participating banks compute a verifiable, compact representation of their transaction history in order to reduce storage costs and broadcast the resulting digest to the consensus layer. Once consensus nodes confirm that the digest is a valid representation of the bank's transaction history, that history is erased from the ledger by all system participants except the pruning bank itself. Although this method significantly reduces memory consumption while maintaining data integrity and privacy, it cannot guarantee transparency. This is because a hash value is insufficient to noninteractively verify a transaction while the original transaction data is deleted.
From this discussion, it is clear that most of the works do not provide auditability, privacy, transparency, and resiliency at once. They compromise one or more of these properties. In addition, they did not consider cross-border payment from a global perspective.

Our Contributions
The contributions of this paper are summarized as follows: This paper proposes a cross-border payment system based on a UTXO model that enables regulatory compliance in cryptocurrency transfer. The system allows registered users to perform domestic and international transactions on the same ledger while government agencies can audit users' digital assets without affecting their privacy.
The system is built on a customized consortium blockchain, which offers governments from all over the world to administer the network with equal rights to supply money through block rewards and make revenue from transaction fees. The PoA consensus algorithm is used to enable low-latency transactions, with minimal computational resources and energy consumption. To enable serverless, privacy-preserving authentication, one-time DIDs are used that provide self-sovereign identity in the consortium network, disabling traceability. As a result, P2P transactions can be conducted without jeopardizing privacy, resiliency, transparency, or regulatory compliance. To obtain a higher transaction throughput without compromising security, the Edwards25519 curve is used instead of the traditional secp256k1 curve. A multi-party computation (MPC) protocol is provided so that a group of users can have a shared transaction and spend it with their unanimous consent. A multi-signature (Multisig) protocol is supported for those users who want to increase security by signing a transaction with multiple private keys. Unlike conventional cryptocurrencies, the system supports a refunding protocol to recover financial losses that may occur because of losing private keys. If a user loses their private keys, an authority marks the corresponding DIDs into a blacklist and refunds the lost amounts to the user's new DIDs. The authority is paid the refunding amounts through excess block rewards with the other authorities' consent. A prototype of the system was implemented in Python. It was found that the system outperforms existing auditable cryptocurrency designs, striking a balance between transaction size and speed. The remainder of this paper is organized as follows: The background of this research study is elaborated in Section 2. The proposed system and algorithms are described in Section 3. The security and privacy of the system are analyzed in Section 4. Implementation results and performance analyses are presented in Section 5. Limitations and scopes of this work are mentioned in Section 6. Finally, the paper is concluded in Section 7.

Consortium Blockchain
A federated or consortium blockchain is a semi-public blockchain that combines public and private blockchain functionsabilities [15]. It is also a permissioned blockchain, which is controlled and regulated by a group of trusted validators. Each validator in the network represents a specific organization or authority. Because of the following advantages, a consortium blockchain is the best option for enterprise environments [26]: Low Energy Consumption: The energy-intensive PoW algorithm is avoided because a limited number of identified nodes participate in consensus. Lightweight and energy-efficient consensus algorithms are utilized. High-Speed Consensus: Due to the small number of validators, a consensus is obtained rapidly and with minimal effort.
High Throughput: The number of transactions processed per second grows with a speedier consensus algorithm.
No Risk of 51% Attack: This is the most appealing characteristic of consortium blockchains. Although blockchains provide a higher level of security, a 51% or Sybil attack is a serious threat to a permissionless platform [11], [12]. In contrast, a 51% attack is impossible in a consortium blockchain because the miners are from diverse organizations who must be authorized in the network. No Criminal Activity: A miner cannot be anonymous, making it difficult to engage in a malevolent activity. When everyone in the network is acquainted with one another, the likelihood of illicit activity is much reduced. Regulation: In a consortium blockchain, all nodes must follow the network's rules and regulations.

Proof of Authority
PoA is a reputation-based consensus algorithm that makes private and consortium blockchains more efficient. It does not feature the longest chain or the confirmation rule, unlike PoW. With the unanimous consent of a limited number of trusted validators, new blocks are instantly added to the blockchain. Complex mathematical puzzle solving is not a race of the validators. As a result, only a little amount of computation power is required to reach consensus. PoA is reliant on a group of N trusted nodes referred to as authorities, each of which is recognized by a unique ID or public key [14]. To achieve network transparency, a majority (at least N=2 þ 1) of authorities must be honest. Therefore, all authorities actively monitor each other's behavior. A round-robin schedule is used to propose blocks containing valid transactions, with each authority being assigned block creation responsibilities in turn.
PoA has two different schemes, called Aura and Clique, which were originally proposed as part of the Ethereum blockchain for private networks [12]. Although both schemes have their own set of advantages and disadvantages [13], we choose the Aura scheme for our system to avoid forks and achieve greater consistency and security in the consortium network. Fig. 1 illustrates the Aura scheme's message patterns. The current leader's block proposal is covered in the first round, and the non-leader authorities accept the block in the second round. After the majority of authorities have approved the block, it is stored in the blockchain. If the current leader broadcasts a malicious block, the block is rejected, and the leader is voted out by the network's honest majority.

Decentralized Identifier
Decentralized identifiers (DIDs) are a new type of cryptographic identifier that allows for decentralized digital identity verification. They are designed to be independent of centralized registries, identity providers, and certificate authorities, unlike traditional federated identities. As a result, they can be used as self-managed means of authenticating. They are essential for access control in blockchains and other P2P networks. The World Wide Web Consortium (W3C) is currently standardizing DIDs [17]. However, the W3C standards do not specify a fixed protocol for DIDs; instead, this is left as an open implementation choice [18]. A DID can represent any subject (e.g., a person, organization, document, or data model) that the DID controller defines. A DID in our system represents the pseudonymous identity of a transacting party while its validity begins from the moment when a centralized registry referred to as the DID issuer signs it. The DID holder must prove the authenticity of their DID in a transaction by providing its issuer's signature and public key while the issuer also must be registered by any authority of the consortium network.

Hash Functions
Cryptographic hash functions play an important role in a cryptocurrency system. A hash function is a collision-resistant, one-way function used to map data of arbitrary length to an irreversible string of fixed size. Several hash functions that are frequently used in cryptocurrency systems include SHA256, SHA512, Ethash, SCrypt, Equilhash, Keccak256, Keccak512, blake256, and RIPEMD160 [27]. In our system, we use the SHA256 and RIPEMD160 hash functions to create DIDs. SHA512 is used for digital signature generation and verification. Algorithm 1. EdDSA Signature Generation [29] Input: Private key k, message M Output: Signature S 1: Compute the private key digest: h ¼ SH A512ðkÞ 2: Extraxt the suffix of h: a ¼ h½0 : 32 3: Extract the prefix of h: b ¼ h½32 : 64 4: Compute g ¼ SH A512ðbjjMÞ 5: Convert a and g to integers in little-endian form 6: Generate the public key: Q x;y ¼ aG 7: Encode Q x;y : Q ¼ encodeðQ x;y Þ 8: Generate the 1st part of signature: r x;y ¼ gG 9: Encode r x;y : r ¼ encodeðr x;y Þ 10: Compute h 0 ¼ SHA512ðrjjQjjMÞ 11: Convert h 0 to an integer in little-endian form 12: Generate the 2nd part of signature: s ¼ ðg þ h 0 aÞ mod n 13: Make the signature: S ¼ r þ bytesðsÞ 14: return S

Elliptic Curve Cryptography
Elliptic curve cryptography [28] with Edwards25519 is used to generate DIDs while the Edwards curve digital signature algorithm (EdDSA) [29] is adopted to authenticate them. Edwards25519 is a twisted Edwards curve that offers lowlatency group operations while being highly resistant to side-channel attacks [30]. On the Edwards25519 curve, elliptic curve point multiplication (ECPM) is much faster and more secure than on the traditional secp256k1 curve [31]. As a result, cryptographers are more inclined to use Edwards curves for a high-speed, high-security digital signature generation [32].
Edwards25519 over a prime field F p is provided by the equation [30]: (1) A wallet public key Q is a point on E d , which is obtained through ECPM. The underlying principle of ECPM is multiplying a base or generator point G 2 E d =F p with a scalar or wallet private key k 2 F p such that Q ¼ kG. A DID is considered a 34-character alphanumeric string that is generated by converting an uncompressed arbitrary public key (i.e., ''04 00 jjQ x jjQ y ) into a hash value using the SHA256 and RIPEMD160 hash functions, consecutively. The hash value is then encoded using the Base58Check encoding scheme, 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).
The EdDSA signature generation and verification mechanisms are shown in Algorithms 1 and 2, respectively [29]. The signature generation scheme accepts a private key k and a message M as the input and outputs a signature S. The signature verification scheme verifies S associated with M using the corresponding public key Q of k:

Unspent Transaction Output
In cryptocurrency, a transaction refers to the transfer of money or coin in the form of a digital value, which is broadcast to the entire network and stored in a block after being validated by the network miners. A UTXO is the amount of digital currency that is transferred to a crypto address or that remains after a transaction is executed. To spend some amount from a UTXO, the sender must refer to a previous transaction (considered the input) in which they received the UTXO and prove their ownership of it. If the input amount exceeds the transacting amount, the excess amount is refunded to a new address of the sender, which is considered a change. By dividing the input amount into multiple output amounts, multiple recipients can be included in the same transaction. When a transaction takes place, outputs are created as new UTXOs that can then be spent in future transactions. An inbound transaction exists as a UTXO until it is used as an input in a subsequent transaction. Fig. 2 depicts a conventional UTXO model with the dynamic-address approach in which users change their addresses after each transaction. Let us consider three users, such as Alice, Bob, and Charlie, whose dynamic private-public key pairs are fðk 0 Alice has a UTXO of 10 coins from which she transfers 7 coins to Bob and receives 3 coins as a refund. While conducting the transaction Tx 1 , Alice must prove that she owns that UTXO. To prove her ownership of the input, she must provide the UTXO public key Q 0 A and a signature that is generated by signing Tx 1 with her private key k 0 A . If the signature is verified with Q 0 A , her ownership claim is true as she knows the corresponding private key of the UTXO address. Similarly, Bob transfers 5 coins to Charlie from the UTXO received from Alice and gets a refund of 2 coins. Both transactions are recorded on a blockchain that is visible to all participants of the network. Although this model provides transparency, it does not support non-interactive authentication, which is a crucial requirement for an auditable cryptocurrency. Fig. 3 illustrates an overview of the proposed cross-border payment system, in which participants are connected to a consortium blockchain network. The functional roles of individual entities, transaction process, and proposed algorithms for transaction and block management are described in this section.

SYSTEM DESIGN AND PAYMENT MECHANISM
Functional Roles: Federation: This entity registers individual countries that are interested to participate in consensus and operates a website displaying a copy of the blockchain. Authorities: These entities represent registered country coordinators who participate in consensus to supply joint digital currency (JDC) by creating blocks. They validate broadcast transactions and record them on the blockchain using high-performance computers. DID Issuers: These entities act as CAs or know-yourcustomer (KYC) agents who must be registered by any authorities of the network. They provide authorized DIDs to their customers (JDC users). Users: These entities conduct anonymous transactions using digital wallets with authorized dynamic DIDs while their identity is known to their DID issuers only. Transaction Process: 1) Bob (recipient) creates a one-time DID and sends it to their DID issuer ðQ I Þ. He receives the issuer's signature S I when the issuer signs the DID with their private key. 2) Bob delivers the DID parameters fDID; Q I ; S I g to his payer Alice (sender). 3) Alice prepares a transaction for Bob on her digital wallet using Algorithm 3. The transaction mechanism is described in Section 3.1. She broadcasts the transaction to the consortium network. 4) Upon receiving the transaction, the current leader of PoA validates it and proposes a block including confirmed transactions using Algorithms 4 and 5. The block is validated using Algorithm 6 and added to the blockchain through a consensus process as explained in Section 3.2. 5) Bob receives his transaction by looking up his DID on the federation's website that displays a copy of the blockchain. Fig. 4 depicts the proposed UTXO model for cross-border payment, which integrates DIDs for enabling regulatory compliance without compromising privacy and transparency. Each user holds numerous one-time DIDs to receive transactions.

Transaction Layer
Let issuer X ðk X ; Q X Þ from Korea and issuer Y ðk Y ; Q Y Þ from Bangladesh be the CAs of Alice and Bob, respectively. To receive payment from Alice, Bob creates a DID as follows: Then, he collects a signature S Y on 0 B from his DID issuer Q Y , where Q Y is the public key of issuer Y. He delivers 0 B , Q Y , and S Y to Alice, where 0 B will be defined as the destination address and ðQ Y ; S Y Þ will be included for validators to authenticate 0 B without the issuer Y's interaction. Upon receiving the DID parameters from Bob and collecting her own DID parameters f 00 A ; Q X ; S X g from issuer X, Alice prepares Tx 1 using Algorithm 3.  As shown, multiple UTXOs (inputs) can be included in a single transaction to make the fund sufficient, where the sum of all UTXO amounts is the transaction balance B. In this system, a UTXO can be an incoming transaction or block reward that is not already spent. To prepare a transaction, a fee F is first estimated based on the number of inputs that affects the transaction size. The amount of the refund or change C is calculated by subtracting the sum of the transacting amount T A and F from B. Then, transaction outputs are listed as O, with each output containing a DID (destination address), the issuer's public key, the issuer's signature, and the amount. The output positions are shuffled so that no observer can distinguish between sender and recipient. However, if the issuers are different, this shuffle does not prevent an observer from distinguishing the transacting parties by tracking a transaction input. Therefore, after receiving an international transaction, one is recommended to enhance their anonymity by transferring their received UTXOs to their new DIDs. In that case, no one can conclude whether the outputs belong to the same party or different parties, e.g., the case that Charlie is replaced by Bob in Tx 2 . Note that distinguishing the transacting parties does not enable an observer to identify them. The shuffling operation is only used to reduce traceability and increase anonymity. Even if it is removed, the user's identity still remains private. After randomizing the outputs, a message M is computed by hashing an O, F , and the current timestamp t concatenation. M is signed separately with the corresponding private key(s) of the input public key(s). An input public key confirms the correctness of the corresponding DID, and a signature proves that the sender owns the public key because they know its private key. A signature also ensures the output data integrity to prevent a man-in-the-middle (MitM) attack. After generating the input signature(s), a list of inputs I is set, where each input contains a DID, UTXO amount, public key, and signature. Finally, a transaction is formulated including O, F , t, and I.
When the transaction is ready, Alice broadcasts it to the consortium network for validation and confirmation.

MPC Protocol
Let Alice, Bob, and Charlie intend to make a combined DID ABC to receive a shared transaction, for which Alice is the corresponding owner. To create the DID, they first mix their public keys Q A , Q B , and Q C , which produces a new public key Q ABC . Then, they compute the desired DID as follows: Alice collects a signature S X on ABC from her DID issuer (Q X ) since she is the corresponding owner. If they receive a transaction with the DID parameters f ABC ; S X ; Q X g, any of them can spend the UTXO by providing their public keys and corresponding signatures that prove all parties' consent. To verify the unanimous consent, a verifier first checks whether the point addition of the parties' public keys can generate ABC . Then, they verify each input signature using its corresponding public key.
To reduce the transaction size, only a combined signature can be provided during spending a shared transaction rather than individual public keys and signatures. However, it does not ensure that all parties consent. This also brings up an issue of privacy management when generating a combined signature. Participants need a trusted setup to mix their private keys to compute a combined signature without compromising privacy.

Multisig Protocol
A Multisig allows a transaction to be signed with multiple private keys. It is required to increase the security so that leakage of any private key cannot withdraw funds. Recall the MPC protocol and replace Bob's and Charlie's public keys with Alice's public keys. However, Alice does not require to provide all individual public keys and the corresponding signatures during spending a transaction in this case. To spend a transaction, Alice combines her private keys and signs the transaction with the combined private key resulting in a Multisig. She includes the Multisig and the corresponding public key of the combined private key as the transaction input. As a result, no one can spend Alice's UTXO unless they have all of her private keys required to generate a valid Multisig. if Issuers' signatures on the output DIDs are valid then 5: if All input signatures are valid then 6: if All UTXOs exist in the blockchain then 7: if

Consensus Layer
The authorities reach a PoA consensus to record incoming transactions on the blockchain. They are assumed to be synchronized within one epoch period t e , where an epoch is defined as the generation of the first or genesis block. If N is the number of authorities in the network and d is the duration of each step, the step index t is determined by t ¼ t e =d, and the current leader is designated as A i where i ¼ t mod N. The length of each step is determined by N, the average computing power or processing speed of the authorities, and the block volume. If t v is the average transaction verification time and n is the number of transactions per block (TPB), d is proportional to Nnt v . The value of d is chosen such that the authorities do not fail to complete the tasks of transaction validation, block generation, and acceptance reception within this time interval because of slow speed or poor network connectivity. Therefore, the authorities should be granted minimum processor configuration and network connectivity criteria. Each authority has two local queues: one for pending transactions (q T ) and another for pending blocks (q B ).
Upon receiving a broadcast transaction, individual authorities store it in q T . The current step leader validates the transaction using Algorithm 4. First, they confirm that the input balance is sufficient. Second, they check whether the DID issuers are registered CAs in the network. Third, the recipients are authenticated by verifying the issuers' signatures using the issuers' public keys provided at the transaction outputs. This confirms that the recipients are network registered users with authorized DIDs. Fourth, the correctness of each input signature is checked using the input public key. This proves sender's ownership of the UTXO by confirming that the sender knows the private key used to generate the input DID. Fifth, the leader determines whether the UTXO is an output of a transaction in the blockchain or not. This validates the UTXO by ensuring its existence in the blockchain. Finally, the leader confirms that the UTXO was not spent previously as the input of any transactions in the blockchain. This prevents double-spending of a UTXO by a criminal. If the UTXO is not double-spent, the UTXO is considered as valid input. After validating all inputs, the transaction is added to a list of confirmed transactions that are waiting to be stored in a block. The leader generates a block containing confirmed transactions from q T and sends it to the non-leader authorities. If no transaction is available at that time, an empty block is sent. After receiving fB; S M g from the step leader, each nonleader authority first verifies S M and then validates each and every transaction in B as shown in Algorithm 6. If S M and all transactions are valid, they store B in q B and send the acceptance feedback in terms of their signature on the block to all other authorities. As soon as the block receives N=2 þ 1 valid signatures, it moves from q B to the blockchain, and the common transactions between the block and q T are removed from q T .

Algorithm 5. Block Generation
The blockchains stored by individual authorities must be identical. However, if an authority is offline for some moments or misses some blocks because of poor internet connection or faces cyber-attacks, their blockchain mismatches the other blockchains in the network. In that case, they synchronize their blockchain with that of other authorities using Algorithm 7 when they rejoin the network.

Latency Analyses
To analyze the system's performance, the number of transactions per seconds (TPS) that the system can process is measured. The TPS depends on the block time B t that is the latency required to process a block. As illustrated in Fig. 5, B t is the sum of the block preparation, proposal, authentication, validation, and acceptance time. If T s and h are the transaction size and average data rate over the network (bytes/s), respectively, B t is estimated as follows: where nT s =h is the block broadcasting time; t v is the sum of the signatures verification time and some extra time required to check other parameters (i.e., double-spending and the balance sufficiency); and t d is an offset delay results from the asynchronous validation and acceptance of the block by N authorities, such that t d / N. The block authentication time, which is required to verify the miner's signature, is considered a transaction verification time. If all authorities receive the block simultaneously and take the same amount of time to validate the block and share their acceptance, t d tends to 0. However, in practice, this does not occur because not all consensus nodes have the same computing power and network connectivity. Therefore, t d is added as an inequality factor that defines the performance variation of individual authorities in terms of time. If N is even, the value of t d for N þ 1 authorities is smaller than that for N authorities because receiving N=2 signatures from N þ 1 nodes is quicker than that from N nodes. For simplicity, the block preparation time is assumed to be the same as the verification time for n transactions. If n !10, the block hash computation time is negligible compared to nt v . if L ½i has not been used as an input DID in the blockchain then 6: The TPS is obtained using the following equation: where d must be greater than B t so that no step leaders fail to add blocks because of their poor performance. A step leader cannot propose a block before their turns even if the previous block is already added to the blockchain. As a result, there is a wait time t w at each step that acts as a safe guard for slower authorities.

Funds Auditing and Blockchain Verification
A DID issuer can audit their customer's funds using Algorithm 8. First, the issuer checks whether individual DIDs of the user exist at outputs of any transactions in the blockchain. If a DID matches any output DID in the blockchain, it is considered a UTXO of the user. Then, they confirm that the UTXO has not been spent as an input of any transactions in the blockchain. The user's wallet balance is a total sum of their individual UTXO amounts. An interested verifier can investigate the existence of a transaction in a particular block using Algorithm 9. If the transaction hash and other Merkle hashes can produce the block Merkle root, the transaction is considered to be part of the block. Algorithm 10 describes a mechanism for ensuring the data integrity of a specific block. The block transactions, block hash of the previous block, and previous block hash of the next block are used to validate the current block hash. An attempt to alter a value or data in any block is prevented using the block transactions without comparing the data to a backup file, which ensures the [1] blockchain's immutability.
T ½0 ¼ intðT ½0=2Þ. 6: else 7: h ¼ SHA256ðM h ½i½T ½0 À 1 þ hÞ 8: Retrieving k from Q by performing inverse point multiplication is known as the elliptic curve discrete logarithm problem (ECDLP) [28]. It is theoretically possible but practically difficult to solve the ECDLP over a large prime field. For example, ECDLPs over 109-and 113-bit F p took 549 and 1045 days to solve by combining 10000 workstations on the Internet [28], [33]. Therefore, solving an ECDLP over 256-bit F p is nearly impossible.

Lemma 2. No user is assumed to be a double-spender.
Double-spending means using a UTXO more than once. In the Bitcoin network, no one knows the identity of transacting parties. As a result, the network poses higher possibility of double-spending. In contrast, no participant in the consortium network attempts to double-spend a UTXO because it is possible to identify a double-spender with the help of their CA. Although double-spending is strictly prohibited, there is a chance that a UTXO can be double-spent if someone simultaneously broadcasts two transactions with a common input but different outputs. In this case, individual authorities reject both the transactions and blacklist the input DID so that the criminal can no longer spend the UTXO. They also report the DID to the federation. The federation communicates with the corresponding DID issuer in order to impose penalties. Recall Tx 1 in which Alice 2 issuer X transacted 7 JDC to Bob 2 issuer Y. As the transaction is public, issuer Y can observe Alice's fund (2.95 JDC) regarding the DID 00 A . However, they cannot trace Alice's prior transactions because they do not know her DIDs other than 0 A and 00 A . Since the balance is a total sum of a user's individual UTXO amounts, issuer Y cannot learn Alice's balance unless she has no available UTXO in her wallet except 2.95 JDC. Recall the proposed MPC protocol in which Alice, Bob, and Charlie mixed their public keys Q A , Q B , and Q C to generate a combined public key Q ABC , such that According to the properties of an elliptic curve, where k A , k B , and k C are their individual private keys and k ABC is their combined private key. If they required only a combined signature to spend their shared transaction, which could be produced by signing the spending transaction with k ABC , this would not guarantee their unanimous consent since any of them who knew k ABC could cheat other parties. This approach would also necessitate a trusted setup to mix their individual private keys in a privacy-preserving manner as they never want to share their private keys with one another.
To solve these issues, our protocol asks the spender for collecting individual signatures from all other parties involved in a shared transaction. Therefore, no party can spend the transaction without unanimous consent. As no party shares their private key with others and there is no requirement for mixing private keys, privacy and transparency are guaranteed without the need for a trusted setup.
Lemma 5. The system is resistant to man-in-the-middle (MitM)

attacks.
A MitM attack is an eavesdropping situation in which an attacker stands between two parties of a transaction to reroute the victim's money to their wallet. In a MitM attack, the destination address of a transaction is replaced with the attacker's address by installing malware on the target wallet. The proposed system, however, is resistant to such an attack because a DID is used as the destination address that must be authorized. Furthermore, the sender signs the transaction outputs using their private key, preventing the attacker from tampering with the output data. Nobody can replace an output because they are unable to compute a correct signature without the sender's private key.
Lemma 6. The system is not vulnerable to Sybil or 51% attacks.
A Sybil attack occurs when an attacker controls multiple nodes of a network. A 51% attack is a type of Sybil attack in which an attacker can control consensus decisions in a blockchain network by having more than 50% computing power of the entire network. This attack is possible in a Bitcoin-like public blockchain platform where any unknown peer with high computing power can participate in consensus and add a block to the blockchain. Bitcoin avoids a 51% attack by using the energy-intensive PoW algorithm and the longest chain or six-confirmation rule. In contrast, there is no risk of 51% attacks in the proposed system because no unauthorized node can participate in consensus.

Lemma 7.
A distributed denial of service (DDoS) attack may increase the block time and reduce the TPS but cannot shut down the payment service.
The DDoS susceptibility of PoA is the same as that of BFTbased consensus algorithms. Because the PoA consensus requires a stable leader at each step to deliver blocks, continuous DDoS attacks targeting step leaders may increase the block time and impair the TPS, and the fact that some nodes have poor network connectivity can exacerbate the problem. A DDoS attack can target any network node. However, to breach PoA's fault tolerance property, a total of 50% of the consensus nodes must fail. Therefore, unless the network is unstable and has a large number of malicious nodes in specific places, such an assault would be less feasible.

Experiment
The proposed system was implemented in Python by connecting four computers for four consensus nodes such as authority A (CPU: AMD Ryzen 5@3. In this manner, money was continuously supplied to the network using block rewards and circulated through P2P transactions in terms of UTXOs. To be added to the blockchain, a block must be accepted by the majority of authorities, according to the PoA protocol. As a result, the block proposed by a step leader was added to the blockchain by the four authorities as soon as it received acceptance from any two non-leader authorities. At each step, the step leader verified transactions, created a block, broadcast the block to the network, and received at least two acceptances of the block. All these tasks were expected to be completed within the step duration.

Performance Evaluation
Fig . 6 illustrates the PoA consensus times for the first 25 blocks excluding the genesis block. The first round of the consensus was completed in 0.7 s while the second round took 1.9 s, on average. The difference between these two latencies was 1.2 s, which defines the offset delay t d , and the sum of these two latencies was 2.6 s, which defines the block time B t . When a faster node proposed blocks, the first round was completed quickly, but the second round became slow, and vice-versa. At each step, there was a difference of 1.4 s between the step duration and the block time, which is referred to as the wait time or safe guard t w required for a slower consensus node. A mining summary of the network is presented in Table 1. The average transaction and block sizes were 834 B and 49.3 KB, respectively. The block size varied based on the transaction size. The average transaction verification time t v was 11.1 ms, which was the sum of three signatures verification time and input-output inquiring time. The average data rate h and TPS over the network were 2.4 Mbps and 15, respectively. To analyze the system's sensitivity, one of the two TPS parameters, h or t v , was varied while fixing the other one to its experimental value, and the effect of this variation on the TPS was observed. As shown in Fig. 7a, the TPS increases with data rate and becomes flat after reaching a certain value (%17 TPS) while t v is fixed to 11.1 ms. At the saturation level, the block broadcasting time nTs=h in (4) tends to 0 and therefore h does not affect the block time B t while the TPS is inversely proportional to B t . Fig. 7b depicts the effect of increasing t v on the TPS while h is fixed. The TPS declines drastically with larger values of t v . Since h has a little impact on the TPS while t v significantly changes the TPS, the only way to increase the TPS is the reduction of transaction verification time by employing high-performance processors. Table 2 presents a comparison between the proposed system and existing auditable cryptocurrency designs in terms of functional features and performance. Sufficient experimental data were not found in the papers. The designs [19], [20], and [23] used ZK proofs for transaction verification in which transacted amounts were encrypted. Because the exact values of encrypted amounts cannot be viewed by all participants, they do not provide complete transparency. Their correctness, however, can be verified by everyone. The system administrators are unable to monitor cash flow over the network. As a result, in the case of a permissioned blockchain, encrypted transactions are viewed as a flaw rather than a feature. Lin et al. [19] adopted the PBFT consensus algorithm, which is less fault-tolerant than PoA. The higher time complexity of this algorithm increases block time and reduces throughput.

Performance Comparison
To support UTXO-based auditable transactions, the design Li et al. [22] used ring signatures. Although a ring signature provides greater privacy than a standard signature, it significantly increases the transaction size. A larger transaction results in network overhead and low throughput. When compared to other works, our system provides a better trade-off between transaction size and verification time. From the overall comparison, it is observed that the proposed system outperforms the existing works.

LIMITATION AND SCOPE
A limitation of the proposed system is its lower throughput (15 TPS) compared with traditional Visa, which provides an approximate throughput of 1700 TPS. Since transactions are processed through consensus rather than a centralized platform, a blockchain network suffers from poor transaction throughput. If the TPS is less than the incoming transaction rate, the size of the mempool (queue) containing pending transactions expands rapidly [15]. As a result of insufficient utilization, meeting user demands will be challenging. However, to use DLT for payment, transaction speed must be sacrificed. The Bitcoin and Ethereum cryptocurrencies provide their users with an average throughput of 5 and 15 TPS, respectively. To achieve a higher throughput, the processing speed of the majority of PoA consensus nodes must be sufficient. Whereas, two of the four computers were comparatively slow in our experimental environment, which increased the offset delay and decreased the TPS. If higherperformance computers are used, the system will provide more TPS by spending less time to verify transactions as it was observed in Fig. 7b. Furthermore, high-speed hardware technology such as the field programmable gate array (FPGA) can be used to reduce transaction verification time by improving ECPM speed [34]. This is because hardware implementations are faster than software implementations. CPU parallelization is another method for increasing speed.
A practical example provides a better understanding of how our system is applied for cross-border payments. To make a cross-border payment, the payer conducts one domestic and one international transactions with authorized DIDs while both transactions are stored in the blockchain. Let Alice 2 Korea be the payer and Bob 2 Bangladesh be the payee. If Alice does not have sufficient amount of JDC in her wallet, she trades Korean Won (KRW) for JDC with any local JDC agent. Then, she transfers JDC to Bob through the proposed payment network. Bob converts JDC to Bangladeshi Taka (BDT) when he requires. In both sides, exchange rates are determined by the respective central banks based on their territorial economic policies.
The system does not forbid users from carrying out transactions with a static DID. Instead, the system gives them the option of ensuring fundraising transparency by routing transactions (i.e., donations) to a static DID where anyone can observe the fund's incoming transactions. Users use dynamic DIDs only for their personal transactions to protect privacy. Therefore, according to the system's protocol, multiple inputs cannot have the same DID, but multiple outputs can contain the same DID.

CONCLUSION
A UTXO-based auditable cryptocurrency has been proposed in this paper to provide low-cost cross-border  payment through a consortium blockchain network. The presented approach could lead to the legalization of cryptocurrencies and a reduction in global money laundering problems.
Our UTXO model differs from other UTXO models in that it uses dynamic DIDs to enable auditability while maintaining user privacy. The proposed system includes MPC and Multisig protocols, which allow users to conduct shared transactions or increase security. The network is able to add a fund recovery protocol to mitigate key management risks and recover financial losses, which is impossible for permissionless cryptocurrency networks where miners do not know each other. Unlike existing auditable cryptocurrency designs, our system maintains a better balance between memory consumption and speed while supporting full transparency. This paper provides guidelines towards the deployment of blockchain-based crossborder payment or auditable cryptocurrency systems. The proposed consortium network is also applicable for worldwide internet of things data management. Md. Shahjalal (Student Member, IEEE) received the BSc degree in electrical and electronic engineering (EEE) from the Khulna University of Engineering & Technology (KUET), Bangladesh, in May 2017, and the MSc and PhD degrees in electronics engineering from Kookmin University, South Korea, in 2019 and 2022, respectively, and awarded for his academic excellence. In 2022, he Joined the Department of Electrical and Electronic Engineering, University of Liberal Arts Bangladesh as an Assistant Professor. His research interests include optical and THz wireless communications, wireless security, non-orthogonal multiple access (NOMA), Internet of Things, low-power wide-area network, and 6G. He has authored or co-authored more than 50 technical papers and patents.