Simplexity

CBDC系列（1） - OpenCBDC项目

Posted on Edited on
Symbols count in article: 5k Reading time ≈ 17 mins.

基于2022年2月公开发布的OpenCBDC项目（Boston Fed & MIT联合研究项目，也称Hamilton项目）资料：

论文 : A High Performance Payment Processing System Designed for Central Bank Digital Currencies
github仓库 : OpenCBDC

设计目标

当前阶段1属于研究性质，更多是在于探索技术上的可能性，并不是一个即插即用的成熟方案。设计目标着眼于性能以及容错，同时保留足够的灵活性（不限定发行的方式，支持中央银行直接零售发行，也支持类似于数字人民币的批发-零售双层运营模式）。同时，对于其他的课题，例如隐私保护，风控，合规，监管，商业化等也没有深入讨论。（对于隐私保护，论文里提到最安全方式就是从交易源头开始尽可能的少收集数据，这个也在阶段1的设计考虑中。当然，隐私保护与监管风控的目标在一定程度上是对立的。）这些问题会在阶段2里阐述。

设计思想

  1. UTXO模型。用户持有数字钱包，使用私钥签名的方式来消费。
  2. 分层解耦。将交易的合法性验证和资金的存在性验证分离，只有合法性验证才需要交易的细节信息，最小化交易处理核心层的存储（不涉及用户个人信息等）。核心层简单的只做纯粹的资金交易（UTXO的生成和销毁），保证稳定性和性能。货币的扩展功能做在外层。
  3. 基于UHS(Unspent funds Hash Set)和类似比特币交易的数据结构。兼容未来譬如类似地添加锁定脚本等，而无需修改UHS交易核心层的前提下实现扩展功能。

账户模型 VS. UTXO模型

  1. UTXO有更好的执行并行度，账户模型需要锁定账户。OpenCBDC选择UTXO模型。
  2. 账户模型更具易编程性。
  3. Account banlances are more fungible, which is an important property for money.
  4. It might be useful to consider an account balance data model which minimizes the amount of data stored in the transaction processor in the future. 未来可能尝试对比账户模型。
  5. 两种模型都支持账户模型式的用户界面UI。

UTXO数据结构

utxo := (v,P,sn)

  1. v: value，金额。
  2. P(tx, wit): predicate. tx: 消费此UTXO的交易，wit: witness，见证。在支持数字签名的方案里P硬编码pk，并且P校验w包含该pk的签名。在只支持数字签名的方案里，P可以近似等同于pk。
  3. sn: serial number，全局唯一的序列号，用于保证UTXO的唯一性，防止重放双花。our system assigns each UTXO a serial number by deterministically hashing all the corresponding transaction’s inputs, as well as the output UTXO’s encumbrance, value, and its index among all outputs. 铸币的sn选择为均匀分布随机数或者全局单调递增数。
  4. 交易不具有延展性（non-malleable），可参考比特币，防双花。we require signatures to cover all fields of uniquely-encoded transaction and derive UTXO serial numbers from the same fields (plus, output indexes).

交易系统的双层设计思想

  1. transaction-local validation交易合法性验证。主要校验数据结构，输入输出金额相等，签名等。无状态，计算密集型。生成UHS，即cryptographic commitments h := H(v, P, sn)。使用hash值代替交易本身，利用hash碰撞极低概率的特性。
  2. existence validation交易引擎。存储UHS，执行实际的swap操作（UHS的增删，即对应着UTXO的生成销毁）。存储密集型。

设计关键思考：

  • 按需弹性横向扩容。
  • 节省存储空间。交易引擎只存储32字节的hash值。
  • 弹性设计。交易引擎的UHS结构也可以用于账户模型。The UHS makes no assumptions about what hashes represent, and this data structure is not limited to UTXOs; it could be applied to a digital currency with balances or some other application that requires atomically swapping hashes. 账户模型下具体如何对应UHS的增删仍然有待观察，一种方式是账户模型下记账关联UTXO，由合法性验证sentinel来拆分合并UTXO
  • 隐私保护及监管审计。交易引擎功能单一，UHS没有包含交易细节。这部分功能放到sentinel等外围系统，或者是使用隐私计算。例如客户端做本地化验证，提交零知识证明和UHS，而不是原始的交易本身，最大程度的保护隐私。
  • 编程性。并发处理下，UTXO相对账户模型具有一定的优势，账户模式需要锁定账户，UTXO锁定的粒度更小。但是，UTXO要实现复杂的智能合约难度更大，需要在后续智能合约触发使用UTXO时知道状态转移链，以及每个状态的UTXO才能构造交易。而账户模型仅仅需要账户标志。
  • UTXO的获取。UTXO记录在用户本地，交易完成需要通知收发双发。用户丢失UTXO，或者更换设备UTXO转移失败，都需要恢复。但是当前设计下整个系统没有记录UTXO，需要第三方系统协助。

交易模型

  • 交易数据结构


    UTXO的序列号sn := (txid, idx). The first component, txid is the unique transaction identifier: the cryptographic hash of the Mint or Transfer transaction that created this UTXO. This hash covers all input UTXOs, output encumbrances and values. The second component, idx, is the particular output index, i.e., first, second, etc, output of the transaction.

  • 交易引擎的存储及原子性swap处理

用户体验及交互场景

  1. 交互场景收发双方需要协商，发送方需要得到接收方的pk。接收者需要收到output utxo，并且确认这笔transfer交易成功，否则这笔资金有可能无法被使用。The recipient should not consider a payment “complete” until they have received both a confirmation from the transaction processor and the full preimage data for their new outputs.
  2. 非交互的交易场景，例如扫描静态二维码慈善捐款场景，交易系统先存储这些output，接收方后续查询。需要系统存储pk和utxo的对应关系，交易间的关系容易被追踪，有隐私泄露的隐患。

