可信区块链推进计划办公室副主任杨白雪：解读可信区块链标准和评测

2018可信区块链峰会于10月9日-10日在北京召开。会议由中国信息通信研究院、中国通信标准化协会联合主办，国际电信联盟、可信区块链推进计划、工业互联网产业联盟、中国支付清算协会、互联网医疗健康产业联盟、中国保险学会特别支持。在10月10日举办的可信区块链标准与评测论坛上，中国信息通信研究院高级研究员，可信区块链推进计划办公室副主任杨白雪对可信区块链标准和评测进行了解读。

中国信息通信研究院高级研究员，可信区块链推进计划办公室副主任 杨白雪

感谢各位领导和嘉宾，也感谢各位听众朋友们，来支持我们分论坛的工作。

首先我今天讲的内容大概分为两部分，一部分是践行重要的事情，说三遍的需求，把昨天已经通报过两遍的可信区块链测试情况再为大家详细讲解一遍，昨天博士已经讲的非常到位了，因为我昨天坐在观众席，我大概讲一下我在观众席里听到的某些疑问，在这里为大家做一下解答。

首先是可信区块链测评的依据，这个依据是我们针对可信区块链系列标准来进行测评的。昨天我听到的首先的疑问是，可信区块链系列标准是不是只有这三本？其实不是的，在这次测评中其实已经用到了第四本，在以后可能还会用到第五本，第六本，对接垂直行业的时候可能各自都会有自己的标准。另外就是功能试图，是不是每年都是这些项呢？肯定也不是的，我们对软件的基本诉求是很多年不变的，通用性、易用性、安全性，大致都是这些，但是我们实现的方式多种多样，尤其是对区块链这么一种新兴的技术，它的这个测试方法肯定是要不断地迭代，一定要跟上技术发展的脚步，为技术的安全使用保驾护航。

测评的整体情况大概就是这样，我们对报名前期的审核是比较严的，对于形式和内容的提交都限制的比较死，所以说报名的42家最终是只有20家参与了测试。性能测试这个非常抱歉，因为我们机房的排期导致已经报名的10家只有7家顺利进行了测试，明年我们会根据今年的情况进行调整，尽量使用更加方便便捷的云服务之类的形式来进行这种性能测试。

这些能力画像选了18个指标来对区块链系统进行评价，评价的方面大概也是可靠性、数据一致性、兼容性、安全性和稳定性这些主要的指标，为什么选择这些指标？还是那句话，我们对软件的需求一直以来是没有太大变化的，变化的是实现方式和测试方式。至于对这些项大家有没有什么执念我觉得大可不必，技术在发展，评测方法也在发展。

昨天大家拍照最多的大概就是这张图，这张图我觉得展示的已经非常到位，大家可以拍照了。还有这张，这是一个对于评测通过的项目数量的统计，在这方面我们再强调一下，项目通过的多少并不代表这个产品的好坏，只能代表这个产品是不是覆盖了很多个点，主要还是希望大家着重于业务需求，服务实体经济这个方面，而不是说跟每个功能点都要覆盖到。当然我们感谢这些尽量覆盖多，尽量想提供好服务的厂商，但是对于其他厂商请也不要气馁。

这是可选项和必选项的试图，必选项是我们通过多次研讨会一致认为需要具有这些特征才算做一个区块链产品，可选项是对一些业务层的支持程度。我们从这个图可以看出在参评的2我家企业，拿到证书的20家企业必选项是全部通过的，可选项的通过率各有不同，大家在司药管理和共识算法这一方面普遍重视程度较高，在共识算法调整和海量数据控制方面普遍存在一些知识性不足。究其原因感觉共识算法的调整是一个很场景化的东西，很多比如存证类的业务部需要高频发，它知识需要一个很稳定的环境，根据业务可能就没有做这方面的优化，但是海量数据控制这个我觉得是大家迟早要碰到的问题，在这一项上我们当时把这个放上是觉得引导厂商去重视海量数据的控制和管理，我们这一项应该在以后的测试中还会保留，希望厂商能为海量数据的控制提供一些比较合理的解决方案。

