金融分布式账本技术资金管理应用技术要求(T-NIFA 25—2023).pdf

《金融分布式账本技术资金管理应用技术要求(T-NIFA 25—2023).pdf》由会员分享，可在线阅读，更多相关《金融分布式账本技术资金管理应用技术要求(T-NIFA 25—2023).pdf（29页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、ICS 35.240.40 CCS A 11 团 体 标 准 T/NIFA 252023 金融分布式账本技术资金管理应用 技术要求 Fund management application of financial distributed ledger technologyTechnical requirements 2023-11-10 发布 2023-11-10 实施 中国互联网金融协会 发布 T/NIFA 252023 I 目 次 前言.II 引言.III 1 范围.1 2 规范性引用文件.1 3 术语与定义.1 4 缩略语.5 5 总体要求.5 5.1 对等合作.5 5.2 安全透明.6

2、 5.3 数据可追溯.6 5.4 开放共享.6 5.5 分层部署.6 6 资金管理技术参考架构.6 7 基础设施层.7 7.1 总体要求.7 7.2 机房要求.7 7.3 服务器要求.8 7.4 网络要求.9 7.5 基础软件要求.10 7.6 运维要求.11 8 金融分布式账本平台层.12 8.1 总体原则.12 8.2 参考架构.13 8.3 功能要求.14 8.4 性能和安全.20 9 资金管理服务层.20 9.1 总体原则.20 9.2 参考架构.21 9.3 功能要求.21 参考文献.24 T/NIFA 252023 II 前 言 本文件按照GB/T 1.12020标准化工作导则 第

3、1部分：标准化文件的结构和起草规则和GB/T 20004.12016团体标准化 第1部分：良好行为指南给出的规则起草。请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别专利的责任。本文件由中国互联网金融协会提出。本文件由中国互联网金融协会归口。本文件起草单位：中国互联网金融协会、中国工商银行股份有限公司、深圳前海微众银行股份有限公司、京东科技控股股份有限公司、博雅正链（北京）科技有限公司、华为技术有限公司、中国人民保险集团股份有限公司、北京银行股份有限公司、交通银行股份有限公司、上海浦东发展银行股份有限公司。本文件主要起草人：单强、陆书春、朱勇、王新华、刘朝伟、夏琼、陈法山、姚新亮

4、、郭晓磊、周婧、张薇、余纬中、马文杰、傅华崧、温沛霖、杨立峰、武国峰、邸明杰、刘燕青、高玉翔、王海龙、王飞、张小军、张亮亮、杨猛、李赫、刘朋辉、王光中、钱菲、高扬。T/NIFA 252023 III 引 言 金融分布式账本技术是密码算法、共识机制、点对点通讯协议、分布式存储等多种核心技术体系高度融合形成的一种分布式基础架构与计算范式。资金管理是金融领域的重要应用场景，金融分布式账本技术可提升资金管理的安全性、可信性、公开性。金融分布式账本资金管理应用技术要求旨在提供基于金融分布式账本技术的资金管理所需的基础设施、平台、服务和应用的技术指标。T/NIFA 252023 1 金融分布式账本技术资金

5、管理应用技术要求 1 范围 本文件确立了基于金融分布式账本技术的资金管理系统的设计原则，明确了系统的参考架构，规定了系统的功能要求。本文件适用于金融分布式账本资金管理系统研发、部署、运营、检测等。2 规范性引用文件 下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件，仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。GB/T 222392019 信息安全技术 网络安全等级保护基本要求 GB/T 329052016 信息安全技术 SM3密码杂凑算法 GB/T 329072016 信息安全技术 SM4分组密码算法 G

6、B/T 32918.22016 信息安全技术 SM2椭圆曲线公钥密码算法 第2部分：数字签名算法 GB/T 32918.42016 信息安全技术 SM2椭圆曲线公钥密码算法 第4部分：公钥加密算法 GB/T 370922018 信息安全技术 密码模块安全要求 GB 501742017 数据中心设计规范 GM/T 00452016 金融数据密码机技术规范 GM/T 00542018 信息系统密码应用基本要求 GM/T 01042021 云服务器密码机技术规范 JR/T 01842020 金融分布式账本技术安全规范 JR/T 01932020 区块链技术金融应用 评估规则 ISO/IEC 1488

