Zhuang's Diary

Scalable，transparent， and post-quantum secure computational ==> https://eprint.iacr.org/2018/046.pdf 部分内容翻译：

0 介绍

可扩展式验证的计算完整性，超过密文数据集

本文讨论的问题基于如下假设：想象警察 Police(P) 是负责国家法医DNA档案数据库 database(D)，声称一个即将任命(或者据称可能发生腐败案)的DNA档案文件 profile(p)没有出现在D中。加密协议能否说服怀疑者相信警察的声称，并且不进入D或p，不依赖于任何外部信任方（例如，首席大法官）和具有”合理”计算资源？

DNA配置文件匹配 (DNA profile match, DPM) 示例是一个普遍问题的特殊情况。某一方(party, P)在数据集(D)上执行计算(C)能会有错误报告，而不是正确输出 (C(D))，提出了计算完整性问题 (computational integrity ,CI)，以确保P确实报告C(D)。当数据集 D 是公开时，任何有兴趣验证 CI 的一方 (verifier, V) 都可以在 D 上重新执行 C 并将其输出与 P 报告输出进行比较，因为客户可能会检查餐厅账单，或作为一个新的比特币节点将验证其区块链。此原始的解决方案无法扩展，因为验证器 (Tv)花费的时间与执行程序 (Tc)所需的时间一样大，V 必须读取完整的数据集D。基于加密哈希函数的承诺方案常用于计算大型数据集 Dt，t 时刻状态的”指纹”哈希为cmt。通常，与 Dt 相比，cmt 的长度可以忽略不计，作为公告可以很容易地张贴在块链上。但是，CI 的方案中，我们希望解决扩展性问题，也就是增加参数和计算深度的问题，其中验证时间和计算复杂度近似于 logTc 和 |cmt|(cmt的bit长度)，而不是 Tc 和 |Dt|；至少 验证时间/通信 应该严格小于 Tc 和 |Dt|。

当数据集 D 包含机密数据时，无法再实现原始的解决方案，并且负责D的P方可能以保密的面纱隐瞒违反计算完整性的行为。当对机密数据强制实施 CI 的方法则依赖于”受信任方”，例如审计师或会计师代表公众验证计算。此解决方案不提供可扩展，就像数据公开的方案一样。更糟糕的是，它要求公众信任第三方，这创造了一个潜在的协议中的失败点，因为第三方可能违反协议，如收到恶意方贿赂或胁迫。

零知识(ZK)证明和论证系统是取代人工审核员的自动化协议。为了保证计算完整性同时基于机密数据，实现有效的计算，消除腐败并降低成本。ZK系统中，S和计算C是一对随机算法，S=(P, V)；证明人 P 是用于证明计算完整性的算法；验证人 V 检验这样子的证明(proofs)。S 的完整性和健全性意味着 P 可以有效地证明所有真相，但无法说服 V 任何谬论。关于 ZK 系统针对通用计算的可扩展式验证，最早出现在1990年代，基于 Probabilistically Checkable Proofs (PCP) 这一篇论文。PCP 定理提供了一种平衡，证明人构建证明花费的时间(Tp)和验证人验证的时间(Tv)的平衡。这种平衡意味着生成证明的时间多项式式增加(Tp=Tc多项式)，同时验证时间指数式增加(Tv=logTc多项式)。

基于PCP定理（ZK-PCP）的ZK系统具有三个附加优点，这使得公众信任计算完整性至关重要。

(一) 这些构建安全的假设被建造起来了。即交互式解决方案具有抗碰撞哈希函数，非交互式函数具有对随机函数(“随机预言模型”) 的通用访问权限，这些理论基础在目前认为还不会受到大型量子计算机的影响，我们称之为后量子安全(post-quantum secure)。量子计算机规模以及对后量子密码协议的需求都在增长，如，美国国家标准与技术研究院技术(NIST)强调了后量子安全ZK解决方案的重要性。

(二) ZK-PCP是知识证明(proof of knowledge, POK)系统，或者当如上所述实现时，是知识论证(argument of knowledge, ARK)系统。非正式地，在DPM示例的背景下，ZK-ARK是一个证明，使公众相信警察已经使用了“真实的”数据集Dt和总统候选人DNA配置文件p，总统候选人的承诺是先前已经宣布过的。

(三) 最重要的是，ZK-PCP是透明的 (或“公共随机性”)，这意味着验证者使用的随机性是公共的。特别是，与更加新一些的ZK解决方案（包括Zcash加密货币使用的解决方案）相比，ZK-PCP不需要外部受信任的设置阶段。透明性对于能否取得公众信任至关重要，因为它限制了当事人P滥用系统的能力，因为，只要在可观察的宇宙中存在不可预测的事物，透明的系统就是公众可能会信赖的系统。

综上所述，ZK-PCP是确保公众对机密数据CI信任的最佳方法，并具有六项核心优点。

(一) 透明性；

(二) 普遍性—适用于任何有效的计算C，即使它需要上述Dt之类的辅助输入；

(三) 机密性，即零知识性(ZK)—请勿破坏Dt等辅助输入；

(四) 后量子安全；

(五) 基于知识的证明(或者论据)；

(六) 可扩展的验证。