还有这次我们想表扬一下自己的就是我们进行了全球首次商用级的区块链性能基准测试，基准测试基准表现在是统一了硬件环境和软件环境，还有统一了测试指标。测试场景上我们选择了高并发、压力测试和长时间低负载运行三个，高并发要求的是产品在非常大的并发量下无丢失交易，这对于一个系统的稳定是一个非常重要的指标。你在高并发下，交易可以失败可以由不同的返回值可以不执行，但是绝对不可以出现交易丢失的情况，参加我们性能测试的全部都能做到这一点。另外是时间低负载运行，这是稳定的指标，如果不能低负载运行肯定性能非常差。另外压力方面是大家各展异彩的地方，自己支持多大的性能，对系统做了多好的并行优化都在这个方面有所体现。

测试拓扑是我们给了一个非常好的实验室的测试环境，我们的机器全部用光纤直接连接，在网络上几乎没有延时，这个环境在联盟链上可能还有望达到，这并不是生产环境希望大家注意这个问题。在生产环境下没有这么高带宽的情况下是不是还能达到这样的并发性能，也是大家需要注意的问题。

下面说一下在测试中我的感受，仅代表个人观点，大家也按这个流程来。首先从底层架构上两个极端，只要不是自营的，只要是拿来主义的，改造fabric是绝大多数的选择，只要不是改造fabric是大家自己研究的，我觉得百花齐放，没有共性。究其原因如果是做落地业务的为什么会选择fabric，有一个很简单的原因是fabric技术支持十分到位，这也是很多厂商需要学习的地方。fabric不管从帖子、教材、社区都是非常活跃的，看我们的自研平台里面，白皮书里写的最好大概是腾讯和上海保交所两家，从它的详实程度和各个层面上的解读还是比fabric要单薄很多。如果我们一定要推行这种自研平台的话，在技术支持上要加大一些力度。不是说fabric比我们自研的平台产品要好多少，只是说它的服务要好特别多。

共识算法这一块就更是百花齐放了，我们大致在这里把它分为三类：一类是非拜占廷类的，它不太能防恶意消息，大概率这种基于权益类的共识类的算法今年在测试比例中医明显下降。第二类是今年十分欣喜的看到一种新的共识模式，我们现在是暂时把它叫做分层共识，它的设计思路是因为区块链验证要选择打包节点和验证节点，这些节点的选择之前是通过一次的不管是投票也好还是权益也好，还是各种PDFT也好，都是一轮选出来的，这种不可避免的要非常大的带宽消耗，但分层共识可能把打包节点和验证节点分批选择了，这种在灵活性上和性能上都可以有较大的提升。

数据模型是如何选择的？比特币是基于两种数据模型，基于账户，基于资产，基于OSO，基于操作，基于状态都可以，大概指得都是一类是像比特币的UTSO的这种模型，一种是传统的银行体系以及各种体系传统业务经常用的账户模型，我给你开户，记录你的操作，记录你的转账，记录你的流水，这两种模型我们一直觉得UTSO可能更加适合区块链的模型，但是UTSO在市翁中存在非常大的问题，好处在于它防篡改性非常好，几乎不可能伪造出一个一模一样的UTSO体系出来，而且数量越大安全性越好，但是它的查询效率非常低，因为每一笔花费都要找寻它的来源，一直追下去非常难提供到底源头在哪，查询源头只是理论上可以查询，但是实际上操作起来非常困难，我们在这里推荐的模型大概是这种混合模式或许是一个解决方法，UTSO用来记账，在执行中可以并行，运行效率比较高，最好是同步再有一个账户模型来记录你的操作，一边记录你的状态，一边记录你的操作，两边要随时同步，状态是可以保证你防篡改，账户是可以保证你有一定的查询效率。我们非常欣喜的发现已经有公司这样做了，腾FIT是账户和私厂（音）混合，可以防可篡改性和安全。