7、82:2008 信息技术 安全技术 带附录的数字签名 第2部分:基于整数分解的机制 ISO/IEC 148883:2018 信息技术 安全技术 带附录的数字签名 第3部分:基于离散对数的机制 ISO/IEC 180332:2006 信息技术 安全技术 加密算法 第2部分：非对称密码 ISO/IEC 180333:2010 信息技术 安全技术 加密算法 第3部分：分组密码 3 术语与定义 下列术语和定义适用于本文件。3.1 金融分布式账本 financial distributed ledger 分布式账本 distributed ledger 由一组金融分布式账本节点（3.2）共享，并使用共识

8、机制（3.3）在分布式账本技术节点之间同步的分户账（3.4）。来源：ISO 22739:2020，3.22，有修改 T/NIFA 252023 2 3.2 节点 node 金融分布式账本节点 financial distributed ledger node 参与网络并存储分户账记录（3.5）的完整或部分副本的设备或过程。来源：ISO 22739:2020，3.27，有修改 3.3 共识协议 consensus protocol 共识机制 consensus mechanism 达成共识（3.6）的规则和程序。来源：ISO 22739:2020，3.12，有修改 3.4 分户账 ledger

9、保存最终的、确定的和不可变更（3.7）的交易（3.8）记录（3.9）的信息存储。来源：ISO 22739:2020，3.43，有修改 3.5 分户账记录 ledger record 包含交易记录（3.10）、交易记录的哈希值（3.11）或交易记录（3.10）在金融分布式账本（3.1）上引用的记录（3.9）。来源：ISO 22739:2020，3.44，有修改 3.6 共识 consensus 金融分布式账本节点（3.2）之间的约定，一是一个交易（3.8）是已确认的（3.12），二是金融分布式账本（3.1）包含已确认的（3.12）交易（3.8）排列的一致集合。来源：ISO 22739:2020，

10、3.11，有修改 3.7 不可变更性 immutability 一旦添加到金融分布式账本（3.1）中，分户账记录（3.5）就不能修改或删除的属性。来源：ISO 22739:2020，3.40，有修改 3.8 交易 transaction 工作过程的最小单元，它是产生符合治理规则的结果所需的一个或多个活动序列。来源：ISO 22739:2020，3.77，有修改 3.9 记录 record 一个组织或个人在履行法律义务或在业务交易中（3.8）作为证据和资产（3.13）创建、接收和维护的信息。T/NIFA 252023 3 来源：ISO 22739:2020，3.67，有修改 3.10 交易记录

11、transaction record 记载任何类型的交易（3.8）的记录（3.9）。来源：ISO 22739:2020，3.79，有修改 3.11 哈希值 hash value 一个密码哈希函数（3.14）的输出位串。来源：ISO 22739:2020，3.39，有修改 3.12 已确认的 validated 当实体（3.15）所需的完整性条件已被检查后的状态。来源：ISO 22739:2020，3.81，有修改 3.13 资产 asset 任何对干系人有价值的东西。来源：ISO 22739:2020，3.1，有修改 3.14 密码哈希函数 cryptographic hash functio

12、n 函数将任意长度的二进制字符串映射到固定长度的二进制字符串，这样在给定的输出中寻找一个映射到输出的输入在计算上成本很高，在给定的输入中寻找第二个映射到相同输出的输入在计算上不可行，且在计算上寻找任何两个不同的输入映射到相同的输出也不可行。来源：ISO 22739:2020，3.15，有修改 3.15 实体 entity 在信息和通信技术系统内部或外部的项，如人、组织、设备、子系统，或能被清晰地识别出来的由多个项构成的项组。来源：ISO 22739:2020，3.34，有修改 3.16 智能合约 smart contract 存储在金融分布式账本系统（3.19）中的计算机程序，该程序的任何执行

13、结果都被记录在金融分布式账本（3.1）上。来源：ISO 22739:2020，3.72，有修改 3.17 金融分布式账本系统 financial distributed ledger system T/NIFA 252023 4 实现金融分布式账本（3.1）的系统。来源：ISO 22739:2020，3.30，有修改 3.18 金融分布式账本平台 financial distributed ledger platform 一组处理、存储和通信的实体（3.15），它们共同提供每个节点（3.2）上金融分布式账本系统（3.17）的能力。来源：ISO 22739:2020，3.29，有修改 3.19

14、区块 block 由区块数据（3.20）和区块头（3.21）组成的结构化数据。来源：ISO 22739:2020，3.2，有修改 3.20 区块数据 block data 包含零到多个交易记录（3.10）或交易记录引用的结构化数据。来源：ISO 22739:2020，3.3，有修改 3.21 区块头 block header 包含到前一个区块（3.19）密码链接（3.22）的结构化数据，除非没有前一个区块。来源：ISO 22739:2020，3.4，有修改 3.22 密码链接 cryptographic link 使用密码哈希函数（3.14）技术构造的指向数据的引用。来源：ISO 22739:

15、2020，3.16，有修改 3.23 预言机 oracle 通过金融分布式账本系统（3.17）以外的数据更新金融分布式账本（3.1）的服务。来源：ISO 22739:2020，3.28，有修改 3.24 共识节点 consensus node 负责金融分布式账本数据一致性的节点。JR/T 01842020，定义3.24，有修改 3.25 记账节点 accounting node 负责金融分布式账本数据完整性的节点。JR/T 01842020，定义3.25，有修改 T/NIFA 252023 5 3.26 跨链 inter-blockchain 在多个分布式账本之间传递价值和信息的技术方案。3.

16、27 数据归档 data archiving 将金融分布式账本中不经常使用的历史数据迁移到一个单独的存储设备来进行长期保持的技术方案。3.28 可编程支付 programmable payment 根据预先设定的条件和规则进行自动支付的技术方案。3.29 隐私信息 private information 特定自然人的标识信息及其在特定系统中的活动信息。JR/T 01842020，定义3.41 3.30 个人信息 personal information 以电子或者其他方式记录的能够单独或者与其他信息结合识别特定自然人身份或者反映特定自然人活动情况的各种信息。JR/T 01842020，定义3.

17、42，有修改 3.31 局部聚集系数 local clustering coefficient 网络分析中的一个感念，用于衡量一个节点的邻居节点之间连接的紧密程度。3.32 联盟 consortium 联盟链 consortium blockchain 由两个以上机构共同运营的金融分布式账本系统（3.17），其中每一个机构控制一个或多个节点（3.2）。4 缩略语 下列缩略语适用于本文件。CA：认证机构（Certificate Authority）ID：身份标识符（Identification）5 总体要求 5.1 对等合作 T/NIFA 252023 6 资金管理应用应由参与机构平等共同维护，

18、不应由一个或部分机构控制资金管理的全流程，应通过金融分布式账本技术实现资金的协同管理。资金管理应用的金融分布式账本应由多个对等节点组成，由上述参与方平等地共同建设、管理和运营，参与方对其所建设、管理和运营的节点享有全部权利。5.2 安全透明 资金管理应用应通过金融分布式账本技术实现资金的安全、透明全流程管理。金融分布式账本存储的数据，除确需保密的管理、运营相关数据外，所有业务数据应毫无保留地向任何参与节点公开，管理运营节点对此类数据的查询权限，应与其他任何参与节点一致。5.3 数据可追溯 资金管理应用应将资金流转、审核流程等信息存储于金融分布式账本，支持信息可回溯。金融分布式账本应如实存储资金

19、管理应用的操作历史，确保系统投入运营后，任意用户在任意时间发生的资金管理操作均可查询。5.4 开放共享 资金管理应用应支持第三方数据接入、系统对接，支持金融分布式账本上的信息共享和权限查询、调用等，应支持多银行机构基于金融分布式账本技术形成联盟链，通过金融分布式账本传递交易信息和反馈结果等。5.5 分层部署 资金管理应用可根据资金管理的不同层级，支持分层部署，如基础设施层、金融分布式账本平台层、资金管理服务层、业务应用层。6 资金管理技术参考架构 基于金融分布式账本技术的资金管理服务从底层到顶层可划分为基础设施层、金融分布式账本平台层、资金管理服务层、业务应用层等四个边界清晰、高度内聚、有机统

20、一的主要功能层。基础设施层包含机房、服务器、网络设备等基础软硬件设施，为上层提供安全可靠的运行环境；金融分布式账本平台层包含金融分布式账本节点及其内部的通讯、共识、合约、存储等关键模块，为上层提供业务无关的核心金融分布式账本技术能力；资金管理服务层包含基础服务、金融服务、运营管理等服务组件，为上层提供资金管理必须的核心业务中间件；业务应用层包含建工、预付、政务等应用场景，为资金管理应用的最终用户提供丰富、完整、友好的资金管理服务。注：业务应用层内容见T/NIFA 242023金融分布式账本技术资金管理应用业务要求。T/NIFA 252023 7 基础设施层机房服务器网络 分布式账本平台层通讯模

