DB36/T 1712-2022 政务区块链基础平台技术规范.pdf

DB36/T 1712-2022 政务区块链基础平台技术规范.pdf
仅供个人学习
反馈
标准编号:
文件类型:.pdf
资源大小:0.9 M
标准类别:建筑标准
资源ID:136963
免费资源

标准规范下载简介

DB36/T 1712-2022 政务区块链基础平台技术规范.pdf简介:

DB36/T 1712-2022 是中国地方标准,全称是《政务区块链基础平台技术规范》。这个标准是为了规范和指导政务区块链技术在公共服务领域的应用和实施,提供了一个技术框架和操作指南。政务区块链是指将区块链技术应用于政府服务,旨在提高政府服务的透明度、效率和可信度。

该规范可能涵盖了政务区块链平台的架构设计、数据安全、共识机制、智能合约、身份认证、数据共享、隐私保护等方面的要求。它可能强调了平台的可扩展性、稳定性、兼容性和安全性,以确保政务数据在区块链上的安全存储和流转。

通过遵循这个技术规范,政府机构能够确保政务区块链平台的实施符合行业标准,提升公共服务的数字化水平,同时保障公民和企业的合法权益。

DB36/T 1712-2022 政务区块链基础平台技术规范.pdf部分内容预览:

DB36/T 202

按网络安全等级保护三级(或以上)要求建设。

DB36/T 1712 2022

应由省、市政务区块链管理部门统筹规划基础设施和平台建设,避免各级政务部门分散重复建 市间跨链应用建设应充分利用省、市区块链基础平台,各县(市、区)原则上不单独建设区块链 台。

应基于当前主流的区块链技术体系,实现区块链平台兼容性升级,支持区块链平台与业务场景 相对独立GB 55029-2022安全防范工程通用规范.pdf,彼此升级互不影响。

DB36/T1712

政务区块链基础平台整体架构采用分层、解耦、复用的设计思想,平台逻辑架构分为基础资源层、 区块链平台层、应用服务层,其逻辑架构如图1所示。 a)基础资源层为区块链平台层和应用服务层提供计算、存储、网络等基础资源支撑。 b)区块链平台层提供基础技术服务和核心能力输出。基础技术服务包括智能合约、共识协议、集 成开发环境、隐私保护、密钥管理、虚拟机插件、存储设计、跨链技术等。核心能力输出主要 为政务部门提供区块链平台运维管理等服务能力,包括运维管控、应用开发、数据服务、跨链 服务、隐私计算等。 c)应用服务层是为有业务上链需求的政务部门提供应用上链环境及接口,包括需新上链的政务区 块链应用和需链改的传统政务应用。

图1政务区块链基础平台逻辑架构图

政务区块链基础平台是应用上多方参与、分布式部署、灵活接入的公共性基础平台,包含省级基础 平台、市级基础平台及区块链管理系统,其部署架构如图2所示。 a)省级平台,包括省级基础链与省级业务链,主要用于满足省级政务部门业务上链需求。省级平 台的部署与运维由省级政务区块链管理部门统一规划和管理。 b) 1 市级平台,包括市级基础链与市级业务链,主要用于满足市级政务部门业务上链需求。市级平 台的部署与运维由市级政务区块链管理部门统一规划和管理。 C) 1 区块链管理系统。主要用于区块链管理平台的运维管理和能力开放,为各级政务部门提供区块 链领域的服务能力,包括运维管控、应用开发、数据服务、跨链服务、隐私计算等。

DB36/T1712 2022

区块链基础平台部署架

不少于当前构建区块链平台技术发展所需的最小化节点数服务要求。其中区块链节点中应包含至少 个监控管理节点,用于管理监控区块链的运行,同时能够获取链运行中权限变更的记录、能够获取需 要审计的相关数据