存储大概是和数据模型非常贴近的一个方面，普遍看起来NoSQL是大大占了上风，MySQL只有寥寥几家，MySQL的选型非常固定，但是NoSQL大家的选型各不相同，究其原因NoSQL是一个比较容易使用的模型，因为它只有一个QA建制段，在MySQL有非常大的好处，首先保证数据的强一致性，V的格式很难限制，QA数据库里在大数据下查询效率非常低，但是MySQL的数据可可以建立很好的查询索引，可以提供很高的查询效率。对于这种现状，我也是推荐大家可以NoSQL和MySQL数据并用。

隐私保护这是一个越来越被重视的问题，在这次测试中隐私保护明显分了这三种策略：一种是非常常见的基于数据隔离的策略，一种是基于隐私保护算法的策略，一种是数据分类分级管理。这三种各自是个什么情况？基于数据隔离的策略大概是把业务分到不同的链上，分到不同的通道，分到不同的片区，各个业务之间不需要通信，这种情况它是一个数据隐私性保护非常好的方法，因为根本没有通信，所以也没有数据泄露的可能，而且实现相对来说比较容易，比较好控制。基于隐私保护算法的策略，这个实现的比较少也是比较困难的，但是它内容保护的指向性更好，它可以选择特定要保护的东西以披露另外一项，而且在隐私保护算法策略的支持下，它可以在业务逻辑更改的情况下，它比较灵活可以根据业务逻辑进行比较好的更改。数据分类分级管理也是一种常用的，就是它在业务层做了很强的控制，不对下暴露接口。在这种控制下也是一个比较容易实现，且数据保护，隐私性保护也比较好的方法。但是因为它强控制业务层，它的加密解密会非常高频，会有一定的性能影响。我觉得对于隐私保护这一块我推荐算法就是大家基于隔离的算法是比较好跟用户沟通的。

密码是区块链里一个非常不好解决的问题，因为它需要加解密频率非常高，大家的性能多数是卡在了密码这一关。所以说密码该如何去优化呢？如何提高加密的效率？从这次测试来看，我大概发现大家是从三个层面来优化自己的加密性能的，算法层面是根据场景选择合适的加密算法，这个是怎么回事呢？大概就是如果你这个数据是强私秘性的绝对不能丢的，你就用一些比较难破解的加密算法，在那些数据价值，隐私价值不是特别高的地方，可以相对用一些计算量小一些的算法，这样来适应来渐渐的提高点性能，但是这种选择提高非常有限，实现层面就是有一些大厂人力资源非常充足的，他可以把密码用重新更高效的语言写一遍，比如Go语言写一遍对CPU的利用更加彻底，然后来实现一部分性能。我估计重写密码包这种性能也不会超过20%。执行层面倒是有非常大的提高空间，硬件加密机和指令级的优化有可能会让加密效率提高10倍以上。

合约是我重点想说一下的问题，现在智能合约的执行环境不论合约越写越长是我所观察到的直接现象，有些合约甚至写到大几百行，虽然在联盟链里安全问题相对好控制，但是大几百行的合约真的好管理吗？这是我对业界的一种疑问。而且智能合约的管理现在的情况是智能合约的管理是比较被忽视的一个方面，尤其是在合约的升级这一方面，不只是私研平台，主流的fabric也有明显的问题，合约发布了一本新的旧的还在那里跑，并没有停到以及更好的优雅的管理方法。合约的退出也是一个非常大的，当这个业务停止了你的合约是优雅的退出还是粗暴的删除，这也是业界应该思考的问题。

比较可喜的是监管管理水平有明显的提升，区块链的报警已经非常到位了。区块链浏览器大家基本上都有了。

再有就是BaaS，我们一开始测试的时候并没有考虑BaaS这个问题，但是测试中发现BaaS跟普通的区块链产品有非常大的不同，主要是一个产品面向的是把一件事情做好，一个Baas面向的是如何把一个群体服务好，它的立足点非常不同。BaaS现在两种情况就是有些多底层的BaaS，比如我这个BaaS支持很多底层，有多底层作为同一件事情作为备份的，有扩展功能的，不管哪一种解决思路，或者两种思路混合使用，BaaS的根本目的只有一个，就是为用户提供更好的区块链服务。

