央行数字货币（DC/EP）技术的无责任猜想

最近，央行数字货币（DC/EP）正在农行内测，并将很快试点推广的新闻让“数字货币”以及“区块链”又火了一把。然后，网上各种关于DC/EP的文章也纷至沓来。然而，其实这次DC/EP的内测消息并不是官方放出的，所以其实关于DC/EP的所有技术特点分析都建立在DC/EP从去年开始放出来的一些新闻，包括央行数字货币研究所所长的访谈和文章，以及数字货币研究所申请的专利的基础上。官方后来放出的新闻也没有跟进任何关于DC/EP的技术方向之类的说明。

因此，既然大家都没有什么内幕消息，那么我也根据之前放出的情报，对于DC/EP采用的技术方案做个无责任推测好了。

首先DC/EP对于行内人士来说真的不是什么新东西了：比如类似的分析我17年就做过一次，而且基本上大体的框架还是一致的。

如何看待央行旗下媒体发文称要加快推出主权数字货币？主权数字货币有哪些使用场景？

这次推测的主要参考文献：

姚前：央行数字货币——对货币体系的优化及其发行设计

姚前：基于区块链的全新央行数字货币实现方案

姚前：央行数字货币的技术考量

范一飞：关于央行数字货币的几点考虑

Chaum, David . "Blind Signatures for Untraceable Payments."Proc Crypto(1982):199-203.

George Danezis, Sarah Meiklejohn, "Centrally Banked Cryptocurrencies", 2015

数篇央行数字货币研究所的专利，之前关于央行数字货币的新闻（之前看过懒得找了）和穆长春关于央行数字货币的课程（没上过那个课，但是间接地了解了一下）。

————————————————————————————————

1，DC/EP是否是区块链/加密货币

其实之前就透露过一个重要的信息，就是“数字货币研发不预设技术路线，考虑区块链或电子支付等”，其中，如果大家有一直关注过央行数字货币的发展和官方消息，就会知道后半句话都是后来加上去的，最早的表态里其实是明确说没有采用区块链的。实际含义就是：1，DC/EP现阶段不采用区块链；2，将来可能考虑采用区块链技术。而这个结论也和央行一直以来放出的消息和技术方向相符。

因此，考虑到上一次关于DC/EP的消息是目前DC/EP仅考虑国内使用，不考虑跨境支付，我基本上可以推测出：

1，DC/EP基本上是一个中心化系统。

2，它也许采用了一些区块链的技术，但是不足以让其称之为“区块链”，甚至连“私有链”都称不上。因此严格上来说他和类似于比特币的加密货币是不一样的。那么换言之这里传递出的核心信息就是——DC/EP不是拜占庭容错的。

3，在未来，当DC/EP已经比较成熟之后，会考虑使用区块链技术来应对跨境支付的需求。

实际上，从个人的角度来看，DC/EP不使用区块链是理所当然的事情——首先，从央行传递出多次的信息来看，它就是个中心化系统，而众所周知，中心化系统用不到区块链技术，也用不到拜占庭容错。我之前看到很多区块链行业的人对此表示失望，一些比特币的支持者尤甚。其实，与他们相反，我对于DC/EP不使用区块链技术一直都是非常欣慰的——这说明央行数字货币研究院的人并不急于去蹭区块链技术的热点，很清楚区块链技术的局限性，也很清楚自己在做什么。

有人可能会说：“为什么Libra就采用了区块链技术和拜占庭容错？是不是说明Libra的技术更先进？”

首先——Libra的确更新，因为DC/EP和Libra处于完全不同的阶段：DC/EP都已经接近落地了，Libra还停留在更改白皮书的阶段。换句话说，DC/EP启动的时间远早于Libra，而在那个时候区块链的技术还不成熟，因此在那个时候选择不用区块链这么一个从理论和实践上都不成熟的技术是正确的。而Libra作为是去年才出来的项目，如果采用的技术还停留在DCEP启动的时候那才是可笑的事情。

