Project Hamilton is a high-performance payment processing system designed for Central Bank Digital Currencies. The highly anticipated technical paper is not complete and it is a toy. It is a proof of concepts, not a complete system. It is, however, a toy for grownups. The paper and accompanying code demonstrate the technical feasibility and usability of a system that solves payments at a scale comparable to the United States and the US Dollar, a widely-used global currency. The system can handle more that one hundred thousand transactions per second. Each transaction must be completed in less than five seconds. The Hamilton team came up with the number based on the observed payment rates for credit cards and other payment systems. There is also a provision for future expansion. Hamilton’s second challenge is to be cash-like without physical cash. This allows users to pay others with CBDC, without the need for intermediaries such as banks or credit card companies. Users can also pay other people using CBDC with privacy and security. The payment transaction must be stored on multiple computers in an all-or-nothing fashion to ensure system resilience and broad usability. Atomicity is a property that proves the payment has been made. It can be updated in all locations, or not in any one. Another challenge is to create a flexible system that can apply policies that are not yet decided.

Privacy is considered to be one the most important properties in 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)The bitcoin paper outlines the following. This privacy-focused transaction model, is called the Unspent funds Hash Set (UHS). It is difficult to understand the UTXO model because accounts are what we are accustomed to. Only the UHS can be stored in the core. The system must also be resilient and resistant against malicious attackers as well as bugs. Some of these issues are addressed, while others are deferred for Phase II. Two architectures were used for testing the system. One architecture orders the payments, while the other does not. The first is a fast blockchain, called the atomizer model. The second is a 2 stage commit model without rollbacks, called 2PC. The 2phase commit is a well-known model in distributed databases. The entire system was made available by the Hamilton team through github.

I am a coder and forked the source. I have been trying to glean the code in an Integrated Development Environment (IDE) on my laptop. This is where I am writing this article. It is written in C++. This language is almost like my mother tongue. However, Hamilton code uses C++17 which is a slightly older dialect than I am used too. It is important to get used to the coding style. As with any complex system, not having access to the code is enough. It takes time to understand the logic and architecture. Hamilton Phase II invites all to participate, even the combative.

This article was difficult to write because technical details had to be presented in an organized manner without losing any of the nuances. The main thrust of this article is what the project means for the story about money in the United States and around the world, especially to generalists. Sometimes technical information has overpowered the telling of this story. You are welcome to comment on the presentation via social media. This will allow the text to be modified to make it more accessible for the general public.

The Two Hamiltons
Although this section may seem to be a distraction from the main theme of the article, you will see its relevance. Hamilton’s name is meant to invoke Alexander Hamilton, the first Treasury secretary, who in 1790 wrote a fifteen-thousand-word report to encourage the founding of the First National Bank (FNB), a similar to the Federal Reserve. He argued for paper currency that was backed by FNB, which would unleash the economy’s power by encouraging private enterprise. The First National Bank would function as an independent Central Bank with large private participation. Hamilton saw the benefits of separating paper currency from specie (gold coins or silver bars), backing it by a true private/public partnership, and allowing decentralization to allow capital and credit for business to be invested more frictionlessly through local decision-making by individuals. Hamilton’s genius was in imagining dead stock (specie) fluttering alive through its transmutation into paper currency. Hamilton faced a confederacy against him, as with all geniuses. Hamilton overcame this opposition in 1790 by publishing his seminal paper. However, the charter for National Bank did not survive Hamilton’s untimely demise seven years before it was up for renewal in 1811.
It is not known what the economic potential for America in the nineteenth-century, if Hamilton had lived longer. In real history, the nation was engulfed in a fratricidal war, its aftermath and its leadup, and a century was lost in unproductive internal conflict and economic malaise, awash in bad money; its echoes echo today. This cycle of booms, busts, panics, and rushes continued until 1913 when the Hamiltonian plan was implemented and the Federal Reserve was established. This launched a century of economic growth, American supremacy, and a century of rapid expansion. The Hamiltonian idea of untethering currency led to the end of the gold standard. We now find ourselves in the moment, where opposition to a CBDC issued to the Fed is still rampant by those who prefer a private solution (e.g., stablecoins) to a digital dollar. Hamilton is the right name for a currency poised to enter the digital realm. However certain interests are holding back this currency. This contest and the features that emergent money will determine whether America’s economy will be stable, flexible, and safe for all citizens. Or rigid, unstable, and insecure.

Jim S. Cunha, animator for the Hamilton project, made it clear that Hamilton was also meant as a reference to Margaret Hamilton. She was approximately the same age in 1776 as Alexander Hamilton and made ground-shifting contributions to Software Engineering, which she helped to coin. Margaret Hamilton was recruited by MIT to the Apollo program. She was the software director of the Apollo Command Module, Eagle, which was the first portable computer that traveled a long distance to land at the moon. Hamilton was the inventor of fail-safe computing, an autonomous system that was able to overcome seemingly failing hardware and deliver the Lunar Landing at the crucial moment. Without Margaret Hamilton the Eagle may not have reached the moon that day. Project Hamilton relies on her as the patron saint (even if she is no longer alive), in order to achieve a CBDC moon shot.

