通过《金融分布式账本技术安全规范》看区块链

本文主要通过解读《金融分布式账本技术安全规范》，分析区块链技术或分布式账本技术在行业应用中的一些发展趋势，为金融行业和其他行业下一步开展区块链相关技术的推广和大规模应用提供一些参考。

2020年2月5日，中国人民银行正式发布《金融分布式账本技术安全规范》（以下称为：规范）（JR/T 0184—2020）金融行业标准。

标准规定了金融分布式账本技术的安全体系，包括基础硬件、基础软件、密码算法、节点通信、账本数据、共识协议、智能合约、身份管理、隐私保护、监管支撑、运维要求和治理机制等方面。

该规范是为落实《中国金融业信息技术“十三五”发展规划》（银发〔 2017 〕140 号文印发）和《金融科技（FinTech）发展规划（2019-2021年）》（银发（2019）209号文印发）的要求，规范分布式账本技术在金融领域的应用，提升分布式账本技术的信息安全保障能力。

该标准适用于在金融领域从事分布式账本系统建设或服务运营的机构，按照合适的安全要求进行系统部署和维护，避免出现安全短板，为分布式账本技术大规模的应用提供业务保障能力和信息安全风险约束能力。

一、《规范》有如下几个特点

1. 《规范》只提到分布式账本，而没有提及区块链

全文并没有强调区块链，而只讲分布式账本，这可能是和银行类业务重点关注账务处理有关。

熟悉R3 Corda的读者应该知道，Corda也没有采用区块链链式数据结构，只用了分布式账本；央行蓄势待发的DCEP只用了数字加密资产技术也没有用区块链数据结构。

考虑到金融业务的高性能要求和基于央行的强中心化和高安全性的网络安全保障，《规范》并没有强制要求必须采用更加安全但性能开销大的链式数据结构，当然这不妨碍我们把分布式账本技术归为区块链技术的大范畴内。

2. 强调监管

区块链技术从比特币创始之初就是希望用分布式和去中心化的数据同步机制，避开中心化金融监管机构的控制。后续的以太坊、EOS等公链技术都很难解决监管和网络自治的矛盾，对公链发行的数字货币的监管也是各国金融监管机构在AML和非法资金往来方面头疼的问题。

而联盟链技术由于剥离了公链价值博弈部分，并采用直接投票共识的方式，节点采用许可准入模式，为监管节点的引入提供了条件。而且分布式节点间数据自动化同步和智能合约技术，都为监管节点提供了低成本穿透式监管的手段。

3. 明确密码算法种类

加密算法是保障区块链网络交易安全的必要条件，各国对于加密算法都有自己的标准，例如：比特币使用的SHA256哈希算法就是由美国国家安全局（NSA）所规划，并由美国国家规范与技能研究院（NIST）发布，我国也不例外。

《规范》对于使用到的分组密码算法、流密码算法、非对称密码算法、密钥交换算法、密码杂凑算法和标识密码算法等，都规定了相应的国家标准。

4. 明确身份、账户和凭证模型关系

《规范》将金融行业重视KYC的要求，赋予了分布式账本体系，并给出了官方设计模型，使分布式账本技术可以真正接入国家金融管理体系，为真正赋能金融行业提供了底层模型支持。

5. 对于生产系统必备的运维和治理标准

目前区块链技术还处于初级阶段，大部分项目还在POC、初步探索期和场景优化设计阶段，对于运维和网络治理，还处于粗放式模式。

业界也还没有针对于区块链（分布式账本）专门的分布式运维监控工具。《规范》给出了一些要求，这也为用区块链技术在金融行业应用提出更高的要求，区块链技术也急需一套分布式运维和治理平台。

二、《规范》相关标准指导分析

1. 基础硬件要求

基本硬件环境应遵循 GB/T 22239-2019 中三级及以上的物理和网络相关要求。国标规定了网络安全等级保护的第一级到第四级等级保护对象的安全通用要求和安全扩展要求。适用于指导分等级的非涉密对象的安全建设和监督管理。