其次，更新不代表更好更先进。的确Libra采用了HotStuff BFT这个我觉得算得上是区块链共识算法的某个“最终答案”的共识算法，同时，在其之上改进的Libra BFT也是我觉得非常符合逻辑的共识机制，但毕竟这仅仅是理论层面，在实践方面还没有先例。同时，区块链共识算法发展至今在我看来仍旧没有称不上成熟和完善，所以即便是现在，我都不觉得DC/EP采用区块链算法是个好主意，所以我认为DC/EP现在将区块链技术定位为“未来可能采用的技术”是非常合适的。

再次，Libra和DC/EP的定位完全不同——Libra是个搅局者，是个非主权货币，换句话说，它如果不用区块链技术，一没有任何竞争力，二没有任何话题性，它和主权货币竞争的愿景（在Libra2.0里这个愿景已经改了）就完全不成立。而相反，DC/EP是中心化的主权货币，从技术上和愿景上都没有用区块链技术的必要。

2，不用区块链，DC/EP的匿名是怎么实现的

实际上，区块链技术也不是用来匿名的，也并没有DC/EP完全匿名的说法，官方的说法是“可控匿名”，我的理解是——对于中央银行而言是可控的，而对于商业银行和其他使用者而言是匿名的。换言之，央行应该有一个非实名的如同类似于比特币的DC/EP账本，在需要的时候，可以追溯资金和交易，这是“可控”，而对于其他商业银行和使用者而言，他们可以验证每笔交易的安全性，但是并不知道交易者的身份，是为匿名。

根据央行数字货币研究院的论文来看，DC/EP的基本结构更像是数字货币先驱David Chaum的Ecash而非类似于比特币的加密货币。但是，并没有用到Ecash的盲签名，取而代之的是央行这个可信中心。

首先，在货币发行上DC/EP采用了和Ecash类似的方法——在DC/EP中，由央行负责发放货币。它对于每个货币给与一个独一无二的编号，然后与面值信息（例如100元，10元）一起用央行的私钥签名，就生成了一个合法的数字货币。这个数字货币，实际上可以看成一个央行背书的一次性兑换券，任何人都可以凭借这个兑换券换取等额的现金，或者一个新的兑换券。

实际上，当然，对于数字货币稍有了解的人都知道，无论对数字货币进行加密的技术多么高明，最难的地方始终在于如何防止双重支付。这个时候，就需要有一个即时拥有全部账本的中心，负责验证每一笔兑换券是否已经用过。于是，当有人想要发起一笔交易的时候，接收者需要将收到的数字货币发给中心进行验证，如果这个编号之前没有使用过，那么中心注销这个货币，并且重新发放一个等值的新兑换券给接收者——以上的这个步骤相当于验钞。

这个方案的问题是可追踪性——因为这个中心实际上将掌握所有交易的去向，因此David Chaum提出了盲签名——一种可以让某条消息“盲化”，于是，让中心可以在不知情的情况下对兑换券的编号签名。这样，中心在验证交易的时候就只能：“嗯，这上面有我的签名，是真的，而且这个编号是第一次见，所以没有使用过。但是我不记得我是什么时候签的了，所以我不知道这张兑换券是我什么时候发给了谁，我只能确认确实是我发的。”

但是，DC/EP应该是没有用到盲签名技术，因为对于央行而言，并没有匿名和防止追踪的需求。而对于央行而言的匿名，是不能让商业银行和机构通过这个账本对资金进行追踪或者破解出对应某笔资金所有者的信息——

这里，就要提一下DC/EP的双层运营体系了。

简单来说，DC/EP的发行和使用是通过两层进行的，央行负责把钱给到下属商业银行，下属商业银行用自己的系统搞出相应的钱包软件，然后支持用户把钱换成央行数字货币。换句话说，央行自己有一个中心账本，负责把钱发给商业银行，商业银行再负责通过集成到自己银行客户端的钱包软件把钱发给个人，但是发到个人之后，这笔钱还是要去央行的账本中登记。换句话说，DC/EP的使用是肯定要通过商业银行的。

