【锁定直播】字节、华为云、阿里云等技术专家讨论如何将大模型接入 AIOps 解决实际问题,戳>>> 了解详情
写点什么

央行数字货币在技术上是如何实现的

  • 2019-12-02
  • 本文字数:6831 字

    阅读完需:约 22 分钟

央行数字货币在技术上是如何实现的


最近关于央行数字货币 DCEP(Digital Currency Electronic Payment)的消息不断涌现,加上 Facebook 的 libra 对数字货币的推波助澜,以及政府将区块链定位为核心技术自主创新重要突破口,一下子区块链的风头无出其右。在看了央行数字货币研究所所长穆长春先生对 DCEP 以及 libra 的分析对比后,本人对 DCEP 的顶层设计非常好奇,但是苦于当前关于 DCEP 的相关报道都是基于宏观方面的。


作为一个技术人员迫切的想知道 DCEP 与区块链的切合点,于是在仔细阅读了人行的数字货币系统的专利后,写一篇作为一个技术人员或者说区块链从业人员的角度来看 DCEP 的某些技术细节。


在看完数字货币系统专利后,整体的感觉就是,DCEP 并没有采用区块链技术,而是一个以央行为中心的系统。其实也能理解,毕竟权利与义务是对等的,央行承担着法币兑付的义务,因此这个记账的权利自然也应该由他承担。当然在部分自由主义者看来,这种做法似乎不够纯粹,不够 Decentralization。但是去中心化并不是银弹,不能够寄希望他来解决一切问题。相反的,是否选择去中心化是需要和当前场景的主要矛盾相符合,如果当对公平或者透明的诉求成为了主要矛盾,那么去中心化将是一个不错的解决方法,但是在当前很多领域中,对效率的需求还是主要矛盾,所以在这些场景下,采用去中心化效果并不是会很好,反而会起到不断消耗的反作用。


接下来,本文将根据数字货币系统专利,从 DCEP 的特征、实现细节、离线支付场景来着重介绍。

DCEP 的特征

DCEP 的特征主要体现在两大方面,一个是金融上的特征,一个是技术上的特征。专利上主要阐述了技术上的特征,关于金融上的特征,主要源自穆长春先生在公开课中的报道。

关于金融上的特征

  • 替代 M0—— 首先 DCEP 是对 M0 的替代,也就是对现金的替代,之所以只对 M0 替代,是因为 M1、M2 已经实现了数字化,如果把 M0 也数字化后,那么央妈对资金的监管就比较完整了。另外,之所以从现金入手,一部分原因也是因为现金只是承担了货币的功能,所以对社会的影响并不会非常大。

  • 双层运营模式 —— 是指上面一层是人行对商业银行,下面一层是商业银行或者商业机构对老百姓。也就是说,商业银行向人行交付 100% 的准备金,然后人行给与商业银行等额的 DCEP,接下来用户通过现金或者存款等向商业银行兑换 DCEP。如果人行直接面向老百姓,理论上也是可以的,这样的话,人行就需要面对全中国所有的消费者,他就需要设计一个既满足用户体验又满足高性能要求的系统,显然人行是不擅长做这个的,所以最好的方式由市场经济来决定,也就是说将面向用户的那一端交给商业银行或者机构来做,充分发挥市场竞争。

关于技术上的特征

