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

Let’s learn about the modern R&D concept of openness, intelligence and agility, adopt an inclusive technical route, and explore the creation of a high-throughput, low-latency and elastic CBDC transaction processing system.

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 (CBDC) and achieved many phased results. “Project Hamilton” is a CBDC innovative research project (Digital Currency Initiative, DCI) carried out by the Federal Reserve Bank of Boston in the United States 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, USA released a report entitled “A High Performance Payment Processing System Designed for Central Bank Digital Currencies”. ), a technical report summarizing the progress of the first phase of the Hamilton Plan. This article intends to briefly analyze the prototype system of the Federal Reserve’s central bank digital currency through the main content of the report.

Research objectives for the first phase of the Hamilton Plan

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 resilient CBDC transaction processing system. The specific performance goals include two aspects: one is to complete 99% of transactions within 5 seconds, including the completion of transaction verification, transaction execution and confirmation of transactions to users, processing speed and the corresponding indicators of existing US bank card payments and inter-bank instant payment systems The second is that based on the current US cash and bank card transaction volume and expected growth rate, the system processes at least 100,000 transactions per second, and can continue to expand with the growth of post-payment volumes.

The second goal 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 research of system resilience focuses on how to ensure that system access is not interrupted and data is not lost when multiple data centers fail.

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

Federal Reserve Digital Currency Prototype System Design

Coin form: Unspent Transaction Output (UTXO)

There are three types of participants in the Hamilton system: the transaction processor, the issuer, and the user. The transaction processor records the CBDC and verifies and executes the related transactions according to the instructions. Like Bitcoin, Hamilton plans to adopt the currency expression of UTXO. CBDC can only enter and exit the system through the behavior of the issuer, the issuer mint increases the funds in the transaction processor, and redemption (redeem) reduces the funds in the transaction processor. A user performs a transfer operation that atomically changes the ownership of the funds, but the total amount of funds stored in the transaction processor does not change, it is the ownership of the funds that changes. Users use their digital wallet’s public/private keys to process and sign transactions. During a funds transfer transaction, the use of the payer’s unspent funds is the transaction input (input), and the generation of new unspent funds is the transaction output (output) – including the payee and change to the payer for unspent funds. A valid transaction must be balanced: the sum of the transaction’s input values ​​must be equal to the sum of the output values.

Unspent funds are defined as the triple 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. An issuer’s minting operation creates new unspent funds and adds the UTXO to the UTXO collection stored by the transaction processor, while a redemption operation removes existing unspent funds from the UTXO collection, making it non-reusable. Issuers must choose a unique serial number for newly minted UTXOs. It can be set to a uniform random number or a monotonically increasing counter value (when the issuer mints the i-th UTXO, it will set its serial number to i).

Split Authentication 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. Validation is divided into transaction-local validation (transaction-local validation, which does not require access to shared state) and existence validation (existence validation, which requires access to shared state). For this separation, the Hamilton system designed a dedicated component, the sentinel, which is dedicated to receiving user transactions and performing partial verification of transactions. Partial verification includes: verifying that the transaction is well-formed; verifying that each input has a valid signature for its spent output; verifying that the transaction is balanced (ie, the sum of the outputs equals the sum of the inputs). If the transaction meets the criteria, the sentinel will forward the transaction to the execution engine responsible for existence verification, otherwise it will only alert the user to the transaction error.

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

For existence verification, the system needs to pre-convert locally verified transactions into transactions applied to the UTXO hash set, a process called compaction. Specifically, the sentinel calculates the hash value of the input UTXO, and derives the serial number of the output UTXO by combining the input UTXO with the output security lock and value, thereby calculating the hash value of the output UTXO, and then lists these 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 validation and compression transformation, the transaction processor will update the UHS set as follows: Check whether the UHS set has input UTXOs for all transactions, if any input UTXO is missing, then abort further processing, otherwise, process Proceed; the transaction processor deletes the UHS corresponding to the input UTXO of this transaction from the UHS set, and adds the newly created UHS corresponding to the output UTXO to the UHS set. The above operation of one deletion and one addition is called swap.

high performance architecture

In order to achieve high throughput, low latency, and high fault tolerance transaction processing, Hamilton plans to design two architectures. The first is the atomizer architecture, where the system utilizes an ordering server 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 ordered record of transactions.

In both architectures, UHS enables cross-server partitioning, increasing throughput and scaling. Executing a single transaction typically 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 sequence all updates from sentinel-validated updates, and then applies these updates to the 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 be executed. Continuously, multiple transactions can be processed in batches at the same time.

Experimental results from Phase 1 of the Hamilton Project