而央行需要考虑的是这个过程中的隐私性，或者说，部分隐私性，至少让中间的商业银行不能如同中央银行一般对于DC/EP的去向进行追踪——因此，用户和DC/EP之间的通信应该“盲化”，即收款者在验钞的时候提供的数据需要加密，然后只有央行才能解密。而在这中间，商业银行的钱包仅仅负责建立通信。

但其中不可避免的是：

1，如果交易双方来自同一银行，那么通过同一银行的客户端交易，很难保证隐私性，自然资金在同一银行间的流动也是可以被追踪的。

2，如果交易双方不在同一银行，那么无法避免的交易中至少会泄露“资金来自xx银行”这样的信息。

但是，除此之外，这张钞票对于中间的商业银行而言确实达到了和Ecash一样匿名的效果——

假设银行A的用户从银行B的用户那里收到一笔钱，那么，当这位用户再把钱转给银行B的用户时，银行B是无法看出这笔钱和之前那笔钱的关联的，因为两张钱除了面值一样，其他信息都不同也没有任何关联。

3，DC/EP真的和区块链/加密货币没有任何关系吗？

其实也未必——以上的方案有一个有一个巨大的瓶颈，即所有的交易都需要通过中央银行。

这里，中央银行需要维护一个账本，账本中历史记录的部分记录每一笔已经花掉的钱，而现存部分记录每一笔还没有被花掉的钱，或者说，每一张还没有被花掉的电子钞票。

这个账本，有些类似比特币的UTXO账本，也被称为基于token的或者基于价值的账本形式，这和传统的基于账户的账本有所不同，也就是说，在账本中记录的不再是一个个账户的余额，而是一笔笔交易。

而两个账本中转账的过程是不一样的：

举个例子，我们考虑小明想要转100元给小红。

在大家比较熟悉的账户模型里，这个过程是这样的：

1，小明发出转账请求给系统。

2，系统检查小明账户里有没有这么多钱。

3，如果有，那么从小明的账户里扣掉这些钱，然后加到小红的账户上。

而在这个基于价值的账本里：

1，小明将一张100元的电子钞票发给小红，小红向系统发送验钞请求。

2，系统检查a）这笔交易的数额确实是100；b）小明通过电子签名授权了这笔交易；c）这笔钱还没有被花过。

3，如果检查通过，则系统销毁这笔钱，然后发一张新的100元电子钞票给小红，并登记这张钞票归小红所有。

这里，每笔交易中心都需要完成这样的验证步骤。可想而知，如果DC/EP得到大规模应用，那么这个中心系统的压力甚至要超过支付宝和微信。而对于央行这样的机构而言，更明智的选择是将这些压力分摊给原本就已经有条件的机构。而这点，我们也能在上文提到的许多相关人士的谈话和文章中看出来。

其中，在姚前的“基于区块链的全新央行数字货币实现方案”的这段话中提到：

其中，登记中心记录CBDC及对应用户身份，完成权属登记，并记录流水，完成CBDC产生、流通、清点核对及消亡全过程登记。其主要功能组件分为发行登记、确权发布、确权查询网站应用、分布式账本服务几个部分。发行登记进行CBDC的发行、流通、回笼过程及权属记录；确权发布将发行登记的权属信息进行脱敏后异步发布到CBDC确权分布式账本中；确权查询网站依托分布式账本面向公众提供在线权属查询服务；分布式账本服务保证中央银行与商业银行的CBDC权属信息的一致。 通俗来说，可以理解为我们在登记中心利用分布式账本不可篡改、不可伪造特性，构建了一个“网上验钞机”，即CBDC确权账本，对外通过互联网提供查询服务。这种设计对当前分布式账本技术而言，在中央银行和商业银行既集中又分散的二元模式下，提供了一种巧妙的应用思路，一方面将核心的发行登记账本对外界进行隔离和保护，同时利用分布式账本优势，提高确权查询数据和系统的安全性和可信度；另一方面，由于分布式账本仅用于对外提供查询访问，交易处理仍由发行登记系统来完成，以细化原子交易颗粒度的方式来进行交易的分布式计算处理，这样可以通过业务设计的方式有效规避现有分布式账本在交易处理上的技术性能瓶颈。显然，这样的设计充分发挥了区块链的技术优势，保障CBDC验钞的可信，但并未影响中央银行对CBDC的全局管控。

