Differences

This shows you the differences between two versions of the page.

--- cbdc:public:cbdc_omg:04_doc:90_recommend:start [2022/05/10 15:04]
nick
+++ cbdc:public:cbdc_omg:04_doc:90_recommend:start [2022/06/17 19:33] (current)
terrance
@@ Line 1: / Line 1: @@
 ====== 6.0 Recommendations ======
-[[cbdc:private:cbdc_omg:start| OMG Responses to Federal Reserve Discussion Paper]]
+|< 100% >|
+| [[cbdc:public:cbdc_omg:04_doc:start | Return to Main Document]]  |  <WRAP>
+<html><b>
+<a href="mailto:[email protected]?Subject=OMG's CBDC WG Response:
+.0 Recommendations
+">Provide Feedback</a></b>
+</html>
+</WRAP>  |
+The OMG's CBDC WG members wanted to make recommendations to the Federal Reserve for future activities in the area of a U.S. CBDC. They propose 12 different direct actions or activities. One of these activities involves the use of RDT&E funding to explore eight specific Research Development Test & Evaluation (RDT&E) topics.
 The **Object Management Group® (OMG®)**, founded in 1989, is an international not-for-profit software consortium (aka
@@ Line 7: / Line 15: @@
 [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:v:vcsb | Voluntary Standards Consensus Body (VSCB)]]) that sets standards in the many areas including distributed object computing. This means the OMG organization plans, develops, establishes, or coordinates voluntary consensus standards using agreed-upon [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:p:p_p | Policies and Procedures (P&P)]]. The P&P provides a framework for openness and transparency to aid in balancing the interests of the Stakeholders, providing due process for disagreements, and building consensus.