21、块共识模块智能合约 资金管理服务层基础服务金融服务运营管理业务应用层建工场景资金管理预付场景服务政府财政场景 图1 金融分布式账本资金管理应用的参考架构 7 基础设施层 7.1 总体要求 基础设施层是指金融分布式账本技术资金管理应用的基础硬件设施与设备，以及基础软件，分为物理机房、硬件服务器、网络设备、操作系统等基础设施，为金融分布式账本技术资金管理应用的业务系统提供基础支撑环境。基础设施层应使用安全可控、体系架构开放的硬件进行构建，保障安全性、可用性和可靠性。金融分布式账本技术资金管理应用基础设施层应满足国家及金融行业相关标准中对基础设施层的要求。7.2 机房要求 7.2.1 物理机房要求

22、物理机房在选址与设备布置、环境要求、建筑结构、供配电、照明、空气调节、电磁屏蔽、网络与布线、环境与设备监控、消防与安全等方面应达到GB 501742017中B级及以上标准。此外，部署的物理机房及附属设施应符合以下要求：a)对于云端部署模式，应保证用金融分布式账本技术资金管理系统的运行环境位于高安全区域；b)对于金融分布式账本技术资金管理系统中承担共识节点或记账节点功能的系统节点，宜保证使用者业务运行、数据存储和处理的物理设备位于中国境内；c)物理数据中心应具备一定的防自然灾害能力，应防水、防潮、防雷击、防火、防静电、防风、防沙，并进行温湿度控制。7.2.2 安全及管理要求 机房出入人员和物品应

23、进行安全管理，包括但不限于以下要求：a)机房内应严禁存放易燃、易爆、易碎、易污染、强磁场、腐蚀性物品；b)机房内的各类设备、资料、磁介质未经批准不得私自带出；c)机房内设备或主要部件应放置牢固，并设置明显的不易除去的标记；T/NIFA 252023 8 d)应严禁外来人员携带手机、照相、摄像、录音以及其他记录设备等无关物品进出机房；e)外来人员在机房进行维修、维护活动期间，接待部门必须专人全程陪同，并监督、审核全部操作内容。7.2.3 高可用部署要求 机房的规划和部署应满足对业务高可用、灾备演练、自动主备切换等要求，保障在特殊异常情况下可正常对外提供硬件服务器、网络、基础软件等服务：a)机房应

24、至少进行双园区部署，满足灾备演练以及断电、火灾、地震等特殊异常情况的主备机房切换要求。可选择但不限于同城异地模式，两地多中心等模式；b)金融分布式账本节点设备应部署在不同机构各自的所属机房内，各机构对节点所在的设备应具备全权管理能力；c)金融分布式账本节点应避免出现集中托管或运行于同一物理环境的情况。如存在集中托管情况应具备多园区机房的备份能力。7.2.4 监控要求 针对机房内环境和设备的监控应具备但不限于以下要求：a)监测和控制机房内的温度，应确保环境满足机房内设备的运行要求；b)机房专用空调、发电机、不间断电源系统等设备应配带监控系统，监控的参数宜纳入设备监控系统；c)宜支持对设备进行智能

25、化故障诊断和健康检查功能；d)可支持基于 RFID 的设备资产管理功能；e)可支持基于 ZigBee 通讯的电池监控管理功能；f)可支持基于智能 PDU 的电能监测等监控功能。7.3 服务器要求 7.3.1 硬件设备要求 对于金融分布式账本技术资金管理系统中硬件设备主要包括系统部署的服务机，虚拟机归属的物理服务机，云上节点的宿主机，外部存储等。设备指标和基本功能应满足但不限于以下要求：a)应确保设备和存储介质在重用、报废或更换时，能对其承载的数据进行清除且不可恢复；b)应保证不同节点使用的硬件设备具备异构性；c)对于云端部署模式，应在云端环境服务方的配合下，保证云端环境具备一定的异构性；d)应

26、保证设备运行状态或资源使用情况异常时能发出警告；e)对于云上部署的金融分布式账本系统，宜满足以下配置条件：1)共识节点部署的服务器或虚拟机，CPU 宜不小于 16C，内存宜不小于 32G、外部存储宜不小于 500G；2)记账节点的服务器或虚拟机，CPU宜不小于4C，内存宜不小于8G，外部存储宜不小于600G；3)单个共识节点容器，CPU 配置应大于 1C，内存配置应大于 1024M。7.3.2 硬件加密设备安全要求 对于使用硬件加密设备完成密码运算和密钥存储的金融分布式账本技术资金管理系统，所用硬件加密设备应满足以下要求：a)硬件加密设备应符合 GM/T 00452016 的要求；b)云服务器

27、加密设备应符合 GM/T 01042021 的要求。T/NIFA 252023 9 7.3.3 节点部署要求 对于金融分布式账本技术资金管理系统中节点部署的安全及监控功能应满足但不限于以下要求：a)应保证系统关键节点冗余部署，保证操作系统可用性；b)应保证系统承担共识或记账的节点部署在不同机房内；c)应保证带有不适合共享数据的节点放置于机构内部或受保护区域；d)应保证节点的硬件设备存储容量可扩展，避免因容量达到上限而无法同步账本；e)应在支持物理机、虚拟机、云技术等节点部署方式；f)应具备节点状态展现和信息查询等功能；g)应具备节点日志自动收集和统一查询等功能。7.3.4 存储功能要求 对于金

28、融分布式账本技术资金管理系统使用的存储设备资源在功能、安全性和高可用等方面满足但不限于以下要求：a)应支持在每个对等网络节点上部署并使用；b)应支持高效、安全、稳定地提供数据写入及查询服务；c)对于采取分库分表的数据存储方案，存储功能组件应支持数据的分片及路由处理能力；d)能够对写入数据做到持久化处理，随账本节点可持续；e)宜支持对存储数据进行高效备份；f)宜支持在存储节点故障后进行快速自检与恢复；g)宜支持对数据的局部或全局进行加密；h)宜提供扩容支持；i)应支持数据备份与恢复功能；j)应支持分布式账本资金管理系统数据的导出功能，支持将分布式账本系统数据导入到其他数据库或者文件系统中；k)宜

29、支持归档存储功能。7.4 网络要求 7.4.1 网络安全要求 支撑金融分布式账本技术资金管理系统的基础设施在网络架构的安全和通讯传输安全等方面满足但不限于以下要求：a)在网络拓扑中，应防止单个节点故障而形成网络隔离；b)应保证每个重要节点具有较大的局部聚集系数；c)对于金融行业里高敏感度的金融业务，应通过金融专用网或端到端加密的方式与公网隔离；d)应在金融分布式账本各节点间实现信源加密和网络通道加密，信源加密使用加密算法将数据明文转换为密文，网络通道加密可采用 SSL/TLS 协议、SSH 协议、VPN 技术等措施在网络传输过程中对数据进行保护，保证数据机密性、完整性与可用性；e)应对金融分布

30、式账本数据传输实现访问控制，包括但不限于身份认证、权限限制、端口开放限制等技术手段；f)应对数据和信息采取相应的防护措施，保证其能抵抗篡改、重放等主动或被动攻击；g)应增加防火墙设置，避免非法用户访问；h)互联网接入应符合多运营商链路接入，如条件具备，可要求各运营商提供二路由接入机房；i)应提供通信线路、关键网络设备的硬件冗余，保证网络可用性；T/NIFA 252023 10 j)应能对非授权设备私自联到内部网络的行为进行检查或限制；k)应对主机攻击行为可溯源，可还原攻击过程；l)应能检测到对重要节点进行入侵的行为，并且在发生严重入侵事件时提供报警。7.4.2 节点访问要求 支撑金融分布式账本

31、技术资金管理系统的基础网络设施应满足对金融分布式账本系统组网、内部通讯、外部请求访问等功能的基本要求。a)各节点应支持基于网络通信协议和对等网络进行通信和数据互换；b)通信控制功能应分布在各节点上，且任一节点均至少与其他两个节点建立通信连接；c)保证共识节点或记账节点之间能直接进行网络通信或能间接进行消息传递；d)支持上层服务应用通过域名访问金融分布式账本节点；e)对于负责接入访问金融分布式账本节点的网关应支持负载均衡功能；f)支持对网关设备的自动健康检查功能，对于异常网关能够自动实施隔离措施，并发起报警；g)支持网络故障快速切换功能。7.4.3 网络监控要求 对于金融分布式账本技术资金管理系

32、统中基础网络的监控功能应满足但不限于以下要求：a)应支持网络故障报警功能；b)应支持网络关键设备或资源的状态可视。7.5 基础软件要求 7.5.1 安全要求 基础软件环境应遵循GB/T 222392019中三级以上的主机安全、应用安全、数据安全及备份恢复相关要求，同时还应包括以下对访问控制、入侵防范、恶意代码防范等方面的要求：a)应由授权主体配置访问控制策略，访问控制策略规定主体对客体的访问规则；b)访问控制的粒度应达到主体为用户级或进程级，客体为文件级、数据库表级；c)应对重要主体和客体设置安全标记，并控制主体对有安全标记信息资源的访问；d)应遵循最小安装的原则，仅安装需要的组件和应用程序；

33、e)应关闭不需要的系统服务、默认共享和高危端口；f)应通过设定终端接入方式或网络地址范围对通过网络进行管理的管理终端进行限制；g)应提供数据有效性检验功能，保证通过人机接口输入或通过通信接口输入的内容符合系统设定要求；h)应能发现可能存在的已知漏洞，并在经过充分测试评估后，及时修补漏洞；i)应采用免受恶意代码攻击的技术措施或主动免疫可信验证机制及时识别入侵和病毒行为，并将其有效阻断。7.5.2 操作系统要求 系统应有针对不同操作系统的软件版本，宜支持至少三种操作系统或系统版本。示例1：Ubuntu、SUSE、麒麟 Neokylin 是三种操作系统。示例2：Ubuntu 18.04.6 LTS、

34、Ubuntu 16.04.7 LTS、Ubuntu 14.04.6 LTS 是同一种操作系统的三种不同系统版本。7.5.3 软件部署要求 应支持针对物理机、虚拟机、云上节点等服务器使用的操作系统、数据库、JAVA 等基础软件及其版T/NIFA 252023 11 本进行灵活配置，并能够进行自动安装。7.6 运维要求 金融分布式账本基础设施层应配套运维监控平台，具备用户登录身份鉴别和访问权限控制功能，以及对金融分布式账本的网络部署、节点维护、接入交易统计、日志查询等运维功能进行统一管理和维护的能力。7.6.1 身份鉴别 登录运维平台的用户应通过注册信息，设置密码等鉴别方式进行身份鉴别，包括但不限

35、于以下功能要求：a)应具备新增、删除用户，修改用户信息和密码等管理功能；b)应对登录的用户进行身份标识和鉴别，身份标识具有唯一性，身份鉴别信息具有复杂度要求并定期更换；c)应配置并启用结束会话、限制非法登录次数和当登录连接超时自动退出等相关措施；d)应采用口令、密码技术、生物技术等两种或两种以上组合的鉴别技术对用户进行身份鉴别，且其中一种鉴别技术至少应使用密码技术来实现；e)核实过程应能接受监管审计；f)在身份核实阶段不应弄虚作假、核实操作员不应渎职不作为、核实过程应严谨。身份核实错误导致的系统损失由身份注册机构承担；g)存在隐私保护需求的金融分布式账本系统可使用匿名身份认证。但应遵循“前台自

36、愿、后台实名”的原则，前台使用匿名标识，后台应能还原注册实体的实名身份。7.6.2 访问控制 运维平台应对登录用户的访问和操作权限进行控制，包含但不限于以下功能要求：a)应授予管理员账户所需的最小权限，实现用户的权限分离；b)应支持重命名默认账户，修改默认账户的默认口令；c)应及时删除或停用多余、过期的账户；d)应对登录的用户按分组进行权限控制；e)应支持管理员账户修改用户分组信息；f)应支持管理员账户维护用户分组的访问权限；g)管理员账户应具备对普通用户操作的审批权限；h)每一次权限操作应写入日志，尤其是账本敏感信息的查看和使用，用于复查和审计。7.6.3 运维功能 运维平台对于金融分布式账

37、本基础环境运维操作应支持但不限于以下功能要求：a)应支持金融分布式账本网络的自动构建、部署、停止、启动功能；b)应支持金融分布式账本网络新增节点操作，且具备数据自动同步功能；c)应支持底层硬件设备部署配置功能；d)应支持存储设备配置功能；e)应支持智能合约自动部署功能。部署智能合约时应充分考虑合约版本兼容性，以及部署期间各运行合约节点的可用性，并对最终部署成功节点合约进行校验，确保合约版本一致性；f)应支持日志搜索功能；g)应支持展示统计平台用户数、累计访问量、金融分布式账本网络数、网络交易数、节点分布情T/NIFA 252023 12 况、节点状态、最新区块哈希值、区块高度、系统资源消耗等信

38、息；对于异常节点、系统负载超过阈值的情况，应以醒目方式提示运维人员。7.6.4 版本升级 金融分布式账本基础环境版本升级应支持但不限于以下功能要求：a)节点的版本升级前，应在测试环境进行验证，应保证升级过程中对业务的平滑过渡。除非发生重大安全事故，应避免采用所有节点同时停止服务进行升级的方式；b)节点的版本升级应支持向下兼容，升级后仍须支持旧版本的数据；c)节点的版本升级应记录升级过程中相关操作日志，做到可审计、可追溯；d)应制定版本升级失败的应急预案，在升级失败的情况下启动应急预案进行回滚，在规定时间内恢复节点的可用性；e)分布式账本节点升级应小于 30 分钟。7.6.5 漏洞修复 金融分布