尽管，后来央行在“不预设路线”的表态中表示以上只是一种思路，未必是最终方案，并且央行数字货币不预设方案。但是从这个方案中，也能看出对于一个中心进行交易处理的压力是需要通过某种方式分摊的。此外，从关于央行数字货币意义（而非技术）的另一些谈话和文章中看出，DC/EP的最核心的意义还是宏观上降低发行成本，优化支付体系和提高货币政策有效性。因此，央行希望能够在必要的时候追溯货币的流向，但是这个目的是统计上而并不需要实时性。从这个角度讲，更理想的设计是——商业银行自行完成交易，然后定期（比如每天）与中央银行账本汇总。这样对于央行而言，就仅仅作为数字货币发行方和流通的监督方，而由商业银行负责数字货币平时的使用——这点似乎对于商业银行和中央银行两边都更为有利。

于是，很多人会发现——说到头来，不还是需要所有的节点之间共享一个账本吗？于是，这不就还是要用到区块链吗？而且，这会产生更严重的性能瓶颈——原本只有中心需要记录整个账本处理所有交易，但现在每个银行都需要实时处理所有交易了，这并不能达到将压力分散给商业银行的目的。

实际上，我们不一定要用到真正意义上区块链——区块链考虑的是一个完全无信任的场景，而在DC/EP的场景中却并不是这样——实际上，2015年伦敦大学学院提出的央行数字货币RScoin就描述了这样一种结构。

简单地说，我们假设每个地址和银行的对应关系对所有银行已知。然后，考虑在A行的小明想要付100元给B行的小红。

1，小明通过A行的地址将一张100元的电子钞票发给小红，小红向B行的系统发送验钞请求。

2，这个时候，B行系统需要检查a）小明（根据地址判断）是A行的用户；b）小明通过电子签名授权了这笔交易；c）A行签名确认这笔钱还没有花过，并承诺将这笔钱标记为花过了。

3，如果检查通过，则B行将这笔钱添加到小红的指定地址，并且发给小红一个签字的收据。

但这里有一个问题——B行要信任A行确实验证了这笔钱存在并且诚实地将其标记并不再双重支付。而这点，可以通过几个方法来保证：

1，央行的仲裁：以上的步骤中，在交易的时候小明的客户端提供了一个证明上有A行的签名，因此如果A行有不当行为是可以由小明提供证明向央行申诉的。而同理，如果B行行为不当，也可以通过小红提供证明被央行发现。

2，可以引入冗余：以牺牲部分效率为前提，让每个地址由多个银行（例如3个）负责，然后获得其中多数的签名才被视为合法。

3，可以引入拜占庭容错算法：引入冗余相当于将多个银行视为一个只会出现一般错误的系统，我们也可以考虑其中有恶意的情况，于是采用拜占庭容错算法来保证输出结果的一致。

以上三种做法的实施就很灵活了——对于一些较为可信的机构，可以只用第一种，而对于较为不可信的机构，则可以采用第三种。而另一个可以灵活改动的地方是——其中的三个步骤：1）付款银行检查是不是有这笔钱；2）付款银行将这笔钱标记为花过；3）收款银行将这笔钱计入，是可以分开考虑的。而在姚前之前那段引文中，我们就看到了这样的提案——检查的步骤可以采用拜占庭容错算法来保证安全，而其他两个步骤可以不通过拜占庭容错算法进行来保证效率。

