In recent years, news has risen one after another about various CBDC (Central Bank Digital Currency) studies and possible technological implementations. Most of these studies can be linked to various Central Banks (such as the Bank of England, the European Central Bank, the Central Bank of Sweden ...), where there is usually no specific proposal for the implementation of a specific technology. In this sense, it is questionable whether a blockchain platform to implement a CBDC use-case would be the right technology. On the other hand, specific technology companies, usually using some distributed general ledger technology, develop and publish CBDC implementation architectures. An example of such an developed technology architecture is the CBDC proposal based on Consensys Ethereum, R3 Corda and Algorand platform. In this article, we take a closer look at Consensys ’Ethereum-based proposal (source: https://consensys.net/solutions/payments-and-money/cbdc/ ).
For the successful implementation of a CBDC, it is worth summarizing the requirements of the CBDC at both technology and use case level in general:
1. Type of CBDC: The very first question is whether the CBDC should execute a retail, interbank, or both type of transaction.
2. Token or account based.
3. Monetary policy and token allocation: an important planning question is what monetary policy is for digital money, how much of it is in circulation on an annual basis, and who determines the output. Examples of such issues include determining interest rate and / or token inflation.
4. System change and decision mechanisms (governance): similar to the previous point, another question is who can change the various parameters of the system and how.
5. Privacy versus transparency: it is generally technically difficult to comply with both properties and, in addition, to comply with all possible AML / KYC regulations. Here, it is worth setting the priorities differently for each user case.
6. Performance, robustness, stable operation, and scalability: While stable operation, robustness, and high availability are a matter of course for most blockchain protocols, speeds such as the number of transactions per second cannot in many cases be met trivially.
7. Legal requirements and applicable legal environment.
8. Risk Analysis: One of the biggest challenges for CBDC is perhaps its risk-free implementation without compromising the existing financial ecosystem.
Consensys proposes a multi-tier architecture in general to implement a CBDC.
- The core of the system consists of a consortium block chain network that runs at the central bank and similarly significant players and regulates the issuance and administration of the fund token (layer 1).
- The second layer connects this basic system with other major financial actors through so-called state channels, which allow private and fast asset / token transfer (layer 2).
- The third layer implements the quasi-retail BCDC with channels subordinated to the main system, so-called side channels (layer 3).
- The latest layer of the system would provide services to end users, either directly or through additional technology and / or fintech providers (layer 4).
Although the system outlined is not a plain blockchain protocol, but a combination of several decentralized systems, state and side channels, it is expected to meet the requirements for a CBDC:
- Token issuance is fully controlled by the Central Bank.
- Quasi real-time token transfer.
- High number of transactions per second.
- Large number of participants with different roles.
- Well controllable and configurable transaction visibility, compliance with various KYC / AML regulatory requirements.
- An acceptable amount of energy required to maintain the system (Proof of Stake).
To the best of our knowledge, an Ethereum-based CBDC implementation does not yet exist. Thus, of
course, an interesting question to be answered in the future is exactly how well the architecture outlined by Consensys fits in with a particular CBDC implementation.