Two messages are here. One is the development of the Apollo Programs, which included those that went from Low Earth Orbit (Apollo 1) to orbiting the Moon (Apollo 8), and then to landing safely on the Moon and returning safely to Earth, all crewed missions. Apollo was the successor to Mercury, Explorer and Gemini programs. The USA is not even at the level of the Explorers in CBDCs. China launched its own Sputnik via e-CNY. Pilot programs that rippling from MIT’s college campuses, or even multiple foci, must address the growth of knowledge and confidence that comes with real CBDCs. No amount of sandbox testing can match the experiences gained from the wild. CBDCs in a country such as the US should not arrive with a bang.

The second message is about failsafe computing and self healing systems. Margaret Hamilton’s obsession about the what if scenarios that seem unlikely, saved the mission when they improbably happened. One third to one quarter of any code today must be about error handling or recovery. It is important to account for the complex properties of a complex CBDC system. 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. Avionics design patterns are also important in high-risk solutions like the Digital Dollar. They help to prevent a low-probability but highly risky outcome.
I created a graphic to incorporate Margaret Hamilton into their announcement.
A Digital Dollar for the People
The Central Bank is the Counterparty Of Last ResortThe Fed is the only bank that can take care of all your financial needs. A CBDC is the only digital currency available from the Central Bank. This instrument is the most risk-free. Economists are the ones who have suggested most of the CBDC design concepts. They enshrine intermediaries to be the distribution vectors or custodians. Since their main fear of credit destruction is the disintermediation, most Dollars Euros Pounds Renminbi Rupees and Yuen are generated by commercial banks lending to private individuals and companies. The economists are familiarized with cash, so they propose a similar distribution scheme for CBDCs. Economists can also choose to design these systems using an account or 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”. It would be beneficial if economists collaborated more closely with technologists before they offered technical designs to the public.
Project Hamilton illustrates how technical design can cross these seemingly binary options to offer new capabilities. The Hamilton design shows an instrument that can be used as both an account-based and token-based instrument. Dual view: An asset that is modeled with UHS (a la bitcoin) does not make it a token-based system. The paper explains that this is dependent on who is looking. A system that appears opaque from the core system’s vantage point can be made account-based in their digital wallets. It is not tokens or accounts, it’s tokens AND accounts.
The technical design choices include creating a modular infrastructure for public administration that can be expanded to implement regulatory, policy and legal directives. The foundation for building capabilities is a solid base. The Phase I Hamilton project aims to create a foundation for such an endeavor. This whitepaper suggests that there are many opportunities for private intermediaries in this design. It is possible to build on top public substrates.
The technical whitepaper explains the transaction model in both atomizer (or blockchain), and 2PC (a distributed data base) models. The transaction model is the data model for a payment. It is how a payment goes from one user to another and transforms into an UHS. It does this by passing through the validating layer, stripped of personal data, and ending up in replicated storage that serves as proof of payment. The transaction model is the foundation of everything. It determines the transaction flow, scale, speed of finality, and the core models. Users have digital wallets that keep their means of proving they are authorized to spend the CBDC. They also provide a way to check how much CBDC they have. This wallet interacts directly with the transaction validation layers. It consists of two layers. The sentinel verifies transaction inputs, and forwards the validated transaction to the core layer. The transaction validation layer can be separated from the core store layer. This pre-validation feature is a feature of Hyperledger Fabric, a popular enterprise blockchain that also uses UTXO as its core. The transaction validation layer compresses the payment transaction so that only the proof of the payments are deposited in the central system. However, most data, including amounts and numbers, does not end up in this system. These are the layers: The wallet, the transaction validation and the core system. The transaction processing layer is made up of the core system and the transaction validation layer.
The design could lead to a self custody digital wallet, which is one option. This is the ultimate in privacy control and control. All operations, including the creation of new money and transfer of funds, rely on the public/private key pair. The private keys are only kept at the edges of the wallets. The public key is the only form of identity. The choice can lead to multisig (where multiple signatures will be required to spend) capabilities, and hierarchical determinaistic (a way of creating multiple keys) wallets. This is another way to manage keys.
This expansion of capabilities looks like the fusion of Layer-2 architectures into a solution right from the start. This project has made two important contributions: privacy and the possibility to create self-custody wallets. This empowers people: the payers, payees, and users of this system. Although the system is more private than Bitcoin, it allows users to have their own custody wallets.
The key architectural choices made in this area and in the construction the transaction flow have left many questions unanswered. Among them is how data not contained in the core system can still be accessed without compromising privacy. This could be necessary to collect economic statistics such as the velocity of money and recover a wallet that was lost. 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. These options can be solved by embedding privacy-preserving architecture into the core infrastructure, as well as the wallets. These include homomorphic encryption protocols or zero-knowledgeproofs. These are worthy goals to be achieved in Phase II.
Blockchain or not to Blockchain
The Executive Summary and the technical report make a lot of statements.  These lines concern the suitability for a blockchain architecture to be used in a system managed by one entity, the Federal Reserve. This is interpreted as a rejection of the blockchain philosophy for CBDCs. These statements are not about the suitability for such a mechanism to manage a single entity’s system, but rather about how complex and expensive it is to coordinate in a blockchain. The majority of blockchain-based consensus algorithms that ensure all copies (or replicas in distributed systems parlance) are atomically identical slow down replication. Hamilton uses Raft as a distributed systems practice classic algorithm. This algorithm is one of the options for Hyperledger Fabric. These algorithms are called Byzantine Fault Tolerance or BFT because they allow for the presence of malicious or imperfect participants in the inner circle. They are used to generate trust from a group of untrustworthy participants. It is based upon the classic distributed systems problem, the Byzantine Generals Problem. In Phase II, a BFT algorithm will also be available.
The most basic interpretation of a blockchain is that of a data structure, a chain of blocks, as Satoshi’s bitcoin paper says, the paper never mentions the word blockchain. A block is made up of a series of transactions. A chain, on the other hand, refers to a sequential order of blocks. Once the chain has been created, it should not be broken. However, new blocks are constantly added to strengthen the chain. Project Hamilton has a lot of ideas related to payment transactions. The UHS, and the idea of cryptographic custody or transfers. Protection against replay attacks and double spending is the outcome. The UHS model uses microledgers to create transactions. Each transaction contains references to the transactions that precede it. The same theme is apparent: the design creates an transaction model that is a block chain, not a 2PC blockchain.
The three basic operations in a transaction model that allows for a payment system to function are mint, redeem, and transfer. These operations are responsible for controlling the money supply and allowing the money to be used for payments. The money supply can change, and money can be spent by transferring money from one wallet to the next. Double your spend If the same money is used twice, 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. Due to the sensitive nature of these functions, basic operations such as redemption and minting have not been properly modelled. Maybe in Phase II.
Hamilton Phase II
As the story unfolds it becomes clear that many of the features required for a functioning CBDC are missing in Phase I. Many of these features are difficult to model and implement. It is possible that some cannot be implemented without changing Phase I’s basic design and feature constructions, such as Privacy Safety, Auditability, Auditability, and the Transaction Model. It is common and necessary to kick the can down the road in academic settings and papers. However, it is a bug as well as a feature of open inquiry. CBDC has found no other solution. The source code is available for inspection and, most importantly, for anyone to build upon. This has been done by Bitcoin, Ethereum, and many other public blockchains. These are not CBDCs. Hyperledger is one of the enterprise Blockchains. It houses many variants, including Fabric, which is a widely utilized Enterprise blockchain. There are some CBDC projects in production. Hyperledger is a large tent that also includes Besu (an Ethereum implementation) which is a widely used public Blockchain.
Phase II promises to tackle