但这里需要注意的一点是——即便需要参与验证的是所有银行，并且采用拜占庭容错，这仍旧不是一个传统意义上的区块链系统，这点我下一节会详细解释。

然后，在每天结束的时候，央行负责汇总所有的账本，然后，重新发放新币给各个用户的地址。

但以上这种做法引来的一个问题是隐私和匿名问题——因为不是每次交易都重新发放货币，一天之内货币的流动是可以被追踪到的——这样可能会导致隐私泄露。因此，可以采用的方法是类似比特币“非实名”的方法。用同一个账号生成不同的地址收款和付款，但只有所在银行和中央银行可以计算出这些地址属于同一个人，而其他机构只能看到这些账号来自同一个银行。

这种方法，可以在匿名性上添加另一层保护。

4，DC/EP的钱包/客户端

首先非常重要的一点——DC/EP的钱包和如同比特币一样的加密货币的钱包非常不同！

原因是，如上文所述的DC/EP的系统不是拜占庭容错的，甚至不是一般容错的，即便在交易验证和录入的时候采用了拜占庭容错算法也并不能使整个系统拜占庭容错——这也就是为什么说它不是个区块链的原因。

这个系统是完全可能出现单点故障的，而这个单点就在钱包/客户端。

上面这套系统的冗余设置和央行的仲裁机制只能保证在商业银行和央行这里不出错，而对于客户端，我们的假设是用户没有理由去刻意制造不一致——比如小明付钱给小红的场景，比如为了买东西，小明肯定希望想小红证明付款成功，于是他有义务给小红提供一个“我的100元是真钞”的证明，而在提供这个证明的时候，这个钱就已经转出了。而小红收到了钱，自然是为了以后去用，那么她也有动机去把这个证明发给自己拥有的地址所对应的机构，否则这笔钱她以后就花不了。

但以上的这些步骤，肯定是会由银行集成到一个钱包中的。从逻辑上讲，商业银行自然也不会刻意制造不一致，但是只要是软件就可能出bug，而且在现实的网络中，有可能出现丢包或者信号突然断开的情况。而实际上，在以上的系统中这个钱包如果出现了问题是很容易引起整个账本的不一致的。例如在让所在的银行开具合法的证明的时候，如果采用了冗余机制有三个银行负责验证，如果客户端只给其中一个发了合法证明的请求，然后断网，然后由于系统bug在重连之后没有给另两个机构发请求，或者由于断网时候的操作，在重连之后对另两个账本请求了不同的交易，那么就会造成其中一个账本和其他两个账本的不一致。类似这种情况造成的不一致是系统设计之外的，可能会导致非常难以预料和解决的后果。

因此，钱包的安全性是至关重要的，因为与比特币之类的传统加密货币不同，钱包是整个系统安全性的一部分。比特币的钱包出故障，丢的最多是使用者的钱，而不是影响到比特币账本的一致性，但DC/EP的钱包如果出了故障，可能会导致整个系统的账本出错或者瘫痪。

而基于此，就有了接下来的推测：

1，DC/EP是人民币的数字化，仅此而已——因为从技术路线上，这个系统是封闭的，而且即便到未来也是不可能完全开放的，也就是钱包和账本都仅仅会开放给少数经过授权的机构才能开发，并且需要经过长时间的测试和授权机构的检验和认证——这代表了不可能使用DC/EP开发Dapp或者进行DeFi这种金融创新，也不会是所谓的“可编程货币”，这点与Libra的愿景以及许多类似的项目和虚拟货币相去甚远。因为开发者最多只能和用支付宝一样，调用授权钱包给出的转账接口，而无法直接向账本发出请求或者发起交易。

2，这个钱包大概就是现在农行内测的重点。由于目前内测范围仅限农行，我倾向于认为目前阶段仅仅考虑央行和农行两个机构，在验证的部分也不考虑加入其他机构的冗余设计。因此，未来能够加入DCEP的，大概率在一开始仅有五大行。

