A CBDC could take multiple forms :
1) A Retail CBDC would be issued to the public to enable fast and secure payment,2) A wholesale CBDC would only be accessible by banks and would facilitate large-scale transfers.
The security of CBDCs has real-world import and is one of the major challenges to overcome and it will depends on Roles involved and Stacks Involved.
1) Currency issuer. Every CBDC system needs an entity that creates money. Let's call this role currency issuer.
2) Payment validator. CBDC systems require entities that keep the system running and provide the needed infrastructure for other participants.
3) Account provider. Another infrastructure role in a typical retail CBDC system is an account provider that allows users to register, obtain payment credentials (e.g., in the form of a digital wallet), and start making CBDC payments. I
4) Payment sender and recipient. Payment senders and recipients are generally not trusted by other system participants. Instead, it is assumed that users may behave arbitrarily or even fully maliciously.
5) Regulator. The task of the regulator is to ensure that all payments in the system conform to requirements such as anti-money laundering rules.
6) Technology provider. The end users (i.e., payment senders and recipients) need to trust the technology provider for the correctness of the payment application and potentially also for the management of payment credentials.
++ Layers of the technical stack ++
Attackers can exploit different components of a CBDC to achieve their goals. In this section, we outline the CBDC technical stack, illustrated to the right.
Attackers can exploit different components of a CBDC to achieve their goals. In this section, we outline the CBDC technical stack, illustrated to the right.
1) Human. Although end users are not part of a technical CBDC implementation, they can be exploited to affect system security at large.
2) Application. CBDCs are expected to usher in an ecosystem of new applications that can interface seamlessly with the digital payment system.
3) Consensus. In order to provide redundancy against unforeseen factors like faulty devices, compromised infrastructure, and resource outages, many proposed CBDC designs involve the use of consensus protocols: decentralized processes for determining the validity of financial transactions among multiple payment validators
4) Computation and storage. CBDCs require back-end infrastructure to maintain a secure and functional payment system.
5) Network. The validation of transactions, issuance, deletion of money, and all other events in a CBDC will be communicated to the relevant parties via an underlying network.
6) Hardware. CBDCs will ultimately run on hardware, including mobile devices, hardware wallets, and servers that maintain the state and functionality of the system.
No comments:
Post a Comment