search

mit-dci / opencbdc-tx

A transaction processor for a hypothetical, general-purpose, central bank digital currency
Other
901 stars 199 forks source link

Adding Smart Contract Support #83

Open davebryson opened 2 years ago

davebryson commented 2 years ago

Question

What amount of smart contract support is possible with the UTXO model and CBDC architecture?

Benefit

A CBDC with smart contract support could be useful to both policy makers and end users:

Practically speaking, while this all sounds valuable, it’s important to find the right balance between the desired smart contract feature set and the impact it could have on the overall architecture.

Proposed Solution

The UTXO approach has many valuable features: scalable, simpler, and deterministic. Many of these benefits come from the fact that it doesn’t require transactions to operate on global state.  But the lack of state can make it challenging to provide smart contract support beyond the simple script support in Bitcoin.   Potential research:

  1. Investigate cryptocurrency approaches and how they may be used in a CBDC. For example, platforms such as Cardano, Bitcoin Cash, and Ergo are evolving smart contract support for the UTXO model via efforts such as extended UTXO (eUTXO) and multi-stage UTXO. 
  2. Explore the use of Web Assembly as a CBDC smart contract environment. Blockchain platforms such a Near, Substrate/Polkdadot, and CosmWasm use Web Assembly (WASM) as a smart contract runtime environment.  Wasm is an open standard for a portable binary and runtime with the goals of being safe and deterministic

Possible Difficulties

Adding smart contract support will affect (at a minimum) the transaction format and transaction processor.  This could impact performance as well as further complicate a privacy solution. 

Prior Work

Code of Conduct

HalosGhost commented 2 years ago

@davebryson thank you for opening this proposal! I think a lot of people are interested in determining the limits of what can be achieved on top of the UTXO model. One thing that comes to mind for me was discreet log contracts; have you taken a look at them yet?

I'm also interested in your offering of WASM for a runtime environment; why do you think it would be a better language/environment than one of the others already in wide-use (or indeed something totally different)?

davebryson commented 2 years ago

@HalosGhost I missed discreet log contracts - but I'll dig in! I don't want to try to argue why I think it'd be better (yet), but I'll offer some reasons why I think it's worth exploring.

HalosGhost commented 2 years ago

Sounds good! As for WASM, I should have clarified that I wasn't asking you to defend your choice, but only to understand the motivation. The examples you listed are quite compelling for it to be a candidate.

I particularly find the “choose your favorite language to author contracts in” point to be motivating.

pkyriakis commented 2 years ago

I wanted to start working on this, as it seems very exciting. I just have a doubt about the purpose of adding smart contracts in a centralized currency. Since this would be run by a single, trusted authority, any programmability logic could be external, not necessarily part of the transaction processor, right? In the current system, if users need to pay taxes or set up recurring payments, that could be taken care of by the website/app interface of the tax agency or business that requires recurring payments. Putting that logic in the transactions would increase the load in the processor and perhaps limit the programmability that the service providers can do. However, being able to automate policy is a truly important benefit, e.g., for example, the central bank can restrict the usage of stimulus funds to investment rather than consumption.

Maybe the terminology should be changed from "smart contracts" to "programmable money". Smart contracts are almost exclusively associated with decentralized applications.

HalosGhost commented 2 years ago

@pkyriakis, you raise several great points.

First off, I don't think it is a settled issue whether or not programmability (in some form) is a good idea for a CBDC—that is, at least in part, relevant to the given jurisdiction. What's more, the level of programmability to-be-supported is also an open question. To your point, layer-2 can probably handle a huge portion of the basics that people would expect (e.g., recurring payments), at least in some form—I'd be happy to talk at more length about this, but programmability at layer 1 might be able to offer different protections and guarantees than at layer 2. But if the ledger (in whatever form it takes) is not public, then a lot of the use-cases being explored in the cryptocurrency space are potentially impossible at higher layers.

As for the terminology, I suspect Dave used the term “smart contract” purely because it's the norm in the digital currency space. I'm not certain there is a “right” term, but I definitely think the terminology is evolving generally.

pkyriakis commented 2 years ago

@HalosGhost I am sure there is a lot of value in programmability, but honestly I do not think that such a radical technology will be adopted by any central bank. Nonetheless, it's definitely interesting to implement it.

@davebryson Is there a strong reason to require deterministic execution? As far as I understand, in the decentralized setting deterministic execution is needed in ensure consensus, which is not an issue in CBDC. I think that CBDC would benefit from non-deterministic smart contracts.

On the technical side, I started looking into WASM which I think is a good choice for the run time. The NEAR blockchain, among other, are using it along with Rust for writing contracts/.

Is anyone else working on programmability and wants to collaborate?

HalosGhost commented 2 years ago

cf. #164