3，对于匿名性——由于钱包和银行账号绑定，因此采用A行钱包转账实际上无论从DC/EP的逻辑上，还是从银行内部实现的方式上，都应该十分类似于使用银行账户进行转账，但两者并不一定绑定在一起，也就是所谓的“松耦合”的概念。

4，在技术上，DC/EP提供了框架，但是对于央行来说实际上重要的是：1，货币以中心账本登记的为准，商业银行仅是代管，账本需定期向中央银行汇总；2，商业银行内部可以采用任何技术，例如账本上重新建一个数据库也好，采用已有的账户也好，交易验证完全中心化靠信用背书也好，相互之间采用区块链技术来提升沟通效率或者安全性也好都没问题，央行欢迎你们尝试各种技术，但是，汇总到总帐本的格式需要一致，数据要可靠，而且最终的账本还是以央行汇总的为准。

5，双离线支付

DC/EP的一个与现在的支付宝/微信支付的一个重大不同是双离线支付，其中一个被用来举例的场景就是在连线状态下，两台手机互相碰一碰就完成支付。

其中，两台手机互相碰一碰的部分可以通过蓝牙或者NFC进行信息互换，但核心的双离线的方式，根据数字货币研究所所申请的专利，可能会需要用到可信硬件。

具体方法是：在支持TEE（可信执行环境）的手机里，规定离线支付需要通过TEE进行签名并且检查没有进行过双重支付，这个时候双离线支付的安全性实际上交给支持TEE芯片的生产商进行担保。这样，首先破坏TEE的技术难度较大成本较高，其次，手机芯片也是实名的，如果TEE芯片安全性被破坏，则可以追责并且可以将该设备列入黑名单。

但根据专利中的内容来看，双离线支付应该只适用于临时和小额的场景，收到的钱需要通过上线同步到账本之后才能再次使用——这点其实并不难理解，因为如果离线收到的钱可以一直在离线状态使用，相当于同时存在了两个账本，或者说两种数字货币。一种在线的数字货币安全性由央行担保，而另一种离线的数字货币的安全性由各个TEE芯片生产商担保。这不符合DC/EP的逻辑。

而如果仅仅将双离线支付作为一个临时的手段的话，那么TEE仅仅作为一个离线状态下小额资金的一个临时托管方，这样即便TEE的安全性被破坏，也不对DC/EP的安全性造成影响，央行也在要求TEE的生产方补偿损失的时候也更容易计算。

————————————————————————————

然而，其实以上的逻辑不需要TEE也可以实现，比如把TEE换成一个实名的和手机绑定的银行客户端——这个客户端在代码中写死以上的逻辑，然后，如果发现客户端被修改导致了数据错误，就把绑定的手机写上黑名单并对持有者追责。实际上两者的效果是一样的，区别就在于TEE的安全性更高一些而已。

但是，从逻辑上来讲，双离线支付单纯通过钱包也是可以实现的——毕竟，按照之前的设计，从央行的角度讲，所有当日的交易在未写入总帐本之前都属于银行代管，本身就依托于双方银行的信用，而如果钱包软件也由双方银行提供，那么由钱包软件暂时托管货币也相当于双方银行对货币的安全性负责。

6，DC/EP的基本结构

通过以上分析，我推测DC/EP的基本结构如下：

其中，中央银行拥有一个DC/EP的总帐本，账本采用基于价值/基于代币的结构，记录所有已发行数字货币的使用和回收情况。如果正在流通，则记录其当前所有者以及所在银行。每隔一段时间（例如每天），央行从商业银行和其他可信机构那里通过中心化的方式汇总而成当日的账本，然后进行检查和比对，对于账本出现不一致的情况，中央银行拥有仲裁权。然后，对于所有还没有在央行登记的交易（当日的交易），央行在总帐本上进行登记并收回已经使用过的货币，并将等额的新的匿名货币发给相应的地址。最后，将新的当日流通货币的编码发布给所有验证机构。