这个性能测试我们昨天看过结果，性能测试是一个结果差距比较大的地方，类fabric的产品大概性能都集中在1000-3000TPS，这个性能是写入性能是一对一转账，但是它不支持关连交易这是一个非常严重的问题。比如我在一个收账的场景，比如我是一个淘宝卖家，我卖出来十件产品高峰期可能只收到一笔。

我们最好性能的甚至超过了5万，这种性能是怎么达到的？因为我们这个平台是开源的，大家可以看一下它的接口。它对于网络的使用，磁盘的使用，CPU的使用并行化做得非常好，能达到这个性能。普遍性能我认为比较可信的，在比较好的性能在5000上下，在普通的生产环境普通的配置下。

一句话总结的话就是参评的厂商真的都很棒，两句话总结就是参评的厂商都很棒，但是我们还可以做得更棒。

另外我就说一点我本职工作，我是负责可信区块链标准和评测的，在这里简单跟简单跟大家汇报一下我的工作。我今天分两块汇报，一块是可信区块链标准，一块是可信区块链测试。标准的话从标准现有的体系和标准的发展方向从两方面来说，测试从三方面来说。

目前的可信区块链标准已有的标准已经有了四本，第五本正在编制中。技术框架和总体要求就是前两部分是总纲性文件，是我们认为的区块链应该有的特征。第三部分测评方法是这次功能测试的依据。第四部分是性能测试是这次性能测试的方法依据。第五部分BaaS标准将成为我们明年进行可信区块链BaaS测试的标准。

可信区块链是基于什么目的要不断地迭代？这次测试中深切的发现区块链技术发展的真是太快了，我们还是应该在对软件的基本需求之外去聚焦一下区块链的特征，比如说区块链的共识，比如说区块链的P2P构建，这都是我们在以后要着重测试的部分。还有一个就是CA的管理，因为联盟链中有准入机制，准入机制什么样充分的限制了产品的可扩展性。所以说CA是不是好管理？是区块链的重要特征之一。再一个就是要区分不同的技术类型，我们这次测试中就已经发现，区块链普通的平台产品和BaaS这种提供服务的产品设计理念完全不同，用一个标准来衡量不同理念的产品是不合适的，所以我们应该细分不同的技术类型，然后针对性的进行测试。我们还会细化测试的场景，为什么要细化测试的场景？就是因为以共识为例，共识不是说达到共识这个共识就有效，共识最好的情况是你在任何情况下都能达到共识，而不是在理想情况下可以达到共识。尤其是在有些破坏性的测试下，你是不是依然能维持这个共识的稳定，基于这种目的我们会细化测试场景，充分覆盖各种可能发生的情况。还有响应十九大精神，区块链要加速服务实体经济，我们会着重于对接垂直行业。首先我非常欣喜的发现区块链其实已经有一些落地了，在某些协作类的以及要求数据强一致性的场景下已经有一些已经成型的产品，我们希望把这些已有的经验总结起来写成标准，在垂直行业里作为团标进行推广。