同时对场地安全、硬件设备、节点部署安全、硬件加密设备安全、网络架构安全、通信传输安全都规定了相关要求。该要求对分布式账本的云端部署和本地化节点联盟部署都分别给出了要求，例如：本地化节点联盟部署方式，要求节点物理位置必须设置在中国境内；节点间网络传输采用VPN方式等。

2. 基础软件要求

分布式账本的软件环境应遵循 GB/T 22239-2019 中三级以上的主机安全、应用安全、数据安全及备份恢复相关要求，还分别对账本结构、共识模块、分布式组网、数据存储、智能合约、接囗设计、数据传输、时间同步和操作系统等方面提出要求。

在账本结构的要求中，对链式数据结构建议是“宜使用”，而非必须，这也为在不同业务场景，采用不同数据结构提供了建设选择权。

例如：在网络安全有保障的云端部署模式可只采用分布式账本，而对本地化节点联盟部署模式则可以使用更安全的链式数据结构。

在智能合约的要求中，不允许智能合约代码在未授权的情况下明文查询，并且要求智能合约要通过相关方审核发布。作者认为这是为了防范有漏洞的智能合约被违法之徒发现和利用。

3. 密码算法要求

分布式账本系统中的密码算法主要包括分组密码算法、流密码算法、非对称密码算法、密钥交换算法、密码杂凑算法和标识密码算法等（密码杂凑算法就是我们常说的哈希算法）。

要求分别符合国标：GB/T 32905-2016、GB/T 32907-2016、GB/T 32918-2016。GB/T 32905-2016是哈希算法的国标版：SM3；GB/T 32907-2016是分组密钥算法的国标版：SM4; GB/T 32918-2016是椭圆曲线加密算法的国标版：SM2。

《规范》还要求了应符合GM/T 0006-2012、GM/T 0009-2012、GM/T 0010—2012、GM/T 0015-2012、GM/T 0044—2016等行业规范标准。这些规范分别是：密码应用标识规范、SM2密码算法使用规范、SM2密码算法加密签名消息语法规范、基于SM2密码算法的数字证书格式规范、SM9标识密码算法。

4. 节点通信

节点通信采用授权准入的原则，通信双方要使用双向身份认证体系，这基本限定只有联盟链技术路线符合《规范》要求。节点通信要有容错处理和数据恢复能力，在某节点出现数据毁坏后，节点恢复可以从其他节点自动重新拉取数据。

5. 账本数据

《规范》明确要求账本数据的生成、传输、存储、调用等操作不可被非授权方式更改或破坏，不可被非授权方式访问和使用，同时在原有联盟链技术中增加了对审计的要求：

账本数据的访问应提供安全审计功能：审计记录包括访问的日期、时间、用户标识、数据内容等审计相关信息：
数据变更应提供审计功能：审计记录不仅包括数据变更成功的记录，还应包括数据变更失败的记录；
节点有效性校验失败、一致性校验失败等情况下同步账本数据，应提供安全审计功能：审计记录包括事件类型、原因、账本数据同步的节点、账本数据校验值等审计相关信息，审计记录可由记账节点自行记录，不必写入账本。

6. 共识协议

《规范》对于共识协议没有明确规定，建设方可以根据业务特点自行选择，包括但不限于POW、POS、DPOS、BFT等；以业务激励规则和技术运维安全机制共同保障共识有效性和安全性。

同时在：合法性、正确性、可终止性、一致性、不可伪造性、可用性、健壮性、容错性、可监管性、低延迟、激励相容、可扩展性等相关系统评价标准方面给出了一些简要要求。

7. 智能合约

《规范》没有限定一定要采用图灵完备的智能合约，实际上图灵完备的智能合约的安全风险更大，这也是比特币脚本引擎限制Loop的使用原因。

智能合约需要满足除了标准区块链智能合约在版本控制、复杂度限制、原子性、一致性的要求外，《规范》还增加了金融业务系统必备的：访问控制、安全审计、生命周期管理、攻击防范、安全验证等要求。