虽然 ZK-PCP在上个世纪90年代已经被知晓，但并没有被实现，因为“PCP定理产生的证明既漫长又复杂，以至于要花费数千年的时间来生成和检验它们，并且将需要比宇宙中原子更多的存储位”。ZK系统在为通用计算的努力过程中，仍没有完全实现 (一) — (六) 的替代技术上，尽管某些算法对于某些具体的电路尺寸和计算开销是有效的。

1 本文的主要贡献

我们在IOP(Interactive Oracle Proofs)模型中提出了一个（双重）可扩展和透明的ZK系统的新结构（Scalable Transparent IOP of Knowledge, ZK-STIK）。我们将该系统实现为ZK-STARK，并将其应用于概念验证POC“有意义”的计算，该计算本质上是高度顺序的，如前面介绍的DPM问题。我们实现了如下两点：

(一) 验证时间严格小于原始运行时间 (Tv<Tc)

(二) 通信复杂度严格小于见证人大小

本系统中核心创新和改进性能的主要来源是对IOP模型的扩展，包括快速FRI (Fast Reed-Solomon (RS) IOP of Proximity (IOPP)) 协议，这里的IOP是 Interactive Oracle Proofs，还有一个新的算法规程。我们强调，验证时间和验证大小适用于为任意见证者定义的任何计算，尽管加速实现的具体点取决于计算的复杂性。

DNA档案匹配计算

ZK-STARK是一个“有意义”的概念验证(POC)，特别适用于DNA档案匹配问题(DNA profile match (DPM))。该计算做出了以下场景假设：假设警察(充当证明人P)负责国家法医DNA档案数据库(D)，并且在先前时间的t，发布数据库状态Dt(例如，在区块链上)隐藏承诺cmt。警察现在声称，即将任命的和据称腐败的总统候选人的DNA档案p没有出现在Dt中，因此希望以可扩展的方式创建一个有说服力的证据，使得公众认为DPM计算正确无误，并且警方报告的输出(关于p和Dt)是正确的。

在超过50个国家/地区中使用的DNA图谱的主要标准是联合DNA索引系统(CODIS)格式； 根据该标准，个人由其DNA的短串联重复序列(STR)表示，针对一组20个“核心基因”进行了测量。假定对CODIS数据库状态Dt的承诺(commitment) cmt是公共信息(如，在时间t，公开于区块链之上)，对于总统候选人简历p的承诺是cmp。我们假设p是由独立实验室提取的，然后在公开发布cmp时将其(秘密地)交给了警察。 假设警察宣布：

“该值a是在具有承诺cmt的数据库中，对具有承诺cmp的档案文件进行匹配搜索的结果”

答案是三种可能性之一：“不匹配”，“部分匹配”或“完全匹配”。公开(开源)计算C是将由可信任的第三方执行的用于验证上述声明的计算。此计算需要三个公共输入(cmt, cmp和A)，以及两个机密输入：DNA文档数据库D’和个人DNA文档文件p’。当且仅当公共输入(cmt, cmp, A)和机密输入(D’, p’)满足以下三个条件时，计算C则成功终止：

(i)针对机密输入D’的承诺cm’与公开输入cmt相等；

(ii)针对机密输入p’的承诺cmp’与公开输入cmp相等；

(iii)在机密数据集D’中对机密输入p’进行匹配搜索后，得到输出则会公开宣布结果a.

令|D(n)|为数据集D(n)的比特长度，n为DNA档案的条目数量(每条档案为40字节长度)。令CC(n)为ZK-STARK的通信复杂度，数据集仍然为D(n)，例如，在证明人与验证人之间，总的通信比特值。令Tc(n)为原始验证计算C在D上执行时，数据量为n时，所耗费的时间。令Tv(n)为V验证所耗费的时间。以上时间是同为一台物理服务器上测试所得。

2 讨论 — 权力下放的社会职能的应用

以比特币为首的加密货币通过建议完全分布式的货币体系来代替法定货币，加密货币同时正在破坏已建立的金融系统。 金钱只是可以分布式的社会功能之一，法律合同已经被以太坊区块链中的自动智能合同取代。 在本节结束时，我们将讨论ZK-STARK系统对分散式公共分类账的两个预期影响。

可扩展性

现如今，在区块链中进行了激烈的讨论，围绕着适当的方式来扩展交易吞吐量，而又不会增加参与网络的节点的时间和空间。正如其中一位作者首次指出的那样，并且最近被数种加密货币计划所采用，完全可扩展的证明系统(即使没有零知识)也可以通过成倍地减少验证时间来解决可扩展性问题。更详细地讲，单个“证明人节点”可以在准线性时间内生成一个证明，该证明将说服其他节点接受账本当前状态是有效的，而无需那些节点原始地重新数据库查询计算，也不需要存储整个区块链的状态。

隐私性

ZK证明的保密性已被用于增强加密货币的互换能力和隐私能力。最近在Zcash加密货币中实现并使用一种特殊的零知识证明，即ZK-SNARK，它基于密码学指数知识(knowledge of exponent, KOE)的假设，以完整地维护其条目的分布式注册表，该注册表隐藏着未动用资金的承诺。

