Solving CBDC’s privacy problem
If you were designing a CBDC you might want to create a cash-like experience for users. This is just one design decision, but it’s surprisingly tricky. There are two features in particular that define the user experience with cash: it’s anonymous and it’s authenticable. Creating a token that incorporates one of these features is straightforward. Creating a token with both features together, however, poses an interesting—though solvable—challenge for blockchains that use the UTXO model.
The challenge is that if you want to spend your CBDC, the merchant wants to verify that it actually came from a central bank. To do this, they’d need to be able to trace the history of that token back to its origins. But validating the history of the token by walking back through all past transactions (called the backchain) reveals some data about how it was spent, which is not cash-like at all.
Fortunately there are a number of different solutions that fall into two categories: reissuance and sealing. We describe them below and consider how they would work in a future state where CBDC is a commonly-used unit of exchange.
1. The challenge of longevity
If CBDC is going to be a digital form of money, we might expect that it will, like cash, change hands many times over its lifecycle. But unlike a $10 banknote which is expected to be in circulation only about 5 years before it is replaced, a CBDC could be traded around forever.
This longevity means that each CBDC could have a backchain of transactions that would grow arbitrarily long. Long backchains create an opportunity for rogue actors. Such actors might examine the behavior of public keys for a particular token. Over time, there might be sufficient data on a single public key to build up a pattern of behavior and identify spending habits.
On its own, the data held in the backchain reveals little. It consists of data about the public keys that have previously held the token since its issuance and whether all previous transfers of the token were valid. An important detail to keep in mind—this is not personally identifiable information (PII). Public key data is abstracted from a real person’s PII. This is why Bitcoin is referred to as pseudonymous rather than anonymous. There is no GDPR-violating PII in your backchain, but there is a way to track a specific public key over time.
Fortunately, this problem is well understood and has solutions. Four in fact. The table below illustrates them. We’ll go through each in turn to highlight how they address the potential problems inherent in long backchains.
Table 1: Evaluation of 4 backchain workarounds
Source: Authors’ assessment
2. Type 1 solution: Reissuance
Reissuance is the standard solution-type used today. Reissuance solutions limit the length of the backchain by burning and re-minting the original token. Reissuance mechanically solves the problem, and also allows the designer to decide how long the backchain should be. The two primary drawbacks include latency during token reissuance and the fact that the issuer maintains the data associated with the issuances.
There are two ways that reissuance can be built into a token’s lifecycle which we detail below.
Direct involvement of the issuer
The Fed’s Project Hamilton uses the most direct fix to backchain length, which is to have no backchain at all. This is accomplished by involving the original issuer in every transaction. In this case, there are never any prior transactions to verify. In a direct issuance model, the issuer is responsible for verifying that the token is real, destroying the spent token and issuing a new unspent token to the recipient, through atomic reissuance.
In a CBDC context, this would mean that the central bank would be involved in every CBDC transaction. This is already the case at the time of original issuance. The new holder receives a fresh CBDC directly from the Fed and therefore knows that it’s real. In a direct issuance model, all subsequent transactions would require the recipients to authenticate the Fed as the issuer.
This design choice is unusual in CBDC since it requires the issuer to be available and highly active 24/7/365. It also needs users to be comfortable with the issuer having involvement in every transaction. Examples of direct issuer involvement is how regular payments work today. When you pay with a credit card, Visa or MasterCard is involved in that transaction.
Chain snipping (plus key rotation)
A second reissuance-type solution is to limit the lifespan of the token. Chain snipping is the most popular privacy-boosting method in place as it solves the problem of transactions becoming slower as backchains get longer (a notable Bitcoin problem). It is in fact called out specifically in the original Corda whitepaper.
Chain snipping keeps the backchain length short by imposing a limit on the number of transactions a token can undertake. This limit could be based on time or frequency (e.g. every 24 hours, or every five transfers). Once the limit is reached, the token is recalled by the issuer, and it is burned and reissued. Upon reissuance the token is fresh and contains no backchain data, other than proof of issuance.
For a CBDC, this would mean that the token would reveal only pre-set data fields in the examination. Since this data wouldn’t be PII, its examination would not reveal sensitive data. Rather, examination would provide the issuer with a snapshot of what money lay where and with whom—something that it can’t do at the moment with cash and could support monetary policy analysis.
If we combine chain snipping with regularly changing the public key of the holder, we add an additional source of security. Key rotation is a common method of system resilience even outside of blockchain. It works by regularly changing the public key assigned to the real individual. This rotation ends any connection between the past activity of a user with their future activity and is configurable in how often the rotations take place.
Used together, these mechanisms would mean each CBDC would collect only a fixed number of transactions, and will likely record multiple identities for any single holder that uses the CBDC more than once. As a solution to privacy from other users it is robust, but does require a level of trust in the issuer of the CBDC as they require key information in order to perform the reissuance to the new holder.
3. Type 2 solution: Sealing the backchain
The two solutions in this category address privacy in a completely different way. They allow arbitrarily long backchains, but seal them by using secure verification techniques. Zero Knowledge Proofs (ZKPs) do this using software, while secure enclaves provide a similar flow using hardware.
Sealing solutions like these would undertake this technical assurance work of verifying a token’s history without revealing the backchain. For a CBDC this would allow users to have confidence that the token they received is legitimate and also provide considerable protection from private information being revealed, even at the level of the system operator, such as a central bank.
The reason that this category of solutions might be attractive is because the issuer might prefer to keep a long backchain history for analytical purposes (such as AML auditing). It might also be important in the event of some future hack or outage where a history of transactions could help in recovery. Additionally, the issuer does not need to be available for reissuance 24/7. Finally, there is the ability to keep data private from payment networks while also sharing it with regulators or auditors.
Zero Knowledge Proofs
The first solution in the sealing category is Zero-Knowledge Proofs (ZKP). ZKPs are a software-based privacy-enhancing technique that enables a prover (the holder of the CBDC) to convince a verifier (the merchant) that a statement (e.g. the holder has verified the backchain of their token) is true while revealing no information (e.g. backchain data) except that the statement is true.
ZKPs work by creating proofs derived from knowledge of system data, which is never revealed. This is done by turning transaction validity functions into the smallest possible mathematical operations, creating an arithmetic circuit. These proofs can then be verified as authentic by a verifier.
For a CBDC, using a ZKP would mean that the backchain could continue to exist, but the potentially privacy-revealing data could be replaced with a ZKP (hash). This means that when validators go to examine the backchain, they see only proofs of valid transactions.
Despite their relative nascence in the market there are known drawbacks to ZKPs. These include performance (e.g. speed) and limited market testing. Today, ZKP performance is slower than reissuance solutions, though the absolute degree depends on processing power. There are ongoing efforts to address performance speed. For example, there is active research into recursive proofs, which could result in instant verification. ZKPs are also relatively new in the market so additional benefits and drawbacks may become known as time progresses. For now, there are applications in music royalties for example.
There are also non-technical drawbacks to newer solutions like ZKPs. ZKPs cannot be applied to any computational problem directly. The problem first needs to be converted into an algebraic circuit. While most computational problems can be converted into algebraic circuits, doing so requires dedicated, specialized teams.
Secure enclaves
The second type of sealing solution includes hardware-based secure enclaves. Secure enclaves are relatively common today as they are a standard piece of hardware in both Android and Apple mobile wallets. Because of their established place in the market, we have a clearer idea of how a path to CBDC production would look.
In spirit, secure enclaves are similar to ZKPs in that they increase security by intervening in the validation process. Much like with ZKPs, this would provide both the users and system operators of CBDC with the kind of technical assurances that the system would work safely, with the added advantage of having all transaction data only examined in a secure enclave, meaning that none of it can be revealed. In a CBDC solution, this might provide a unique advantage to the offering, with the CBDC providing the privacy-focused solution for digital payments, akin to cash, but on a digital platform.
Two differences mean that they might be deployed slightly differently. The first difference is that secure enclaves are separate from the issuer. This means that every node on the network runs their own secure enclave, in a similar way to how every iPhone runs on its own. This is needed because every participant only trusts their own enclave.
The second difference is that it is a hardware solution. Secure enclaves work by running a validation process on encrypted data to generate a proof that the token is valid. This can be achieved via one of two modes. One mode inspects the token’s entire backchain to make the assessment, and the other builds upon the trusted chain of attestation to only examine the most immediate transaction. In either mode, this work is done within the secure enclave. Secure hardware enclaves therefore provide no method for the revelation of data, either about the identity or activity of previous CBDC holders. This method also provides an additional layer of protection of data in use from inappropriate leaks or hacks—even from those running the physical hardware.
A potential drawback of secure enclaves is latency. The more things that a network is asked to do, the greater the chance that it will take more time to do it. However, another may be the appeal of technical solutions themselves—and more importantly, which entity is staking their trusted reputation on the performance of them. In some nations, the central bank might be highly trusted and well placed, but in others that may not be so, meaning that local market taste might dictate who is capable of providing the assurances that advanced technologies like ZKP and secure enclaves provide.
4. Which solution will win out?
The most appropriate privacy-boosting technique for a CBDC can’t be decided in the abstract. It is only one design decision among a myriad of decisions that will need to be considered. And each country has different risk preferences, regulations and consumer demands.
Given our current state of knowledge, in 2022, we’d expect to see all 4 solutions used in various future CBDC issuances. Today, reissuance solutions are commonly used in token-based operational flows and we expect that to continue. But sealing solutions offer different functionality that may also appeal to central banks as these become more common and standardized.
Today, we’re at the point where the standard implementations already do not store GDPR-type data in transaction histories. This is accomplished by either adopting a hybrid or indirect model of retail CBDC, or, if the central bank prefers a direct model, by implementing prudent measures, such as data abstraction and secure storage of personal data. This is an important start that can only be made even more secure through the use of additional measures such as those described here.