8. 身份管理

由于金融业务的特殊性和对于KYC的重视，《规范》对身份、账户、身份凭证做了大篇幅的详细定义：

身份：

是指涉及自然人及法人等实体的属性的集合。在金融分布式账本系统中，身份可以进行数字化标识（简称数字标识）。

账户：

是身份的一个属性集合，分为系统用户账户和应用账户。系统用户账户包括普通成员账户、系统管理员账户和其他特定权限的系统用户账户，其中系统管理员账户具有最高权限（如部署智能合约）。

身份凭证：

在金融分布式账本系统中，一个身份可对应多个账户。每个账户应关联一个身份标识，即身份凭证。身份凭证是用户实体通过身份鉴别后，由鉴别者为用户出具的一种可信任的电子凭据，包括但不限于数字证书和公私钥对等，不同的鉴别及验证方式应遵循金融业的业务及监管要求。

身份定义的实体范围：

为自然人和法人等，不包括设备实体。

身份注册：

是指自然人及法人等实体向注册机构提供权威机构发行的法定身份证件等身份证明材料，申请获取。

身份核实：

是指注册机构向身份信息权威机构核验注册者提供的身份证明材料是否与注册实体一致。

账户授权：

是指身份注册机构对注册实体的账户进行权限分配的过程。

凭证签发：

是指完成身份核实后，身份注册机构向注册实体的账户发行身份凭证。

身份鉴别：

是指自然人及法人在使用分布式账本服务 / 活动过程中，对注册实体的凭证和属性进行鉴别的过程。

在比特币网络中，身份暨公钥，比特币是匿名区块链，大部分公链也都采用匿名设计。在国内金融管理规范要求中，金融业务必须是实名制，为此《规范》将区块链技术的数字身份技术和传统金融系统的身份第三方认证、全生命周期管理、监管和审计结合在一起，形成具备金融行业应用能力的分布式账本身份管理方案。

9. 隐私保护

隐私保护也是《规范》篇幅较长的章节，重点给出了对于分布式账本应用中的隐私信息的定义，即是指：

在金融分布式账本系统中，单独或者与其他信息相结合能识别特定自然人身份或者反映特定自然人活动情况的各种信息，包括但不限于分布式账本系统中各方的账户信息、鉴别信息、交易信息、个人身份信息、财产信息及其他反映特定自然人活动的各种信息。

《规范》要求应将隐私信息按照敏感程度进行分级，并设置对应的隐私保护策略。

低隐私保护要求类别信息经过组合、关联和分析后可能产生高隐私保护要求类别信息，应根据实际情况采用对应的高隐私保护策略。隐私保护行为应该符合：GB/T 35273-2017中的“个人信息安全基本原则”，且不违法金融相关监管要求。

加密策略要求交易信息可加密验证、可公开验证、通过发布式验证节点自动验证。隐私保护技术和方法包括：认证授权、局部广播、摘要存储、变更标识、混淆技术以及零知识证明、群签名、环签名、同态加密等算法组合，可根据业务场景组合解决方案，实现信息保密性和隐私保护的目的。

10. 监管支撑

《规范》提出监管和分布式账本技术的融合要求，虽然《规范》中并没有给出监管的具体方式，但定义了包括但不限于：设置监管规则，提取交易记录，按需查询、分析特定业务数据等监管操作，应支持监管机构访问最底层数据，实现穿透式监管。

区块链与监管结合方案一般有：超级权限方式和监管节点方式两类。

超级权限方式就是给监管方查询和检查任一分布式节点底层数据的权限，这种方式区块链底层改造简单，但由于是超级权限，数据安全风险比较大。

监管节点方式是在监管方设置监管节点，利用分布式数据同步技术将监管数据一致性地同步到监管节点，利用智能合约触发监管预警，监管节点方式是一种对区块链网络低侵入式的方案，能有效保证各方数据安全。

11. 运维要求