交易系统确认方式

  • 交易执行成功后，交易系统对结果签名，返回发送方。发送方直接中继给接收方确认。
  • 构造交易时，交易结构增加callback endpoint。交易系统执行成功后，回调此endpoint通知接收方。此方案依赖于callback endpoint的可用性，暂时不可用时需要支持降级查询功能，增加了系统的存储需求，也就记录交易主体和交易本身的关联关系。本方案里很关注隐私保护的考虑，也就是尽可能的减少交易可被追踪的可能性。此确认方式有所冲突。

交易方式局限性

当前 无法 支持由收款方主动发起（例如代发工资，划扣生活缴费等场景），因为构造交易需要指定input utxo并且发送方签名，在缺少发送方的知识和私钥的情况下，难以构造合法交易。账户模式以记账模式比较容易实现。

交易系统架构设计

1. 全局有序方案

TBD

2. 两阶段提交方案

  • 批量执行。两阶段执行结果是具备确定性的，批量内的交易可能会因为相互冲突导致部分失败。

  • 集群容错。每个组件都使用Raft协议保证数据一致性。

    工程实现上仍然还有很多细节需要考虑设计，极端场景，边缘场景等，这些无法在论文里展开详述。

未来的工作

  1. 隐私保护，费用，风控，合规
  2. 中间机构（例如商业银行）的作用
  3. 离线支付
  4. 防止DoS攻击
  5. 丰富使用场景，提升用户体验。通知收发双方确认交易完成和隐私保护间的平衡
  6. 提升系统性能（先消费input UTXO，延迟生成output UTXO）

思考

  1. CBDC领域里UTXO模型有局限性，某些场景下等同于账户模型。

    • 正如论文里提到的用户体验，如何将可用UTXO通知到用户，并且需要能支持查询，恢复。这就涉及到UTXO的存储和用户关系（可能是pk）的管理，这就类似于账户模型了。一旦pk关联的用户被获得，就完全退化为账户模型。
    • 目前难以实现由收款方主动发起且付款方一次授权后续无需参与的交易，因为前提是需要获取到付款方的可用UTXO。可以由货币发行方统一管理和记录，用户和UTXO的对应关系，但这一定程度上也等价于账户模型。或者授权第三方，这需要付款方及时将可用UTXO发送到第三方，保证充足的头寸。这些方案都需要将私钥托管。这就涉及到隐私保护和支付安全的问题，虽然可以通过签订协议，以及为不同的场景生成不同的密钥对来一定程度上保护。账户模型下，也可以通过开立专用账户达到同样的效果。
    • CBDC领域里差错处理是非常重要的，当前常用的账户模型下货币记账方拥有更多的控制权，使用冲正等方案也比较成熟，能有效避免资损。相对来说UTXO模型更加依赖即时清结算的确定性。
    • 类似账户模型的分级管理等风控手段，业务规则在UTXO模型下可能难以使用。

  2. 智能合约与UTXO结合更能达到对支付的有效控制。
    UTXO模型下，智能合约的代码是内生在UTXO数据结构本身的（witness字段），类似于比特币里的锁定脚本，智能合约控制着UTXO是否能被消费。而相比之下账户模型下智能合约的执行和记账本身是分离的，理论上存在绕开智能合约直接改动账本的可能性。当然，witness字段必须尽可能的少占据空间，因此也限制了智能合约的复杂性，同时能够通过脚本语言做到图灵完备，或者简化的满足CBDC领域的需要，这点仍然有待更多的研究。

  3. 隐私和监管的平衡。
    UTXO的隐私性更强，监管难度更大。由于用户理论上可以无限的自由生成公私钥对，并且生成的密钥对里无法反向推出用户信息。再结合混币器混淆等技术，UTXO的交易路径也很难被追踪，相比账户模型，其隐私保护的能力更强。同时从监管角度更难追踪交易流向。对于涉及到反诈骗反洗钱反恐怖融资等场景，监管当局对风险交易和账户及时的识别和处置风险难度很大，手段较为有限。账户模型下采用冻结账户和资金等方式则较为简单有效。当然，这也是一把双刃剑，在国际纷争中也很容易成为“制裁”的武器。

总而言之，当前金融系统采用账户模型，这一套运行体系已经很成熟了。要在货币领域转到UTXO的方式还缺少可以借鉴的成功案例，在讲求稳定的金融领域，这个目前还只能算是很初级的研究阶段，距离落地还有很长一段距离。当然，UTXO还是有很多优点，例如与智能合约的结合实现更有效的专款专用和监管。但可以确定的是，加密货币领域单纯的UTXO模型是无法完全适用于CBDC领域的。在当前的传统账户模型下，如何利用UTXO模型的优点，这是应该着力探索的方向，大概率是账户模型和UTXO的有机结合。至于OpenCBDC项目的第一阶段，尽管中心化系统，没有使用区块链，但是借鉴和组合了当前很多区块链和分布式应用领域的技术，本身并没有特别多的亮点，除了引发对CBDC的数据模型的思考，仅仅是因为其背景和宣称的实验室测试数据而受人关注。很多工程细节都没有考虑，这些在一定程度上肯定会影响系统的复杂度和性能。还是期待下一个阶段能有一些更有创新性或者更接近落地的成果。

To beloved Hannah ❤