On The Report Published By The Boston Fed And MIT

Project Hamilton is a High Performance Payment Processing System Designed for Central Bank Digital Currencies (CBDC). Before we get excited, the authors of the highly anticipated technical paper confirm that it is a toy, a proof of certain concepts, not a complete system. However, it is a toy for grownups. The paper and the accompanying code demonstrates the technical feasibility of a system that solves payments on a scale like that of the United States and of the US Dollar, a widely used global currency. The system can handle more than one hundred thousand payments per second where each transaction has to complete in less than 5 seconds. One hundred thousand per second was a number that the Hamilton team arrived at by looking at the observed payment rates of credit cards and other payment systems, including a provision for future expansion. The other challenge for Hamilton is to be most cash like without the physicality of cash. This means the freedom for users to pay others using CBDC without relying on intermediaries like banks or credit card companies, with the privacy of cash. For system resiliency and wide usability, the payment transaction has to be stored in multiple computers in an all or nothing fashion. A property called atomicity, that is the proof of the payment has to be updated in all the locations or not in any location. Another challenge is to build a flexible system that can implement policies that are yet to be decided.

Privacy is taken to be one of the most important properties of such a system. In order to achieve this, Hamilton’s layered architecture has a highly modified payment transaction model which is based on the Unspent Transaction Output (UTXO), outlined in the bitcoin paper. This privacy focused transaction model is called the Unspent funds Hash Set (UHS). The UTXO model is difficult to grasp, because accounts are what we are used to. Only the UHS is stored in the core system. Additionally the system has to be resilient, resistant to malicious attackers, and to bugs. Some of these are handled, others are deferred to Phase II. The system was tested in two different architectures. One of which orders the payments and another that does not. The first is a fast blockchain called the atomizer model, the second is a 2 phase commit model without rollbacks called 2PC. The 2phase commit is a familiar model in distributed databases. The Hamilton team has made the computer code of the entire system available in open source, thru github.

Being a coder, I forked the source and have been trying to grok the code in an Integrated Development Environment on my laptop, where I am writing this article. It is written in C++, a language that I can almost read like my mother tongue, but a mother tongue that is slightly rusty from disuse, since Hamilton code uses C++17, a slightly later dialect than I am used to. Getting used to the coding style is also part of the process of familiarization. Like with any complex system, having access to the code is not enough, time has to be spent in figuring out the logic, along with the architecture to make sense of the details. A plan for Hamilton Phase II invites participation from all, including the curious and the combative.

This article was very challenging to write, as technical details had to be presented in a condensed way without losing too many of the nuances. The main thrust is what this project means for the story of money in the United States and globally, especially to interested generalists. Sometimes technical material has overwhelmed the telling of the story. However, comments on the presentation especially in social media are welcome, so that the text can be altered to make it more accessible to the general public.

The Two Hamiltons

This section could appear to be a digression from the main theme, but read on to see the relevance. The name Hamilton is meant to evoke Alexander Hamilton, the first Treasury Secretary, who wrote a fifteen thousand word report in 1790, to urge the launching of the First National Bank(FNB), similar to the Federal Reserve. The argument that he made was for paper currency backed by the FNB which would unleash the power of the economy by stimulating private enterprise. The First National Bank would be an independent Central Bank with extensive private participation. Hamilton clearly saw the advantages of untethering paper currency from specie (gold or silver coins and bars), backing it with a true private-public partnership, as well as allowing the decentralization of investment so that capital and credit for businesses could be invested more frictionlessly through local decisions by individuals. As with any genius, Hamilton had a confederacy of dunces arrayed against him. This opposition was overcome by Hamilton in 1790 with his seminal paper, although the charter for the National Bank did not survive his untimely death seven years before it came up for renewal in 1811.