ZK-SNARK(zero-knowledge succint non-interactive arguments of knowledge。Zero knowledge：零知识证明；Succinctness：证据信息较短，方便验证；Non-interactivity：无交互，证明者基本上只要提供一个字符串义工验证。对于区块链来说，这一点至关重要，意味着可以把该消息放在链上公开验证；Arguments：证明过程是计算完好（computationally soundness）的，证明者无法在合理的时间内造出伪证（破解）。跟计算完好对应的是理论完好（perfect soundness)，密码学里面一般都是要求计算完好；knowledge：对于一个证明者来说，在不知晓特定证明 (witness) 的前提下，构建一个有效的零知识证据是不可能的。

ZK-SNARK是不是透明的，因为它们需要一个“设置阶段setup phase”，该阶段使用了非公开的随机性，如果受到损害，则可以用来损害系统的安全性。展望未来，ZK-STARK可以替代ZK-SNARK，透明地实现Zcash的可替代性和机密性。当前，ZK-SNARK比ZK-STARK证明size小约1000倍，因此用ZK-STARK替换ZKSNARK还需要进行更多的研究以缩短证明长度，或者使用可增量验证的计算来汇总和压缩多个ZK-STARK证明。例如，ZK-SNARK的证明size为几百bytes，ZK-STARK的证明size为几百Kbytes。

3 与其他的ZK系统相比较

hPKC — Homomorphic public-key cryptography 同态公钥密码，如Pinocchio和libSNARK。

DLP — Discrete logarithm problem 离散对数问题，如BulletProofs。

IP — Interactive Proofs 交互式证明。如Hyrax。

MPC — Secure multi-party computation 多方安全计算。如ZKBoo、Ligero。

IVC — Incrementally Verifiable Computation 增量可验证计算。如hPKC-based IVC。

具体测试指标

测试均基于同一个硬件服务器，基于同样的DPM问题。

Arithmetic circuit complexity as standard measuring yard — 算术电路复杂度作为标准测量场。此处测试的所有系统(包括ZK-STARK)均为算术化之后的运算，将计算完整性(CI)语句简化为相关的有限域上的低次多项式系统。我们强调ZK-STARK也可以在素数场上运行，但代码中尚未实现。

在DPM计算中，数据库中具有n条数据，算术电路的参数如下：

• 电路深度 depthn = 62·n

• 电路宽度 w = 81

• 验证复杂度 witn = 40·n bytes

• 乘法复杂度 multn = 1467·62·n ≈ (2^16.4)·n

  我们对ZK-STARK系统(证明方+验证方)进行了测量，本ZK-STARK具有60位(bits)的安全性，即n最大值≈60。libSNARK、SCI具有80位的安全性。BCCGP具有128位。Ligero具有60位的安全性。我们预估80位证明者的证明时间比60位最多长5％。如果您看到下图，则它们还包括一个没有setup的libSNARK线，并且明显位于ZK-STARK线之下。

总结

在上述以对照的方式进行测试，ZK-STARK是测量的所有电路尺寸中生成证明最快的，特别是与libSNARK相比较，速度快了近10倍。在小电路情况下，ZKBoo和Ligero的通信时间更短，验证更快。在深度较小的电路的情况下，Hyrax的通信时间更短，验证更快。在同一固定电路上多次重复的计算，BulletProofs, Pinocchio, libSNARK的通信时间更短，验证更快。但是，对于一般的大规模计算，ZK-STARK的验证时间和通信复杂性优于其他透明系统。换句话说，我们对ZK-STARK的实践表明，对于实际相关的具体计算(例如DPM)，已经充分体现了完全可伸缩性和透明性的优势，并表明我们的系统类型对于构建可伸缩性解决方案很有用， 例如，用于分布式的加密货币。

2020年1月21日，国际清算银行（BIS）、加拿大央行、英国央行、日本央行、欧央行、瑞典央行和瑞士央行官网同时发布一则信息：成立央行小组，开展CBDC应用案例研发。

加拿大

加拿大央行与瑞典央行已进入CBDC的试验测试阶段：2016年加拿大银行和新加坡金融管理局分别启动了Jasper和Ubin项目，探索分布式账户技术（DLT）在银行间大额支付系统的应用。双方都采用了R3联盟的DLT技术，开发了国内银行间支付结算的批发型数字货币原型系统，并经过几个阶段的后续试验验证，但仅限于在国内尝试。2019年加拿大银行和新加坡金管局合作开发Jasper-Ubin项目，在没有中介代理的环境下，实现了跨境、跨币种和跨平台支付中应用CBDC的试验成功。可以说在批发型CBDC应用于银行间大额支付结算和跨境支付方面，加拿大央行已经进入了概念验证试验的阶段，走在国际前列。

瑞典

瑞典央行的情况与加拿大不同，其无现金化趋势和速度为全球关注。发行CBDC“电子克朗“的目的是确保国家货币发行权、维护国内支付结算体系稳定发展、让金融服务普惠社会各类群体。从2017年启动电子克朗研发计划到目前进入测试阶段。它着眼的方向是零售型CBDC。