这一块是指 DCEP 在设计上所需要满足的几个特征,这几个特征与 BTC 等基于区块链的虚拟货币概念比较相似。当然,与其说和 BTC 等虚拟货币的概念比较相似,不如说满足那几个基本特征的才算是数字货币。


  • 安全性 —— 这个要求防止商务中任意一方更改或者非法使用数字货币,这个更多的是体现在对 DCEP 使用的监管上,甚至于说可以终止某次非法的交易。

  • 不可重复花费性 —— 这个是指数字货币只能使用一次,重复花费容易被检查出来。之所以提这个,是因为一旦现金被数字化后,那么数据的复制就是难免了,比如有个用户用面额是 100 的 DCEP 买了一张电影票,但是又复制了这么一份相同的 DCEP 去进行消费,那么就是对同一份数字货币进行重复花费,所以对于数字货币来说这个是基本特性。对于 BTC 来说,是通过 UTXO 来实现防止双花,而对于 Ethereum、libra 来说则是通过交易的 seq 来防止双花。对于 DCEP 来说,则是采用类似 UTXO 的方式,至于这里的 UTXO 与 BTC 的 UTXO 的区别,会在下一篇文章中介绍。而现金则由于难以伪造的特性,在物理上可以保证只此一份。

  • 可控匿名性 —— 这个意思是说,即使商业银行和商户相互勾结,也不能跟踪 DCEP 的使用,换句话说就是除了 DCEP 的发行方(人行)外,其他的结构都无法追踪用户的购买行为。终于可以摆脱部分隐私泄露的问题了。

  • 不可伪造性 —— 比较好理解,除了发行方以外,不能伪造假的数字货币。对于现金来说,是通过物理上的防伪手段来保证。对于 DCEP 来说,做法比较简单,就是只有经过央行的私钥签名的才是真的 DCEP。岔开说下,之前 Google 暴出量子计算的新闻,币圈各种自嗨,觉得 BTC 会被破解,量子计算真出来了,他的攻击目标就算不是核武器,怎么也得是央行这种级别,币圈真的是太把自己当回事了。

  • 公平性 —— 支付过程是公平的,保证交易双方的交易过程要么都成功,要么都失败,更贴切的应该是满足交易原子性。

  • 兼容性 这个表示 DCEP 的发行和流通环节,要尽可能的参照现金的发行与流通。

DCEP 实现细节

这里的实现细节主要针对上述的特性来展开讲解。

货币模型

基于对当前各个专利的研究,大致能确定 DCEP 是一种类似 UTXO 结构的货币模型。DCEP 的发行模式有三种方式(这里为了简单我们称央行的发行的数字货币为 D 币)


  1. 按照最小面额产生,比如说央行发行总量为 100 元,并且最小面额是 1 分,那么央行将发行 10000 个面额为 1 分的 D 币;

  2. 根据用户具体提款金额来生产,例如某个用户通过转账得到了 12.34 元的 D 币,那么央行相当于发行了一个面额的 12.34 的 D 币;

  3. 按照流通中实际货币面额产生,这个是最贴近当前实际现金的,例如央行发行面额为 100、50、20、10、5、1 元等的 D 币,那么后续流通过程中都是以这些面额的 D 币进行流通。


关于 UTXO 结构,这块与 BTC 有很大不同,UTXO 表示未花费的交易,BTC 中通过这个未花费的交易来表示你拥有的余额。比如说 Alice 转给 Bob 一个 BTC,对于 Bob 来说如果没有花掉这个 BTC 的话,那么 Bob 就拥有了一个金额为 1 BTC 的 UTXO,就像现金一样 Bob 拿到了纸钞,只要不花掉,那么就是你的钱。Bob 如何证明他的确拥有这个 UTXO 呢?简单地说,谁拥有解开 UTXO 的锁的钥匙,这个 UTXO 就是谁的,至于有哪些锁,如何开锁,大家可以查询下 P2PKH,P2SH 等信息,我们也会在接下来的文章中详细介绍。在 DCEP 中,是通过登记中心来完成 UTXO 的功能,至于如何做的会在下面仔细介绍。

系统核心要素