Privacy and auditability
Offline payments
Minting and redemption
Attacks on the service denial
Quantum resistance

It is a mix of features and capabilities at different scales, from different disciplines. Some features can be considered very basic and without them no CBDC can function (Minting or redemption, for example). A fully functioning CBDC requires all of these, except quantum resistance. Some of these are missing: upgradeability and a fully functioning digital wallet. Security and monitoring are also missing.

The entire source code of Project Hamilton Phase I has been released by the MIT team into open source. It contains all the code required to run and interact on the two core architectures.
In addition to being open-source, the code relies upon a number open-source components and libraries. These include the llvm clang compiler and tools as well as LevelDB from Google, NuRaft and Paypal, and cryptography components taken from Bitcoin. The test setup was performed on AWS servers that use AWS internal networks. These AWS components cannot be open-sourced. It should be possible to run it on any Linux system or Unix system because Unix sockets can be used in communication.
Project Hamilton’s most important decision was to open-source the CBDC project. Many companies, large and small alike, use open-source software (oss). Although 98% of enterprises use open-source software, only a few contribute to it. This is the free-rider issue of OSS. The example of opencbdc.tx shows that the project couldn’t have been completed as quickly without OSS. Statistics favor OSS. There are only.19 bugs per 1000 lines of OSS, compared to 20-30 for every 1000 lines of proprietary off-the-shelf software. OSS is faster to fix and easier to coordinate.
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”. It remains to be seen how long this purity can be maintained in the face of the auditability that will enter the picture in Phase 2. 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. Project Hamilton Phase I has not prioritized investment in user interface design or improvements in usability. This important element cannot be ignored in Phase II. The design of the digital wallet’s front and back ends on a mobile device is essential for widespread adoption. This is not an easy task. Online access is required for disconnected settings with low or no internet. It can be used on various devices, including cards and feature phones. Phase II planning should include a pilot program with a graduated rollout and easy feedback, rapid updates, and releases.
The Digital Dollar will only succeed if the legislators get off the fence, and endorse the move to legal certainty as well as the affirmation of a CBDC-project. This is not possible with the current state and tension within the various branches and country.

Source link