《规范》中，运维要求应符合GB/T 22239-2019 中安全运维管理相关要求，同时还应包括设备管理、节点监控、节点版本升级、漏洞修复、备份与恢复、应急预案管理、权限管理、议案机制等功能。

12. 治理机制

《规范》为分布式账本给出了建立管理委员会、安全管理机构、日常管理团队、应急管理团队的安全治理架构，管理委员会作为金融分布式账本系统安全治理的决策层，由主任委员、副主任委员和委员组成，可以由监管机构或由占领导地位的单一机构创建，也可以由多个机构或用户联合组建。

管理委员会下设安全管理机构作为安全治理的管理层，负责日常安全管理工作的统筹和异常情况的应急处置统筹。安全管理机构下设日常管理团队和应急管理团队作为安全治理的执行层，负责日常管理和应急管理的具体执行。

13. 小结

《金融分布式账本技术安全规范》的发布，为区块链技术在金融行业的大范围推广应用，铺平了道路。

最大的亮点是将金融行业的强监管和KYC要求，以标准化的形式固化在安全规范中，同时也给出了金融级区块链技术在身份、账户和身份凭证方面的设计模型，为金融级区块链技术的完善和优化提供了方案。

全文对于加密算法、软硬件部署、运维等都给予了明确标准要求，但对区块链核心技术路线则给予了比较宽松的环境，这也是考虑到目前区块链技术还处于初级阶段，特别是在共识效率提升、零知识证明等技术方面都还有很大的未知变化。

总体上看，该规范不光是为金融级区块链技术发展提供了安全标准指引，同时也为区块链技术在其他行业的标准化提供了参考和借鉴。

三、基于行业应用的区块链技术发展趋势

以比特币为代表的区块链1.0技术，让我们看到基于分布式的、去中心化的点对点安全交易成为一种可能，如今比特币也是最具价值和安全性的区块链网络。

而以以太坊为代表的可编程的区块链2.0技术，使基于分布式账本模型，构建多样化的第三方去中心化应用（DAPP）成为主流。

那区块链3.0会是什么样呢？业界对于区块链3.0有多种看法。例如：有人认为区块链3.0是价值互联网，是对生产关系的一种变革。

作者认为区块链在2.0时代后，已出现了一次认知分叉，坚持价值博弈为中心的公链技术，将会继续在完全去中心化和无监管模式方面，探索和发展自治网络。

而坚持行业应用的联盟链技术，将区块链分布式节点和现实社会、经济实体连接起来，并有效平衡了监管和去中心化的矛盾，将区块链技术融洽地集成进现实社会管理和技术体系中。

公链技术是以彻底改变生产关系为原则，而联盟链技术则是以优化生产关系为目的，公链技术更像社会协作实验室或沙箱，在未来很长一段时间，他还将承担新价值传递网络、新生产关系和新技术研究验证的试验田；而联盟链技术则采用相对成熟、安全的技术，服务现实应用，联盟链未来技术发展方向将会重点聚焦在分布式领域建模和行业应用集成优化两大方向。

现在讲区块链3.0的形态还为时过早，而且空泛讨论3.0还是4.0并无实际意义，务实的态度是要加速区块链技术在行业应用中落地，改变区块链自娱自乐的内部链、圈子链的现状，实现金融链、政务链、制造链、企业链等社会新型协作网络。

区块链技术要从极客技术到企业级应用和大规模商业还有很长的路要走，本节重点讲几点我们认为的在行业应用方面的技术发展趋势。

1. 区块链的分区、分片治理是行业应用的必然趋势

作者曾经参与过一个国家级征信区块链课题研究项目，项目要求利用区块链技术整合目前各类非银行类金融机构的征信服务，包括：消费金融公司、小额贷款公司、汽车消费金融公司、P2P机构等。

这是全国性征信项目，有地域分区问题，同时这是整合了非银行业务的不同类型的金融机构，存在业务差异性分区问题，但对于个人征信数据又需要全面和一致性。