这是我们青岛可信区块链第一次全会讨论出的可信区块链功能标准体系，这个在数次迭代后也可能作为明年的标准。在我们这次的迭代中把区块链分成四个平面。平台层和业务层是之前区块链本来就强调的部分，但我们这次平台层中会更加强调部署和启动方式，就是组网方式，P2P如何启动，数据存储和传输的方式。业务层单独抽离是因为在测试中发现对接不同的业务，账户体系和分类授权管理和监控方面差距非常大，所以业务层有可能是针对不同的业务场景，大家不会分的很多。比如说分为存证类、非存证类、金融类，然后来针对性的进行一些限制，不该限制的太死的地方我们准备放开，需要限制的比较到位的地方我们会加大力度。再者一个大的改变是把证书签发单独拿出来作为一个重要项进行测试。在联盟链里证书签发是非常重要的环节，是它的准入机制的重要部分。证书签发的管理是决定一个联盟链是否容易扩展，是否容易业务逻辑更改的重要模块。我们在这一块会把它单独拿出来。再一个要强调的就是审计功能，为什么要强调这个？大家不是说区块链是防篡改，防伪造，防恶意，那怎么证明？我们现在的证明方式是我的东西都在那里，我的东西环环相扣，我的数据是绝对真实的，但是现在有个问题，这个数据非常难以提取有效数据，所以我们把审计功能单独拿出来作为一个模块，在以后会对这块加大力度进行测试。

测试的类型我们目前只有功能测试和性能测试，我们在下一轮测试中一定会把BaaS测试拆出来，大概分为三类测试。其中功能测试和BaaS测试定位是满足基础要求，而且披露信息可信，性能测试是一个基准测试，我们会统一逻辑，统一环境，统一交易类型和那些配置参数，然后来做一个基准测试，是可以横向对比的。

测试方法不管是哪一种测试类型，测试方法都是这个流程，第一步信息披露，我们会提供披露项文件，按要求详实的描述自己的文件。第二步是实地测试、采集数据、生成报告，实地测试我们建议服务类的产品，我是向用户提供服务的，建议在生产环境进行测试，破坏性测试可以在测试环境进行。基准测试我们会提供稳定的云环境或者机房环境统一进行。第二步是评审会，专家评审，评审会我们会邀请多种角色全方位的评审这个产品，保证结果公正透明可信。

性能测试的测试方法，因为我们在前期没有做太多性能测试测试方法的披露，在此为大家补上。性能测试的交易类型大概分这三类：存证类是只有输入没有输出的交易，转账类是有输出和输入的交易，另外开户和资产发行，这两个是对等的，都属于创建账户这种类型，这种三类对性能的要求是不一样的，转账类可以需要支持关连交易、高运营场景，存证类更在数据稳定和可一致性。测试场景依旧保持三种测试场景，一种是高并发下要求不丢失不崩溃，压力测试希望压出大家性能的峰值。还有长时间运行。计算方法是吞吐量和交易确认时间，大家注意交易确认时间，在这次测试中大家普遍没有重视交易是多长时间进行确认的，交易确认时间也是用户体验的重要指标，一笔交易发出去石沉大海是大家都不愿意看到的场景。

另外我重点想跟大家讲解的是这个测试工具的逻辑，按这个流程图给大家说一遍我们将用的性能测试测试流程的逻辑。首先因为客户端其实跟服务器是在不同的端口，如果客户端和售后端一起进行压力是不合适的。什么是一起的，签名和生成是一起执行的，生成之后发送到Server端进行执行。我们测试将是产品的证书模块适配测试工具，然后按照统一的交易逻辑生成交易体验，这是客户端这边的性能。再者是服务端这边的性能，根据生成的提议体系我们进行交易发送，发送给服务器进行共识执行，并写入硬盘，记录时间，然后从发包机统计交易发送的时间，在硬盘里直接读取数据来拿到区块链信息，来确认这个交易确认的时间，根据这两个时间来计算性能测试的指标。这种测试有什么好处？首先是客户端，这边是用户主要体验部分，客户端的逻辑，客户端的性能怎么样和服务器端的性能怎么样，因为客户端是不可以并行的，一个客户只有一个客户端，服务器端相对来说是一个厂商可以控制的部分，分开计算它的性能我觉得是有道理的。再者是这个性能该怎么统计，为了适应各种不同的区块链产品我们不想用工具限制大家的想象，所以我们觉得直接在硬盘读取大家的数据，然后这种一方面避免了数据造假，一方面是非常准确的TPS，也不埋没大家的性能。

我今天要分享的大概就是这样，感谢大家今天的支持，希望大家支持我们的标准租，开源基准测试组和BaaS组，谢谢大家！