同时中央银行负责管理一个身份数据库，记录所有地址对应的身份。这个身份数据库既不对内也不对外公开，仅仅在涉及犯罪行为的时候才可以查阅相关人员的地址信息。

此外，中央银行管理一个查询接口和一个交易录入接口，前者可供公开验证（当日）账本的正确性和完整性，和对每一笔货币进行有限的追溯（不过是非实名的地址），后者仅供认证的钱包接入用于更新交易账本。商业银行各自维护自己当日的账本（总帐本不做要求，因为央行那里有总帐本），要求保持安全性和可用性。这里，这个账本可能是该机构用户的账本，也可能包括该机构之外其他机构的账本（冗余设计）。但是账本及整个图中蓝色方框部分都只有地址信息，没有用户信息。这部分账本是匿名的——每笔交易除了当事人，涉及到的银行，钱包提供方以外，没人能够从交易中得出任何关于交易双方或者当日之前资金来源的信息。

央行授权商业银行或者其他可信机构开发钱包，并且需要通过认证和验收。只有通过钱包可以获得DC/EP和进行交易。这里，DC/EP的钱包是整个系统的重要部分，因此并不能任意开放给第三方。

对于用户而言，在使用DC/EP的时候，可以将整个DC/EP（绿色部分）看作黑盒子，仅仅通过钱包互动。但也可以通过第三方调用查询接口查阅账本和验证自己的交易记录是否和钱包提供的相符。在隐私方面，钱包是实名的，因此钱包提供方会在央行的监督下管理用户信息。用户在注册钱包的时候需要把个人信息通过钱包存入身份数据库。

于是，如果小明想要通过A行的钱包和A行的地址向B行的小红发一张100元的数字货币（简便起见，我们考虑面对面付款），有如下的交易流程：

1，小明与小红使用的钱包间通过二维码或者NFC通信，获知小红在B行的一个收款地址。

2，小明的钱包选择一张在小明未花费过的在A行的地址，向交易接口发布交易请求。

3，交易接口按照索引找到该地址对应的A行（以及如果有冗余设计的话的其他行），然后要求他们证明这张货币可用（在央行公布的当前流通货币列表中，并且未被标注使用）。

4，以上的记账机构通过某算法a返回可用证明并声明已标记为使用。

5，小明的钱包收到返回的证明之后，将证明与交易发给小红的钱包。

6，小红的钱包向交易记录接口提交交易，然后交易验证接口根据索引找到相应的地址对应的B行。

7，对应的机构根据算法b将交易加入B行（以及如果有冗余设计的话的其他行）的账本，并返回一个交易已经加入账本的证明发给小红。

8，交易完成。

这里，如果仅涉及单个机构，算法a和算法b可以是简单的读写，当涉及到多个机构的时候，可以是一般容错算法，也可以是拜占庭容错算法。

在账本汇总中，如果出现不一致，中央银行有裁决权。如果结果出现问题，用户可以通过手中的证据向中央银行要求遗失的钱，然后中央银行可以根据证据调查流程中的过失责任方。

双离线支付并没有包含在这个流程中，但可以很容易看出来，双离线支付的逻辑应该内嵌在钱包软件里，在断网的时候触发。于是，这笔交易不会传递到账本，仅仅通过钱包软件记录交换信息完成，暂时记录在硬件中，并由TEE提供商（芯片制造商）或者是钱包提供方担保交易完成，然后再联网之后同步到账本里。

这个结构其实也可以与姚前提的“一币、两库、三中心”的说法对应起来，原文是：