英国央行与欧央行对CBDC进行了原型设计与概念验证：笔者前文《英国：发行数字货币，还是发行塑料钞，这是一个问题》对英国开展数字货币的研发有介绍。简单说，英国作为全球首个央行数字货币模型RSCoin的创始者，虽然后来没有像加拿大、瑞典那样有更实质性的动作，但研究的步子一直没有停顿。加新两国的联合项目，也有英国的参与：2018年下，英格兰银行和加拿大央行、新加坡金管局以及4家商业银行、2家第三方机构参与了Jasper项目第4阶段的研究活动，对解决跨境支付存在的挑战和摩擦，创建交易新模式提出了建议，为2019年加新两国的DLT系统对接奠定了研究基础。此外，英国央行前行长马克·卡尼提出了一个“合成霸权货币”的概念，意欲以此取代目前以美元为主导的国际货币组合。

欧央行

对CBDC的研发早已做了大量准备工作，拉加德就任行长以来，欧央行在CBDC方面的研发大幅度提速，最近在它主导下，十几个欧盟国家央行与埃森哲和R3联盟合作，开发设计了一种基于DLT的“欧洲链”系统，解决CBDC小额支付中隐私与反洗钱的平衡问题。并经过概念验证。

日本

日本央行与瑞士央行暂处于CBDC理论研究阶段：日本是一个现金偏好明显的国家，80%日常购物仍使用现金（《日本时报》，2019）。甚至在2019政府为抵销消费税上涨而推出的非现金支付积分奖励情况下，民调50-70岁以上的人仍有31%至 54%无意使用非现支付手段（《每日新闻》，2019）。显然缺乏开展零售型CBDC研发的动机。天秤币发行计划推出后，日本官方态度保持低调，直到12月央行行长黑田东彦还称，当前没有推出CBDC的需要。但最近，其副行长雨宫正佳（Masayoshi Amamiya）表示：“在日本，公众对CBDC的需求可能会激增，这取决于结算系统的发展情况。如果发生这种情况，我们必须做好应对的准备。”

去年底央行发表了一个有关CBDC法律问题的报告，对CBDC发行后给现行私法和刑法、日本银行法、数据收集法、行政法和竞争法等法律领域带来的影响进行了探讨，是目前所见CBDC研究中讨论法律问题最为全面、深入的报告，说明准备工作并没有停顿。

瑞士

瑞士情况和日本相似，公众有强烈的现金偏好，即使是年轻人如此。其他国家纷纷出于反洗钱和反恐融资等目的而取消大面额现钞，降低现金消费限额，而瑞士法郎仍然保留最大面额1000瑞郎，现金交易上限是10万瑞郎。对于私人加密货币的态度它也和日本一样比较友好，有众多加密货币机构在瑞士设立。央行高管曾表态数字货币还是私有化比较合适，去年底瑞士联邦委员会仍称CBDC目前不会给瑞士带来好处，相反将引发金融稳定等风险。

美国

DIGITAL DOLLARS: ELECTRONIC CASH VS DIGITAL CURRENCY
New technological capabilities have created a dynamic, via tokenization, that allows for a digital version of central bank currency, without sacrificing stability, security or privacy. This is about more than a federal government payments infrastructure.

In addition to coins and paper money, a dollar-based Central Bank Digital Currency (CBDC) could operate as a third form of money backed by the full faith and credit of the United States of America, but brings it into the truly portable digital world, opening up new possible use cases and applications.

Considering the importance of the U.S. dollar to the global economy, our work on a U.S. dollar-based CBDC via the Digital Dollar Project is a logical and important step as we drive towards a digital transformation of the global financial system.

The Digital Dollar Project will be driven by an open, innovative, collaborative mindset, which will explore the full range of possibilities on how to best bring this to fruition

数字美元：电子现金与数字货币
新的技术通过Token化创建了一种动态的功能，该功能允许在不牺牲稳定性，安全性或私密性的情况下使用数字版本的中央银行货币。这远远超出了美国联邦政府的支付基础设施。

除硬币和纸币外，以美元为基础的中央银行数字货币（CBDC）可以作为第三种形式的货币，以美利坚合众国的充分信仰和信誉为后盾，但将其带入真正的便携式数字世界，打开新的可能的用例和应用程序。

考虑到美元对全球经济的重要性，在我们朝着全球金融体系的数字化转型迈进的过程中，我们通过“数字美元项目”在以美元为基础的CBDC方面的工作是合乎逻辑且重要的一步。

数字美元项目将以开放，创新，协作的心态驱动，它将探索各种方式来最大程度地实现这一目标。

和中国CBDC的设计几乎完全一致。本白皮书内容中并未提及”blockchain”。白皮书作者为Digital Dollar Project办公室与埃森哲

中国

中国人民银行拟推出的CBDC本质上是法定货币人民币的数字化版本，由法币储备（M0）按照1比1的比例进行兑换。

“从央行角度来讲，无论你是区块链还是集中账户体系，是电子支付还是所谓的移动货币，你采取任何一种技术路线，央行都可以适应。当然，你的技术路线要符合我们的门槛，比如因为是针对零售，至少要满足高并发需求，至少达到30万笔/秒。” 穆长春在会议上说到。

易纲在新闻发布会上表示，人民银行把数字货币和电子支付工具结合起来，将推出一揽子计划，目标是替代一部分现金。

作为理论上无成本的交换媒介，CBDC将能够提高支付系统的效率。 同时，在跨境金融交易的情况下，CBDC可以促成更快，更安全的结算，并允许数字金融服务领域进行更多的创新。此外，CBDC的推出还有助于打击假币，因为每个令牌和交易都需要由集中式系统进行实时的密码验证。