39、式账本基础环境漏洞修复应支持但不限于以下功能要求：a)应对节点的服务器进行定期漏洞扫描检查包括但不限于服务器本身的漏洞、分布式账本软件的漏洞、智能合约的漏洞，并对发现的安全漏洞和隐患提出修复方案进行审批，审批通过后进行修复，无法由运维修补的漏洞须评估可能的影响并上报；b)进行漏洞修复，应不影响节点的账本数据、密钥等关键业务数据的历史数据。修复前应在测试环境进行验证。如果漏洞修复影响到账本数据，则应通过共识协议进行数据的修正；c)应记录漏洞修复的审批记录、操作历史等信息，做到可审计、可追溯。7.6.6 异常恢复 金融分布式账本基础环境异常恢复应支持但不限于以下功能要求：a)由于停电、系统崩溃等意

40、外突发事件造成共识节点宕机，RTO 应控制在 1 小时内；b)应制定节点的主动恢复方案，保障当出现突发情况时，节点能够主动快速地恢复正常运行。8 金融分布式账本平台层 8.1 总体原则 8.1.1 不可篡改 平台层以区块链存储资金管理应用的操作历史，不允许对物理数据进行修改、删除，如果在业务逻辑上确有必要对某一笔资金管理操作进行修改，那么只能通过新增一笔物理操作记录，声明过去的某一笔操作被修改、删除，但该笔被声明修改、删除的记录，应依然存储在平台上，并永久保持可查询状态。8.1.2 跨链支持 平台层应支持金融分布式账本与其他区块链系统和非区块链系统之间的互联互通，通过可信交互节点、密码学技术、

41、跨链协议等实现数据的可信跨链流转。8.1.3 安全审计 平台层的数据应通过全文加密或摘要加密方式提供安全审计功能，审计记录包括访问时间、用户标识、数据内容等升级相关内容。T/NIFA 252023 13 8.2 参考架构 8.2.1 总体架构 金融分布式账本平台层可由通讯模块、密码学模块、共识模块、存储模块、智能合约五部分构成。如图2所示，其关系如下：a)通讯模块接收用户和其他系统的服务请求并返回响应数据，与其他金融分布式账本节点进行数据同步；b)通讯模块接收的外部数据经密码学模块解密，对外发送的数据经密码学模块加密、签名；c)通讯模块接收到的共识数据由共识模块进行处理；d)通讯模块接收到的交

42、易信息由存储模块持久性存储；e)共识模块共识完成后得到的区块信息由存储模块持久性存储；f)智能合约模块执行交易信息对应的智能合约；g)智能合约模块在执行合约的过程中读写存储模块的业务数据。通讯模块密码学模块智能合约存储模块共识模块用户、其他系统金融分布式账本节点 图2 金融分布式账本平台层参考架构 8.2.2 通讯模块 金融分布式账本节点应通过可靠的传输协议、数据传输加密算法，确保数据在传输过程中不丢失、不被篡改，应确保与其他对等节点保持连通。8.2.3 共识模块 金融分布式账本应根据业务特点选用适宜的共识协议，包括但不限于权益证明、授权股权证明、实用拜占庭容错等，应满足各种共识协议平稳运行的

43、必要条件，并结合激励机制、准入机制保证共识协议自身安全。8.2.4 智能合约 金融分布式账本节点应支持智能合约，智能合约应稳定可靠，具备高安全性和抗攻击能力，支持非图灵完备智能合约或图灵完备智能合约。T/NIFA 252023 14 8.2.5 存储模块 在系统投入使用后，金融分布式账本节点应如实永久存储发生在金融分布式账本上的任何操作记录和业务数据。具体要求包括但不限于：a)宜支持历史数据归档功能，实现在线数据高效操作；b)宜支持数据备份功能，应对存储设施故障；c)应支持数据的实时同步或定时同步，避免不同节点出现数据不一致的情况；d)应支持高效的数据比较机制，降低节点内容比较开销和数据同步开

44、销；e)应支持数据恢复功能，当节点出现故障时可手动将数据恢复到正常状态。8.2.6 密码学模块 金融分布式账本节点密码学模块应符合GB/T 370922018、GM/T 00542018的要求，具体要求包括但不限于：a)对称加密算法提供机密性保护，不低于 128 比特安全强度，符合 GB/T 329072016 的要求或者参考 ISO/IEC 18033-3:2010/Amd 1:2021；b)非对称加密算法提供机密性保护，不低于 128 比特安全强度，符合 GB/T 32918.42016 的要求或者参考 ISO/IEC 18033-2:2006/Amd 1:2017；c)哈希算法提供完整性