What the economic possibilities for America in the nineteenth century would have been, had Hamilton lived longer is unknown. Instead, in the real history, the nation was mired in a fratricidal conflict and a whole century was lost in unproductive infighting and economic malaise, with its echoes resonating today. This series of rushes, booms, panics and busts continued until 1913, when the establishment of the Federal Reserve, following the Hamiltonian plan launched a century of economic growth and American primacy. The Hamiltonian idea of untethering the currency, culminated in the abolition of the gold standard. This brings us to the present, when the opposition to a CBDC issued by the Fed is still rampant among the folks prescribing a purely private solution (stablecoins for example) instead of a digital dollar. The name Hamilton is thus apposite for a currency that is on the verge of a leap into the digital realm, which is held back by certain interests. The result of this contest and the features of this emergent form of money will determine whether the American economy will be safe, flexible and stable by benefiting all people, or rigid, unstable and insecure.

Jim S. Cunha of the Boston Fed, the animator of the Hamilton project made clear that the name Hamilton was also meant to evoke Margaret Hamilton, who was about the same age as Alexander Hamilton was in 1776, when she made ground shifting contributions to Software Engineering, a term she helped coin. Margaret Hamilton was recruited from MIT into the Apollo program and was the software director for the Apollo Command Module, the first portable computer that traveled a long way to land on the moon. An inventor of fail-safe computing, an autonomous system that came through at a crucial moment for the Lunar Landing in the face of apparently failed hardware. Without Margaret Hamilton, the Eagle may not have landed on the moon at that time. Project Hamilton needs her as the patron saint (even though she is still alive), for a CBDC moon shot to succeed.

There are two messages here, one is the way that the Apollo Programs developed, from those that went from Low Earth Orbit to orbiting the moon (Apollo 8) and then to landing on the moon and returning safely, all crewed missions. Apollo was the successor of the Explorer, Gemini and Mercury programs. USA is not even at the Explorers level in CBDCs. China launched its own Sputnik in e-CNY. The expansion of knowledge and confidence that come with real CBDCs have to be addressed with pilot programs rippling outward from a college campus like MIT, maybe even with multiple foci. No amount of sandbox testing will match experiences gained from the randomness of the wild. CBDCs in a country like the US best not arrive with a bang.

The other message is about fail-safe computing and self-healing systems. Margaret Hamilton’s obsession about the what if scenarios that seem unlikely, saved the mission when they improbably happened. Even today one third to one fourth of any code has to be about error handling and recovery. Emergent properties of a complex CBDC system have to be accounted for. Margaret Hamilton spent most of the rest of her life working on a Universal System Language, and its implementation in 001, a toolkit to enforce the Development Before the Fact (DBTF) concept. Also relevant in a high risk solution like a Digital Dollar are design patterns from Avionics to guard against a low probability but highly risky outcome.

Since the reference to Margaret Hamilton is missing from the graphic that accompanies the announcement of the technical paper on the Boston Fed, I created a graphic of my own that infuses Margaret Hamilton into the official image of their announcement.

A Digital Dollar For The People

As a Central Bank is the Counterparty Of Last Resort, the buck literally stops at the Fed. A CBDC would be the only digital currency issued by the Central Bank available widely. Such an instrument carries the lowest credit risk. Most of the designs for CBDCs have been proposed by economists, they enshrine intermediaries as the distribution vectors and custodians, as their main fear is the disintermediation of credit creation, most Dollars, Euros, Pounds, Renminbi, Rupees and Yen are generated by commercial banks making loans to private individuals and enterprises. As cash is the model the economists are familiar with, they propose a similar distribution mechanism for CBDCs. The other design choice that the economists who design these systems offer is an account versus a token system. Project Hamilton shows how these designs are limited in their imagination, as they put it “CBDC design choices are more granular than commonly assumed”. In particular, it would help if economists collaborated with technologists before offering technical designs to the world.

Project Hamilton shows how a technical design can straddle these seemingly binary choices to offer new capabilities. The Hamilton design models an instrument that can function as both a token and an account based instrument. A dual view, an asset modeled with UHS, a la bitcoin does not make it a token based system. The paper makes clear the fact that this depends on who is doing the looking. A system that looks like an opaque token based system from the vantage of the core system can be turned into an account based view in their digital wallets. It is not tokens OR accounts, it is tokens AND accounts.

