by Ratko Veprek
July 7, 2020
In our previous articles on this series on “Central Bank Digital Currencies”, Darko has written about the benefits and difficulties of CBDC, and Richard introduced how such a currency would look like in Daml. In this article, I want to add a few thoughts on the technological properties a sound CBDC solution should provide.
There is one question: on what kind of platform should CBDC run? Naturally, it makes sense to use a sufficiently standardized approach, and here, Daml fits perfectly. First, Daml is a smart contract language that can run on many systems. Second, because we designed Daml to model complex rights and obligations, it naturally allows us to express concepts such as CBDC. From an anecdotal point, we created Daml by using a physical British pound note as a design inspiration. We picked the British pound specifically because the original legal promise of the Bank of England is still printed on every note (I promise to pay the bearer on demand the sum). Instead of revolutionizing how legal papers work, we thought it is smarter to work off existing legal concepts and revolutionize their form.
Moreover, the key to capturing the benefits of CBDC is to make the usage and the integration of CBDC in day to day business convenient and safe. But how should one do that as the integration of applications in distributed setups with different companies remains a very cumbersome process? Such systems need to provide atomic transactions, such that a change across multiple systems is either applied entirely or not at all. Otherwise, you quickly end up with consistency problems, such as canceling some invoices without having received the money.
Even more, especially when dealing with financial data, privacy and security are an absolute must. Few companies are willing to share their inventories and cash balance sheets openly with everybody. Because of that, most systems end up with expensive, tightly locked down systems we often refer to as silos. The result is that cross-system synchronization requires significant efforts to build and continuously reconcile. Therefore, just creating a CBDC system is not going to be enough. We need to ensure that it becomes attractive, convenient to use, and able to integrate safely.
What is required is what we refer to as application composability: the ability to individually extend the entire system with own workflows without requiring any additional collaboration or approval from a central operator. It should be possible for a supply chain, an insurance consortium, or an exchange to use CBDC money for atomic settlement without the central bank being aware in what context the money is being transferred. The Central Bank shouldn’t even be able to discern who all the other participating parties are except the ones directly involved in the money transfer. And other participants to the system shouldn’t even learn that there was some transaction.
How should that work? A central bank will not let other people deploy their applications within the central bank system, nor does a central bank ever intend to run unvetted software or software that is not directly tied to the service the central bank offers.
Here, we need to introduce another concept on which we based Daml. We built Daml to express rights & obligations digitally. Therefore, we can create a tree structure of a transaction and involve the parties only on a need to know basis. This concept is called sub-transaction privacy, where parties are only informed about the parts of the transaction they are entitled to see. To the best of our knowledge, this is a concept currently only available in Daml. Other contract languages treat smart contracts as blobs, which are either publicly known to all participants of the system or the transaction, but only Daml does a fine-grained decomposition.
However, Daml is just a language. One key question a CBDC solution needs to address is on which platforms a central bank should offer such a service. The above reasoning tells us that such a ledger should provide the composability and sub-transaction privacy that Daml expresses to make the offering attractive enough for widespread adoption.
Figuring out what is the best platform for CBDC is not easy given today’s existing solutions. Many choices lack horizontal scalability and, therefore, would add an upper limit to the number of theoretically possible transactions. Many ledgers have poor trust properties and can not deal with malicious participants. Thus, to provide security, systems are operated as strongly permissioned systems with operators being cautious about who to allow to participate. This approach locks down the system, making it available only to an exclusive club of strongly vetted and privileged users.
Even more, if a central bank selects a particular digital ledger, users of other digital ledgers will be excluded from the benefits, creating yet another silo that is hard to integrate. The only way around this is to build such a CBCD system on top of an interoperability protocol that allows us to bridge the gap between different technologies, and still provides all the above properties.
For us, one thing is clear: to be interoperable, systems need to speak a compatible language, where we think that Daml is just the right tool. And we need a protocol that allows us to connect all Daml ledgers. We at Digital Asset are working hard towards this vision, which we are trying to fulfill with our next generation of Daml ledger integrations, based on our new Daml ledger interoperability protocol. We named this protocol Canton (if you are interested in the origin of that name: the federation of independent Cantons forms the Helvetic federation, more formally known as “Switzerland”).
Canton ticks all the boxes established above. It is a Daml-based protocol for interoperability between existing ledger technologies (databases, permissioned or open blockchains, hardware enclaves, etc.). While Daml provides the capability to write your distributed application independent of the platform you want to run it on, Canton extends that capability such that you can run your Daml workflows across multiple platforms and make them interoperate, even when the original platform authors didn’t add this capability.
If you are interested in learning about Canton, please look at a short explanation named “Elements of Canton”, and consult the Canton documentation. And you should definitely check out daml.com to convince yourself about how easy writing distributed applications becomes with Daml. Daml has also a new learn section where you can begin to code online:
