This week MIT’s Digital Currency Initiative (MIT DCI) released the source code of research into smart contracts for central bank digital currency (CBDC) – PArSEC (Parallelized Architecture for Scalably Executing smart Contracts). Given the solution is designed for central banks, it is a centralized offering and sidesteps using blockchain, although it supports Ethereum smart contracts.
The work is part of Project Hamilton, an initiative in conjunction with the Boston Federal Reserve and the source code is released under the umbrella of openCBDC.
It claims to have sufficient scale for most potential central bank applications, although it is very much a research project rather than pilot or production ready.
Supported use cases
The aim of the research was to explore more advanced use cases for CBDC beyond payments. This might include automated market makers (AMM) that can enable FX transactions 24/7 for cross border payments. BIS Project Mariana is exploring AMMs. MIT mentions the potential for trading bonds, tokenized securities and repurchase agreements (repos) using AMMs.
Another potential use case is to support cross border interoperability. It’s possible to run separate virtual machines so that central banks and private companies can operate in separate underlying systems. This is not dissimilar to the BIS concept of the Unified Ledger.
PArSEC achieves scalability
MIT claims PArSEC supports a peak throughput of 118,000 transactions per second (TPS) for Ethereum-style ERC-20 transactions with an average transaction time of less than 1.6 seconds. To put that in context, a permissioned Ethereum blockchain processes around 400 TPS.
Scalability achieved partly by running operations in parallel and using a database rather than a blockchain.
We had some questions on the topic of scalability. Conceptually with a token based on an ERC-20 smart contract, that smart contract knows every token holder. Imagine a large country such as India where most of the population have CBDC. We wondered about the scalability of a smart contract with hundreds of millions or billions of account holders, even if it’s using a database.
The PArSEC project also made some important assumptions. For example, the paper assumes “correct smart contract execution does not require execution of smart contracts in a linear order; state must simply reflect an ordered execution, and contracts should not interfere with each other.”
In the real world explicit ordering can be important, particularly for trading securities or FX, where people compete for the optimal price.
UTXO versus account based
The other research modules of Project Hamilton adopted variations of Bitcoin’s UTXO model partly for efficiency and also in order to preserve privacy. In contrast PArSEC uses an account-based approach for smart contracts.
UTXO works similarly to cash – when you hand over a note you get some change, and the coins you receive don’t particularly link you to all your other transactions. This contrasts with an account approach – if you know the identity of someone’s account, you might be able to see all their transactions, so a central bank could take a look.
Reading this paper, one could mistakenly arrive at the conclusion that you cannot have smart contracts using UTXO. In fact R3’s Corda enterprise blockchain uses UTXO and so does DAML’s Canton and both have smart contracts. On the other hand, if you want to support Ethereum smart contracts without altering them, an account-based approach is necessary.