The Hamilton Project developed two complete sets of computational source code or code bases in the first phase. One is a centralized atomic server architecture codebase capable of processing about 170,000 transactions per second, of which 99% have a tail latency of less than 2 seconds and 50% have a tail latency of 0.7 seconds. Since atomic servers cannot be sharded across multiple servers, the system throughput of this architecture is limited, although the functionality in the atomic server state machine can be reduced to input sorting and deduplication for only a small subset of transactions. That said, a design that strongly orders valid transactions limits throughput. The other is the code base of the 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 transactions have a tail delay of less than 0.5 seconds, which is much higher than the set target. The basic requirement of 100,000 transactions per second. In addition, adding more consensus nodes to the 2PC architecture can further improve throughput without negatively impacting 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 purpose of promoting CBDC research and development cooperation.

comparative analysis

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 this paper, a new cryptographic protocol based on RSA algorithm – blind signature is proposed. The use of blind signatures to build an electronic cash system with anonymity and untraceability 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 blinded signature. The unique serial number generated by random ordering can ensure the uniqueness of the digital cash; the blinded 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 mode and utilizes The encryption algorithm realizes the security and attack resistance of the system. But the Hamilton plan overcomes the shortcomings of E-cash. In the E-Cash model established by David Chaum, each used E-Cash serial number is stored in the bank’s database. As transaction volume rises, the database becomes larger and the verification process becomes 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 use sharding technology and high-performance architecture to greatly improve transaction performance.

In short, spent transaction output and unspent transaction output are two opposite 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 Plan also adopts the UTXO model for the design of the coin. But the difference between the two is: Bitcoin’s blockchain stores all UTXO information; while the Hamilton plan does not use the blockchain model, the coins cannot be easily traced, and its transaction processor does not store UTXO details, only UTXO’s hash value. In particular, the trust basis of the Hamilton Plan is completely different from the distributed consensus mechanism of Bitcoin. Its platform will be managed by a trusted central organization, and the consensus algorithm will only be used to coordinate the consistency of each partitioned server in the system, which is more similar to third-party payment. Backend distributed system design.

In terms of preventing double-spending, non-replay attacks and other threats, 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 transaction system. Safe and reliable. Specifically, for each transfer in the Hamilton transaction processor, the serial number output by its UTXO is determined after being processed by the hash algorithm. As long as the serial number starting from the original minting transaction is globally unique, the subsequent recursion can be obtained. Each UTXO serial number of will also be globally unique and will not coincide with any other item in the past or future UTXO set. The global uniqueness of serial numbers is not only a technical detail, but can achieve two effects. One is no double spending. The swap operation will permanently mark the UTXO as spent. Since serial numbers are unique, any UTXO can only be spent once and cannot be rebuilt after spending. 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 UTXO other than this transaction (including future created UTXOs), and the transaction cannot be copied and the same transaction cannot be executed multiple times. The risk point in the design of the Hamilton Plan is: Is the central agency necessarily credible? Is the serial number of the issuer’s mint globally unique? Is the transaction processor secure enough to guarantee that the stored UHS collection cannot be tampered with?

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

Other comparisons

The technical report of Project Hamilton cites the author’s working paper at the 2018 International Telecommunication Union (ITU) Fiat Digital Currency Focus Group 2nd meeting. This paper is mainly a review of the prototype system of digital renminbi, and the core idea is the technical architecture of “one currency, two banks, and three centers” (“Prototype Conception of China’s Legal Digital Currency”, see “China Finance” 2016 Issue 17), And a two-tier business structure based on the layered and combined 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 coin refers to the digital dollar, that is, the encrypted digital string expressed by 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 public and private keys of users; 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 entire process of the generation, circulation and demise of the digital currency.

In terms of digital currency design, both prototype projects emphasize the monetary properties of encrypted digital strings and the properties of central bank liabilities. In the circulation link, both projects use wallets as the main carrier, emphasizing the user’s ownership and operation rights of digital currency. In terms of transaction confirmation and registration, both projects have designed a transaction registration center and an “online money detector”. In general, the two prototype projects have similarities in the design concept. They both adopt the idea of ​​centralized encryption, and the transaction processing is “one-time-one-pass”, which fully considers the security of digital currency. The technical route is not limited to blockchain technology, which not only absorbs the advanced components, but also abandons possible technical blocking points. The difference between the two projects is that the first phase of the Hamilton Plan 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 considers and designs the role of intermediaries, and proposes 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 calculate the hash layer by layer, and store the hash of the transaction information in the registration server instead of the plaintext information, which reduces the system overhead and is more refined in terms of privacy protection.

Epilogue

Overall, 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 does not yet meet the practical 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 attack, ability to resist quantum attack. The Hamilton plan provides two important lessons for the development of digital currency by central banks.

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

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

Posted by:CoinYuppie,Reprinted with attribution to:https://coinyuppie.com/yao-qian-a-brief-analysis-of-the-federal-reserves-digital-currency-prototype-system/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.

Like (0)
Donate Buy me a coffee Buy me a coffee
Previous 2022-05-09 10:32
Next 2022-05-09 10:34

Related articles