45、保护，摘要长度不小于 256 比特，不低于 128 比特安全强度，符合 GB/T 329052016 要求或者参考 ISO/IEC 18033-2:2006/Amd 1:2017；d)数字签名算法提供可认证性和不可否认性保护，不低于 128 比特安全强度，符合 GB/T 32918.22016 要求或者参考 ISO/IEC 14888-2:2008、ISO/IEC 14888-3:2018/Amd 1；e)应支持密码算法的可配置性，提供配置参数供分布式账本应用选择具体的密码算法，应提供至少两种可选算法；f)宜支持通过硬件方式实现密码算法。8.3 功能要求 8.3.1 网络查询 金融分布式账本节

46、点应支持查询整个金融分布式账本网络的节点数量、状态，应提供用户界面和编程接口调用网络查询，具体信息包括但不限于：a)在线总节点数量与节点信息，如果节点数量变化，应发出提醒；b)在线共识节点数量与共识节点信息，如果共识节点掉线，应发出报警。8.3.2 数据查询 金融分布式账本节点应支持查询金融分布式账本的账本信息和智能合约信息，应提供用户界面和编程接口调用数据查询。a)账本信息可查询的内容如下：1)账本的区块高度，如果节点的账本区块高度与其他节点不一致且维持一段时间，可显示相关提示信息；2)账本的区块高度在一段时间内的增长量（如最近 1 小时、最近 24 小时等）；3)账本的区块哈希值，如果节点

47、的账本区块哈希值与其他节点不一致且维持一段时间，可显示相关提示信息；4)账本存储空间大小；5)账本存储空间在一段时间内的增长量（如最近 1 小时、最近 24 小时等）。T/NIFA 252023 15 b)智能合约信息可查询的内容如下：1)智能合约状态，如正常、冻结等；2)智能合约使用情况，如调用总量、查询总量；3)一段时间内智能合约使用量变化（如最近 1 小时、最近 24 小时等）。8.3.3 合约调用 金融分布式账本节点应支持智能合约的调用，应提供用户界面和编程接口调用合约。a)应支持智能合约一键式部署，在任意节点发起部署指令应将智能合约部署到所有共识节点，具体要求如下：1)在一个节点（共

48、识与非共识节点均可）发起部署指令，该节点应自动将智能合约文本发布到所有共识节点；2)共识节点达成共识后，各节点应将合约文本存储于账本上，并自动编译合约文本，将编译后的可执行文件安装到节点的合约执行环境如容器、虚拟机；3)节点宜在执行环境中运行智能合约的可执行文件。b)合约部署时间应小于 15 分钟；c)应支持合约仓库，提供合约的发布和复用；d)应支持至少两种编程语言实现智能合约；e)智能合约应支持版本控制，要求如下：1)应支持合约升级；2)应支持合约不同版本；3)应确保新版本的合约不覆盖旧版本合约；4)调用合约应提供合约版本号。f)智能合约支持访问控制，要求如下：1)应在隔离的可信执行环境执行

49、智能合约，如容器、合约虚拟机等；2)应确保合约的执行不影响节点运行；3)应确保一个合约的执行不影响其他合约的执行；4)宜支持不同的用户设置，对不同的合约、合约的不同函数拥有不同的权限。g)智能合约应对复杂度加以限制。1)应设置合约的执行超时时间，若合约执行时间过长，应终止合约执行并回滚；2)应设置合约的源码字节数上限，若合约字节数过大，应拒绝合约部署。h)智能合约应提供生命周期管理。1)应支持合约的冻结、解冻、作废；2)作废的合约源码应继续保留在账本上，但不准许调用，其业务数据也应保留在账本上，但不准许访问；3)应将合约冻结、解冻、作废的操作记录在账本上。i)智能合约应满足原子性和一致性。1)

50、合约执行出错退出时，应回滚合约出错前对账本的业务数据所做的一切操作；2)合约在达成共识的节点上执行结果应完全一致；3)合约执行结果应为确定性的，合约运行不应依赖于随机变量或环境变量；4)合约执行过程中不应访问账本业务数据以外的其他变量，包括但不限于系统时间、硬件参数、网络参数等；5)合约交易应只存在成功和失败两种状态，不存在中间状态。j)智能合约部署、访问、执行符合安全需求的要求如下：T/NIFA 252023 16 1)合约部署前，应提交源码，通过管理方审核；2)宜以提交源码形式部署合约，源码可写入账本；3)应支持设置合约执行超时阈值，合约执行时间过长应终止执行，避免长时间占用系统资源；4)