DB33_T 2382-2021 财政电子票据区块链技术应用规范.pdf

ICS 01.140.30 CCS A 02 33 浙江省地方标准 DB33/T 23822021 财政电子票据区块链技术应用规范 Technical specification for financial e-invoice blockchain system 2021 - 09 - 30 发布 2021 - 10 - 30 实施 浙江省市场监督管理局 发 布 学兔兔 w w w .b z f x w .c o m 标准下载DB33/T 23822021 I 目 次 前言 . III 1 范围 . 1 2 规范性引用文件 . 1 3 术语和定义 . 1 4 系统架构 . 1 4.1 架构图 . 1 4.2 服务使用方 . 2 5 总体要求 . 3 5.1 业务应用 . 3 5.2 高可用性 . 3 5.3 可信性 . 3 6 业务通用要求 . 3 6.1 实名归集 . 3 6.2 票据业务不可篡改性 . 4 7 技术要求 . 4 7.1 节点管理 . 4 7.2 一致性 . 4 7.3 共识机制 . 4 8 业务流程要求 . 5 8.1 基本要求 . 5 8.2 链上开票 . 5 8.3 票据冲红 . 5 8.4 票据上链 . 6 8.5 票据查询 . 6 8.6 票据应用 . 6 8.7 票据入账 . 6 8.8 票据归档 . 6 9 数据要求 . 7 9.1 数据格式 . 7 9.2 数据加解密 . 7 附录 A （资料性） 区块链财政电子票据系统部署方式 . 9 附录 B （资料性） 区块链财政电子票据开票及应用案例 . 10 参 考 文 献 . 11 学兔兔 w w w .b z f x w .c o m 标准下载DB33/T 23822021 II 前 言 本标准按照 GB/T 1.12020标准化工作导则 第1部分：标准化文件的结构和起草规则的规定起草。 请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别专利的责任。 本标准由浙江省财政厅提出并归口。 本标准起草单位：浙江省财政票据管理中心、浙江省数字财政管理中心、蚂蚁科技集团股份有限公司、浙江省方大标准信息有限公司。 本标准主要起草人：蓝一鸣、叶时宝、聂勇、文昕、黄健民、金永勤、彭晋、王昕、昌文婷、钮清锋、张晓蒙、朱敏、王春聪。学兔兔 w w w .b z f x w .c o m 标准下载DB33/T 23822021 1 财政电子票据区块链技术应用规范 1 范围 本标准规定了基于区块链技术的财政电子票据的系统架构、总体要求、业务通用要求、技术要求、业务流程要求和数据要求。 本标准适用于基于区块链技术的财政电子票据系统的设计、开发、部署和应用，以及财政电子票据全生命周期管理。 2 规范性引用文件 本文件没有规范性引用文件。 3 术语和定义 下列术语和定义适用于本文件。 3.1 财政票据 finance invoice 由财政部门监（印）制、发放、管理，国家机关、事业单位、具有公共管理或者公共服务职能的社会团体及其他组织依法收取政府非税收入或者从事非营利性活动收取财物时， 向公民、 法人和其他组织开具的凭证。 注：财政票据包括非税收入类票据、结算类票据、其他财政票据。其中，其他财政票据包括公益事业捐赠票据、医疗收费票据、社会团体会费票据、其他应当由财政部门管理的票据。 3.2 财政电子票据 finance e-invoice 以数字信息代替纸质文件、以电子签名代替手工签章，依托计算机和信息网络技术开具、存储、传输和接收财政电子票据， 实现电子开票、 自动核销、 全程跟踪、 源头控制的电子形式票据， 以下简称 “电子票据”。 3.3 区块链 blockchain 使用密码技术链接将共识确认过的区块按顺序追加形成的分布式账本。 注：区块链旨在防止篡改并创建最终的、确定的和不变的账本记录 3.4 智能合约 smart contract 存储在分布式账本中的计算机程序，其共识执行结果都记录在分布式账本中。 4 系统架构 4.1 架构图 学兔兔 w w w .b z f x w .c o m 标准下载DB33/T 23822021 2 4.1.1 区块链财政电子票据系统应由支撑系统、服务系统和业务系统构成，其框架如图 1 所示。区块链财政电子票据系统部署方式的相关示例见附录 A。 图1 区块链财政电子票据系统架构图 4.1.2 支撑系统主要通过区块链的共识机制、块链存储、隐私保护和合约引擎提供存证服务和智能合约服务。 4.1.3 服务系统包含密钥子系统和业务处理子系统，其中密钥子系统负责密钥管理和密钥生成，业务处理子系统实现票据上链、查询、理赔、报销等业务的处理。 4.1.4 业务系统提供接入系统，用于服务使用方发起业务。 4.2 服务使用方 4.2.1 财政部门 财政部门监制财政电子票据，通过财政部门接入系统（通常为财政电子票据管理系统），实现电子票据的上链。 财政电子票据管理系统应进行升级改造以接入区块链财政电子票据服务系统的业务处理子系统。 接入方式包括但不限于客户端、用户图形接口、命令行、脚本、API等。 4.2.2 开票单位 开票单位宜支持通过区块链财政电子票据系统实现链上开票，并对链上开具的票据进行签名。 开票单位在开具、冲红后，应及时将相关信息反馈至区块链财政电子票据系统。 4.2.3 收票方 学兔兔 w w w .b z f x w .c o m 标准下载DB33/T 23822021 3 收票方分为个人和单位。 收票方通过服务应用，实现电子票据的查询。 注：典型的服务应用，如支付宝、浙里办等。 4.2.4 用票方 用票方实现电子票据的应用、报销入账，并在入账、归档后将相关信息反馈至区块链财政电子票据系统，更新电子票据的状态。用票方接入系统应对收票方进行实名认证。 注：典型的用票方如医疗保障部门、保险机构等。 4.2.5 监管部门 监管部门可接收区块链财政电子票据系统推送与监管职能相关的信息。 5 总体要求 5.1 业务应用 区块链财政电子票据系统应符合如下要求： a) 支持的电子票据容量应不小于 20 亿张； b) 并发性能支撑同时并行处理不小于 3 000 笔业务； c) 票据上链服务响应时间应不大于 3 s。 5.2 高可用性 区块链财政电子票据系统应符合如下要求： a) 区块链财政电子票据系统可用率应不低于 99.999 %； b) 对区块链财政电子票据系统及应用监控覆盖率应达到 100 %； c) 宜支持异地多活技术，不同城市建立独立的数据中心，接入高可用架构； d) 宜实现相距大于 150 km 的异地多数据中心架构； e) 任何单机、单机房或单个城市故障，均不宜停止服务，即系统恢复时间为 0； f) 数据恢复时间不宜高于 60 s； g) 业务功能恢复时间不宜高于 30 min。 5.3 可信性 区块链财政电子票据系统应符合如下要求： a) 由财政部门监制并上链，确保票据源的可信性； b) 基于区块链不可篡改、不可抵赖的特点，确保传输、存储、应用全链路的可信性； c) 基于实名认证、用票授权等确保用票的可信性； d) 支持票据在链上可信状态的维护。 6 业务通用要求 6.1 实名归集 区块链财政电子票据系统应支持实名归集功能： a) 基于收票方代码建立账户，并将对应收票方的票据归集到对应账户； 学兔兔 w w w .b z f x w .c o m 标准下载DB33/T 23822021 4 b) 基于开票单位代码建立账户，并将对应开票单位的票据归集到对应账户； c) 归集到账户名下的票据信息，应包含票据代码、票据号码、票据检验码、票据总金额。 6.2 票据业务不可篡改性 区块链财政电子票据系统应具备不可篡改特性： a) 通过时间戳证明、首尾相连记账规则、哈希算法、数字签名、共识机制等技术应用和机制设计,保证电子票据链账本不可篡改； b) 通过智能合约技术，实现电子票据数据库链上链下的实时映射与比对，保证链下电子票据数据库不可篡改。 7 技术要求 7.1 节点管理 7.1.1 区块链组网中节点可分为共识节点和非共识节点。共识节点参与共识保证区块链分布式系统数据的一致性，非共识节点（如监管节点和业务节点等）可以提供链上数据的查询服务，分散区块链系统数据查询压力。 注1：典型的共识节点如财政管理部门部署的区块链节点。 注2：典型的非共识节点如卫生保健部门、医疗保障部门、档案管理部门等监管部门部署的节点，业务节点如医院或学校等用票房部署的节点。 7.1.2 应支持区块链两种节点的动态增加和删除，实现根据具体业务对资源的动态扩容或降配，相关要求包括： a) 应在等待新节点同步数据后完成节点增加； b) 应在释放节点资源后完成节点删除； c) 链上共识节点数量应保证系统的整体健壮性； d) 动态增加或删除节点不影响现有业务的运行。 7.2 一致性 区块链财政电子票据系统应符合一致性要求，主要包括： a) 在数据存储方面，通过链式架构、区块存储、时间戳等关键技术以及检验机制，实现电子票据数据存储的可靠性、不可篡改、不可伪造特性； b) 在网络通信方面，需要对不同节点的功能进行统一控制，对新生数据进行全网传播后共同认证，验证完成的新数据才能进行区块链存储； c) 在密码技术方面，应使用安全并符合国家密码管理规定的算法和协议进行摘要计算、认证签名、所有权确认与使用权保障，并通过加密技术确保信息安全防护等级，从而保障区块数据的一致性、可靠性。 7.3 共识机制 区块链财政电子票据系统应遵循共识机制，主要包括： a) 能够根据电子票据验证及背书策略确保区块中所有电子票据应用有效； b) 能够确保所有节点提交和应用电子票据顺序的一致性； c) 能够利用智能合约接口，验证电子票据的有效性和提交顺序。 学兔兔 w w w .b z f x w .c o m 标准下载DB33/T 23822021 5 8 业务流程要求 8.1 基本要求 区块链财政电子票据系统应当支持财政电子票据的链上开票、票据冲红、票据上链、票据查询、票据应用、票据入账和票据归档等功能，其业务流程见图2。区块链财政电子票据开票及应用案例的相关示例见附录B。 图2 区块链财政电子票据系统业务流程图 区块链财政电子票据系统应记录财政电子票据的状态变化，状态应包括已开具、已冲红、用票中、已用票、已入账和已归档。其中，已开具、用票中、已用票、已入账、已归档是电子票据的有效状态；已冲红是电子票据的失效状态；电子票据进入失效状态后不应再进行操作。 a) 链上开票或票据上链后，标记为“已开具”状态； b) 开票单位票据冲红后，标记为“已冲红”状态； c) 用票方进行票据应用时，标记为“用票中”状态； d) 用票方票据应用返回结果后，标记为“已用票”状态； e) 用票方提交票据入账反馈，标记为“已入账”状态； f) 用票方提交票据归档反馈，标记为“已归档”状态。 8.2 链上开票 区块链财政电子票据系统应支持电子票据链上开具，具体流程为： a) 开票单位向区块链财政电子票据系统发起开票请求； b) 生成财政赋码； c) 完成开票单位和财政的电子签名； d) 生成电子票据文件； e) 完成链上开票。 注：上述流程均在链上执行。 8.3 票据冲红 区块链财政电子票据系统应支持票据冲红， 以实现开票单位因原开具电子票据有误需更正、 调整时，而开具的红字票据，通常金额是负数。具体流程为： a) 开票单位向区块链财政电子票据系统发起冲红请求； b) 查询原始电子票据是否处于不可冲红状态，如用票中、已用票、已入账、已归档、已冲红等； 学兔兔 w w w .b z f x w .c o m 标准下载DB33/T 23822021 6 c) 若处于可冲红状态，则执行红票链上开具，或红票票据上链，完成冲红。 8.4 票据上链 票据上链业务，应由财政部门发起，经由财政部门接入系统，最终存入区块链财政电子票据系统。具体流程应如下： a) 交款人到开票单位办理业务，业务办理完毕开票单位收取款项； b) 开票单位