央行的 DCEP 系统主义功能就是对法定数字货币的资金转移,它由中央银行与各商业银行一起联合运营。总的来说 DCEP 的核心要素有:一种币,两类库,三个中心。


  • 一种币 :这里的一种币就是指央行发行的法定数字货币,也就是说系统中只能转移央行发行的这个法定数字货币。正如前面说的,只有央行私钥签名的才是法定数字货币,因此我们的电子钱包等都会内置央行的公钥,用来验证该数字货币是否为央行发行的。

  • 两类库 :两类库是发行库和商业银行库,这两个库是数据库。比如说,根据数字货币发行总量,央行根据上面说的方式用它的私钥签名生成对应总量的数字货币,此时这些数字货币是存放在央行的发行库中。如果某个商业银行需要提取一定量的数字货币,那么系统就会将对应的数字货币发送到该商业银行的商业银行库中,即数字货币从发行库到银行库的转移。需要注意的是,用户从商业银行提取数字货币,是数字货币从银行库进入到电子钱包的过程,属于流通环节。

  • 三个中心 :三个中心一共两种类型,一个是登记中心,另外一个是认证中心。


登记中心主要负责管理数字货币的整个生命周期,包括印制、转移、销毁、回笼等过程。他主要有两张表,一个为数字货币权属登记表,另外一张为交易流水表。这个权属登记表的作用是记录某面额的数字货币是属于谁的(如下图所示),每当数字货币发生了转移,在央行的登记中心都会对对应的数字货币的属主进行更改,通过这个表可以实现确权查询。这里的重点是,登记中心确定用户到底有多少钱。



认证中心分为两类,一个是 CA 认证,一个 IBC 认证。


CA 认证主要用于相对来说比较高级的机构,而 IBC 认证则是用于个人的。这里引入认证中心的原因是,当用户或者机构发起一笔 DCEP 的转账时,需要通过自己的私钥进行签名,也就是说这笔转账的合法性是通过签名来保证的。在一般意义中的 BTC、Ethereum 或者 Libra 中,私钥是用户自己创建,由自己保管,并且用户的地址是由私钥对应的公钥通过一系列运算(Hash,checksum)等得到的,这种方式的优点是资产账户和私钥是天然绑定的,你拥有了私钥也就拥有了其对应的资产。但是在 DCEP 中,由于存在监管这个特性,资产归属和私钥是分开的,也就是说央行会在用户注册了一个 DCEP 钱包后,会通过认证中心给钱包用户分配一个私钥,这个私钥用来证明是这个用户,至于这个用户是否拥有数字货币,是在登记中心来确定的。所以这里的重点是,用户私钥是央行生成的。


另外,这里简单介绍下 IBC 认证,IBC(Identity-Based Cryptograph)是基于身份标识的密码系统,还是基于非对称的秘钥体系,他与 CA 认证的最大区别就是不需要证书,而是通过用户标识例如手机号码、邮箱等作为公钥,由 IBC 认证中心根据用户标志生成对应的私钥,由于用户标志本身就是一个公钥,通过用户标志就能确认身份有效性了,从而就不用再依赖证书和证书管理系统了。当然,此时央行的公钥还有用户的私钥、证书数据就相当的重要了,需要将该数据存储在 SE 区域。


通过对一种币,两类库,三个中心的介绍,大致可以了解 DCEP 的一些顶层设计原则,接下来会结合具体的场景,来实际将顶层设计的逻辑走一遍。

DCEP 具体场景描述

在货币模型中提到了 DCEP 关于面额一共有三种方案,我们这里以第三种固定面额来介绍。

印制

相比纸币的印制过程,DCEP 的印制其实就是产生一串由央行签名过的数字,这里根据数字货币系统专利来介绍如何生成这串分量十足的数字。


  1. 由央行的主密码与面额数字 1,5,10,20,50,100 分别产生 6 个基本加密密码。这 6 个加密密码分别是用于不同面额的数字货币。

  2. 由 Hash 算法生成系统随机数,这个随机数就跟纸币上的冠字号码一样。

  3. 由步骤 1 生成的基本加密密码与随机数加密,生成加密密码。这个加密密码其实就已经对应特定冠字号的数字货币了。

  4. 央行通过私钥对加密密码进行签名,此时一枚新的法定数字货币就产生了。


下图是印制的过程


用户登录