一套行业应用系统，无论分布式还是中心化，数据按照地域和业务进行分区、分中心部署是一种常见的结构。

与区块链POC或实验室项目不同，一旦大面积商业化区块链技术就涉及到在原有数据分区属性和差异性的业务规则下，如何搭建区块链网络。

采用区块链原教旨主义的完全去中心化网络化，在现实行业业务中是没有意义和必要的，也会严重受到性能问题的考验。

未来的行业应用的区块链必然是需要支持在分区、分片治理，同时全网数据要保证一致性，简单说就是需要：交易分区校验和证明、数据全网一致性网络保障的行业链。

分片技术(Sharding)是把整个 P2P 网络中的节点分为若干相对独立的片区，以实现系统水平扩展。

分片的情况下，通过把交易导引至不同节点，多个网络片区并行分担验证交易的工作。

目前的分片策略包括网络分片(Network Sharding)、交易分片(Transaction Sharding)和计算分片(Computational Sharding)。

子链技术是在主链上派生出来的具有独立功能的区块链，子链依赖主链而存在，并且可以定义自己的共识方式和执行模块。通过定义不同的子链，系统的可扩展性、可用性和性能均得到提高。

多通道技术是系统中多个节点组成一个通道，每个节点也可以加入不同的通道中，通道之间互相隔离，通过锚节点互相通信。多通道技术可以消除网络瓶颈，提高系统可扩展性。

2. 集成优化趋势

要利用区块链技术服务于行业应用，就需要适应行业应用现有的集成环境，而不是推翻重新构建。

简单、安全、快速地与现有行业应用集成是区块链技术普及推广的必然过程，哪种区块链技术更加务实，更容易和行业集成，那也就将更受欢迎。

从集成方面看有身份集成、监管集成、业务集成运维集成四个方面的考虑。

1）身份集成

在央行发布的《金融分布式账本技术安全规范》中，对于身份管理给了明确要求，目前国内主要行业应用都要求采用“实名制”认证，特别是金融业务对于KYC的重视，不允许采用匿名交易的现象存在。

《金融分布式账本技术安全规范》中对于身份、账户、身份凭证给予了明确定义，如果需要在金融环境中开展区块链集成也必须满足该规范的要求。

区块链中的身份是公钥或者数字证书，而在现实行业应用中的身份是：KYC管理、客户信息管理、全国公民身份证号码查询服务中心等，区块链的密钥体系要和行业应用的客户身份管理体系集成；区块链中的账户要与行业应用的账务处理集成；身份凭证要与行业应用的交互令牌集成。只有完成与行业应用的身份集成才能将现实社会身份、自然人身份与区块链密钥和资产，实现映射和管理，区块链上的交易才能变得具有现实意义。

2）监管集成

是否需要行业监管是行业背景和业务规则决定的，无论采用中心化的系统建设模式，还是区块链分布式应用的模式都需要遵守行业规定和国家法规。

所以采用区块链技术，并不意味着就可以不用监管，而如何快速接入监管环境是衡量一套区块链技术是否满足标准和具备行业准入条件的基础。

从监管集成方式来看超级权限方式和监管节点方式，都可以实现行业监管方对区块链的交易记录，按需查询、特定业务数据分析、违规告警等穿透式监管功能。

但从数据安全性和低侵入方面考虑，构建监管节点将是一种更加轻量和低成本的集成方案。

3）业务集成

区块链技术只是一种建立可信协作的分布式框架而已，需要和行业应用系统做紧密集成，才能实现完整的业务功能。

例如：基于区块链技术的供应链金融，可信协作部分是多机构间票据资产的发行和流转，所以区块链的账户资产处理要和供应链金融本身的融资平台集成；基于区块链技术的供应链溯源，可信协作是供应链上下游间的商品流转，所以区块链的交易要和供应链采购、物流、库存管理平台集成。

区块链技术需要提供更加友好、标准和高效的模块化集成方案，不同的行业应用集成方式将会有很大差异，区块链技术业务集成需要具备相当的行业知识沉淀，不存在通用集成模型。

