Project Hamilton by the Boston Fed: A Summary

Introduction

Project Hamilton is a joint venture between the Federal Reserve Bank of Boston and the Massachusetts Institute of Technology’s Digital Currency Initiative.  It is a multi-year research project aimed at gaining a hands-on understanding of CBDC design.  Hamilton is in phase one, researching a transaction processing system flexible enough to support experimentation with multiple CBDC models. In a white paper, “A High Performance Payment Processing System Designed for Central Bank Digital Currencies,” the Project Hamilton developers describe their efforts and results.  Here is my summary of the Hamilton Project whitepaper.

Privacy of payments

First of all, I was struck by how much thought is being put into creating private or anonymous transactions. Here’s what I have gleaned so far.

First, they are decoupling “transaction validation from fund existence checks; only a validating layer needs to see the details of a transaction.” Funds are stored as “opaque 32 byte hashes inside an Unspent funds Hash Set.” This UHS, it is argued, will allow for future privacy-preserving designs that will be explored in Phase 2 of the project. They are also following the UTXO model to allow for “scalable privacy designs.” (Bitcoin comes up a lot in this paper.)

A key to Hamilton’s privacy design is the use of “sentinels” for local validation of transactions. These sentinels receive transactions from users and validate that each transaction is correctly formatted, has valid signatures, and that the balance is preserved (outputs equal inputs). For the sake of privacy, the sentinels could then “strip witness data and only forward the transaction’s inputs and outputs for processing.”  

Further, the developers state that the transaction processor does not need to store account balances and information, but the sentinels need to see them to validate a transaction. “We anticipate being able to remove this requirement using cryptographic privacy-preserving design” in Phase 2.

This will result in rather anonymous transactions. However, the devil is in user access to the platform. What KYC will be needed to get into this game?

Transaction execution and design

The Project Hamilton CBDC system has two potential designs: the Atomizer and the Two-Phase Commit (2PC).  Here is a summary of how the Atomizer transaction is executed.  The different components are in CAPS. 

A transaction is submitted by a wallet to a SENTINEL (a local platform component) that validates the transaction and reports back to the wallet of pending status.  The SENTINEL then verifies and compacts the transaction, stripping it of identifying data, and forwards it to SHARDS that hold unspent outputs.

The SHARDS then check that the input UHS (Unspent funds Hash Set) IDs are actually unspent.  If so, the SHARDS send the transaction to the ATOMIZER along with their current block height and the UHS IDs.

The ATOMIZER collects the data from the SHARDS and “appends the compact transaction to its current block.” Once the block is made, the ATOMIZER broadcasts this to the SHARDS, which update their current block height and set of UHS IDs.  Also informed is the ARCHIVER, which retains a record of all the blocks created.

The ATOMIZER also sends this information to the WATCHTOWER.  The WATCHTOWER “updates its cache of UHS IDs to indicate which have been spent and created recently.” It also informs the wallet that the transaction was successfully completed.

Here is how a transaction is conducted in the other Project Hamilton design, Two-Phase Commit (2PC).  The 2PC consists of transaction coordinators and shards.  Each SHARD holds the unspent UHS (Unspent funds Hash Set) IDs. (Again, the different components are in CAPS.)

Briefly, this is how a transaction occurs in the 2PC.  A Wallet sends a valid transaction to a SENTINEL, which compacts the transaction, stripping it of identifying data, and forwards it to the coordinator.  The coordinator then “splits input and output UHS IDs to be relevant for each SHARD and issues a ‘prepare’ with each UHS ID subset.” 

In response, each SHARD “locks the relevant input IDs and reserves output IDs” and reports this back to the coordinator after recording the transaction data.  After this, the coordinator issues a ’commit’ to each SHARD, which finalizes the transaction.  The SHARDS do this by atomically deleting the input IDs, creating the output IDs, and updating the local transaction state.  The SHARD then tells the coordinator that the ‘commit’ was successful.

The coordinator issues a ‘discard’ to each SHARD to forget now irrelevant data as the transaction is now complete and reports to the SENTINEL that the transaction was successful.  The SENTINEL then responds to the WALLET that the transaction was executed.

It is very difficult to accurately summarize the authors’ comparison of the Atomizer and 2PC designs.  A very rudimentary summary is that the 2PC model is more scalable with higher throughput than the Atomizer.  But, the 2PC model may present a greater “attack surface” for exploiting bugs as it scales up, and it may have greater trouble recovering from a crash or power failure.

Conclusion 

In concluding my review of the Project Hamilton CBDC white paper, I want to summarize the seven key results of the project as identified by the authors, which are enlightening:

• “CBDC design choices are more granular than commonly assumed.”  The existing design models are too limiting.  CBDC developers need to move beyond token-based or account-based designs and even beyond blockchain.  Desired features need to dictate design, not vice versa.
• “CBDCs can adopt a wide variety of design characteristics depending on public policy objectives and system performance demands.” Technical researchers can provide a lot of options to policymakers in CBDC design.  But, policymakers need to establish “clear policy objectives” to guide design.
• “Techniques from cryptography, distributed systems and blockchain technology can be combined to provide unique functionality and robust performance.” Designers need to break out of mindsets that limit them to just one approach to developing a CBDC design.
• “Using a Byzantine fault tolerant (BFT) single state machine approach might cater for an unnecessarily strong threat model if the central bank directly operates the CBDC.” A central bank directly running its CBDC does not need a BFT design as the threat from malicious nodes is almost non-existent. If it is not, then a distributed BFT-based approach is a better solution.
• “Executing all transactions via a single-threaded state machine, whether generating a blockchain-like data structure or not, prevents horizontal scaling the maximum throughput of the system by adding more nodes.”  A total ordering of all transactions (which means vertical scaling), if required, will run up against bandwidth and processor speed limitations.
• “It is challenging to implement a non-interactive payment protocol while maintaining user-to-user privacy.”  If two parties in a transaction cannot speak to each other to verify settlement to maintain privacy, then transactions need to be visible to all parties so that parties can independently verify settlement.  This situation is not acceptable for a privacy-focused CBDC, making for complex design.

“The central bank does not need to retain all transaction information to implement a secure CBDC system.” It is appealing for privacy concerns that the central bank does not have to retain full transaction data (storing only unspent funds as opaque 32 byte hashes), but it makes self-custody more challenging for users.

This article was prepared by the author. The views expressed in this article are the author’s own and do not necessarily reflect the views of the Digital Euro Association.