农业银行的PoC如下：

姚前

2020-04刊文

目前大多数国家的央行数字货币（Central Bank Digital Currency，CBDC）实验都是基于区块链技术展开的。但时至今日，CBDC是否采用区块链技术依然存有争议，一种典型的观点是区块链的去中心化与中央银行的集中管理存在冲突，因此不建议CBDC采用该技术。笔者认为，区块链技术正以前所未有的速度在发展，并与各项主流技术在深度融合，因此无论从技术角度还是业务角度，现实应用中的区块链都与“原教旨主义”的理解有所不同。如何运用区块链技术来更好的服务于中心化管理下的分布式运营，可能是CBDC当前需要重点探索的方向。本文以三个典型场景为例，讨论了区块链在CBDC中的可能应用和解决方案，指出虽然区块链的技术特点是不依赖中心机构，但不代表其不能纳入到现有中心机构的体系内，只要通过合理的设计，中央银行恰恰可以利用区块链将分布式运营有效整合起来，更好地实现对CBDC的中心化管控，两者并不存在必然冲突。

场景一：CBDC验钞

笔者曾提出“一币、两库、三中心”的央行数字货币体系。“一币”即央行数字货币，是由央行担保并签名发行的代表具体金额的加密数字串。“两库”指数字货币发行库和数字货币商业银行库，前者是中央银行在CBDC私有云上存放CBDC发行基金的数据库，按照中央银行的现金运营管理体系进行管理，后者是商业银行存放CBDC的数据库，可以在商业银行的数据中心也可以在CBDC私有云上，遵循商业银行现金运营管理规范。“三中心”则包括认证中心、登记中心和大数据分析中心。

其中，登记中心记录CBDC及对应用户身份，完成权属登记，并记录流水，完成CBDC产生、流通、清点核对及消亡全过程登记。其主要功能组件分为发行登记、确权发布、确权查询网站应用、分布式账本服务几个部分。发行登记进行CBDC的发行、流通、回笼过程及权属记录；确权发布将发行登记的权属信息进行脱敏后异步发布到CBDC确权分布式账本中；确权查询网站依托分布式账本面向公众提供在线权属查询服务；分布式账本服务保证中央银行与商业银行的CBDC权属信息的一致。

通俗来说，可以理解为我们在登记中心利用分布式账本不可篡改、不可伪造特性，构建了一个“网上验钞机”，即CBDC确权账本，对外通过互联网提供查询服务。这种设计对当前分布式账本技术而言，在中央银行和商业银行既集中又分散的二元模式下，提供了一种巧妙的应用思路，一方面将核心的发行登记账本对外界进行隔离和保护，同时利用分布式账本优势，提高确权查询数据和系统的安全性和可信度；另一方面，由于分布式账本仅用于对外提供查询访问，交易处理仍由发行登记系统来完成，以细化原子交易颗粒度的方式来进行交易的分布式计算处理，这样可以通过业务设计的方式有效规避现有分布式账本在交易处理上的技术性能瓶颈。显然，这样的设计充分发挥了区块链的技术优势，保障CBDC验钞的可信，但并未影响中央银行对CBDC的全局管控。

尤其是，这种双账本包容性设计，既延续了传统技术的成熟稳定性，又为新的分布式账本技术留有空间，使得两种分布式技术相互兼容、并行不悖、优势互补，并在演进过程中，竞争择优。

场景二：批发端支付结算

目前各国正在开展的CBDC实验，主要针对批发端场景，且大多基于区块链技术。比如，加拿大的 Jasper 项目，试验基于区块链技术的大额支付系统；新加坡的Ubin项目，评估在分布式账本上以数字新元的代币形式进行支付结算的效果；欧洲央行和日本央行的Stella项目，旨在研究分布式账本技术（DLT）在金融市场基础设施中的应用，评估现有支付体系的特定功能是否能够在DLT环境下安全高效地运转。还有中国香港的LionRock项目、泰国的Inthanon项目等均是试验基于区块链技术的CBDC。这些区块链技术的应用都在中央银行的集中管理和严格控制下展开。

以新加坡的Ubin项目为例，其采用了与加拿大Jasper项目一样的数字存托凭证（Digital Deposit Receipt，DDR）模式。为了支持分布式账本中DDR的发行，现有新加坡电子支付系统（MEPS +），也就是新加坡的RTGS系统，专门建立一个DDR资金抵押账户，每日开始时，参与银行请求中央银行将其RTGS账户中的资金转移到DDR资金抵押账户，以此作为抵押，分布式账本创建相应等值的DDR，发送到各银行的DDR钱包，由此参与银行之间可开展基于分布式账本的转账和支付。日终，分布式账本系统将向MEPS+发送一个网络结算文件，MEPS+依此调整DDR资金抵押账户余额，匹配参与者在DLT网络中的DDR余额。

可见，去中心化的分布式账本与现有成熟的中央主导的金融基础设施并不排斥，完全可以相互融合，相互补充。一方面，基于区块链的DDR支付系统为现有RTGS系统提供了一种不依赖传统账户的新型支付方式，有效补充了现有支付清算体系。另一方面，DDR作为RTGS中电子化法定货币的数字化形态延伸，其最终可以转换回RTGS账户价值，并通过RTGS系统对外结算，也就是说，RTGS系统解决了区块链DDR到传统账户资金的结算最终性问题，这侧面也说明了区块链的结算最终性可以有机融合到现有清结算体系中。此外，由于DDR 是通过100%资金抵押生成，不影响货币供应量，因此分布式账本也不会影响到中央银行对货币的总量管控。

显然，在技术逻辑上，中央银行主导的基于区块链的新型支付系统是完全可行的。某种意义上，参照Ubin项目的数字存托凭证模式，可以无需借助类似网联支付平台这样的中间渠道，各家支付机构和商业银行可以通过在金融专网中构建对等网络的方式，以统一的区块链网络连接起来，开展支付清算。考虑到目前区块链技术的交易性能还在演进的过程中，上述清算业务宜在批发层面展开。

应该说，区块链的去中心化是指去中介，但不去监管。在联盟链的环境下，中央银行等监管部门不但可以对区块链所承载的业务及其风险进行中心化管控，而且还可以实现穿透式非现场监管。

场景三：现金数字化

似乎现金的数字化与准备金的数字化（即前述的数字存托凭证）没有本质上的差别，只是前者面向社会公众，而后者仅局限于银行间流通，但面向社会公众就引发了一个难题，倘若允许公众在中央银行开户，中央银行将面临着极大的服务压力，并可能引发存款搬家，导致狭义银行。

一种解决思路是100%备付准备金模式。代理运营机构向中央银行存缴100%备付准备金，随后在其账本上发行相应数额的数字货币可视为央行数字货币。IMF经济学家把它称为合成央行数字货币（sCBDC）。据此，我国第三方支付机构100%备付准备金存缴中央银行之后，它们虚拟账户中的资金就是央行数字货币了。若此，则中国早就是全球首个实现法币数字化的泱泱大国。

但仔细琢磨，这一思路存在着缺陷：一是技术上，100%准备金存缴意味着数字货币的发行、流通、回笼等全生命周期均要依附于传统账户体系，尤其是跨机构CBDC的流通，除了CBDC账本更新外，还要处理相应准备金账户间的清结算，只能牺牲系统灵活性，加以额度管控的方式去应对，而且还需要成立专门的清算机构提供互联互通服务。这不仅增大中央银行中心系统的压力和复杂性，也就是说，还是没有解决央行的服务压力，而且难以实现“账户松耦合”的要求；二是管理上，这种方式央行和运营机构在发行流通过程中是紧绑定的，央行依然承担中心化压力。如何保证代理运营机构100%备付准备金后没有超发货币，尤其是当代理运营机构运营的支付网络不受中心化管控时，中央银行更难以掌控运营代理层的货币发行量，这在一定程度上也构成了某些反对区块链技术应用于CBDC的理由。

视角决定思路，如果换一个角度看，会得到另一种完全不同的更优的解决方案。现在提到CBDC，许多人是自顶向下，从中央银行发行到商业银行，再从商业银行发行到个人的视角来理解CBDC的技术逻辑，所以总有一个乱发票子的担忧。实物货币受制于印钞造币环节，非如此不可，但数字货币的“印钞造币”可以瞬间完成，无需这种制约，而这才是其优势所在。如果以自底向上的视角看，可以惊讶地发现，数字货币最终用户并没有“发行”的概念，而是“兑换”的理念，是手里有多少现金，有多少存款，去兑换CBDC。所以从这角度看，乱发票子的问题并没有那么突出，代理运营机构兑换出的CBDC，不是中央银行给与的货币发行额度，而是用户用实实在在的真金白银等额兑换的结果，中央银行只是站在全局的角度统计相关信息并予以监管。实际上，目前无论是私人的稳定代币，还是各国研发的CBDC，都是按需兑换的思路，而不是扩表发行，这是一个非常关键的点。这一点对货币政策而言，意义重大，表明其没有根本性的变化；对于技术路线而言，意味着可以不拘泥于实物货币的发行流程，系统的设计可以更为简洁，局面因此大为改观。

基于自底向上的兑换视角，可以提出一个CBDC简化版实现方案。具体思路是：业务由底层客户发起，客户申请兑换CBDC并将其托管至代理运营机构。代理运营机构记录客户托管CBDC的明细账本，为每个托管客户单独建立明细账。代理运营机构收到客户兑换并托管CBDC请求后，在收取现金或扣减客户存款的同时，将等额CBDC记录在该客户明细账下，然后向中央银行缴回现金或扣减存款准备金，并以批量方式混同托管至中央银行。中央银行记录代理运营机构的总账本，是一个总量的概念，与代理运营机构的明细账本构成上下两级双账本结构。当同一家代理运营机构的客户之间发生CBDC支付时，只需在该机构的明细账本上变更权属，无需变更中央银行总账本。当发生跨代理运营机构的CBDC支付时，首先由相关的代理运营机构交互处理，在各自明细账本上完成CBDC的权属变更，然后由中央银行在总账本上定期批量变更各机构总账。为提高效率，减少风险，可考虑引入持续净额头寸调整、流动性节约（LSM）等机制。