这里简单说下登录过程,商业银行系统对连接央行的认证中心和登记中心。


  1. 用户下载对应的某商业银行的电子钱包 APP

  2. 用户在 APP 的登录页注册相关信息,例如姓名,身份证号,手机号,住址等信息

  3. 商业银行通过上述注册信息,利用手机号作为 IBC 的公钥进行登记,在 IBC 完成唯一性验证后,IBC 为该用户生成私钥。

  4. 用户登录后,下载用户用户私钥和央行公钥数据,并将这些数据存储在 SE 区域。


提取

这里介绍下用户通过商业银行账户提取法定数字货币(简称 D 币),例如用户从自己的工商银行账户取 150 元,然后兑换成 D 币。


  1. 用户登录钱包 APP,选择 “提取数字货币”,并选择工商银行,输入银行账户以及兑换的数字货币额度。

  2. 商业银行验证该请求的合法性:校验账户密码,用户账户资金是否足够,以及该商业银行的银行库中的 D 币是否足够。若通过合法性校验,那么将该用户的在商业银行中的账户扣除 250 元,商业银行从银行库中支出 D100、D50 (D100 表示面额为 100 的 D 币),并将这些信息发送至央行数字货币系统。

  3. 央行数字货币系统收到商业银行数字货币系统的请求后,进行发核心校验,例如判断发送过来的 D100 和 D50 是否归属于该商业银,以及对应的签名验证等。在校验通过后,登记中心变更商业银行发送过来的 D 币的属主信息,将工商银行的属主变更为该用户,并且记录对应的交易流水。完成完整动作后,返回处理成功的信息给商业银行。

  4. 商业银行将 D 币发送到用户手机端,至此,用户的手机端便有了 D100 和 D50。需要注意的是,真正决定你是否拥有这 150 元 D 币,不是你手机端存储了这 150D 币,而是登记中心决定的。


这里岔开一下,在另外几篇专利中,我们发现,并不是通过更改属主关系,而是直接将原有的 D 币进行销毁,再重新生成新的 D 币,也就是说央行在收到请求并校验通过后,是将商业银行的那 250 元 D 币直接销毁,然后再重新生成一个新的 250 元 D 币,这样的优点在于,只要央行不公布交易流水,只单单公布一个数字货币确权信息,那么外部是无法将数字货币的转移信息给串联起来的,这样既符合了匿名,又满足了央行的监管,因此后续有可能采取销毁的方案。

支付

这里指用户 A 和用户 B 之间进行 D 币的在线支付,假设 A 用户的电子钱包中有 D100,D50 总计 150 元的 D 币,先需要支付 150 元给 B 用户,支付步骤如下。


  1. A 用户登录 APP,选择付款功能,并输入:付款金额,收款人(例如手机号),点击发送

  2. A 用户的 APP 根据付款金额,自动选择总额为 150 的 D 币,并将信息发送至商业银行数字货币系统。

  3. 商业银行校验支付信息的合法性,例如:D100 和 D50 的合法性,交易金额与数字货币是否等值,以及接收用户的相关校验。校验通过后,将请求发送至央行的数字货币系统。

  4. 央行数字货币系统收到请求后,验证 D100、D50 是否为交易发起者等,在登记中心更改 D100、D50 的属主为 B 用户,并记录对应的流水。最后将成功信息返回给商业银行数字货币系统

  5. 商业银行收到成功信息后,将 D100 和 D50 发送到 B 用户 APP 中,并分别向 A、B 用户的 APP 发送交易成功的信息。


这里的支付和提取的流程基本一致,只要明白属主信息是在央行的登记中心进行修改就可以了。

如何实现匿名、监管

