1、 ICS 35.240 L 79 DB52 贵州省地方标准 DB52/T 14662019 区块链 应用指南 BlockchainApplication guide 2019 - 12 - 31 发布 2020 - 06 - 01 实施 贵州省市场监督管理局 发布 DB52/T 14662019 I 目 次 前言 . . II 1 范围 . . 1 2 规范性引用文件 . . 1 3 术语、定 义和缩略语 . . 1 4 区块链适用性 . . 3 5 应用原则 . . 3 6 应用关注点 . . 3 7 应用路径 . . 4 附录 A（资料 性附录） 区块链关键技术分析 . 13 参考文献 .
2、 . 15 DB52/T 14662019 II 前 言 本标准按照GB/T 1.1-2009标准化工作导则 第1部分：标准的结构和编写给出的规则起草。 本标准由中国电子技术标准化研究院提出。 本标准由贵州省大数据标准化技术委员会归口。 本标准起草单位：中国电子技术标准化研究院、贵阳市大数据产业集团有限公司、贵阳宏图科技有 限公司、上海分布信息科技有限公司、厦门安妮股份有限公司、北京欧链科技有限公司、贵阳大数据交 易所、中电科大数据研究院有限公司、工业和信息化部电子第五研究所、贵阳爱立示信息科技有限公司、 贵阳井通金融科技有限公司、贵州亿步优图科技有限公司、中国电子科技网络信息安全有限公司、贵
3、州 远东诚信管理有限公司、复旦大学、上海计算机软件技术开发中心、北京国盾量子信息技术有限公司、 贵阳银行、贵州优易合创大数据、贵州瑞普科技有限公司、贵州师范大学、九次方大数据、北京邮电大 学、迅鳐成都科技有限公司、电子科技大学网络安全研究中心、贵州智慧科技信息技术有限公司。 本标准主要起草人：李佳秾、李鸣、杨菲、唐晓丹、孙琳、周黎辉、裴莹蕾、蔡蕙敏、张一帆、 相里朋、郝汉、谭智勇、王涛、张亮、雷吉成、李泽源、谈建、李万恒、李尧、阚海斌、文捷、李喜平、 饶维、郝尧、宋承根、杨智浩、李超、蔡维佳、陈小军、薛路、谢红韬、袁琳琳、陈贵平、王明月、 司亚清、夏琦、李弋凡、张乐云、郑咏梅。 DB52/T
4、14662019 1 区块链 应用指南 1 范围 本标准规定了区块链应用的术语、定义和缩略语、区块链适用性、应用原则、应用关注点、应用途 径等要求。 本标准适用于： a) 为区块链应用的实施提供正确的指引； b) 促进区块链系统的实施； c) 统一对区块链技术实施的认识，为应用区块链服务提供指导性意见； d) 降低区块链技术应用风险，提升区块链技术应用效果。 2 规范性引用文件 下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文 件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。 DB52/T 1467 区块链 系统测评和选型规范 IS
5、O 23257 区块链和分布式记账技术 参考架构（Blockchain and distributed ledger technologiesReference architecture） 3 术语、定义和缩略语 3.1 术语和定义 以下术语和定义适用于本文件。 3.1.1 区块链 bloc kchain 区块链是使用密码技术将共识确认过的区块按顺序追加而形成的分布式账本。 ISO 22739 区块链和分布式记账技术 术语 3.1.2 数字签名 digita l signature 附加在数据单元上的数据，或是对数据单元所作的密码变换，这种数据或变换允许数据单元的接收 者用以确认数据单元的来源
6、和完整性，并保护数据防止被人（例如接收者）伪造或抵赖。 GB/T 25069-2010，定义2.2.2.176 DB52/T 14662019 2 3.1.3 加密 enciphermentencryption 对数据进行密码变换以产生密文的过程。一般包含一个变换集合，该变换使用一套算法和一套输入 参量。输入参量通常被称为密钥。 GB/T 25069-2010，定义2.2.2.60 3.1.4 功能组件 functiona l component 参与活动所需的，可实现的一个功能性基本构件块。 GB/T 32399-2015，定义3.2.3 3.1.5 互操作性 interoperabilit
7、y a）两个或多个系统或组件交换信息并相互使用已交换的信息的能力； b）两个或两个以上系统可互相操作的能力。 GB/T 11457-2006，定义2.807 3.1.6 模块化 modularization 把系统分成若干模块（模块变成元素）以便于设计和开发。 GB/T 11457-2006，定义2.976 3.1.7 许可链 perm issioned blockchain 节点需要被授权的区块链（系统）。 ISO 22739 区块链和分布式记账技术 术语 3.1.8 非许可链 permissionl ess blockchain 节点无需被授权的区块链（系统）。 ISO 22739 区块链
8、和分布式记账技术 术语 3.2 缩略语 下列缩略语适用于本文件。 API：应用编程接口（Applicat ion Programming Interface）； ECC：椭圆曲线密码体制（Elliptic Cur ve Cryptography）； IDE：集成开发环境（Integrat ed Development Environment）。 DB52/T 14662019 3 4 区块链适用性 计划使用区块链的组织或个人需要根据自身实际情况，通过分析自身对安全性、分布式适用性等判 断对区块链的应用需求。应用需求的主要参考因素包括以下四个方面： a) 信任和多方协同指企业是否期望通过区块链技
9、术的自信任机制来解决多方的信任、协作或对等 性等问题； b) 数据安全可信指企业是否期望通过区块链技术保证数据可信问题，系统数据是否存在被篡改、 被伪造或一致性差异的情况； c) 业务全要素记录指企业是否期望通过区块链技术支持对包含业务的全要素进行记录，是否对全 流程有追溯、监管或审计需求； d) 价值互联指企业是否期望通过区块链技术支持价值在链上的传递。 5 应用原则 5.1 算法自主 5.1.1 区块链技术发展应符合国家法律和监管要求，以分布式帐本为基础，以规则与共识为核心。 5.1.2 区块链生态体系应以通用记帐平台、点对点分布式的高可用网络、数据安全为重点，建立共用 设施的基础化平台。
10、 5.2 生态互联 生态互联应基于区块链数据构建点对点网络结构，实现区块链的彼此连接，构建记录全网上的价值 交付的历史数据的立体价值结构。提出在异构和跨链环境下，不同区块链彼此连接，区块链上具有统一 属性数据的映射数学表达方法和映射模型。解决区块链上的数据关联，形成跨区域、跨场景、跨部门应 用的区块链立体空间。 5.3 需求驱动 区块链技术应用应有明确的需求驱动，解决实际应用场景中信任缺失或信任依赖、价值联通、生态 整合、内部监管、自证清白、责任厘清、提高成本效率、可信存证等多维度、多层面问题。 5.4 可监管 区块链应用不能与国家政策相抵触。区块链应用架构设计中应预留监管功能和接口，事先考虑
11、监管 需求可以更大程度获得监管机构的支持。 6 应用关注点 区块链应用关注点是在应用分析、应用实现的过程中应考虑的关键因素，其中包括但不限于： a) 业务关注点： 1) 业务适宜性：充分考虑区块链技术的必要性并使其符合应用需求； 2) 可治理性：对业务的持续治理进行规划与调整； 3) 经济可行性：注重经济价值与效率的提升。 b) 技术关注点： 1) 技术可行性：充分考虑应用区块链技术的可行性； DB52/T 14662019 4 2) 功能：考虑功能的完备性、正确性、适应性和恰当性等； 3) 性能：考虑资源利用性、时间特性、容量、吞吐量等性能需求； 4) 可靠性：考虑系统的成熟性、可用性、容错
12、性和易恢复性等； 5) 安全性：考虑数据的真实性、完整性、保密性、抗抵赖性和可追溯性等； 6) 可维护性：考虑平台搭建、配置管理、权限控制等方面的灵活性、易用性； 7) 可移植性：考虑系统的适应性、易安装性和易替换性以及模块的可插拔性等方面需求； 8) 互操作：从数据一致性和可协同性等方面考虑系统互操作性； 9) 易开发性：考虑底层平台的接口、SDK 完善程度以及智能合约体系易用性等。 c) 社会效应关注点： 1) 政策合规：区块链应用须遵守国家现有的监管要求与法律框架； 2) 融合效应：考虑如何利用区块链构建协同产业生态系统。 7 应用路径 7.1 统筹和规划 7.1.1 概述 为满足国家互
13、联网信息办公室等区块链行业主管部门要求，开展区块链业务统筹和规划。分析市场 环境及相关政策，结合应用所属行业特点和痛点，分析实际业务场景下的区块链应用需求。研究区块链 发展现状，分析区块链特点，进行链上业务分析和功能组件分析。 7.1.2 应用需求形成 7.1.2.1 区块链应用需求分析需在区块链技术特征和对发展阶段的准确把握基础上，结合市场需求和 用户信息化水平等因素，着重分析应用区块链能够解决的业务痛点，以判断是否采用区块链以及选择哪 些应用场景。 7.1.2.2 区块链应用需求分析以业务痛点为出发点，分四步逐步判断应用区块链解决具体业务需求的 可行性和必要性，具体包括：分析识别、综合归类
14、，匹配映射和归纳总结。应用需求分析步骤如图 1 所示。 DB52/T 14662019 5 图1 应用需求分析示意图 a) 业务痛点识别和原因分析。应用场景分析需要对应用的诉求（例如解决业务痛点或应用创新需 要）有清晰的认识，在此基础上清楚地分析和判断区块链技术可以带来哪些价值，以及这些价 值是如何实现的。具体可逐个梳理和分析该应用场景下的业务痛点及相应原因，并将业务痛点 与原因对应； b) 痛点原因的综合归类。实际业务中，不同的业务痛点可能会由共同的原因导致，因此需要对分 析识别过程输出的业务痛点原因进行归类汇总，得到若干痛点原因类别； c) 痛点原因类别与区块链价值的匹配分析。匹配映射是将
15、业务痛点原因类别与区块链应用价值对 应，以分析该场景与区块链技术的匹配程度。可重点考察业务痛点原因类别与区块链 IT 架构、 数据两个层次的应用价值的匹配程度，将区块链技术可以解决或部分解决的业务痛点原因类别 与 IT 架构和数据层次的应用特征映射，最终体现业务和社会治理层面的应用价值； d) 区块链适用度归纳总结。在匹配映射过程中区块链应用价值与业务痛点原因类别符合程度的基 础上，对应用区块链的适用度进行归纳总结，最终得出是否采用区块链技术的结论。 7.1.3 应用场景分析 通过分析当前业务场景的应用需求，结合区块链的特点，实现应用场景的业务上链运行，应用场景 分析流程如图2所示，具体分析如
16、下： DB52/T 14662019 6 图2 应用场景分析流程图 a) 需求分析：对当前应用场景下的业务进行需求分析，识别业务痛点及原因并进行综合分类； b) 业务流程分析：结合当前业务需求，理清当前业务流程，对业务流程的可行性，适用性，优先 级进行分析； c) 业务流程设计：结合业务特点，对业务流程进行设计； d) 业务上链设计：结合区块链特点，对业务流程进行再设计，实现现实场景下的业务流程能在区 块链上高效运行； e) 业务上链实现：根据业务流程在区块链上的设计，对业务功能进行实现，并部署在区块链上； f) 业务上链测试：对链上实现的业务进行测试； g) 业务上链运行：将通过测试的业务流
17、程正式部署至区块链。 7.1.4 功能组件分析 参照ISO 23257区块链和分布式记账技术 参考架构提出如图3所示的区块链参考架构功能组件，计 划使用区块链的组织或个人根据实际情况选择相应功能组件。 图3 区块链参考架构功能组件 DB52/T 14662019 7 7.2 构建和运行 7.2.1 应用设计 在应用设计过程中，宜包括以下几个方面： a) 业务架构设计需包含： 1) 基于区块链实现与传统实现的态势分析； 2) 应用的营运模式； 3) 应用的盈利模式； 4) 应用的角色和场景匹配方案。 b) 逻辑架构设计需包含： 1) 应用与区块链网关对接方案； 2) 区块链网络监控方案。 c)
18、物理架构设计需包含： 1) 是否需要部署区块链节点，并确定部署节点类型（全节点、验证节点、同步节点和观察节 点等）； 2) 区块链节点的高可用方案； 3) 区块链节点的物理位置分布。 若是自身搭建区块链网络，需包含： 1) 区块链网络整体部署结构； 2) 根据不同的共识机制，设计验证节点数量和结构； 3) 区块链网络的安全方案（网络安全、数据安全等方面）； 4) 区块链网络的性能方案。 d) 数据架构设计需包含： 1) 明确应用上链数据和非上链数据边界需求； 2) 区块链账本数据存储方案； 3) 区块链账本归档数据存储方案。 若是自身搭建区块链网络，需包含： 1) 数据存储的高可用方案； 2)
19、 数据存储的性能方案。 e) 技术架构设计需包含： 1) 数据加解密密码学方案； 2) 同步和异步通信方案。 f) 账户架构设计需包含： 1) 账户标识用户友好性方案； 2) 账户秘钥安全性方案； 3) 账户结构（含会计分录）。 7.2.2 应用实施 在区块链应用实施过程中，主要关注点包括： a) KYC 要求 区块链应用实施过程中需遵循以下要求： 1) 落实信息内容安全管理主体责任； DB52/T 14662019 8 2) 建立与其业务相适应的真实身份认证制度和程序， 目标对象包括使用区块链服务的个人和 组织； 3) 认证过程需收集能够表明区块链服务使用者真实身份的有效信息。 若特定业务或
20、行业监管 规定对身份认证有其他更严格要求的，从其规定。 b) 监督检查要求 区块链应用实施过程中需在区块链系统中为监管部门： 1) 设置相应的监管角色和功能； 2) 开放具备监管功能的接口和权限； 3) 提供数据支持和技术协助； 4) 对不符合国家法律法规要求的信息应予以屏蔽或拒绝处理。 c) 安全性要求 区块链应用实施过程中需遵循以下要求： 1) 配备与业务相适应的日志信息保存机制，相关记录应当按照审计要求，保留六个月以上； 2) 配备不良信息检测和预防机制，防范此类信息的传播； 3) 制定应急处理机制，以在紧急情况下中断或屏蔽不良信息的传播； 4) 若区块链网络由多个参与方进行维护，应制定
21、协调机制，确保不良信息的应急处理措施可 在多个参与方之间执行； 5) 利用安全伪随机数生成器生成密码。 d) 隐私保护要求 区块链应用实施过程中在收集、存储、应用、披露和删除数据时，需遵循以下要求： 1) 获得隐私主体的授权； 2) 只为经过授权的用户提供有关隐私数据的访问权限； 3) 保护服务使用者的隐私，对敏感数据的存储应当采用加密、脱敏、隔离存储等安全措施； 4) 建立必要的隐私保护管理规范和应急处理办法。 7.2.3 应用运营 图4 区块链应用运维过程 DB52/T 14662019 9 在应用运营过程（如图4）中，需要重点关注的实践点： a) 监管机构： 1) 区块链应用系统备案；
22、2) 不能利用区块链技术传播、记录违法、不良信息。 b) 用户：建立健全用户注册、信息审核、应急处置、安全防护等管理制度。 c) 运营： 1) 品牌推广扩大品牌知名度； 2) 营销推广提高用户量。 d) 运维： 1) 需要监控（自动）网络的运行稳定情况； 2) 需要监控（自动）磁盘、CPU、内存等使用情况； 3) 需要关注开源社区的最新动态，尤其关注优化升级、软硬分叉和全节点变化情况； 4) 运营账户分权（多签名）管理。 e) 若是自身搭建区块链网络，需包含以下实践点： 1) 根据网络的运行稳定情况，动态调配环境资源； 2) 在灵活性和安全性两面进行平衡； 3) 测试环境和生产环境进行隔离。
23、7.3 评估和监督 7.3.1 区块链应用评估 7.3.1.1 业务维度评估 7.3.1.1.1 业务适当性 区块链应用需符合业务需求，评估目标业务场景中是否存在区块链可解决的需求点，评估中心化系 统在该业务场景中的痛点和不足，以及使用区块链技术后可为该业务带来的价值。 7.3.1.1.2 可治理性 鉴于区块链的业务系统与传统中心化系统在运营和管理上的差异，需对业务的持续治理进行规划与 调整，采用可行性、可持续性的治理结构。 7.3.1.1.3 经济可行性 区块链应用需能有效解决当前行业发展和业务流程中的痛点，带来经济价值的最大化和效率的提 升。 7.3.1.2 技术维度评估 针对具体的应用需
24、求，从技术可行性、功能、性能、可靠性、安全性、可维护性、可移植性、互操 作性、易开发性等方面综合评估。技术评价维度中的评价指标参考DB52/T 1467的要求。 7.3.1.3 社会效益维度评估 7.3.1.3.1 政策合规性 区块链应用中的区块链信息服务、区块链信息服务提供者与区块链信息服务使用者，应遵守区块 链信息服务管理规定的规定。法律、行政法规另有规定的，遵照其规定。 DB52/T 14662019 10 7.3.1.3.2 生态效益与产业融合 主要评估区块链应用是否与现有商业生态有效结合，是否有效打通产业上下游，构建新的面向结构 性特征的协同生态系统，形成新的价值共享应用生态，是否推
25、动整个产业、经济体系实现技术变革、组 织变革和效率变革，为构建现代化经济体系做出贡献。 7.3.2 区块链治理评估 7.3.2.1 治理原则 区块链技术应按照各行业的商业与监管要求来设定核心治理架构，确保符合监管要求。区块链应用 平台需遵循以下治理原则： a) 合法合规原则：遵守国家相关法律法规和监管要求，为监督审计需求提供技术支持； b) 可追溯原则：业务与活动都有记录，可追溯，可审计； c) 安全原则：采取各种必要的安全手段防范攻击，保障链上资产和交易等信息的安全； d) 隐私保护原则：保障链上的用户隐私安全，防止泄露用户隐私； e) 业务导向原则：以需求推动技术，设计与开发时优先考虑适用
26、的业务场景，通常需要对原有业 务流程进行重新梳理。一方面在保持合规性的同时使区块链技术特性得以充分发挥，另一方面 还应考虑如何为业务带来改善与价值创造。 7.3.2.2 治理对象与过程 区块链应用系统的治理对象包含参与者与技术系统的多个方面，内容广泛，以下选取部分具有联盟 链和私有链的治理对象进行说明： a) 身份认证与准入机制 这里的身份认证体系主要针对机构。在特定业务背景下，经个人用户授权后，由机构代理其个人用 户在链上进行交易。 一个机构拥有一个到多个区块链节点，节点接入到联盟链的网络中，代表其所属机构在链上进行活 动，包括同步数据、参与共识、发起交易等，机构和节点是一对多的关系，为了达
27、成机构级别的安全控 制和审计监督， 首先需要对机构进行身份认证和准入控制， 比如采用CA证书实现对机构身份认证的机制。 b) 节点管理 依据数据和共识参与程度， 部分或全部节点可设置为共识节点， 参与共识算法， 成为链上的记账者。 不参与共识，只同步数据的节点称为观察节点。 节点的配置管理包括两个维度： 1) 全网配置。将参与网络的所有节点信息写入到链上共同维护的全局配置，在此配置里的节 点才能被链上其他节点接受， 不存在该配置里的节点或配置有误的节点， 都会被拒绝连接； 2) 本地配置。是全网配置的一个子集，在本地配置文件里实现。本地配置只对拥有该配置的 节点生效，不影响全网配置，可以是暂时
28、性或永久性的，运维人员可根据节点的具体情况 进行精细化控制，给节点的管理增加了更细粒度的控制能力。 c) 共识机制 共识机制的基本决定参数： 1) 去中心化治理：单一中央机构不能提供交易不可改变性； 2) 节点结构：节点通过既定方式来交换信息，可分多个阶段或层级； 3) 身份验证：验证参与者的身份； 4) 完整性：验证交易的完整性，如通过加密算法； 5) 不可否认性：验证假定发送者真实发送了信息； DB52/T 14662019 11 6) 隐私性：协助确保只有既定接收人才能读取信息； 7) 容错性：即使某些节点或服务器失效或运行减慢，网络仍能高效、快速地运行； 8) 性能：包括吞吐量、实时性
29、、可扩展性和延迟。 上述参数的一部分通过加密法中四个主要方法来执行，这四个方法使用数学公式来尝试确保安全性 和隐私性。这四种方法包括公钥、私钥、散列法以及分层确定性密钥。不同共识机制中的参数会存在很 大差异。 公有链如比特币、以太坊等使用的共识算法通常为工作量证明或权益证明等；联盟链共识机制的设 计目标和公有链有所不同，比如： 1) 支持国际主流的数字签名算法，如 RSA 数字签名算法、ECDSA 等； 2) 支持我国商密的数字签名算法，如 SM2 数字签名算法等。 联盟链或私有链的共识机制的实现应符合联盟链或私有链的场景需求，可避免算力浪费、防分叉和 提升运行稳定性。 d) 隐私保护 针对个
30、人用户和机构用户的隐私数据，通常使用密码学算法保护数据、在体系架构上引入可信第三 方、以及按交易牵涉范围进行隔离等。 以下提出对联盟链和私有链应用平台上隐私数据进行保护的一些措施和评估方法： 1) 对数据的安全和敏感级别进行甄别，部分和交易以及账本无强相关，又具有高敏感性的数 据，应脱敏后再发到区块链上或不发送到区块链上； 2) 提供机构和机构之间点对点通信方式，数据通信仅发生在相关的机构之间，当机构之间针 对交易数据完成校验和协商之后仅把需要对全网确认共识的数据发送到联盟链上进行共 享； 3) 数据明细在链下保存，链上提供共识过的数据摘要、数据有效性证明、对数据的寻址方法、 数据访问授权约定
31、等，供机构之间在必要时通过数据下载协议获取可信的数据； 4) 数据可以对全联盟链进行广播，但采用高强度的加密数据信封方式进行保护，仅在交易参 与方以及中央对手方、监管方之间共享数据； 5) 在部分只涉及到数据数值加减的场景，可采用加法同态加密算法，实现对数据的隐私保护， 同时不会对性能有大的影响； 6) 在部分能承受一定效率损耗，并且涉及到复杂数据操作的交易场景，采用零知识证明，多 操作同态加密等算法，用密码学方式实现隐私保护。 7.3.3 监督与审计 7.3.3.1 监督的实施可从以下几个方面考虑： a) 监督节点不同于开发者、交易管理员、运营者、运维者等，监督节点可以拥有以上角色的权限 的
32、一部分或全部，也可以针对特定的业务场景，制定特定的权限集合； b) 在一些监督场景中，应用平台可支持监督节点选择性地参与到交易过程中，如在智能合约执行 前或者生效前，由监督节点检查合约的规则、数据，是否符合监管要求，进而给出签名背书。 具有监管方签名且得到全链共识的交易才能生效； c) 通过监管工具、角色赋权等方案，监督节点能在事后通过区块链数据同步的特性，审计所有的 数据，进行业务合规检查等操作，让监督节点可以直接对联盟链或私有链实施的控制。 7.3.3.2 审计的实施从以下几个方面考虑： a) 在特定情况下允许审计者加入区块链系统并作为其中一个节点进行实时监控与审计； b) 区块链账本可永
33、久保存与审计活动相关的数据和证据，包括协议所有参与方的活动、运营环境 条件的记录和日志、审计员的审计查看动作记录等； DB52/T 14662019 12 c) 在区块链应用平台之外，建立完善健全的审计制度，做到事后审计与事前、事中审计的有机结 合，建立包含查处违规违纪审计、内控制度审计、绩效审计等维度的内审指标体系；保障业务 运作的安全合规。 7.4 改进和优化 7.4.1 性能优化 针对高频的实时交易处理需求时，需采用跨链、多链、分片等并行处理方式来提升区块链系统的处 理性能。 7.4.2 隐私保护优化 隐私保护优化方式可考虑包括以下两种思路： a) 通过加密手段和密钥管理机制的结合实现对
34、隐私信息或者隐私信道的受控访问； b) 通过环签名、同态加密、零知识证明等安全机制实现对交易的关键隐私信息的保护。 7.4.3 安全性优化 区块链系统安全机制参考附录A。 DB52/T 14662019 13 A A 附 录 A （资料性附录） 区块链关键技术分析 区块链关键技术主要包括分布式共识、P2P网络 、密码学、数据库与智能合约。本附录将从共识机 制、隐私保护、智能合约、安全机制、数据存储等方面对区块链关键技术进行分析。 A.1 共识机制 共识机制是区块链或分布式账本技术应用的一种无需依赖中央机构来鉴定和验证某一数值或交易 的机制。共识机制是所有区块链和分布式账本应用的基础，其核心在于
35、如何解决某个变更在网络中是否 一致的问题。常用的共识机制主要包括：PoW、PoS、DPoS和PBFT等。在公开匿名场景和带权限管理场景 中对共识机制的需求差异较大，如PoW算法考虑的是公开匿 名场景下的最坏保证，并通过概率模型确保 合法的最长链。其他类似改进算法有PoS、DPoS和Casper。 A.2 隐私保护 隐私保护是指使个人或集体等实体不愿意公开的信息受到保护。隐私保护需要考虑匿名、数据访问 控制、审计、在线社会网络隐私保护、移动定位隐私保护以及数据库个人隐私保护等方面的问题和需求。 区块链主要通过密码学来防止交易记录被篡改，证明交易双方的身份与保护交易双方的隐私。密码技术 包括Has
36、h算法，加解密算法，数字证书和签名(盲签名、环签名与同态加密)等。 A.3 智能合约 智能合约是一套以数字形式定义的承诺，合约参与方可以在上面执行这些承诺的协议。一个合约就 是区块链里的程序代码，合约的参与双方将达成的协议提前安装到区块链系统中，在双方的约定完成后， 开始执行合约，且不可篡改。基于区块链的智能合约包括事务处理和保存的机制，以及一个完备的状态 机，用于接受和处理各种智能合约，事务的保存和状态处理都在区块链上完成。事务主要包含需要发送 的数据；而事件则是对这些数据的描述信息。整个智能合约系统的核心在于智能合约以事务和事件的方 式经过智能合约模块的处理，处理之后还是一组事务和事件，智
37、能合约的存在是为了让一组复杂的、带 有触发条件的数字化承诺能够按照参与者的意志，正确执行。 A.4 安全机制 信息安全主要指需保证信息的保密性、真实性、完整性、未授权拷贝和所依赖系统的安全性。区块 链的安全性主要体现在密码学安全性、网络安全性、共识机制安全性与业务安全性等方面。 a) 密码学安全性。包括签名、验签、Hash 摘要等（不是所有的区块链都需要加密和解密操作）。 目前区块链技术采用的密码学算法都是相对安全的，需考虑区块链技术后期迭代发展出现漏洞 的可能性； DB52/T 14662019 14 b) 网络安全性。指数据在网络中传输的安全性，此部分数据还未持久化，包含内存中的数据，暂
38、时统称为空中数据。网络安全性问题当前主要采用 HTTP+SSL 的方式进行处理，以保证区块链 平台数据在网络传输过程中防篡改和加密处理的需求； c) 数据安全性。在区块链系统中，账本数据全部公开或者部分公开，强调的是账本数据多副本存 在，防止存在数据丢失的风险。当前采用的解决方案大部分是全分布式存储，即在网络中的多 个全节点间同步所有账本数据，使数据丢失的风险降低。建议在部署区块链网络时，尽量将全 节点分散在不同地理位置，选用不同的基础服务提供商、不同的利益体； d) 共识机制安全性。采用不同的共识机制需要考虑整个区块链网络的活性和业务安全性。大部分 的公有链区块网络更加强调活性，通过分叉来保
39、证整个网络的活性。其他区块链网络更加强调 业务安全性，当网络中出现异常事务时，即全网停机维护升级。共识机制可实现两种类型的折 中，同时要按照业务的实际应用场景进行选择； e) 智能合约安全性。智能合约的编写存在各类型的安全漏洞，如可重入攻击、误操作异常等。此 类安全性风险的解决方案包括形式化验证、委托专业机构审计合约或者对合约加密。目前智能 合约应用处于初级阶段，新的漏洞会不断产生； f) 业务安全性。也称为语义安全性或逻辑安全性。此类安全性最为复杂，防范难度大。越灵活使 用的区块链技术， 出现问题的概率越大， 目前防范此类安全性风险的解决方案包括形式化验证、 静态分析、覆盖率测试等。 A.5
40、 数据存储 从数据库的角度看，区块链是一种新型的数据组织方式，区块链网络中的块信息需要写到数据库中 进行存储。区块链系统的应用是通过大量的写操作、Hash计算和验证操作等，跟传统数据库的行为有明 显差异。面向区块链的数据库技术仍然是需要突破的技术难点之一。现阶段levelDB、RocksDB等键值数 据库，因具备很高的随机写和顺序读写性能，以及相对较差随机读的性能，被广泛应用在区块链信息存 储中。 A.6 跨链技术 跨链技术是指跨越链和链之间数据流通障碍的技术，是实现不同区块链数据互联互通的关键，从而 实现跨链数据资产的转移。目前主流的跨链技术包括：侧链、公证人、哈希锁定和分布式私钥控制等。
41、其中侧链技术利用中继链等技术，实现了不同区块链之间的可信互通。公证人技术引入了可信第三方， 作为跨链过程中的资产保管人。哈希锁定利用哈希原像实现了公平的跨链资产交换。分布式密钥控制技 术利用分布式密钥生成算法，使得跨链过程中的资产保管人角色由全网节点承担，而不是少数第三方。 当前侧链和分布式密钥等技术都需要不同链之间彼此获知链的更新状态， 使用区块头在不同链中构建了 微型的目标链，然而当需要交互的链数目较多时，将会对区块链的性能带来影响。而除了哈希锁定技术 外，其余技术直接或间接的引入了第三方，因此可能带来外部风险。 A.7 分片机制 共识机制和区块大小的限制使得每次共识的交易确认数有限，造成了区块链系统交易吞吐量的瓶 颈。分片机制通过将全网节点划分成不同的集合，每个集合独立并行的进行共识、确认交易，从而使得 系统的吞吐量随着全网中参与共识的节点的增加而增加。 目前分片机制的安全性分析较少且存在由于网 络延迟被恶意攻击的可能性。 DB52/T 14662019 15 参 考 文 献 1 GB/T 32399-2015 信息技术 云计算 参考架构 2 CBD-Forum-001-2017 区块链 参考架构 3 中国区块链技术和产业发展论坛 中国区块链技术和应用发展研究报告（2018）. 4 国家互联网办公室 区块链信息服务管理规定. _ DB52/T 1466-2019