这一方案有以下优点：一是明确了持有者对CBDC具有完全掌控权。未经持有者的签名或同意，其他任何主体均不能动用CBDC。这就使CBDC真正具备现金属性，与存款类货币本质不同。二是央行不对底层客户单独建档，也就是说，普通公众不在中央银行“开户”，降低了中央银行的服务压力，同时真正实现了“账户松耦合”的要求，因准备金账户批量调整，CBDC系统相对独立于RTGS系统。三是各家代理运营机构可以根据自己的理解，在满足统一标准的基础上，发挥各自特长构建自身的数字货币代理运营系统，有助于竞争，便于客户选择。由于是按需兑换，而不是扩表发行，因此就没有了运营代理层超发货币的担忧。另外，虽然底层客户交易信息只存储在中间层，不存储在中央银行账本上，出于政策需要或监管需要，中央银行有权向下一层的代理运营机构提取信息明细，从而在分布式运营条件下实现了中心化管控。

结语

区块链作为一种可能成为未来金融基础设施的新兴技术，对于中央银行和商业银行二元模式而言，有助于实现分布式运营，同时并不会影响集中管理。本文通过三个典型场景进一步论证了区块链技术的去中心化特点可以纳入到CBDC的分布式运营与央行的集中管理体系中。可将区块链技术应用于CBDC的登记账本，对CBDC验钞，保障可信。在批发端场景，各国开展的实验也表明，基于区块链技术的CBDC和支付系统具有可行性。而在现金数字化的零售场景，本文认为之所以目前CBDC研发方案一直无法发挥出央行中心管控下的分布式运营应有的优势，问题在于自顶向下的“发行”视角，对此，本文基于自底向上的“兑换”视角，提出了全新的CBDC实现方案，这一方案同时实现了“管控中心化，运营分布式”的目标。

“物物而不物于物”，“形而上者之为道，形而下者之为器，以道御器”，这是我国古代哲人的思想。集中管理与分布处理历来需要辩证统一地看待，不宜“先入为主”地将制度层面的中心化管控与技术层面的分布式处理简单对立起来。当前，各国基于区块链技术的央行数字货币实验进展迅速，内容已涉及隐私保护、数据安全、交易性能、身份认证、券款对付、款款对付等广泛议题。作为一项崭新的技术，区块链当然还有这样那样的缺点与不足，但这不是我们轻言放弃的理由。Facebook的Libra项目已在研发基于安全、可扩展和可靠区块链的新一代金融基础设施，这是一个全新的赛道，机遇与挑战并存，“逆水行舟，不进则退”。

• Zero-Knowledge Proofs ==> https://zkp.science/
• https://github.com/matter-labs/awesome-zero-knowledge-proofs

CheckTx

在burrow项目中，/consensus/abci/app.go:

1
2
3
4
5

func (app *App) CheckTx(req types.RequestCheckTx) types.ResponseCheckTx {
	......
	checkTx := ExecuteTx(logHeader, app.checker, app.txDecoder, req.GetTx())
	......
}

此处的 ExecuteTx 位于 /execution/execution.go :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

// If the tx is invalid, an error will be returned.
// Unlike ExecBlock(), state will not be altered.
func (exe *executor) Execute(txEnv *txs.Envelope) (txe *exec.TxExecution, err error) {
	......
	// Verify transaction signature against inputs
	err = txEnv.Verify(exe.params.ChainID)
	if err != nil {
		logger.InfoMsg("Transaction Verify failed", structure.ErrorKey, err)
		return nil, err
	}

	if txExecutor, ok := exe.contexts[txEnv.Tx.Type()]; ok {
		// Establish new TxExecution
		txe := exe.block.Tx(txEnv)
		defer func() {
			if r := recover(); r != nil {
				err = fmt.Errorf("recovered from panic in executor.Execute(%s): %v\n%s", txEnv.String(), r,
					debug.Stack())
			}
		}()

		err = exe.validateInputsAndStorePublicKeys(txEnv)
		if err != nil {
			logger.InfoMsg("Transaction validate failed", structure.ErrorKey, err)
			txe.PushError(err)
			return nil, err
		}

		err = txExecutor.Execute(txe, txe.Envelope.Tx.Payload)
		if err != nil {
			logger.InfoMsg("Transaction execution failed", structure.ErrorKey, err)
			txe.PushError(err)
			return nil, err
		}

		// Increment sequence numbers for Tx inputs
		err = exe.updateSequenceNumbers(txEnv)
		if err != nil {
			logger.InfoMsg("Updating sequences failed", structure.ErrorKey, err)
			txe.PushError(err)
			return nil, err
		}
		// Return execution for this tx
		return txe, nil
	}
	return nil, fmt.Errorf("unknown transaction type: %v", txEnv.Tx.Type())
}

此处 txExecutor.Execute(txe, txe.Envelope.Tx.Payload) 因 txExecutor 类型的不同，分别对应至 /txs/payload/payload.go 中的 Type ，如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

// Account transactions
TypeSend  = Type(0x01)
TypeCall  = Type(0x02)
TypeName  = Type(0x03)
TypeBatch = Type(0x04)

// Validation transactions
TypeBond   = Type(0x11)
TypeUnbond = Type(0x12)

