Phase 1 has surfaced several key learnings on the potential design of a CBDC:
Select ideas from cryptography, distributed systems, and blockchain technology can provide unique functionality and robust performance. We suspect existing database and distributed systems technology is sufficient to provide a more traditional payment architecture for CBDC where one actor stores users' accounts, users cannot custody their own funds, and there is no transaction scripting functionality. We created a new design to offer both these features and new opportunities for different intermediary roles.
A CBDC can provide functionality that is not currently possible with either cash or bank accounts. For example, a CBDC could support cryptographic proofs of payment, more complex transfers to or from multiple sources of funds, and flexible forms of authorization to spend, such as varying transaction limits.
We found that separating a transaction processor into modular components improves system scalability and flexibility; for example, we can scale and replicate transaction validation independently from preventing double spending and committing transactions, and our architecture can support many future designs for programmability and privacy.
Despite using ideas from blockchain technology, we found that a distributed ledger operating under the jurisdiction of different actors was not needed to achieve our goals. Specifically, a distributed ledger does not match the trust assumptions in Project Hamilton's approach, which assumes that the platform would be administered by a central actor. We found that even when run under the control of a single actor, a distributed ledger architecture has downsides. For example, it creates performance bottlenecks, and requires the central transaction processor to maintain transaction history, which one of our designs does not, resulting in significantly improved transaction throughput scalability properties.
CBDC design choices are more granular than commonly assumed. Currently, CBDC designs are categorized as direct, two-tier, or hybrid models, with "token" or "account" access models 1 2 7 12 15. We found these limited categorizations lacking and insufficient to surface the complexity of choices in access, intermediation, institutional roles, and data retention in CBDC design 10. For example, wallets can support both an account-balance view and a coin-specific view for the user regardless of how funds are stored in the database.
By breaking transaction processing into steps like creation, authorization, submission, execution, and storing history, CBDC designers can consider the potential roles for intermediaries at each stage, creating opportunities for innovation.
By implementing a robust system, we identify new questions for CBDC designers and policymakers to address, regarding tradeoffs in performance, auditability, functionality, and privacy. Our work raised important questions to address in how the technical architecture might affect the use and function of CBDC in payments. For example, it is an open question how important from an economic perspective it might be to support atomic transactions. In database parlance, this implies multiple operations to different pieces of the data are applied in a way that appears instantaneous (atomic), or the set of updates does not happen at all; there is no partial application 4 14. In the context of a payment processor, this means users could reliably issue payments that might transfer multiple bills (or funds from multiple accounts) entirely, and would never see partial transfers, even if there are crashes or system errors. We chose to implement atomic transactions, which has a direct impact on the performance of the system 8.
The main functional difference between our two architectures is that one materializes an ordered history for all transactions, while the other does not. This highlights initial tradeoffs we found between scalability, privacy, and auditability. In the architecture that achieves 1.7M transactions per second, we do not keep a history of transactions nor do we use any cryptographic verification inside the core of the transaction processor to achieve auditability. Doing so in the future would help with security and resiliency but might impact performance. In the other architecture, we can audit the set of unspent funds to make sure they were created correctly. Storing the history of transactions implies the central transaction processor can reconstruct the transaction graph, which, in combination with other data sources, could reveal sensitive user information 16 17. In the next phase of work, we will focus on adding privacy-preserving designs for auditability.
Similarly, our goals of supporting self-custody and reducing data stored in the core of the transaction processor had direct implications on data users might be required to store, failure scenarios, recovery protocols, and on what types of payment functionality we can support.