Sidebar
Table of Contents
Question: 22. Are there additional design principles that should be considered? Are there tradeoffs around any of the identified design principles, especially in trying to achieve the potential benefits of a CBDC?
Question
- Are there additional design principles that should be considered?
- Are there tradeoffs around any of the identified design principles, especially in trying to achieve the potential benefits of a CBDC?
Answer
Non-Functional Requirements Design Principles
Overview
Some major design principles missing from the White Paper are the specification of Non-Functional Requirements. The Distributed Immutable Data Objects - Reference Architecture (DIDO-RA) provides a list of Non-Functional Requirements applicable to the CBDC. The following is an outline of the Non-Functional Requirements:
1. Portability
2. Reliability
4. Security
6. Usability
7. Performance
9. Elasticity
10. Scalability
Examples
Some of these Non-Functional requirements were alluded to in the White Paper, but not directly specified or defined. Table 1 provides an example of cross-referencing the Non-Functional Requirements to the Benefits, Policy Considerations, Risks and Design requirements identified in the White Paper Analysis done by the Object Management Group's CBDC WG.
| Non-Functional Requirement | Benefits, Policy Considerations, Risks and Design requirements |
|---|---|
| Adaptability |
|
| Performance |
|
| Availability |
|
| Confidentiality |
|
| Efficiency Metrics |
|
B = Benefit Considerations |
|
P = Policy Considerations |
|
R = Risk Considerations |
|
D = Design Considerations |
|
- Note: There should be no tradeoffs between Non-Functional Requirements and any existing requirements identified in White Paper as determined by the OMG's CBDC WG White Paper Analysis
Discussion of Example
The first requirement listed under Adaptability is Benefit B0008:
| B0008 | 3 | Provide entrepreneurs a platform on which to create new financial products and services |
|---|---|---|
B = Benefit Considerations |
||
P = Policy Considerations |
||
R = Risk Considerations |
||
D = Design Considerations |
||
In order to realize B0008, the CBDC needs to be considered a system that can support both:
- Software Adaptability - A software component with a well-defined, stable Application Programming Interface (API) can be exchanged using another component with minimal effort, as long as that component adheres to the API. For example, SQL describes an API for a database component. As long as the software adheres to the standard SQL API, the Database Management System (DBMS) can be exchanged between, for example, Oracle | Oracle and PostgreSQL, with no to minimal impact.
- Architecture Adaptability - Connectors between software components change without having to change the components. This again comes down to having well-defined, stable APIs for the connectors. For example, the Unix File System (UnixFS) is a connector between software components and the physical filesystem. The associated UnixFS library can be exchanged for the InterPlanetary File System (IPFS) UnixFS connector and the software component should have no to minimal impact.
Obviously, this is just an example, and the Federal Reserve should adopt the information and update the information in the OMG's CBDC WG White Paper Analysis and also perform their own assessment a similar to that presented in Table 1. The discussions and justifications for each requirement need to be captured for future reference. For example, B00008 would have its own discussion area within the CBDC requirements document.
Functional Requirements Design Principles
Overview
Some major design principles missing from the White Paper are the specification of https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:f:funcreq. The Distributed Immutable Data Objects - Reference Architecture (DIDO-RA) provides a list of Functional Requirements applicable to the CBDC. The following is an outline of the Functional Requirements:
1. Platforms
Some of these Functional Requirements were alluded to in the White Paper, but not directly specified or defined. The Table 2 provides an example of cross-referencing the Functional Requirements to the Benefits, Policy Considerations, Risks and Design requirements identified in the White Paper Analysis done by the Object Management Group's CBDC WG.
Examples
| Functional Requirement | Benefits, Policy Considerations, Risks and Design requirements |
|---|---|
| Hardware Platforms |
|
| Access Control |
|
B = Benefit Considerations |
|
P = Policy Considerations |
|
R = Risk Considerations |
|
D = Design Considerations |
|
Discussion of Example
The one of the first requirements listed under Platforms is Benefit B00011:
| B0011 | 7 | Make payments:
|
|---|---|---|
B = Benefit Considerations |
||
Requirement B0011 is a compound requirement, and the selection of a Platform can have an impact on:
B00011-1- FasterB00011-2- CheaperB00011-3- More ConvenientB00011-4- More Accessible