4）运维集成

区块链技术的综合运维能力将是衡量区块链技术商业成熟与否的标准，设备管理、节点监控、节点版本升级、漏洞修复、备份与恢复、应急预案管理、权限管理、议案机制等分布式运维功能，都是大规模商业必不可少的辅助能力。具备强大运维能力的区块链技术才能赢得行业客户的信赖和准入。

一套基于分布式环境下的区块链综合运维平台将是下一步发展重点。

5）分布式领域建模决定区块链行业应用的成败

区块链也存在领域建模吗？答案是肯定的。

我们回头再看看比特币的UTXO（Unspent Transaction Output）模型就是一套典型的分布式安全交易模型，UTXO模型和我们常见的银行账务余额模型的最大区别是：银行账务余额模型的“余额”是账户的一个属性、一个数字，而UTXO是数字货币的自我证明模型。

例如：你在银行存了1000万人民币，对于银行账务系统来说这只是一个数字1000万而已。

如何保障这1000万真实存在呢？

还需要银行现金管理的相关模型综合保障，例如：对账、金库盘点等。

所以银行账务系统的余额模型是一个不能实现自我证明（自恰）的模型。

比特币的UTXO模型则是一套可以实现自我证明的模型，在分布式环境中每个节点都可以验证这笔交易涉及的金额是否真实存在，以及是否已经花销掉。

比特币这样的设计是出于在无第三方机构对货币的统一存储和管理的环境下的安全交易要求，这种UTXO模型就是“点对点电子现金系统”（比特币）的领域模型。

四、总结

业界对于区块链相关技术提得最多的是分布式账本技术，账本概念在区块链应用中是一种抽象概念，并不一定指资金账本。例如：Hyperledger Fabric 账本就是存放通用数据的一种分布式共享数据库。

我们可以通过比特币、以太坊和Fabric的账本，来观察区块链应用模型设计发展的不同特点：

比特币没有账本概念，交易是基于UTXO发起，UTXO模型是一套经典数字货币溯源自恰模型，在分布式环境中强调数据真实性和一致性。
以太坊没有账本概念，交易是基于账户余额发起，余额本质是一套分布式账户模型，在分布式环境中强调账户一致性。
Fabric有账本概念，交易是基于World State发起，账本本质是一套通用共享数据库，通过共识协议保障数据一致性，在分布式环境中强调数据库一致性。

哪种模型更适合行业应用发展需求呢？

以上三种模型在行业方面都有各自缺陷，比特币和以太坊是公链网络，是针对去中心化货币交易领域设计的模型，很难在其他行业直接应用。

而Fabric是通用区块链技术架构、也是企业级应用，你可以用于金融、供应链等多行业场景，但由于Fabric的账本模型本质上是维护一套分布式共享数据库，并不具备业务自验功能。

例如：在供应链交易中虽然可以实现交易数据的一致性保证，但无法在协议层实现供应链生产和采购数据的业务自恰性验证（生产数=采购数），也无法实现供应链数据三流合一（信息流、资金流、物流）自验证场景。

目前联盟链技术还停留在节点数据一致性的保障上，而分布式的行业应用往往是多元、异构的复杂应用组合。

例如：在支付清算中，需要订单、支付单、清算单等的等额自恰性验证，目前是用大量线下校验实现的。

在数据一致性保障方面，目前的中心化应用系统有很多解决手段，区块链只是其中一种，只有通过分布式领域建模实现多节点业务协作的区块链技术，才会在行业应用中真正体现应用价值。

可以说，未来在分布式领域建模方面的成败，直接关系着区块链技术在行业应用中的推广和普及。

参考文献：

《金融分布式账本技术安全规范》http://www.cfstc.org/bzgk/gk/view/bzxq.jsp?i_id=1855
信通院《区块链白皮书2018》
Vitalik Buterin. Chain Interoperability [EB/OL]. (2016-09-09) https://www.r3.com/reports/chain-interoperability/