Platypus 一种集中式的央行数字货币方案

集中式的CBDC，混合使用账户模型和UTXO模型。

角色分类

中央银行：发行货币，交易验证，公开交易日志，防止双花。

不是完全受信任的，假定为会遵守监管要求，但可能会破坏交易隐私，即获取交易信息（交易价值以及交易双方信息）。
持有公私钥对 $sk_C,pk_C)$ ，用于签名用户账户状态承诺。

监管者：发行证书，执行监管需求，如AML（反洗钱）。
用户：作为交易双方，维护自己的账户状态。

持有公私钥对 $sk_U,pk_U)$

基本交易流程

账户由三部分组成，账户状态 $state_i$ ，金额 $bal_i$ ，序列号 $serial_i$
假设交易双方为A、B

Transaction Initiation：发送方A更新自己账户，并发送一共6部分内容，
1. $v_{Tx}$ ：交易金额。
2. $blind_{Tx}$ ：随机盲因子，用于生成承诺。
3. $comm_{Tx}$ ：交易承诺， $comm_{Tx}=comm(v_{Tx},blind_{Tx})$ 。
4. $serial_i^A$ ：旧状态的序列号。
5. $state_{i+1}^A$ ：新账户状态，基于以前的账户状态，通过伪随机生成的序列号 $serial_{i+1}^A$ 和新的账户余额 $bal_{i+1}^A=bal^A_i-v_{Tx}$ 生成。
6. $zkp_{i+1}^A$ ：零知识证明，证明自己完全遵循上述步骤。
Transaction Completion：接收方B更新自己账户，拿到信息后，和A一样计算自己的新账户状态，和相应的零知识证明，证明自己账户遵循合理步骤，账户相比之前的状态正好增加了对应金额。然后发送以下给央行。
$comm_{Tx}$ ：交易承诺。
$serial_i^A,serial_i^B）$ ：交易双方的旧帐户序列号。
$state_{i+1}^A,state_{i+1}^B)$ ：交易双方的新账户状态。
$zkp_{i+1}^A,zkp_{i+1}^B)$ ：交易双方的零知识证明。
Transaction Execution：央行首先验证双方零知识证明，然后检验两个旧帐户序列号是否出现在之前的交易中，没有出现则添加到已使用记录中，然后对两个用户状态签名得到 $(\sigma_{i+1}^A,\sigma_{i+1}^B)$ 。
Payment Acceptance：B验证签名是否有效，有效则接受此交易更新账户信息，然后转发 $\sigma_{i+1}^A$ 给A。
Payment Completion：验证签名并更新账户信息。

此外，为了防止B不发送签名给A，央行会同时发布从B收到的所有信息以及自己对新账户的签名，用于A通过自己的序列号找到自己的交易信息并接受。

基础协议流程

CRS（Common Reference String）在CDBC背景下是成立的，此背景默认Central Bank为trusted，无需其他假设。
设定一个监管者，一个央行，两个用户。

初始化

央行

创建自己密钥对 $sk_C,pk_C)$ ，并公开公钥。
设置金额最大值 $bal_{max}$ ，防止溢出

用户注册

用户

生成私钥 $sk_U = (sk_{U1},sk_{U2})$ ，用于伪随机生成序列号 $serial^U_1$ 和盲因子 $blind^U_1$ 。
生成新的状态承诺 $state^U_1=(serial^U_1,bal^U_1,blind^U_1)$
生成零知识证明 $zkp^U_1$ ，证明自己的状态承诺中的 $bal^U_1=0$
发送 $(state^U_1,zkp^U_1)$ 给央行。

央行

验证，对账户签名，然后发送签名 $\sigma_{1}^U$ 给用户。

交易

假设交易双方为A, B。那么双方的当前的账户为
$state^A_i=(serial^A_i,bal^A_i,blind^A_i)$
$state^B_j=(serial^B_j,bal^B_j,blind^B_j)$
双方都拥有当前账户的签名
$\sigma_{i}^A=Sign(sk_C,state^A_i)$
$\sigma_{j}^B=Sign(sk_C,state^B_j)$

Transaction Initiation

发送方A

确定交易金额 $v_{Tx}$ ，选择随机数 $blind_{Tx}$ ，并创建承诺 $comm_{Tx}=comm(v_{Tx},blind_{Tx})$ 。
生成新的序列号和盲因子，然后创建新的账户承诺 $state_{i+1}^A=comm(serial_{i+1}^A,bal^A_i-v_{Tx},blind_{i+1}^A)$
零知识证明，生成proof $zkp_{i+1}^A$ 。证明自己
1. 旧账户是正确的，即账户和签名能通过验证， $Vrfy(pk_C,comm(serial_{i}^A,bal^A_i,blind_{i}^A),\sigma_{i}^A)$ 。
2. 承诺计算正确。
3. 账户状态更新正确。
4. 金额没有超过阈值。
5. 金额更新正确。
6. 序列号更新正确，即在旧序列号上伪随机产生。
发送信息 $v_{Tx}，blind_{Tx}，comm_{Tx}，serial_i^A，state_{i+1}^A，zkp_{i+1}^A$ 给B。

