Yao Qian: A Brief Analysis of the Federal Reserve’s Digital Currency Prototype System

Adhering to the modern research and development concept of openness, common wisdom and agility, and adopting an inclusive technical route, explore the creation of a high-throughput, low-latency and elastic CBDC transaction processing system

Editor's note: This article was first published in China Financial Magazine, author: Yao Qian, "Director of the Science and Technology Supervision Bureau of the China Securities Regulatory Commission"

In recent years, the monetary authorities of the world's major economies have continuously increased their research and development efforts on central bank digital currency (Central Bank Digital Currency, CBDC) and achieved many phased results. "Project Hamilton" (Project Hamilton) is a CBDC innovation research project (Digital Currency Initiative, DCI) jointly launched by the Federal Reserve Bank of Boston and the Massachusetts Institute of Technology. This plan has been going on for several years. On February 3, 2022, the Federal Reserve Bank of Boston released a document entitled "A High Performance Payment Processing System Designed for Central Bank Digital Currencies". ) technical report summarizing progress on the first phase of the Hamilton program. This article intends to briefly analyze the Federal Reserve Bank’s digital currency prototype system through the main content of the report.

Research objectives of Phase 1 of the Hamilton Project

The first goal of the first phase of the Hamilton Plan is to explore the performance of the CBDC system, that is, to technically develop a high-throughput, low-latency and elastic CBDC transaction processing system. The specific performance goals include two aspects: one is to complete 99% of transactions within 5 seconds, including completing transaction verification, transaction execution, and confirming transactions to users. The second is that according to the current cash and bank card transaction volume and expected growth rate in the United States, the system can process at least 100,000 transactions per second, and can continue to expand with the growth of later payment volume.

The second objective is to explore the resilience of the CBDC system. To maintain public trust in a CBDC, a CBDC system must ensure continuity of service and availability of funds. The focus of system resilience research is how to ensure uninterrupted system access and data loss when multiple data centers fail.

The third goal is to explore the privacy protection of CBDC. The R&D team believes that the safest way to protect privacy is to reduce data collection from the beginning of the transaction, so a scheme to minimize transaction data retention is designed in the CBDC transaction system.

The Federal Reserve Digital Currency Prototype System Design Coin Form: Unspent Transaction Output (Unspent Transaction Output, UTXO)

There are three types of participants in the Hamiltonian system: transaction processor, issuer, and user. The transaction processor records the CBDC, and verifies and executes the relevant transactions according to the instructions. Like Bitcoin, Hamilton plans to adopt the monetary expression of UTXO. CBDC can only enter and exit the system through the behavior of the issuer. The issuer mints (mint) to increase the funds in the transaction processor, and redeem (redeem) reduces the funds in the transaction processor. The user performs a fund transfer (transfer) operation to atomically change the ownership of the funds, but the total amount of funds stored in the transaction processor remains unchanged, and what changes is the ownership of the funds. Users use their digital wallet's public/private keys to process and sign transactions. In the process of fund transfer transactions, the unspent funds of the payer are the transaction input (input), and the generation of new unspent funds is the transaction output (output)—including the unspent funds of the payee and change to the payer. A valid transaction must be balanced: the sum of the transaction's inputs must equal the sum of its outputs.