// Admin transactions
TypePermissions = Type(0x21)
TypeGovernance  = Type(0x22)
TypeProposal    = Type(0x23)
TypeIdentify    = Type(0x24)

根据 Type 不同，在如下 contexts 对应的 Context 的 Execute 方法则会不同，分别对应为如下代码文件中的 Execute 方法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

├── burrow
│   ├── execution
│   │   ├── contexts
│   │   │   ├── bond_context.go
│   │   │   ├── bond_context_test.go
│   │   │   ├── call_context.go
│   │   │   ├── governance_context.go
│   │   │   ├── identify_context.go
│   │   │   ├── name_context.go
│   │   │   ├── permissions_context.go
│   │   │   ├── proposal_context.go
│   │   │   ├── send_context.go
│   │   │   ├── shared.go
│   │   │   └── unbond_context.go

例如，在执行发送 TypeCall 类型的交易时， txExecutor.Execute(txe, txe.Envelope.Tx.Payload) 对应的具体逻辑为 /execution/contexts/call_context.go 中的 Execute 方法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

func (ctx *CallContext) Execute(txe *exec.TxExecution, p payload.Payload) error {
	var ok bool
	ctx.tx, ok = p.(*payload.CallTx)
	if !ok {
		return fmt.Errorf("payload must be CallTx, but is: %v", p)
	}
	ctx.txe = txe
	inAcc, outAcc, err := ctx.Precheck()
	if err != nil {
		return err
	}
	// That the fee less than the input amount is checked by Precheck to be greater than or equal to fee
	value := ctx.tx.Input.Amount - ctx.tx.Fee

	if ctx.RunCall {
		return ctx.Deliver(inAcc, outAcc, value)
	}
	return ctx.Check(inAcc, value)
}

DeliverTx

在执行 ExecuteTx(logHeader, app.committer, app.txDecoder, req.GetTx()) 中，executor execution.Executor 被指定为 app.committer , 与 CheckTX 执行同样的 Execute 逻辑

Commit

具体执行逻辑为 /execution/execution.go 中的 func (exe *executor) Commit(header *abciTypes.Header) (stateHash []byte, err error)

./burrow natives , Dump Solidity interface contracts for Burrow native contracts.

抽出Burrow内置的solidity接口合约。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69

➜  script ./burrow natives       
pragma solidity >=0.4.24;

/**
* acmstate.ReaderWriter for managing Secure Native authorizations.
* @dev This interface describes the functions exposed by the native permissions layer in burrow.
* @dev These functions can be accessed as if this contract were deployed at a special address (0x0A758FEB535243577C1A79AE55BED8CA03E226EC).
* @dev This special address is defined as the last 20 bytes of the sha3 hash of the the contract name.
* @dev To instantiate the contract use:
* @dev Permissions permissions = Permissions(address(uint256(keccak256("Permissions"))));
*/
interface Permissions {
    /**
    * @notice Adds a role to an account
    * @param Account account address
    * @param Role role name
    * @return result whether role was added
    */
    function addRole(address _account, string memory _role) public view returns (bool _result);

    /**
    * @notice Removes a role from an account
    * @param Account account address
    * @param Role role name
    * @return result whether role was removed
    */
    function removeRole(address _account, string memory _role) public view returns (bool _result);

    /**
    * @notice Indicates whether an account has a role
    * @param Account account address
    * @param Role role name
    * @return result whether account has role
    */
    function hasRole(address _account, string memory _role) public view returns (bool _result);

    /**
    * @notice Sets the permission flags for an account. Makes them explicitly set (on or off).
    * @param Account account address
    * @param Permission the base permissions flags to set for the account
    * @param Set whether to set or unset the permissions flags at the account level
    * @return The permission flag that was set as uint64
    */
    function setBase(address _account, uint64 _permission, bool _set) public view returns (uint64 _result);

    /**
    * @notice Unsets the permissions flags for an account. Causes permissions being unset to fall through to global permissions.
    * @param Account account address
    * @param Permission the permissions flags to unset for the account
    * @return The permission flag that was unset as uint64
    */
    function unsetBase(address _account, uint64 _permission) public view returns (uint64 _result);

    /**
    * @notice Indicates whether an account has a subset of permissions set
    * @param Account account address
    * @param Permission the permissions flags (mask) to check whether enabled against base permissions for the account
    * @return result whether account has the passed permissions flags set
    */
    function hasBase(address _account, uint64 _permission) public view returns (bool _result);

    /**
    * @notice Sets the global (default) permissions flags for the entire chain
    * @param Permission the permissions flags to set
    * @param Set whether to set (or unset) the permissions flags
    * @return The permission flag that was set as uint64
    */
    function setGlobal(uint64 _permission, bool _set) public view returns (uint64 _result);
}

./burrow dump , Dump chain state to backup

1
2
3
4
5
6
7
8

➜  script ./burrow dump local backup_dump
Sourcing config from first of: defaults
Sourcing config from defaults
Sourcing config from first of: genesis file at genesis.json
Sourcing config from genesis file at genesis.json
{"log_channel":"Info","message":"Dumping accounts"}
{"log_channel":"Info","message":"Dumping names"}
{"log_channel":"Info","message":"Dumping events"}

./burrow restore, Restore new chain from backup

从backup文件恢复区块链