因为现金交易存在匿名的特性,如果 DCEP 不能满足匿名性,那么有很多的场景下,普通用户可能还会选择用现金,因此 DCEP 必然需要满足匿名性。但是,DCEP 的另外一个功能是为了满足监管需求,因此 DCEP 目前对匿名也是前台匿名后台实名的方式。


  • 匿名 —— 在上面支付的场景中,交易信息 M 可以设计为 M = 交易代码 || 发送者公钥 ||D 币信息 || 支付金额 || 接受者公钥,再通过 Hash 算法将 M 信息做摘要,并用发送者的私钥对摘要进行签名得到 m,最后将 M||m 信息发送到商业银行的数字货币系统。由于对交易双方做了一定的匿名处理,若再采取每次转账都销毁再生成的方式,商业银行和机构是难以追踪资金转移的。

  • 监管 —— 由于在认证中心需要用户登记身份标识作为公钥,同时在注册时用户会上传对应的信息,因此央行的后台系统对用户信息是一清二楚的,同时登记中心会记录交易流水,因此通过大数据分析可以做到一定的监管。

关于双离线支付场景分析

DCEP 相比支付宝等电子支付有一个特性,就是离线支付。这个特性非常重要,因为 DCEP 是现金的数字化,因此需要具备现金的特性,可以想象下,如果有一天出现了极端恶劣的情况例如大地震、战争等,导致网络不可用,如果 DCEP 不支持双离线支付,那么就意味着普通百姓没办法进行正常的生活了。因此,即使出现双离线支付的场景概率非常小,但是还是必须支持这个功能。


在数字货币系统专利中,提到了双离线支付的解决方案。例如 A 用户的电子钱包中有 D100,现在 A、B 用户都离线的情况下需要支付 D100 给 B 用户。


  1. A 用户打开 APP 后,选择离线支付功能,输入付款金额和接收方信息后点击支付。

  2. A 用户对上述信息利用自己的私钥进行签名,并用收款人的手机号或者其他标识收款人的信息通过 NFC 等近场通讯的方式进行加密传输。

  3. B 用户 APP 接收到加密信息后,解密并验证 D 币的合法性,以及金额是否等值。此时对于 A、B 用户来说已经完成了双离线支付,但是此时 B 其实并没有真正收到 A 转给他的 D 币,在 APP 界面上来说,接受到的 D 币应该是出于不正常状态(不可用)。接下来,B 用户的 APP 会在联机状态后,将支付信息发送给商业银行数字货币系统。

  4. 商业银行收到这个支付信息后,在校验了合法性后,会将这个信息发送给央行数字货币系统。

  5. 央行数字货币系统收到支付信息后,在完成与在线支付一样的校验后,就会更改属主,将原本属于 A 的 D 币,变更为 B 用户,最后将结果返回给商业银行。

  6. 商业银行收到成功信息后,通知 A、B 用户 APP 发送交易成功的消息,此时 B 用户接收到的 D 币状态才会变成可用状态。


因此,如果 A 转给 B,那么 B 在联网之前,A 转给 B 的 D 币无法转给 C 的,这个双离线支付并不能完成链式的支付。总体感觉,这个解决方案只能用于临时性的离线情况,例如在地下停车场或者网络不好的场所进行支付。


另外,在双离线支付场景中,若用户利用某些漏洞实施了双花,从专利来看,是通过事后追责的形式来处理的。

为什么要推 DCEP

要推行 DCEP 的理由,对内一方面是加强对资金转移的监管,提高金融稳定性,增强反腐、反洗钱的能力。对外,有利于人民币国际化,不过人民币国际化,不会因为人民币数字化了而成功,国际化的背后必然是我国国力强大,坚持通过用真理说服人。但是,DCEP 可以降低国际友人的使用门槛,随着中国消费者走出国门进行境外的消费,说不定在不久的将来,我们的国际友人也可以通过手机号注册一个钱包,直接收款,而不必再通过开通银行账号。


在不久的将来,自上而下的通过整理说服人,自下而上的通过消费者带动国际友人使用人民币。


本文转载自:


深入浅出区块链(ID:blockchaincore)


原文链接: 


https://learnblockchain.cn/2019/11/06/DCEP-research


作者知乎:


https://zhuanlan.zhihu.com/c_1124734224619773952


2019-12-02 16:208355

评论 2 条评论

发布
用户头像
不错
2019-12-04 10:27
回复
用户头像
这篇文章中的面额方案已经不是最新的了,最新的是采用零币整付,整币零付的方式,参考姚前2018-01-02收稿的《中央银行数字货币原型系统实验研究》
2019-12-03 17:28
回复
没有更多了
发现更多内容

JPA + EclipseLink + 云平台 = 运行在云端的数据库应用

Jerry Wang

数据库 Cloud Cloud Native 11月日更

TDSQL将发布免费版本,助力国产数据库生态完善

腾讯云数据库

数据库 tdsql

2020一个Android大牛的面试经历分享(金九银十面试30多家公司)

android 程序员 移动开发

2020上半年百度Android岗(初级到高级)面试真题全收录

android 程序员 移动开发

教你如何在Spark Scala/Java应用中调用Python脚本

华为云开发者联盟

Java Python spark JVM Spark Scala

2020-Android-面试重难点(万字篇),android屏幕适配的五种方式

android 程序员 移动开发

2020 更新 - 腾讯 Android 面试 (已拿到月薪22K offer)

android 程序员 移动开发

2020Android 开发年度总结:“这一年里我到底做了些啥,面试阿里的时候一定会问到的

android 程序员 移动开发

模块三作业

doublechun

「架构实战营」

2020Android开发者学习路线(快速篇),分析android进程管理机制

android 程序员 移动开发

2020倒计时,大厂核心送给每一个脚踏实地努力着的Android程序员,逆风前行

android 程序员 移动开发

2020字节跳动,腾讯,网易云,美团Android面试题

android 程序员 移动开发

双11在即,分享一些稳定性保障技术干货

老张

系统稳定性 大促 生产环境全链路压测

恒源云(GPUSHARE)_U1S1,1年1度GPU云种草大会

恒源云

深度学习

2020 国内互联网公司的Android工程师薪酬排名!看看你是什么水平

android 程序员 移动开发

实用推荐系统:寻找有用的用户行为

博文视点Broadview

硬核干货!TDSQL全局一致性读技术详解|

腾讯云数据库

tdsql 国产数据库

TDSQL | 深度解读HTAP系统的问题与主义之争

腾讯云数据库

tdsql 国产数据库

2020 年需要关注的 5 大 Android 开发技术(1),Android知识总结

android 程序员 移动开发

2020Android面经,历时一个半月,斩获3个大厂offer,移动端开发工程师面试题

android 程序员 移动开发

2020在项目中使用MVVM的正确打开方式,你没用过的船新版本,还不快学学

android 程序员 移动开发

【Java原理剖析系列】深度synchronized工作原理分析

洛神灬殇

java 11月日更

TDSQL已助力20余家金融机构完成核心替换

腾讯云数据库

tdsql 国产数据库

用一套代码实现APP和小程序

Speedoooo

容器 移动开发 ios开发 APP开发 Andriod开发

2020你与字节跳动只差这份笔记,我靠着这份笔记,工资从15K到了40K(1)

android 程序员 移动开发

2020你与字节跳动只差这份笔记,我靠着这份笔记,工资从15K到了40K

android 程序员 移动开发

使用JPA + Eclipselink操作PostgreSQL数据库

Jerry Wang

eclipse 数据库 11月日更

助力邯钢工业4.0!TDengine在深度(平潭)节水减排项目中的应用

TDengine

数据库 tdengine 后端

2020倒计时,大厂核心送给每一个脚踏实地努力着的Android程序员,逆风前行(1)

android 程序员 移动开发

飞鹤乳业数智化转型之路

大咖说

云计算 数字化转型 数字化 企业上云

2020Android-目前最稳定和高效的UI适配方案!你头秃都没想到还能这样吧!

android 程序员 移动开发

央行数字货币在技术上是如何实现的_区块链_Sunrye_InfoQ精选文章