Unspent funds are defined as the triplet utxo:=(v, P, sn). Among them, v is the amount, P is the encumbrance predicate (which can be understood as the holder's public key), and sn is the serial number. The issuer’s minting operation creates new unspent funds and adds UTXOs to the UTXO set stored by the transaction processor, while the redemption operation removes existing unspent funds from the UTXO set, making them non-reusable. The issuer must choose a unique sequence number for a newly minted UTXO. It can be set to a uniform random number or a monotonically increasing counter value (when the issuer mints the i-th UTXO, its sequence number will be set to i).

Separation of verification and UTXO compression

In a Hamiltonian system, the transaction processor verifies the correctness of the transaction and executes the transaction by deleting inputs and creating outputs. Verification is divided into transaction-local validation (transaction-local validation, which does not require access to shared state) and existence verification (existence validation, which requires access to shared state). For this separation, the Hamiltonian system designs a dedicated component - sentinel, which is dedicated to receiving user transactions and performing partial verification of transactions. Partial verification involves: verifying that transactions are well-formed; confirming that each input has a valid signature for its spent output; and confirming that transactions remain balanced (i.e., the sum of outputs equals the sum of inputs). If the transaction meets the criteria, Sentinel will forward the transaction to the execution engine responsible for existence verification, otherwise it will only prompt the user for a transaction error.

Existence verification mainly verifies the existence of unspent funds. In order to achieve privacy protection, the Hamilton system stores funds as an opaque 32-byte hash value in the Unspent funds Hash Set (UHS), h:= H(v, P, sn), instead of storing Complete utxo:= (v, P, sn), where H is a hash function, and the Hamiltonian system uses the SHA-256 algorithm. Replacing UTXO sets with UHS sets not only helps privacy protection, but also reduces storage requirements and improves system performance.

In order to verify the existence, the system needs to convert the partially verified transactions into transactions applied to the UTXO hash set in advance. This process is called compaction. Specifically, the sentinel calculates the hash value of the input UTXO, and uses the input UTXO together with the output security lock and value to derive the serial number of the output UTXO, thereby calculating the hash value of the output UTXO, and then lists the two hashes Sent to the transaction processor holding the UHS for existence check and execution.

Existence Verification and UHS Interchange

Assuming that a transaction has passed the transaction partial verification and compression transformation, the transaction processor will update the UHS set as follows: check whether the UHS set has input UTXO of all transactions, if any input UTXO is missing, then abort further processing, otherwise, process Proceeding; the transaction processor deletes the UHS corresponding to the input UTXO of the transaction from the UHS set, and adds the newly created UHS corresponding to the output UTXO to the UHS set. The above-mentioned one-delete-one-add operation is called swap.

high performance architecture

In order to achieve high-throughput, low-latency, and high-fault-tolerance transaction processing, the Hamilton Project designed two architectures. The first is the atomizer architecture, where the system utilizes ordering servers to create a linear history of all transactions. The second is a two-phase commit (2PC) architecture, where the system executes several conflict-free transactions (that is, those that do not pay or receive the same funds) in parallel without creating a uniformly sequenced transaction record.

In both architectures, UHS enables partitioning across servers, increasing throughput and scaling. Executing a single transaction usually involves multiple servers, and each architecture uses different techniques to coordinate the consistent application of a transaction across multiple servers. The centralized atomic server architecture uses the Raft protocol to sort all the updates that come from the sentinel verification, and then apply these updates to the whole system. The 2PC architecture uses distributed consensus nodes to perform atomic transactions and locks required for serialization. Transactions using different funds will not conflict and can be executed in parallel; once the funds of a valid transaction are confirmed as unspent, the transaction can Continuously, multiple transactions can be processed in batches at the same time.

Experimental results from the first phase of Project Hamilton

The first phase of Project Hamilton developed two complete computational source codes, or code bases. One is the code base of the centralized atomic server architecture, which can process about 170,000 transactions per second, 99% of which have a tail delay of less than 2 seconds, and 50% of which have a tail delay of 0.7 seconds. Since the Atomic Server cannot be sharded across multiple servers, although the functionality in the Atomic Server state machine can be reduced to input ordering and deduplication for only a small subset of transactions, the system throughput of this architecture is still limited. That said, a design that strongly orders valid transactions limits throughput. The other is the code base of 2PC architecture, which can process 1.7 million transactions per second, of which 99% of the transactions can be completed within 1 second, and 50% of the transaction tail delay is less than 0.5 seconds, which is much higher than the set target. The basic requirement of 100,000 transactions per second. In addition, the 2PC architecture can further increase throughput by adding more consensus nodes without negatively affecting latency.

The above code has been open-sourced, and Hamilton plans to call it the "Open Source Central Bank Digital Currency Project (OpenCBDC)", with the aim of promoting cooperation in CBDC research and development.

Comparative analysis and comparison with electronic cash (E-cash)

In 1982, American computer scientist and cryptographer David Chaum published a paper titled "Blind Signatures for Untraceable Payment Systems". In the paper, a new cryptographic protocol based on RSA algorithm (RSA algorithm) - blind signature (blind signature) is proposed. Using blind signatures to build an anonymous and untraceable electronic cash system is the earliest digital currency theory and the earliest experimental system that can be implemented, and has been highly recognized by the academic community. There are two key technologies: random ordering and blind signature. The unique serial number generated by random matching can guarantee the uniqueness of the digital cash; the blind signature can ensure the bank's credit endorsement of the anonymous digital cash.

The Hamilton plan adopts a similar idea to E-cash: on the one hand, the uniqueness of the currency (UTXO) is guaranteed through a globally unique serial number that requires system verification for each transaction; on the other hand, it adopts a central processing model and utilizes The encryption algorithm realizes the security and anti-attack of the system. But the Hamilton plan overcomes the shortcomings of E-cash. In the E-Cash model established by David Chaum, every used E-Cash serial number will be stored in the bank database. As the transaction volume increases, the database becomes larger and larger, and the verification process becomes more and more difficult. Hamilton plans to reduce the storage and computing pressure of the transaction processor as much as possible by separating verification and compression processing, and utilize sharding technology and high-performance architecture to greatly improve transaction performance.

In short, spent transaction outputs and unspent transaction outputs are two opposite and complementary design ideas. The latter optimizes the problem of infinite data expansion faced by the former, which is also the essence of Bitcoin surpassing E-Cash.

Comparison with Bitcoin

Similar to Bitcoin, the Hamilton Project also adopts the UTXO model for the design of the coin. But the difference between the two is that: Bitcoin’s blockchain stores all UTXO information; while the Hamilton Project does not adopt the blockchain model, the currency cannot be traced easily, and its transaction processor does not store UTXO details, only UTXO hash value. In particular, the trust basis of the Hamilton Project is completely different from Bitcoin's distributed consensus mechanism. Its platform will be managed by a trusted central organization. The consensus algorithm is only used to coordinate the consistency of the partition servers in the system, which is more similar to third-party payment Background distributed system design.

In terms of preventing threats such as double spending and no-replay attacks, Bitcoin adopts the Proof of Work (PoW) mechanism, while the design of the Hamilton plan relies on the hash algorithm and is highly dependent on the issuer and the transaction system. Safe and reliable. Specifically, for each transfer in the Hamilton transaction processor, the serial number of its UTXO output is determined after processing the hash algorithm. As long as the serial number from the original minting transaction is globally unique, the subsequent recursion can be obtained Each UTXO sequence number of will also be globally unique and will not coincide with any other item in the past or future UTXO collection. The global uniqueness of the serial number is not only a technical detail, but also achieves two effects. One is no double spending. A swap operation permanently marks the UTXO as spent. Since the sequence number is unique, any UTXO can only be spent once and cannot be rebuilt after being spent. The second is to prevent replay attacks. Because each transaction corresponds to one or more UTXO inputs with global uniqueness, its signature will cover the entire transaction, including all related inputs and outputs. Therefore, the signature of a transaction is not valid for any other UTXO other than this transaction (including UTXO created in the future), and the transaction cannot be copied, and the same transaction cannot be executed multiple times. The risk point of the design of the Hamilton plan is: Is the central institution necessarily credible? Is the serial number of the issuer's coin globally unique? Is the transaction processor secure enough to guarantee that the stored UHS collection cannot be tampered with?

In short, although both Bitcoin and the Hamilton Project use the UTXO data model, the Hamilton Project maintains a centralized hash registration system, while Bitcoin maintains a distributed blockchain hash registration system.

other comparisons

The Hamilton Project technical report cites the author’s working paper at the second meeting of the 2018 International Telecommunication Union (ITU) Legal Digital Currency Focus Group. This paper is mainly a review of the digital RMB prototype system, the core idea is the technical framework of "one currency, two libraries, and three centers" ("China's Legal Digital Currency Prototype Concept", see "China Finance" 2016 No. 17), And a two-tier business structure based on the layered use of bank accounts and digital currency wallets ("Digital Currency and Bank Accounts", see "Tsinghua Financial Review", Issue 7, 2017).

The current overall structure of the Hamilton Project can be expressed as "one coin, one wallet, one center". One currency refers to the digital dollar, which is an encrypted digital string expressed in the UTXO data structure signed and issued by the central bank; one wallet refers to the digital currency wallet used by individual or unit users, and is also the carrier for storing the user's public and private keys; one center refers to The transaction registration center records and stores the hash value of the unspent transaction funds of the digital currency, and completes the ownership registration of the whole process of digital currency generation, circulation and extinction.

In terms of digital currency design, both prototype projects emphasize the monetary attributes of encrypted digital strings and the attributes of central bank liabilities. In the circulation link, both projects use the wallet as the main carrier, emphasizing the user's ownership and operation authority of the digital currency. In terms of transaction confirmation and registration, both projects have designed a transaction registration center and an "online money detector". Generally speaking, the two prototype projects have similarities in terms of design concepts. They both adopt the idea of centralized encryption currency, and the transaction processing is "one-time encryption", fully considering the security of digital currency. The technical route is not limited to blockchain technology, which not only absorbs the advanced components, but also discards possible technical blockage points. The difference between the two projects is that the first phase of the Hamilton Project did not explore the technical role of intermediaries and how to achieve a balance between user privacy and compliance; the digital currency prototype system proposed by the author considered and designed the role of intermediaries, and proposed The design idea of separating the certification center and the registration center can not only achieve privacy protection but also meet regulatory compliance requirements. It is worth mentioning that Hamilton plans to store hashes of transaction information instead of plaintext information in the registration server through layer-by-layer hash calculations, which reduces system overhead and is more refined in privacy protection considerations.

epilogue

In general, the prototype design of the first phase of the Hamilton plan is not a complete system, does not have all the functions required for an effective CBDC, and cannot meet the actual application standards. The follow-up Hamilton plan will continue to explore the implementation path of CBDC, continuously improve the security, auditability, programmability, compliance, and interoperability of the system, improve the offline payment function, clarify the role of intermediaries, and strengthen the defense against internal attacks, Denial of service attacks and the ability to resist quantum attacks. The Hamilton Plan provides two important revelations for the development of central banks' digital currencies.

One is the inclusiveness of technology. The Hamilton Plan is not limited to a certain technical route in the process of designing the CBDC. It not only fully absorbs the advantages of E-cash, Bitcoin and other cryptocurrencies and avoids possible disadvantages, but also effectively absorbs the high-performance and high-fault-tolerant architecture design of distributed systems. This shows that the choice of CBDC design should not be fixed, and there is no need to limit the thinking to a certain technical framework or field.

The second is the openness of technology. At present, the CBDC experiments in various countries are basically the relatively secret "Manhattan Project", while the Hamilton Project adheres to the modern research and development concept of openness, wisdom, and agility, actively open-sources the first-stage code, creates the OpenCBDC project and publishes it on github public. At present, the Hamilton Project is still actively seeking external contributions to the open source code base and absorbing new working group members, aiming to work with all parties to promote CBDC research and development. The open innovation model of the Hamilton Project is undoubtedly worth learning from in the practice of CBDC research and development by other countries.

(This article only represents the author's personal academic point of view)