-The OMG is not a financial institution, a government institution, or a provider of goods, services, or technology. The main goal of the OMG is to produce standard technical specifications for use by the national and international communities with a proven track record, see the [[cbdc:private:cbdc_omg:04_doc:04_intro:start#about_the_object_management_group_omg | Introduction]]). Based on our experience in formulating the responses to the questions posed in the **White Paper**, our members have formulated a set of recommendations to help aid the Federal Reserve to move forward with a U.S. CBDC. The OMG members are very active in 26 vertical markets, including Business, Finance, Government, Healthcare, Manufacturing, Military, Robotics, Space, and Telecoms.
+The OMG is not a financial institution, a government institution, or a provider of goods, services, or technology. The main goal of the OMG is to produce standard technical specifications for use by the national and international communities with a proven track record, see the [[cbdc:public:cbdc_omg:04_doc:04_intro:start#about_the_object_management_group_omg| Introduction]]). Based on our experience in formulating the responses to the questions posed in the **White Paper**, our members have formulated a set of recommendations to help aid the Federal Reserve to move forward with a U.S. CBDC. The OMG members are very active in 26 vertical markets, including Business, Finance, Government, Healthcare, Manufacturing, Military, Robotics, Space, and Telecoms.
-<nspages cbdc:private:cbdc_omg:04_doc:90_recommend: -tree -r -exclude -subns -pagesInNs -h1 -textNs="">
+<nspages cbdc:public:cbdc_omg:04_doc:90_recommend: -tree -r -exclude -subns -pagesInNs -h1 -textNs="">
-===== Establishment of Consortium  =====
-[[cbdc:private:cbdc_omg:04_doc:90_recommend:start| Return to Top of Recommendations]]
-The [[https://www.omg.org/ | Object Management Group ]] recommends the US Federal Reserve continues to pursue **''P0011''** and **''P0030''** Desirements((
-A **Desirement** is a blended word combining the word **Desire** and **Requirement**. **Desirement** is something that is desired, but not absolutely required and is often used to caption the capabilities of a product or system before it has reached the formal requirements phase.
-Source: [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:d:desirement | Desirement]]
-)) which can be reviewed in Table {{ref>furtherAction}}.
-<table furtherAction>
-<caption>The Policy Considerations identified in the **White Paper**</caption>
-^  Statement No.  ^  Page No.  ^  Desirement  |
-^ P0011 ^  3  | The Federal Reserve does not intend to proceed with the issuance of a CBDC without clear support from:<WRAP>
-  - Executive Branch
-  - Legislative Branch
-  - Ideally in the form of a specific authorizing law
-</WRAP>|
-^ P0030 ^  21  | The Federal Reserve will only take further steps toward developing a CBDC if: <WRAP>
-  - Research points to benefits for households, businesses, and the economy overall that exceed the downside risks
-  - Indicates that CBDC is superior to alternative methods
-</WRAP>|
-</table>
-Each of the two Desirements needs to be pursued separately. The Federal Reserve should continue to pursue garnering support from the Executive and Legislative Branches of Government for a CBDC as stated in **''P0011''** and also pursue obtaining an authorizing law. However, while pursuing these avenues, it is important to present [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.2_views:3_taxonomic:4_data_tax:01_cog_taxonomy:start | Data, Information, Knowledge, Understanding, and Wisdom]] based on the findings from [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:r:rtd_e | Research Development Test & Evaluation (RDT&E)]].
-The purpose of a Consortium would be to help initiate, guide, oversee, and coordinate RDT&E efforts. These efforts would be used to help formulate an authorizing law and provide evidence to the Executive and Legislative branches of government.
-The CBDC is a large problem with many moving parts, all of which require a lot of systems analysis, engineering, testing, and simulation in order to ensure public confidence:
-  : //For a nation’s economy to function effectively, its citizens must have confidence in its money and payment services. The Federal Reserve, as the nation’s central bank, works to maintain the public’s confidence by fostering monetary stability, financial stability, and a safe and efficient payment system. // from the **Executive Summary** provided in the [[https://www.federalreserve.gov/publications/files/money-and-payments-20220120.pdf | Money, and Payments: The U.S. Dollar in the Age of Digital Transformation]] White Paper
-Pursuing a CBDC that is flawed or not having stakeholder buy-in could ultimately inflict more damage than it is worth.
-The OMG further recommends that an **Other Transaction (OT) Consortium** be considered and the stakeholders are invited to join. An OT Consortium is a formal relationship between a government sponsor (i.e., Federal Reserve), an OT Administrator, and a collection of traditional and non-traditional vendors, non-profit organizations, and academia aligned to a technology domain area (i.e., cyber, space, undersea, propulsion) that are managed by a single entity, and focused on innovative solutions to government technology challenges that meet the intended scope and purpose of other transactions.
-OT Consortium is based on the following [[https://aida.mitre.org/demystifying-dod/ots-otconsortia/ | OT Consortium Model]]:
-<figure consortium>
-{{  cbdc:private:cbdc_omg:04_doc:20_comments:brp:q01:screen_shot_2022-02-27_at_1.26.52_pm.png?600  |}}
-<caption>The Existing OT Constoria Model</caption>
-</figure>
-Generally, an OT Consortium has three components:
-  * Government Sponsor
-  * Government Contracting Office
-  * Consortium Manager
-  * Consortium (i.e., Stakeholders)
-  : **Note:** Sometimes the government sponsors prefer to manage a consortium in-house rather than hire an industry Consortium Manager or Consortium Management Firm.
-The Consortium Manager is awarded an OT agreement by the government (base OT agreement) and manages OTs awarded to its consortium member organizations (project OT agreements) under the base agreement. In the [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra | OMG Distributed Immutable Data Object Reference Architecture (DIDO-RA)]], this highest level (i.e., OT Consortium) is referred to as the [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.2_views:1_stakeholder:4_ecosphere | Ecosphere]] which would roughly follow the steps outlined in [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.3_gov:1_communities:2_stakeholder | Steps for Establishing an Ecosphere]]. The OT Consortia (ie., Ecosphere) can create any number of Ecosystems and Domains as is needed. It is recommended that the Ecosystems create and are responsible for Domains that fall under their auspices, however, the Policy and Procedures (P&P) may require the Ecosphere's approval for creation.
-===== Defining the Stakeholders  =====
-[[cbdc:private:cbdc_omg:04_doc:90_recommend:start| Return to Top of Recommendations]]
-Obviously, when it comes to determining the Stakeholders it might be fair to include every U.S. Resident, or at least those having banking or credit union accounts. Obviously, this would be unwieldy. All these individuals are supposedly represented in government through elected officials in Congress and the President. These elected officials have taken the problem and made various departments or agencies that should be representing these people. Based on a cursory review, it appears that there are at least 33 different Oversight authorities in the U.S., see Table {{ref>summaryStakeReg}}.
-<table summaryStakeReg>
-<caption>Summary of the estimated number of Government Stakeholders for the CBDC.</caption>
-^Potential Oversight Authorities  ^  No. of Stakeholders  |
-^ [[https://www.omgwiki.org/CBDC/doku.php?id=cbdc:private:cbdc_omg:04_doc:15_common:05_stakeholder:start#us_federal_government_oversight_authorities | U.S. Federal Government Oversight Authorities ]] |  14  |
-^ [[https://www.omgwiki.org/CBDC/doku.php?id=cbdc_omg:04_doc:15_common:45_privacy:start#us_state_laws_and_regulations   | non-U.S. Federal Government Oversight Authorities  ]]  |  19  |
-^ Total  ^  **33**  |
-</table>
-However, this does not include the roughly 4,200 Commercial Banks insured by the FDIC, see Figure {{ref>numberFDIC}} or the largest Banking Association in the U.S., The American Banking Association (ABA), or its competitors, nor the roughly 5,300 Credit Unions.
-<figure numberFDIC>
-{{  :cbdc:private:cbdc_omg:04_doc:90_recommend:screen_shot_2022-05-08_at_1.35.14_pm.png?600  |}}
-<caption>Number of FDIC-insured commercial banks in the United States from 2000 to 2021.((
-Statistica,
-__Number of FDIC-insured commercial banks in the United States from 2000 to 2021__,
-Accessed: 8 May 2022,
-[[https://www.statista.com/statistics/184536/number-of-fdic-insured-us-commercial-bank-institutions/]]
-))</caption>
-  : **Note:** In 2021, there were 4,236 FDIC-insured commercial banks in the United States.
-</figure>
-It does not represent all the retail outlets, service providers, landlords, etc that all have a "stake" in the U.S> Dollar and consequently a U.S. CBDC. For more on the Stakeholders identified in the OMG analysis, please refer to section [[cbdc:private:cbdc_omg:04_doc:15_common:05_stakeholder:start]].
-===== Defining Applicable Laws and Regulations  =====
-[[cbdc:private:cbdc_omg:04_doc:90_recommend:start| Return to Top of Recommendations]]
-The members of the OMG have compiled a list of the Laws and Regulations within the U.S. that applicable to the Financial System covering:
-   * [[cbdc:private:cbdc_omg:04_doc:15_common:45_privacy:start | Privacy]] see Table {{ref>summaryPrivReg}} for summary
-   * [[cbdc:private:cbdc_omg:04_doc:15_common:48_natsec:start | Security]] see Table {{ref>summaryLawsReg}} for a summary
-These laws were passed by the Legislative and the Executive Branches of the Government and have been upheld by the Supreme Court. Therefore, this can be considered as part of the will of the people ( see Stakeholders).
-<table summaryPrivReg>
-<caption>Summary of the number of laws and regulations covering National Security Considerations.</caption>
-|< 40% 20% 10% >|
-^ U.S. Privacy Consideration  ^ No. of Laws and Regulations  |
-^ [[https://www.omgwiki.org/CBDC/doku.php?id=cbdc_omg:04_doc:15_common:45_privacy:start#us_federal_laws_and_regulations | U.S. Federal Laws and Regulations ]] |  10  |
-^ [[https://www.omgwiki.org/CBDC/doku.php?id=cbdc_omg:04_doc:15_common:45_privacy:start#us_state_laws_and_regulations   | U.S. State Laws and Regulations  ]]  |   6  |
-^ Total  ^  **16**  |
-</table>
-<table summaryLawsReg>
-<caption>Summary of the number of laws and regulations covering National Security Considerations.</caption>
-|< 40% 20% 10% >|
-^ National Security Consideration  ^  No. of Laws and Regulations  |
-^ [[cbdc:private:cbdc_omg:04_doc:15_common:48_natsec:10_human_traf | Human Trafficking ]] |  14  |
-^ [[cbdc:private:cbdc_omg:04_doc:15_common:48_natsec:20_drug_traf  | Drug Trafficking  ]] |   9  |
-^ [[cbdc:private:cbdc_omg:04_doc:15_common:48_natsec:30_corrupt    | Corruption        ]] |  10  |
-^ [[cbdc:private:cbdc_omg:04_doc:15_common:48_natsec:40_launder    | Money Laundering  ]] |  11  |
-^ Total ^  **44**  |
-</table>
-A U.S. CBDC would have to adhere to these laws if it going to be considered valid. Not doing so would be considered arbitrary and capricious. In addition, since the CBDC would most likely rely on new technology, each of these laws would need to be evaluated by a legal team to assess how the laws and regulations need to be reinterpreted, amended, or extended to remain current. Further discussions are well beyond the skills of the authors but it is recommended The Federal Reserve take this on as a serious part of the whole CBDC effort.
-===== Instilling Confidence in the CBDC  =====
-[[cbdc:private:cbdc_omg:04_doc:90_recommend:start| Return to Top of Recommendations]]
-The [[https://www.omg.org/ | Object Management Group (OMG) ]] recommends the Federal Reserve uses a Model-Based Systems Engineering (MBSE) and Unified Architecture Framework (UAF) approach for future CBDC efforts. The CBDC is a complex issue that, once released, could have a life expectancy of many, many years. Only through extensive Systems Analysis, Engineering, Design, and testing will CBDC have the stability it needs to instill confidence of the public.
-Some of the potential requirements in the [[https://www.federalreserve.gov/publications/files/money-and-payments-20220120.pdf | White Paper]] as summarized by the [[https://www.omg.org/ | Object Management Group's ]] [[cbdc:private:cbdc_omg:04_doc:12_summary:start| White Paper Analysis]] reflect the need to instill public confidence (See Table {{ref>confidence}})
-<table confidence>
-<caption>Some requirements in the White Paper that require the confidence of the public.</caption>
-^ Statement No.  ^  Page No.  ^ Statement  |
-^ B0020 ^  13  | Maintain public confidence by not requiring mechanisms, such as deposit insurance |
-^ R0003 ^  3  | **Risk** to the safety and stability of the financial system |
-^ R0004 ^  3  | **Risk** to the efficacy of monetary policy |
-^ R0005 ^  7  | New payment services could pose **Risks** to: <WRAP>
-  - financial stability
-  - payment system integrity
-  - other **Risks**
-</WRAP>|
-^ R0011 ^  11  | Increased **Risk** to consumer's vulnerability to: <WRAP>
-  - loss
-  - theft
-  - fraud
-</WRAP>|
-</table>
-===== Adopting a Model-Based Systems Engineering (MBSE) Approach  =====
-[[cbdc:private:cbdc_omg:04_doc:90_recommend:start| Return to Top of Recommendations]]
-For more than forty years, the practice of systems engineering followed a linear path: requirements are documented
-first, followed by analysis then conceptual design—through the development life cycle. However, regardless of the
-engineering process employed—waterfall, incremental, iterative, spiral, and even sprint-based—the lack of
-integration from one phase to another in the cycle results in longer delivery times and increases costs to correct errors
-introduced at transition points.
-**Model-Based Systems Engineering (MBSE)**((
-"Model-based systems engineering (MBSE) is the formalized application of modeling to support system requirements,
-design, analysis, verification, and validation activities beginning in the conceptual design phase and continuing throughout
-development and later life cycle phases.” INCOSE SE Vision 2020 (INCOSE-TP-2004-004-02), Sept 2007
-MBSE
-)) is an initiative in the systems engineering community that uses
-model-based descriptions and transformations so that work occurs concurrently. Requirements collection, analysis,
-and specifications are performed at the same time as conceptual design. MBSE is practiced across many industries
-around the globe. For example, it was used to develop the world’s largest telescopes, propulsion engines for fighter
-jets, autonomous driving cars, software solutions to include software-defined radios, and space applications (hardware and software).
-MBSE is often contrasted with a more traditional document-based approach to systems engineering, where system
-information is spread across many document-based artifacts (handwritten text documents, spreadsheets, and
-drawings). MBSE brings information together into a cohesive, integrated model of the system that:
-  - Enhances precision, consistency, and traceability;
-  - Includes behavioral analysis, system architecture, requirement traceability, performance analysis, simulation, test, etc.;
-  - Formalizes the practice of systems development through the use of models;
-  - Integrates information across discipline-specific engineering tools, including hardware and software design, analysis, simulation, and test; and
-  - Facilitates shared understanding of the system among the development team, resulting in:\\
-    * quality/productivity improvements and lower risk;
-    * rigor and precision;
-    * ongoing communications among development team and customer; and
-    * management of complexity.
-For more information on MBSE, please see:
-  * [[https://www.omg.org/intro/MBSE.pdf | MBSE Specifications at OMG]]:
-  * [[cbdc:private:cbdc_omg:8_append:60_mbse | MBSE Overview in Appendix]].
-The [[https://www.omg.org/ | Object Management Group (OMG)]] also recommends that the Federal Reserve use the Unified Architecture Framework (UAF) for future CBDC efforts. See [[https://www.omg.org/spec/UAF/ | OMG Unified Architecture Framework (UAF)]]:
-UAFP 1.0 supports the capability to:
-  * model architectures for a broad range of complex systems, which may include hardware, software, data, personnel, and facility elements;
-  * model consistent architectures for System-of-Systems (SoS) down to lower levels of design and implementation;
-  * support the analysis, specification, design, and verification of complex systems; and
-  * improve the ability to exchange architecture information among related tools that are SysML-based and tools that are based on other standards.
-The intent of UAF is to provide a standard representation for describing enterprise architectures using a Model-Based Systems Engineering (MBSE) approach.
-The [[https://www.omg.org/ | Object Management Group ]] also recommends that the Federal Reserve use the Unified Architecture Framework (UAF) for future CBDC efforts. See [[https://www.omg.org/spec/UAF/ | OMG Unified Architecture Framework (UAF)]], it is summarized here:
-//UAF Profile (UAFP) 1.0 supports the capability to://
-  * //Model architectures for a broad range of complex systems, which may include hardware, software, data, personnel, and facility elements;//
-  * //Model consistent architectures for System-of-Systems (SoS) down to lower levels of design and implementation;//
-  * //Support the analysis, specification, design, and verification of complex systems; and//
-  * //Improve the ability to exchange architecture information among related tools that are SysML based and tools that are based on other standards.//
-//The intent of UAF is to provide a standard representation for describing enterprise architectures using a Model-Based Systems Engineering (MBSE) approach.//
-===== Defining the Appropriate Standards or Specifications  =====
-[[cbdc:private:cbdc_omg:04_doc:90_recommend:start| Return to Top of Recommendations]]
-===== Perform Research Development Test & Evaluation (RDT&E)  =====
-[[cbdc:private:cbdc_omg:04_doc:90_recommend:start| Return to Top of Recommendations]]
-[[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:r:rtd_e | Research Development Test & Evaluation (RDT&E) Funding ]]
-==== Consensus Algorithms ====
-[[cbdc:private:cbdc_omg:04_doc:90_recommend:start| Return to Top of Recommendations]]
-  : // Consensus algorithms are the basis of all the blockchains/DAGs. They are the most important part of the blockchain/DAG platforms. Without them(consensus algorithms) we will be left with just a dumb, immutable database.//((
-Vaibhav Saini,
-hackernoon.com,
-__ConsensusPedia: An Encyclopedia of 30+ Consensus Algorithms, A complete list/comparison of all Consensus Algorithms__,
-June 2-18,
-Accessed: 7 September 2021
-[[https://hackernoon.com/consensuspedia-an-encyclopedia-of-29-consensus-algorithms-e9c4b4b7d08f]]
-))
-The OMG members recommend the Federal Reserve invest [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:r:rtd_e | Research Development Test & Evaluation (RDT&E) Funding ]] in developing and perfecting any
-[[https://www.omgwiki.org/CBDC/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:c:consensus_algorithm | Consensus Algorithms ]] required by the CBDC since they are an essential part of any DIDO implementation such as [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:b:blockchain | Blockchain]],
-[[https://www.omgwiki.org/CBDC/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:d:distributed_ledgers|Distributed Ledger]],
-[[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:d:directed_acyclic_graph_dag | Directed Acyclical Graphs]], etc).
-There are a few consequences to not having "the best" Consensus Algorithms for the CBDC:
-  * Loss of confidence in the Federal Reserve and the CBDC by the Stakeholders
-  * Cost of operating the CBDC
-  * Unavailability during disasters
-  * Vulnerability during Cyberattacks
-Currently, in the Cryptocurrency world, most of the Mining Operations have moved from being distributed to being centralized and operated be a few select organizations in highly centralized locations. For example,
-  : //Fundamentally, Bitcoin mining operations ad traditional data centers are similar in the basic design and operational principles. Power must be brought into the building and distributed to the requirement, air distribution systems cool the equipment, and the building provides protection from outdoor conditions and security threats.//((
-Sunbird,
-__Largest Bitcoin Mining Farms in the World__,
-Accessed: 9 May 2022,
-[[https://www.sunbirddcim.com/sites/default/files/Sunbird_InfoGraphic_Bitcoin.pdf]]
-))
-If this is true for a U.S. CBDC, then what advantage does the CBDC have over the [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:r:rtp | Real-Time Payments (RTP)]] developed by the
-[[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:a:ach | Automated Clearing House (ACH) Network]].
-==== Artifical Intelligence (AI) ====
-[[cbdc:private:cbdc_omg:04_doc:90_recommend:start| Return to Top of Recommendations]]
-The OMG members recommend the Federal Reserve use [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:r:rtd_e | Research Development Test & Evaluation (RDT&E) Funding ]] in developing and perfecting Artificial Intelligence (AI) for use with and alongside a U.S. CBDC. The AI could help in detecting suspicious security and criminal activities. When combined with [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:b:biometrics | Biometrics]] and [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:b:biometric_authentication | Biometric Authentication]].
-AI could also consider time and geospatial data to make informed decisions about the validity of a proposed transaction.
-==== Ontologies ====
-[[cbdc:private:cbdc_omg:04_doc:90_recommend:start| Return to Top of Recommendations]]
-The OMG members recommend the Federal Reserve use [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:r:rtd_e | Research Development Test & Evaluation (RDT&E) Funding ]] in developing and perfecting glossaries, taxonomies, and ontologies used to represent the U.S. CBDC, the Intermediaries, and the needs of the Stakeholders. There already exists an OMG Ontology, [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.b_stds:tech:omg:fibo| Financial Industry Business Ontology (FIBO) ]] that probably needs to be extended or updated to handle a U.S. CBDC.
-==== Smart Contracts ====
-[[cbdc:private:cbdc_omg:04_doc:90_recommend:start| Return to Top of Recommendations]]
-The OMG members recommend the Federal Reserve use [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:r:rtd_e | Research Development Test & Evaluation (RDT&E) Funding ]] in developing and perfecting [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:s:smart_contract&s[]=smart&s[]=contracts | Smart Contracts]]. Currently, the //de facto// standard for Smart Contracts is the [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:e:ethereum |  Ethereum]] language called [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:s:solidity | Solidity]]. See the [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.b_stds:defact:ethereum:ethereum_solidity:start | Ethereum Solidity Language Specification]]. However, there are shortcomings in the language which could either be updated or replaced with a more comprehensive language and may not even be procedural in nature. For example, the graphically based [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.b_stds:tech:omg:bpmn | Business Process Model And Notation (BPMN)]]. Another possibility would be to develop a standardized, [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:p:pim | Platform-Independent Model]] for a Smart Contract [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:a:api | Application Programming Interface (API)]] which could have multiple [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:p:psm | Platform Specific Models]] developed from the PIM.
-<figure PIM_PSM>
-{{  :cbdc:private:cbdc_omg:04_doc:90_recommend:screen_shot_2022-05-09_at_3.39.27_pm.png?600  |}}
-<caption>Creating a Platform Indepenent Model (PIM) and transforming it into various Platform Specific Models (PSMs)</caption>
-</figure>
-==== Complex Data Model ====
-[[cbdc:private:cbdc_omg:04_doc:90_recommend:start| Return to Top of Recommendations]]
-The OMG members recommend the Federal Reserve use [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:r:rtd_e | Research Development Test & Evaluation (RDT&E) Funding ]] in developing and perfecting how to model data on a blockchain and especially what data to store on a blockchain.
-TBD TBD TBD
-Most of the data models underlying cryptocurrencies are pretty simple. Generally, it's a balance.
-The OMG members recommend There needs to be a comprehensive study of what needs to be stored in addition to the simple balance, especially if the "ledger" is going to try and prevent criminal activity and protect privacy. It also means that there will most likely be a confederation of blockchains and the need to link these together with the blockchains. some examples of concepts not covered in the existing models are association and composition. However, this extra data comes at a cost.
-==== Understanding Gas ====
-[[cbdc:private:cbdc_omg:04_doc:90_recommend:start| Return to Top of Recommendations]]
-  : //A gas is worth of 0.00000005 ETH and if you planning to store data or let’s say a 256-bit word it will cost you 20,000 gas. A kilobyte is thus 640k gas or 0.032 ETH or 16.70 USD as per the current rate of Ethereum which is $528.3 Dollar.//
-  : //Now calculate the price of storing one GB of data on a blockchain decentralized ledger and blow your mind away with an enormous amount that will come up. As per the current price of Ethereum, 1MB of data will cost you up approx. 17,100 USD. Calculate the price you will need to pay to store 1GB data of data on the blockchain.//
-  Though the facts mentioned above is only true for public Ethereum blockchain while the case can be totally different if we focus on a few private or permissioned blockchain. One will, after reading the solution, definitely conceive the idea of using blockchain as the secured database is far way better than using the traditional database.
-  * 1 Gwei equals 0.000000001 ETH)
-  * median gas price (28 Gwei)
-  * USD/ETH exchange rate ($295/ETH)
-|< 100% 20% >|
-^  Task  ^     Gas required         ^  Cost (ETH)  ^  Cost (USD)  ^  Ops per ETH  ^  Ops per USD  ^  Ops per Block  ^  Blocks to complete OP  |
-^ Add or subtract two integers	    |            3 | 0.000000009 |  0.000002655 | 11111111.11       | 37664.78343 | 1566666.667 | 0.0000006382978230 |
-^ Add two Integers, 1 Million times |      3000000 | 0.09        | 26.550000000 |        11.1111111 | 0.037664783 | 1.566666667 | 0.638297872 |
-|< 100% 20% >|
-^  Task  ^     Gas required         ^  Cost (ETH)  ^  Cost (USD)  ^  Ops per ETH  ^  Ops per USD  ^  Ops per Block  ^  Blocks to complete OP  |
-^ Save a 256-bit word to Storage      |   20000 | 0.0006 | 0.171 | 1666.666667 | 5.649711751 | 243 | 0.004255319 |
-^ Save 1MB to Storage (31250 256-bit words) | 625000000 | 18.75 | 5531.25 | 0.053333333 | 0.000180791 | 0.00752 | 132.9787234 |
-^ Save 1GB to Storage (31250 256-bit words) | 6250000000000 | 18750 | 5531250 | 0.00005333333 | 0.00000018079 | 0.00000752 | 132978.7234 |
-===== Security Baked-in not Bolted-on =====
-[[cbdc:private:cbdc_omg:04_doc:90_recommend:start| Return to Top of Recommendations]]
-Also see the answers to:
-   * [[cbdc:private:cbdc_omg:04_doc:20_comments:brp:q13:sb_01:start]]
-     * [[cbdc:private:cbdc_omg:04_doc:20_comments:brp:q13:sb_01:prt_b:start]]
-   * [[cbdc:private:cbdc_omg:04_doc:20_comments:brp:q07:start]]
-     * [[cbdc:private:cbdc_omg:04_doc:20_comments:brp:q07:start#lack_of_reporting_and_oversight | Lack of Reporting and Oversight]]
-   * [[cbdc:private:cbdc_omg:04_doc:20_comments:dsn:q18:start]]
-   * [[cbdc:private:cbdc_omg:04_doc:20_comments:brp:q02:start]]
-Cryptocurrency skirts near the edges of illegal, illicit, or shady interactions and transactions. The Chainalysis Team recently published their 2021 findings((
-__DeFi Takes on a Bigger Role in Money Laundering, But a Small Group of Centralized Services Still Dominate__,
-Chainalysis Team,
-January 2022,
-Accessed: 4 April 2022,
-[[https://blog.chainalysis.com/reports/2022-crypto-crime-report-preview-cryptocurrency-money-laundering/]]
-)) which highlights some security issues associated with the unregulated or poorly regulated Cryptocurrency realm. The following is an excerpt from the report:
-  : //Overall, going by the amount of cryptocurrency sent from illicit addresses to addresses hosted by services, **cybercriminals laundered $8.6 billion worth of cryptocurrency in 2021**.//
-  : //That represents a **30% increase in money laundering activity over 2020**, though such an increase is unsurprising given the significant growth of both legitimate and illicit cryptocurrency activity in 2021. We also need to note that these numbers only account for funds derived from “cryptocurrency-native” crime, meaning cybercriminal activity such as [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:d:dark_web | Dark Web]] market sales or ransomware attacks, in which profits are virtually always derived in cryptocurrency rather than fiat currency. It’s more difficult to measure how much fiat currency derived from offline crime — traditional drug trafficking, for example — is converted into cryptocurrency to be laundered. However, we know anecdotally this is happening, and later in this section provide a case study showing an example of it.//
-Therefore, security needs to be "baked into" the CBDC from the onset and can not be an afterthought; however, it is hard to balance the tightrope between the need for **Privacy** and the need for **Security**. This difficulty in achieving a balance has been captured in Desirement **''R0014''**:
-^ R0014 ^ Risk of not achieving an appropriate balance between safeguarding the privacy rights of consumers and affording the transparency necessary to deter criminal activity |
-It appears that the [[https://www.omgwiki.org/CBDC/doku.php?id=cbdc:private:cbdc_omg:04_doc:15_common:08_currency_models:10_cash:start | Digital Cash Model]] is less vulnerable than the [[https://www.omgwiki.org/CBDC/doku.php?id=cbdc:private:cbdc_omg:04_doc:15_common:08_currency_models:15_accounts:start | Digital Account Model]]. The use of Stablecoins could help with maintaining the value of CBDC, but would not add any security.
-Regardless of which model ([[cbdc:private:cbdc_omg:04_doc:15_common:08_currency_models:15_accounts:start| Digital Accounts]], [[cbdc:private:cbdc_omg:04_doc:15_common:30_stablecoins:start| Stablecoins]], [[cbdc:private:cbdc_omg:04_doc:15_common:08_currency_models:10_cash:start| Digital Cash]]) is used for the CBDC, the [[https://www.omg.org/ | Object Management Group ]] recommends that the Federal Reserve consider Seurity of the system from the earliest phases of the U.S. CBDC. This means having the Non-Functional requirement of Security be well defined and formal.
-One way to accomplish this is through the use of a Model-Based Systems Engineering (MBSE) and Unified Architecture Framework (UAF) to model all aspects of the CBDC before it is built. Since the requirements for the security of the system are a moving, ever-changing target, this does not mean that every security issue must be fully understood or specified before work can begin. It means that at every step, the Security question needs to be raised. The CBDC is a complex issue that, once released, could have a life expectancy of many, many years. Only through extensive Systems Analysis, Engineering, and Design will the CBDC have the stability it needs to instill confidence in the public.
-During system development, MBSE and UAF models of the system are used along with Use Scenarios and Use Cases to flush out potential problems. This means thinking about all aspects of the State of Data throughout its lifecycle. The OMG DIDO-RA has detailed discussions of the various states of data and how it relates to a distributed system.
-Figure {{ref>DataStateFigure}} graphically represents the different Data States within a system. Most systems are now able to handle Data-in-Motion and Data-at-Rest issues but have traditionally relied on physical security to protect Data-in-Use.
-<figure DataStateFigure>
-{{  :cbdc:private:cbdc_omg:04_doc:20_comments:brp:q13:sb_02:datastateflow.png?700 |}}
-<caption>The various States of Data</caption>
-</figure>
-Table {{ref>dataStateTable}} provides a quick overview of the various data states. These data states are described in detail in the [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.2_views:3_taxonomic:4_data_tax:02_state_taxonomy:start | OMG DIDO-RA]].
-<table dataStateTable>
-<caption>Data can exist in the following different states</caption>
-|< 100% 20% >|
-^ [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.2_views:3_taxonomic:4_data_tax:02_state_taxonomy:data_at_rest   | Data-at-Rest ]]  |<WRAP>
-[[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:d:dataatrest | Data-at-Rest ]] refers to all data in computer storage. It excludes data while it is moving across or within a network, and it excludes data that is temporarily residing in computer memory.
-</WRAP>|
-^ [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.2_views:3_taxonomic:4_data_tax:02_state_taxonomy:data_in_motion | Data-in-Motion]] | <WRAP>
-[[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:d:data_in_motion | Data-in-Motion ]], also referred to as **Data in Transit** or **Data in Flight**, is a [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:d:digital_asset | Digital Asset]] transmitted between locations (i.e., between computers or computer components). Data-In-Motion also describes data within [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:r:computermemory | Random Access Memory (RAM)]].
-</WRAP>|
-^ [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.2_views:3_taxonomic:4_data_tax:02_state_taxonomy:data_in_use    | Data-in-Use]]    |<WRAP>
-[[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:d:data_in_use | Data-in-Use ]] covers data being processed (i.e., updated, processed, erased, accessed or read) by a system. Data-In-Use is not passively stored, but is actively moving through parts of a [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:c:computerplaform | Computing Platform]] (i.e., [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:c:cpu | Central Processing Unit (CPU)]], [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:d:dram | Dynamic Random Access Memory (DRAM),]], [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:b:bus | Data Bus]], etc.). **Data-In-Use** is one of three states of digital data -- the other states are [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.2_views:3_taxonomic:4_data_tax:02_state_taxonomy:data_at_rest | Data-at-Rest]] and [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.2_views:3_taxonomic:4_data_tax:02_state_taxonomy:data_in_motion | Data-in-Motion]].
-</WRAP>|
-</table>
-<table>
-<caption>White Paper Desirements related to disruption and security</caption>
-^ Statement No.  ^  Page No.  ^ Statement  |
-^ B0004 ^  2  | Protect consumer privacy|
-^ B0005 ^  2  | Protect against criminal activity|
-^ B0053 ^  20  | Provide resiliency to threats to existing payment services—including: <WRAP>
-  - operational disruptions
-  - cybersecurity risks
-</WRAP>|
-^ R0011 ^  11  | Increased **Risk** to consumer's vulnerability to: <WRAP>
-  - loss
-  - theft
-  - fraud
-</WRAP>|
-^ D0015 ^  20  | **Design** should include any dedicated infrastructure required to provide a resilience to threats such as operational disruptions and cybersecurity risks |
-^ D0016 ^  20  | **Design** should include offline capabilities to help with operational resilience of the payment system  |
-^ D0017 ^  20  | **Design** should include digital payments in areas suffering from large disruption, such as natural disasters |
-</table>
 /**=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

OMG Central Bank Digital Currency (OMG-CBDC) Working Group (WG) Wiki

User Tools

Site Tools

Differences

Page Tools