笔者曾提出“一币、两库、三中心”的央行数字货币体系。“一币”即央行数字货币，是由央行担保并签名发行的代表具体金额的加密数字串。“两库”指数字货币发行库和数字货币商业银行库，前者是中央银行在CBDC私有云上存放CBDC发行基金的数据库，按照中央银行的现金运营管理体系进行管理，后者是商业银行存放CBDC的数据库，可以在商业银行的数据中心也可以在CBDC私有云上，遵循商业银行现金运营管理规范。“三中心”则包括认证中心、登记中心和大数据分析中心。 其中，登记中心记录CBDC及对应用户身份，完成权属登记，并记录流水，完成CBDC产生、流通、清点核对及消亡全过程登记。其主要功能组件分为发行登记、确权发布、确权查询网站应用、分布式账本服务几个部分。发行登记进行CBDC的发行、流通、回笼过程及权属记录；确权发布将发行登记的权属信息进行脱敏后异步发布到CBDC确权分布式账本中；确权查询网站依托分布式账本面向公众提供在线权属查询服务；分布式账本服务保证中央银行与商业银行的CBDC权属信息的一致。 通俗来说，可以理解为我们在登记中心利用分布式账本不可篡改、不可伪造特性，构建了一个“网上验钞机”，即CBDC确权账本，对外通过互联网提供查询服务。这种设计对当前分布式账本技术而言，在中央银行和商业银行既集中又分散的二元模式下，提供了一种巧妙的应用思路，一方面将核心的发行登记账本对外界进行隔离和保护，同时利用分布式账本优势，提高确权查询数据和系统的安全性和可信度；另一方面，由于分布式账本仅用于对外提供查询访问，交易处理仍由发行登记系统来完成，以细化原子交易颗粒度的方式来进行交易的分布式计算处理，这样可以通过业务设计的方式有效规避现有分布式账本在交易处理上的技术性能瓶颈。显然，这样的设计充分发挥了区块链的技术优势，保障CBDC验钞的可信，但并未影响中央银行对CBDC的全局管控。 尤其是，这种双账本包容性设计，既延续了传统技术的成熟稳定性，又为新的分布式账本技术留有空间，使得两种分布式技术相互兼容、并行不悖、优势互补，并在演进过程中，竞争择优。

这里，一币自然指的是DC/EP，两库即是中央银行账本和商业银行的账本，前者放在央行的私有云上，后者既可以放在央行的私有云上，也可以放在商业银行数据库里。然后，登记中心即为查询接口接入之后的系统，而认证中心就是交易录入系统接入之后的系统，大数据中心是一个单独的接口，在图上没有画出来。两个接口可以采用不同的共识算法，也就是之前交易流程中的算法a和算法b，按照姚前的说法，算法a可以采用拜占庭容错算法保证安全性，而算法b可以用一般容错算法来保证效率。

——————————————————————————————————

7，总结

笔者的专业是区块链共识算法而非金融，对于央行数字货币的了解仅限新闻、公开资料和部分其他人对于DC/EP的解读，因此本文纯属从技术角度做出的推测，主要有：

1，DC/EP的匿名性采用了类似Ecash的结构，但是用中心替代了盲签名，匿名主要体现每个“数字货币”对于所有除了使用者和央行之外的机构都是同质且匿名的。

2，DC/EP的主体架构不是区块链，但是可能采用了类似RScoin的框架。下属商业银行可以采用已有的基础设施来处理交易，也可以用区块链或者其他技术来实现跨行转账，只要保证每天汇总给央行总帐的账本可靠就行。

3，如果采用了类似RScoin的结构，实际上DC/EP的钱包在保证账本一致性中起到了很重要的作用，因此DC/EP应该会是一个相对封闭和功能单一的系统，也就是仅有数字货币的功能，并且账本仅对认证的钱包开放。

4，双离线认证仅仅作为一个临时的支付手段，可以基于TEE，或者仅仅基于软件，然后靠事后追责的方式实现。

5，最早推出的DC/EP可能是个最小可行性版本，也就是上图中仅留下商业银行1和该商业银行推出的钱包。

6，DC/EP没有考虑过跨境支付场景，如果需要跨境支付可以通过下属机构建立相关设施。

最后，以上纯属推测，对于于实施的偏差笔者不负任何责任，如转载请全文转载以防造成误读。