保证节点之间能直接进行网络通信或能间接进行消息传递,基础平台的节点通信应具备以下功能: a) 2 可动态配置节点通信的组网方式,单一节点故障应不影响节点的全网通信; b0 2 节点通信应实现心跳等相关的技术机制,保证节点的在线状态,防止因节点网络离线造成的账 本不一致; C) 1. 单个节点初始化完毕后,应具备完整的通信能力; d) 13 新节点的加入对于全网中所有已加入的节点都等效可知,新的共识或者记账节点应在网络共识 认可后才能加入; e)应支持节点动态退出,不同节点退出对于通讯层应是无感知的,且不影响系统通信能力; f) 1 应保证下线节点重新加入网络后,账本数据同步和消息通讯能够正常进行,且下线节点重新加 入共识后,应保证节点功能正常运行; g) 应对节点在网络中的消息设置唯一的标识符; h) 节点通信应与上层业务解耦。

基础平台的计算引擎应具备以下能力: a) 1 提供基础平台运行过程中的计算能力; b) 在基础平台的网络中,应能够被每个节点采用; C) 1 应支持图灵完备的虚拟机技术、容器技术等; d) 2 应支持多种类型的计算引擎,包括但不限于EVM/WSAM虚拟机在内计算引擎。

基础平台的共识机制应具备以下能力: a) 1 共识算法应支持节点独立进行算法运算,不依赖任何其他节点数据和状态; b) 共识算法应保证各节点对上链数据打包区块的计算能收敛并达到最终一致性; C) 共识算法应声明在一定规模的节点环境下达成共识所需的理论时间,且该时间应能满足业务要 求; d) 应能在节点在线、节点离线、网络规模调整等情况下,不停止系统服务,替换原有共识算法并 达成新的全网共识; e) 1 应保证当任意不超过区块链平台声明数量的节点发生故障,整个平台运行正常; f) 应具备抗攻击的能力,提供防止消息纂改的验证机制。

DB36/T1712 2022

基础平台的智能合约应具备以下能力: a) 1 应提供编程语言支持,必要时可提供配套的集成开发环境: b) 1 应提供智能合约冻结、解冻等功能; C) 2 应提供智能合约运行的载体,如虚拟机等; d 1 在部署智能合约时应能指定版本号,部署成功的智能合约应具有唯一标识; e) 应具备代码安全审查能力,如静态扫描、动态扫描、形式化验证等,防止代码缺陷引发的安全 隐患; f) 1 交易信息中应明确调用的智能合约版本,不同节点之间的相同智能合约应保证版本一致性; g) . 合约在所有参与共识节点上的执行结果应具备一致性。合约重复执行时,在初始条件不变的前 提下,执行结果保持不变; n) 1 对于与基础平台外部数据进行交互的智能合约,外部数据源的影响范围应仅限于智能合约范围 内,不应影响基础平台的整体运行; i) 1 应支持对合约中交易进行监控,实时监测交易异常情况; i) )应具备容错和异常终止功能,同时具有运行时间及资源占用可控性,

提供跨链服务,实现一个链到另一个链的通信。基础平台的跨链技术应具备以下能力: a) 2 应支持多种跨链交互模式,支持同构和异构区块链跨链; bD) 1 应具备管理不同应用链之间跨链互通的能力,包括跨链互认证、跨链互操作等。 C) 应兼容多种异构区块链及跨链机制,保障良好的可扩展性,包括但不限于可信执行环境验证机 制、公证人机制、侧链机制、多链机制等; 1) 应构建全局信任域,信任域由认证根、安全协议、可信环境、基于密码学的验证等机制构建 根据业务跨链流通需求设置跨链数据管理权限,保障分布式账本跨链的安全可信。

开发组件支持上链业务开发方的活动,包括完成业务所需的开发环境管理、构建管理和测试管理等 a) 1 开发环境应提供用于上链业务的开发环境和服务组合的工具,支持模块的开发; b 1 开发环境应支持开发服务相关的配置元数据的生成; C) 开发环境应支持服务配置脚本和组件的编写或生成; d①) 构建管理组件应支持自动化构建软件包功能; e) 构建管理组件应提供自动化编译功能及出错信息提示; f) 构建管理组件应实现构建过程的审核流程; g) 构建管理组件应支持多语言及多平台模式; h) 1 测试管理组件应在测试环境与生产环境集成的情况下进行测试不应影响生产环境; i) 1 测试管理组件应支持自动生成测试报告

