The Two-Phase Commit Design in Project Hamilton CBDC

The Project Hamilton CBDC system has two potential designs: the Atomizer and the Two-Phase Commit (2PC). I summarized the Atomizer in a previous post. This post is on the 2PC, which consists of transaction COORDINATORS and SHARDS. Each SHARD holds the unspent UHS (Unspent funds Hash Set) IDs. (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.