写点什么

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

  • 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:208572

评论 2 条评论

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

2月大事件:度目CM-Mini智能面板机全新发布,飞桨PaddleGAN“复活”李焕英

百度大脑

百度 百度大脑

你的终端从未如此优雅

Kareza

终端工具 3月日更 Hyper

并发编程-原子操作CAS

赖猫

c++ 高并发 并发 CAS Linux服务器开发

Linux 高并发服务器 select/poll实现

赖猫

Linux linux编程 linux开发 Linux服务器开发

San CLI 的实现原理

百度Geek说

cli service san command

知道Python中的字符串是什么吗?

华为云开发者联盟

Python 编程语言 字符串 字符

叹服!微软自爆虐心405页程序员面试通关手册,Github上已获赞75.6K

Java架构之路

Java 程序员 架构 面试 编程语言

写作的意义

ES_her0

28天写作 3月日更

与前端训练营的日子 -- Week19

SamGo

学习

融云集成之避坑指南-Android推送篇

融云 RongCloud

音视频

融云即时通讯SDK集成 -- FCM推送集成指南(Android平台)

融云 RongCloud

即时通讯

融云 IM SDK 转 AndroidX

融云 RongCloud

IM

【数独问题】经典面试题:解数独 ...

宫水三叶的刷题日记

面试 LeetCode 数据结构与算法

安卓应用程序开发理论!免费Android高级工程师学习资源,附面试题答案

欢喜学安卓

android 程序员 面试 移动开发

WebRTC服务器模型

赖猫

音视频 WebRTC

嵌入式技术与人工智能有什么关系?

cdhqyj

人工智能 嵌入式 系统 科技

安卓系统开发架构!5214页PDF的进阶架构师学习笔记,成功入职腾讯

欢喜学安卓

android 程序员 面试 移动开发

OpenKruise v0.8.0 版本发布:K8s 社区首个规模化镜像预热能力

阿里巴巴云原生

容器 云原生 k8s 安全 应用服务中间件

为啥你一入场就开始跌呢?聊聊长期主义

池建强

长期主义

对标阿里P9Java架构师面试题,已助我拿下字节、蚂蚁、滴滴三家Offer

Java架构追梦

Java 阿里巴巴 架构 面试 滴滴

数字孪生技术如何实现复制世界?关键的关键是…

华为云开发者联盟

数据中心 数字孪生 节能 仿真 数据中心网图服务

DataPipeline亮相“2021科技助力湾区数字金融发展峰会”,解锁“实时数据管理”密码

DataPipeline数见科技

Redis和Memcached的区别

赖猫

redis memcached 服务器开发 Linux服务器开发

细粒度授权在安全领域的重要性

龙归科技

安全 iam 细粒度 ABAC PBAC

你的终端从未如此高效

Kareza

3月日更 Oh My Zsh

谷歌大脑团队官方推荐,用浏览器实现深度学习的「黑科技」教程来了!

图灵社区

JavaScript 人工智能 机器学习 深度学习 大前端

寻找被遗忘的勇气(十二)

Changing Lin

3月日更

技术债是什么、怎么还?你想知道的都在这一篇文章里了!

禅道项目管理

技术 技术债 问题

融云即时通讯SDK集成 -- 国内厂商推送集成踩坑篇(Android平台)

融云 RongCloud

即时通讯

对标阿里P7Java架构师面试题,已助我拿下字节、蚂蚁、滴滴三家Offer

Java架构之路

Java 程序员 架构 面试 编程语言

助我拿到37KOffer,这份阿里巴巴890页Redis笔记可谓功不可没

Java架构之路

Java 程序员 架构 面试 编程语言

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