The other technical design choices are about creating modular public infrastructure which can be built upon to implement policy, regulatory and legal directives as needed. Capabilities that can be built upon a solid base. The Phase I Hamilton project is about the creation of a substrate for such an endeavor. The whitepaper suggests that there are many places in this design for private intermediaries to get involved. Building on top of public substrates is what makes for choices.

The bulk of the technical whitepaper describes the transaction model in both the atomizer (or blockchain) and the 2PC (a distributed database) model. At the base of everything is the transaction model, the data model of a payment, how a payment from a user to another transmogrifies into a UHS by its passage through the validating layers, stripped of private data, ending up in replicated storage as a proof of payment, powered by one-way hash functions. The transaction flow, the scale, the speed of finality, the different core models all hang off the transaction model. The users hold digital wallets which keep their means of proving their right to spend the CBDC in the wallet, as well as a way to see how much CBDC they have. This wallet interacts with the transaction validation layer which consists of two layers, a sentinel which checks transaction inputs and forwards the attested transaction to the core layer. The transaction validation layer is separated from the core storage layer. This pre-validation is a feature in a popular enterprise blockchain, Hyperledger Fabric, which also uses UTXO at its core. The transaction validation layer compacts the payment transaction until only the proof of the payments remain to be deposited in the core system, most data including amounts do not end up in the core system. These are the layers: the wallet, the transaction validation layer and the core system. The transaction validation layer and the core system are the transaction processing layer.

The design could result in a self-custody digital wallet as one of the options, this is the ultimate in privacy and control. All basic operations, minting of new money and the transfer of funds rely only on the public key/private key pair, the private keys are held only at the edges, in the wallets. The public key is the only manifestation of identity. The choice can also lead to multi-sig (where multiple signatures are needed for spending) capabilities and hierarchical deterministic (a way to create multiple keys) wallets, another way of managing keys.

This extension of capabilities look like the merging of Layer-2 architectures into the solution from the get go. Privacy and the possibility of self-custody wallets are two of the most significant contributions of this project. This empowers people, the payers, the payees, the users of this system. The system is more private than bitcoin, it preserves the option for self-custody wallets.

In this and in the construction of the transaction flow, the key architectural choices so far have resulted in some unanswered questions, chief among this how data not available in the core system can be accessed without destroying privacy. This may be needed to gather economic statistics like the velocity of money or for recovery of a lost wallet. The enforcement of money flow limits, counter-terrorism, anti-money-laundering and other regulatory controls that are meant to be systemic safeguards become more challenging if not impossible. Implementing privacy preserving architecture deeper into the guts of the core infrastructure as well as into the wallets themselves may solve these choices. These may include zero-knowledge proofs and homomorphic encryption protocols. These are seen as worthy goals for Phase II.

Blockchain Or Not To Blockchain

Much is made of some statements in the Executive Summary and in the technical report.  The lines are about the suitability of a blockchain architecture for a system administered by a single entity, the Federal Reserve. This is read as the repudiation of the blockchain philosophy for CBDCs. These statements are more about the suitability of such a mechanism for a system administered by a single entity, especially since higher costs, in time and complexity have to be paid for coordination in a blockchain. As most blockchain based consensus algorithms that ensure that all the copies (replicas in distributed system parlance) are atomically consistent, slow replication down. A classic algorithm from distributed systems practice, Raft, is used by Hamilton. This algorithm is one of the choices for Hyperledger Fabric. Byzantine Fault Tolerance (BFT) algorithms, so called because these algorithms admit the presence of malicious or imperfect actors in the inner circle, is for generating trust from a circle of untrustworthy participants. It is based on a classic distributed systems problem called the Byzantine Generals Problem. This transformation a BFT algorithm is also promised in Phase II.

The most basic interpretation of a blockchain is that of a data structure, a chain of blocks, Satoshi’s bitcoin paper says, the paper never mentions the word blockchain. A block consists of a set of transactions, and a chain says a serial order, one block after another. Once forged, the chain should be unbreakable, a new block is constantly being worked on, extending the chain. Most of the ideas around payment transactions, in Project Hamilton have been sourced from bitcoin. The UHS and the idea of cryptographic custody and transfers. The outcome, protection, against double spend, against replay attacks. The transactions in the UHS model sets up microledgers, each transaction carries with it references to all the transactions before it in the form of a chain. We get to the same theme, the design creates a transaction model that is a blockchain and not a blockchain even in the 2PC model.