在保证基础平台稳定运行的前提下,快速响应业务的上链需求和用户的访问查询需求,包括完成业 务上链对智能合约的调用、链上数据查询、同步和确认等。 a) 在智能合约的调用上,交易上链成功率不低于95%,交易延迟时间不超过5秒;同时在异常场 景发生并恢复后仍能维持智能合约调用交易性能; b 在链上数据的查询时间效率上,不低于原有业务系统的查询时间效率,同时在异常场景发生并 恢复后能快速还原查询效率:

DB36/T1712

C) 在上链数据同步性能上,交易同步应在块的共识完成前完成;且交易同步时,节点收到的余 交易比例不高于申明的数值,节点同步并写入区块所耗费的时间应不高于出块时间; d 在交易确认时间上,单位时间内交易请求量不大于申明的TPS时,交易从发出到被确认处理完 成的时间应不超过出块时间的2倍。

管理基础平台的的用户或账号。用户管理应至少具备以下功能: a) 用户管理模块中支持用户注册、账号管理、权限配置等; b) 应支持账户的冻结和解冻,冻结状态用户不允许发起交易,

管理基础平台上的节点。节点管理应至少具备以下功能: a) 应具备增加区块链节点、删除区块链节点的功能; 应支持区块链节点管理账户权限体系; 6 C) 支持管理体系自定义,用户可根据不同应用场景设定节点权限等级和能力范围

联盟管理应至少具备以下功能: a) 1 应具备创建联盟链、删除联盟链、加入联盟链、退出联盟链等功能; b) 1 应支持联盟链的管理,根据业务要求或用户隔离要求,多个联盟链间数据和业务隔离,保证联 盟链间数据隐私和业务独立。 C) 2 应具备查看联盟链列表和属性信息,查看区块链节点和应用链列表信息等功能; d) 应具备查看区块列表、区块信息、交易列表、交易信息等功能; e) 应具备查看合约列表,查看合约信息等功能。

告警管理应至少具备以下功能: a 2 实时监控区块链上各节点的状态,并针对异常情况进行告警: b) 实时监控各联盟链的状态,并针对异常情况进行告警; C) 跨链状态下,实时监控连接状态,并针对异常情况进行告警,

应具备创建应用链、删除应用链、加入应用链、

DB36/T 1712 2022

基础平台应提供智能合约的全生命周期管理能力,包括合约编写、编译、部署、调用、升级、冻结、 解冻和终止合约等

建标 146-2010 国家法官学院分院建设标准(附条文说明)基础平台应具备访问控制、权限管理等功能。

数据接入应至少具备以下能力: a 应支持多种数据源对接的能力,数据源地址可配置; b) 支持自动获取待协作使用的数据详情; C) 在协作业务运行过程中支持自动读取相关的数据; ? 提供跨进程调用功能,为终端应用及用户层提供核心层接入服务,

基础平台中,不同的区块拥有不同的全局状态根哈希。平台应支持根据不同区块和不同的全局 哈希,构造出不同的全局状态历史树,进而查询到不同历史状态下的数据

对于链上关键节点,如审批节点、流转节点、协作应用参与节点,平台应提供统一的上链存证 查看服务,以便于对数据使用链路的行为进行审计。

数据审计应至少提供以下功能: a 系统具备记录用户访问日志,便于监管审计; b) 应确保无法单独中断审计进程,无法删除、修改或覆盖审计记录

DB36/T1712

省市之间、各设区市之间政务部门的跨链服务应支持同构链、异构链之间的相互通信DBJ50/T-245-2016 混凝土真空脱水技术规程.pdf,跨链示意 如图3所示。

跨链数据交互时,业务合约通过调用跨链协议合约的通讯接口,与其它区块链进行数据交互。应符 合如下要求: a) 业务合约上应具备跨链操作接口,支持主动查询跨链数据,主动发送跨链数据等能力: b) 1 业务合约应具备对接收的跨链数据进行存储的能力。

©版权声明
相关文章