Transaction Completion

接收方B

生成新的序列号和盲因子，然后创建新的账户承诺 $state_{j+1}^B=comm(serial_{j+1}^B,bal^B_j-v_{Tx},blind_{j+1}^B)$
零知识证明，生成proof $zkp_{j+1}^B$ ，和A一样。
发送信息 $comm_{Tx}，serial_i^A，state_{i+1}^A，zkp_{i+1}^A，serial_j^B，state_{j+1}^B，zkp_{j+1}^B$ 给央行
Transaction Execution

央行

验证零知识证明和序列号是否重复，不通过则拒绝并通知B。
否则接受交易，存储序列号到已使用列表，对两个更新的新账户进行签名

$\sigma_{i+1}^A=Sign(sk_C,state^A_{i+1})$
$\sigma_{j}^B=Sign(sk_C,state^B_j)$

发送两个签名给B，公开交易到公开交易日志里，会同时发布从B收到的所有信息以及自己对新账户的签名。
Payment Acceptance

接收方B
检查签名是否有效，有效则存下签名，转发A的签名给A。

Payment Completion

发送方A
检查签名是否有效，有效则存下签名，至此交易完成。

提升方案

看完前面的方案可能会有点懵，监管者呢，提都没提？WTF？好像很多功能都还没有，怎么中止交易，怎么披露信息，怎么标识用户，怎么执行的监管等等好像啥都没说😇。
原文的描述比较模糊，没有将相关信息放入基础方案里面，只给了单独一章用于表述该角色的额外功能，而且一些函数只给了一个粗浅的定义，并没提具体实施（咱也不知道为啥，可能是想表现可扩展性高？这就是不给源码的原因吗？）

新增角色

监管者
定义为能执行一些监管规则。

持有发行证书密钥对 $sk_{RC},pk_{RC})$ ，加密密钥对 $sk_{RE},pk_{RE})$

新增步骤

用户注册
增加向监管者注册的步骤，明确身份。

用私钥计算出公钥作为自己的唯一标识符，标识为 $pi_U,si_U）$ 。
向监管者注册，并证明自己知道对应的私钥，然后收到监管者签名 $\sigma^U_R=sign(sk_{RC},(pi_U,params))$ $p a r am s$ 可以是一些单独不同的规则所需要的参数，如每个用户的不同的持币限制。
签名以及公共身份会包含在账户承诺中，所以需要证明新旧账户承诺中的身份是一样的。

交易监管

添加辅助信息说明：在账户状态承诺里新增了辅助信息，用于用户对交易信息的一些说明，同样需要证明，那么新的完全体账户状态承诺就变为

$state^A_i=(serial^A_i,bal^A_i,blind^A_i,pi_U,aux_i^U)$ ， $aux_i^U$ 为辅助信息（可以理解为一些额外的监管规则）
辅助信息在每一笔交易也许会不一样，故需要进行更新，更新函数为updateAux。

特定条件下的信息披露：新增一个披露函数RegInfo，输入为用户的状态信息，输出为密文信息或者披露信息（特定条件下），如用户身份，余额等信息。当然，要使得披露信息对外不可区分，需要加密，采用监管者公钥加密 $pk_{RE}$ ，计算密文 $E^U_{i+1}$ 的过程的正确性需要进行证明，密文将作为交易的一部分发送给央行，央行会转发给监管者，监管者可以解密查看。
额外检查：新增额外检查函数checkOther。

交易零知识证明
增加了这么多信息，那么交易所需要的零知识证明自然需要增加。
以下是完整的需要证明的式子

红色部分为新增的，即

拥有合法的身份，即拥有对应身份的私钥
监管者的签名是有效的。
额外辅助信息更新正确
证明自己的计算披露函数和加密过程正确
额外校验校验也正确

小结

没有交易中止功能，出现密钥丢失，被骗等很难追回。
交易追溯是通过公开日志查询的。
没有提多个监管者的方案。
没有异步交易，离线交易功能。

参考

Wüst, Karl, et al. “Platypus: A central bank digital currency with unlinkable transactions and privacy-preserving regulation.” Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security. 2022.

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.rhkb.cn/news/293645.html

如若内容造成侵权/违法违规/事实不符，请联系长河编程网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！