Basic operations in a transaction model for a payment system are just three mint, redeem and transfer. These operations cover the money supply and the use of the money for payments. The money supply can expand or contract, money can be spent by transferring from one wallet to another. Double spends (when the same money is spent twice) and replay attacks (when an observed transaction is resubmitted, in other words spending other people’s money that has already been spent) are prevented by the transaction model. Minting and redemption as basic operations have not been modeled properly, all due to a natural caution around these functions which are highly sensitive. Well, maybe in Phase II.

Hamilton Phase II

As the story unfolds, it can be seen that many features that make for a fully functioning CBDC are missing from Phase I. Most of these are obviously difficult to model, it is even possible that some of them cannot be implemented without changing the basic design and feature constructs of Phase I such as Privacy, Safety, Auditability, the transaction model itself. Kicking the can down the road is popular and necessary in academic settings and papers, it is a bug and a feature of open inquiry. On the whole, no other solution for CBDC has thrown open the source code for scrutiny and more importantly to build on top of. Bitcoin has done this, so has Ethereum and many other public blockchains. However these are not CBDCs. Of the enterprise blockchains, Hyperledger is an open source project that houses many variants, including Fabric which is a widely used Enterprise blockchain, in many CBDC projects, some of them in production. Hyperledger is a big tent that includes Besu, an Ethereum implementation, a widely used public blockchain.

Phase II promises to tackle

• Privacy and auditability
• Programmability
• Interoperability
• Offline payments
• Minting and redemption
• Productionization
• Denial of service attacks
• Quantum resistance

This is quite a mish mash of capabilities and features at different scales from different disciplines. Some can be considered quite basic without which any CBDC cannot function (Minting and redemption for example). All of these except quantum resistance are needed for a fully functioning CBDC. Some are missing: upgradeability, a fully functioning digital wallet, security and monitoring.

The MIT team has released the entire source code of the Project Hamilton Phase I into open source. It consists of all code necessary to run and interact with the two core architectures.

In addition to being open source itself, the code relies on a series of open source libraries and components, they include the llvm clang compiler and tools, LevelDB from Google, NuRaft from Paypal, cryptography components from Bitcoin. The test setup is on AWS servers utilizing AWS internal networks. These AWS components are not open source. However, it should be possible to run it on any compatible Linux hardware.

The decision to open-source the cbdc project is the most momentous decision from Project Hamilton. Many enterprises big and small use open source software. 98% of enterprises use open source, although only a few contribute, which is the free-rider problem. As can be seen from the example of opencbdc-tx, the project could not have been completed so rapidly without the free use of open source software. Statistics favors open source software(OSS) there are only .19 bugs for every 1000 lines in OSS compared to 20 to 30 for every 1000 lines in proprietary off the shelf software. The fixes are faster and propagation and coordination easier in OSS.

Conclusion

Even though we can complain that it is too little and too late, several breakthroughs have been made, the most significant of them is the creation of a framework in which privacy is paramount, achieved with the principle “can’t be evil” not “don’t be evil”. How long that purity can be maintained under the pressures of auditability entering the picture in Phase II is to be seen. The segregation of the data at the edges is a significant development that will give primacy to the devices that are in everyone’s hands and thus control will be decentralized back to the people. Investment in user interface design and improvements in usability, not the strong suite for back end developers, has been given short shrift in Project Hamilton Phase I. Phase II cannot ignore this important element. For widespread adoption, the digital wallet front end and back end design on a mobile device needs to be simple and intuitive, easier said than done. Online use for disconnected settings where there s low or no internet, on different kinds of devices from cards to feature phones are needed for improving accessibility. A pilot project with a graduated rollout, ease of feedback, rapid upgrades and releases should be part of Phase II planning.

A Digital Dollar can succeed only if the lawmakers got off the fence and endorsed the move to legal certainty and the affirmation of a CBDC project. The current state of division and tension in the various branches of government and the country at large does not augur well for such an outcome.