前  言
本标准按照GB/T 1.1—2020《标准化工作导则　第1部分：标准化文件的结构和起草规则》 的规则起草。
本标准由浙江省财政厅提出并归口。
本标准主要起草单位： 浙江省财政票据管理中心、浙江省数字财政管理中心、蚂蚁科技集团股份有限公司。
本标准主要起草人：

区块链财政电子票据规范
1　范围
本标准规定了基于区块链技术实现的财政电子票据的技术框架、业务流程、数据规范和技术要求等。
本标准适用于财政电子票据的开具、传输、存储归集、查询、报销入账和归档，适用于基于区块链的财政电子票据系统的设计、建设、开发、部署和应用。
2　规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。
ISO/AWI 22739 区块链和分布式记账技术—术语和概念
ISO/AWI 23257 区块链和分布式记账技术—参考架构
ISO/AWI TS 23259 区块链和分布式记账技术—合规性智能合约
GB/T 36609-2018 电子发票基础信息规范
3　术语、定义和缩略语
3.1　术语和定义
3.1.1　
财政票据 finance invoice
由财政部门监（印）制、发放、管理，国家机关、事业单位、具有公共管理或者公共服务职能的社会团体及其他组织依法收取政府非税收入或者从事非营利性活动收取财物时，向公民、法人和其他组织开具的凭证。
财政票据包括非税收类票据、结算类票据、其他财政票据。其中，其他财政票据包括公益事业捐赠票据、医疗收费票据、社会团体会费票据、其他应当由财政部门管理的票据。
3.1.2　
财政电子票据 finance e-invoice
以数字信息代替纸质文件、以电子签名代替手工签章，依托计算机和信息网络技术开具、存储、传输和接收财政电子票据，实现电子开票、自动核销、全程跟踪、源头控制的电子形式票据。
注：财政电子票据基本特征是以数字信息代替纸质文件、以电子签名代替手工签章，通过网络手段进行传输流转，通过计算机等电子载体进行存储保管。
3.1.3　
区块链 blockchain
一种在对等网络环境下，通过透明和可信规则，构建不可伪造、不可篡改和可追溯的块链式数据结构，实现和管理事务处理的模式。
3.1.4　
区块链电子票据系统 blockchain-based e-invoice system
基于区块链技术实现的财政电子票据系统，借助于区块链技术在财政票据应用中以电子数据形式实现财政票据的开具、传输、存储、归集、应用、入账和归档。
3.1.5　
智能合约 smart contract
存储在分布式账本中的计算机程序，其共识执行结果都记录在分布式账本中。
3.2　缩略语

4　概述
基于区块链的财政电子票据，简称为“区块链电子票据”，在财政电子票据无纸化基础上，基于区块链技术，打通电子票据的所有流程，支持快速可靠的票据应用。
区块链电子票据具有以下特点：
a) 票据源可信：由财政部门监制并上链，确保票据源的可信性；
b) 全链路可信：基于区块链不可篡改、不可抵赖的特点，确保传输、存储、应用全链路的可信性；
c) 用票可信：基于实名认证、用票授权等确保用票的可信性；票据通过状态机维护可信状态。
5　参考模型
5.1　技术框架
区块链电子票据系统的技术框架如图1所示。

图1　区块链电子票据系统架构图
区块链电子票据系统由支撑系统、服务系统和业务系统构成。
支撑系统实现电子票据的存储、归集、状态机维护等；服务系统分为密钥子系统、业务受理子系统和业务处理子系统，其中密钥子系统负责密钥管理和密钥生成，业务受理子系统实现票据上链（简称为“上票”）、换开等，业务处理子系统实现电子票据的查询、理赔、报销等应用；业务系统由各票据业务使用方搭建，其中服务接入系统面向C端用户提供票据的验证和查询，应用单位接入系统负责用户的实名认证，并发起业务。
5.2　系统角色
5.2.1　概述
区块链电子票据涉及的角色分为服务提供方和服务使用方，相关部署方式参见附录A。服务提供方包括共识节点、监管节点、业务节点；服务使用方包括财政部门、开票单位、收票方、用票方和监管部门。
5.2.2　服务提供方
5.2.2.1　共识节点
共识节点参与共识过程，维护全量数据。
注：典型的共识节点如财政管理部门部署的区块链节点。
5.2.2.2　监管节点
监管节点不参与共识过程，不维护全量数据，维护与监管职能相关的所有数据。
注：典型的监管节点如卫生保健部门部署的区块链节点、医疗保障部门部署的区块链节点、档案管理部门部署的区块链节点。
5.2.2.3　业务节点
业务节点不参与共识过程，不维护全量数据，维护与业务主体相关的所有数据。
注：典型的业务节点如医院或学校部署的区块链节点。
5.2.3　服务使用方
5.2.3.1　财政部门
财政部门监制财政电子票据，通过财政部门接入系统（通常为财政电子票据管理系统），实现财政电子票据的上链。
财政电子票据管理系统应进行升级改造以接入区块链电子票据服务系统的受理子系统。接入方式包括但不限于：客户端、用户图形接口、命令行、脚本、API等。
5.2.3.2　开票单位
开票单位宜支持通过区块链电子票据系统实现链上开票，并对链上开具的票据进行签名。
开票单位在入账、归档后，应及时将相关信息反馈至区块链电子票据系统。
5.2.3.3　收票方
收票方分为个人和单位。
收票方通过服务应用，实现财政电子票据的查询。典型的服务应用，如支付宝、浙里办等。
5.2.3.4　用票方
用票方实现电子票据的应用、报销入账，并在入账、归档后将相关信息反馈至区块链电子票据系统，更新电子票据的状态。用票方接入系统应对收票方进行实名认证。
注：典型的用票方如医疗保障部门、保险机构等。
5.2.3.5　监管部门
监管部门可接收区块链电子票据系统推送的与监管职能相关的信息。
注：典型的监管部门包括财政管理部门、税务管理部门等。
5.3　区块链节点
5.3.1　概述
按照节点的主要功能，区块链组网中节点可分为共识节点和非共识节点。共识节点保证区块链分布式系统数据的一致性；非共识节点（如监管节点和业务节点等）可以提供链上数据的查询服务，分散区块链系统数据查询压力。
5.3.2　节点变更
应支持区块链两种节点的动态增加和删除，实现根据具体业务对资源的动态扩容或降配，相关要求包括：
a) 区块链平台运营方调用区块链系统合约，在节点增加应等待新节点完成数据同步；
b) 区块链平台运营方调用区块链系统合约，应在释放节点资源后完成节点删除；
c) 为增强区块链电子票据系统的整体健壮性，链上共识节点数量宜为3f+1。
注：f为系统能够容错的节点个数。
5.3.3　节点管理
应根据实际业务需求，在不影响现有节点运行的情况下，由区块链平台运营方管理员动态增加或删除节点，且增加或删除节点不影响现有业务的运行。
6　业务流程
6.1　概述
区块链电子票据系统支持的业务包括：链上开票、票据上链（简称为“上票”）、票据查询、票据应用（简称为“用票”）、票据入账、票据冲红和票据换开。
6.2　链上开票
链上开票基于区块链系统实现电子票据的链上开具。利用区块链的可信身份认证、可信计算特性，真正实现区块链电子票据开票业务，保证电子票据真实有效，同时可节省人力资源成本。
链上开票由执收机构发起开票请求，经由区块链开票业务系统接入链上开票系统，生成票据xml数据文件，再经由制票服务完成开票单位和财政的电子签名，生成电子票据xml文件、pdf或png板式文件。
6.3　票据上链
票据上链业务，由财政部门发起，经由财政部门接入系统，最终存入电子票据区块链平台。业务流程如图2所示。

图2　票据上链业务流程示意图
票据上链业务涉及的角色包括财政部门、收票方；涉及的系统包括受理子系统、密钥系统、服务应用、电子票据区块链。时序图如图3所示。

图3　票据上链业务时序图
票据上链业务流程为：
1.财政部门对票据进行验签；
2.财政部门向受理子系统发起票据上链请求，生成业务流水号，并上传电子票据的原始文件。原始文件包括描述票据信息的XML文件，以及票据版式文件URL地址；
3.受理子系统从XML文件中抽取字段，并验证数据的合法性；
4.受理子系统将需要加密的数据进行加密，将需要哈希的数据进行哈希运算；
5.受理子系统根据数据规范（见7.2）构造上链数据；
6.受理子系统将上链数据传送给电子票据区块链平台；
7.电子票据区块链平台建立收票方账户，并将票据归集到该收票方账户下；
8.归集成功后，电子票据区块链平台向财政部门返回交易哈希，并向收票方推送票据消息。
6.4　票据查询
6.4.1　用户票据查询
用户查询名下的票据信息，由收票方发起，经由服务应用系统，查询票据信息列表并对用户选取的票据进行展示。用户票据查询业务涉及的角色为收票方、业务处理子系统、服务应用、电子票据区块链。交互时序图如图4所示。

图4　用户票据查询业务时序图
6.4.2　票据查验
票据查验服务，由收票方发起，经由服务应用系统，查验票据真伪信息。交互时序图如图5所示。

图5　票据查验业务时序图
6.5　票据应用
票据应用业务，由收票方发起，由用票方受理，进行报销、理赔等应用。业务流程如图6所示。

图6　票据应用业务流程示意图
票据应用业务涉及的角色为收票方、用票方；涉及的系统包括业务处理子系统、服务应用、电子票据区块链。时序图如图7所示。

图7　票据应用业务时序图
6.6　票据入账
票据入账指的是企业单位收入或支出票据, 计入账簿里进行会计账务处理。
区块链电子票据系统提供按交款方、收款方归集服务，企事业单位可以在自己的账户下，查询归集到的票据，并计入账簿里进行会计账务处理。
6.7　票据冲红
冲红是执收单位原先开具的票据有误或需更正、调整账目，而重新开具的红字票据，通常金额是负数。执收机构可以经由区块链业务中台，调用链上冲红接口，开票红票，或将已有红票上链。
6.8　票据换开
票据换开业务，由财政部门发起，经由财政部门接入系统，由区块链电子票据平台进行处理。业务流程如图8所示。

图8　票据换开业务流程示意图
票据换开业务涉及的角色为财政部门；涉及的系统包括受理子系统、电子票据区块链。时序图如图9所示。

图9　票据换开业务时序图
6.9　电子票据状态
电子票据状态应包括初始状态、状态查询、用票中、已用票、已开红票、已换开和已入账，相关状态及转换关系如图10所示。
电子票据的状态机由开票单位和用票方共同维护，通过财政部门统一管理，保持唯一性。通过可信的电子票据状态机，防止财政电子票据重复报销套取资金等。

图10　电子票据状态机
其中，初始状态、用票中、已用票、已入账是电子票据的有效状态。已换开和已开红票是电子票据的失效状态。电子票据进入失效状态后不应再进行操作。状态机流转规则为：
——票据上链后，进入“初始状态”；
——收票方提出换开纸质票据后，相应票据进入“已换开”状态；
——开票单位退款或冲红后，相应票据进入“已冲红”状态；
——用票方从业务子系统获取票据文件后，相应票据进入“用票中”；
——用票方返回用票结果，相应票据进入“已用票”；
——用票方提交入账反馈，相应票据进入“已入账”；
——用票方提交开具红票请求并完成处理后，相应票据进入“已开红票”。
7　数据规范
7.1　数据格式
电子票据区块链存储的上链票据信息应包括三部分：描述票据信息的XML文件，票据版式文件URL地址，票据关键信息，具体信息格式应符合GB/T 36609—2018要求。
其中票据关键信息由受理子系统从XML文件中抽取，应包括以下字段信息：
——票据代码；
——票据号码；
——票据校验码；
——票据总金额；
——开票时间；
——开票单位代码；
——开票单位名称；
——收票方代码；
——收票方名称。
当票据冲红时，还应包括以下字段信息：
——相关票据代码；
——相关票据号码。
7.2　数据存储
上链票据信息中加密存储的信息包括：
——XML文件；
——版式文件URL地址；
——收票方名称。
上链票据信息中哈希存储的信息包括：
——票据校验码；
——开票单位代码；
——收票方代码。
上链票据信息中明文存储的信息包括：
——票据代码；
——票据号码；
——票据总金额；
——开票时间；
——开票单位名称。
具体数据存储如表1所示
表1　数据存储方式
序号 数据项 存储方式
1 电子票据代码 明文存储
2 电子票据号码 明文存储
3 校验码 哈希存储
4 总金额 加密存储
5 开票时间 加密存储
6 开票单位代码 哈希存储
7 开票单位名称 加密存储
8 收票方代码 哈希存储
9 收票方名称 加密存储
10 电子票据 加密存储
11 存储地址 加密存储
7.3　数据加解密
7.3.1　密钥生成
密钥的生成应满足以下要求：
——一票一密。基于票据的代码、号码、校验码，生成该票据的唯一加密密钥，从而确保一张票据的密钥泄露不会影响其他票据的安全。
——密钥不落盘。密钥应通过计算的方式得到，禁止在硬盘存储密钥，从而避免拷贝等问题带来的密钥泄露风险。
——加密的根密钥应由财政部门或财政部门授权的相关部门进行管理。
密钥生成方法如图11所示。

图11　密钥生成方法示意图
7.3.2　加密与解密流程
票据上链时，应在受理子系统完成加密。票据应用时，应在业务处理子系统完成解密。加解密流程如图12所示。

图12　加解密流程图
8　基本要求
8.1　实名归集
电子票据区块链平台应支持实名归集功能，通过区块链归集业务模块（包含业务中台、数据库和链上智能合约）实现。实名归集功能包括：
——基于收票方代码建立账户；
——将对应收票方的票据归集到对应账户；
——基于开票单位代码建立账户；
——将对应开票单位的票据归集到对应账户；
——归集到账户名下的票据信息，应包含票据代码、票据号码、票据检验码、票据总金额。
8.2　一致性
一致性相关要求包括：
a) 在存储层级，通过链式架构、区块存储、时间戳等关键技术以及检验机制，实现票据数据存储的可靠性、不可篡改、不可伪造特性；
b) 网络层需要对不同节点的功能进行统一控制，对新生数据进行全网传播后共同认证，验证完成的新数据才能进行区块链存储；
c) 在共识层级，应采用共识算法保障交易数据的同步性；
在密码技术层面，要求采用国产密码 SM2/SM9、SM3、SM4 密码算法，进行摘要计算、认证签名、所有权确认与使用权保障，并通过加密技术确保信息安全防护等级，从而保障区块数据的一致性、可靠性。
8.3　共识机制
共识机制相关要求包括：
a) 交易有效：能够根据票据验证及背书策略确保区块中所有票据应用有效；
b) 交易有序：能够确保所有节点提交和应用票据顺序的一致性；
交易验证：能够利用智能合约的接口，验证票据的有效性和提交顺序。
8.4　不可篡改
不可篡改相关要求包括：
a) 票据链账本不可篡改，即通过时间戳证明、首尾相连记账规则、哈希算法、数字签名、共识机制等技术应用和机制设计，保证票据应用记录的不可篡改；
b) 链下票据数据库不可篡改，即通过智能合约技术，实现票据数据库链上链下的实时映射与比对，保证链下数据库的票据记录的正确性与完整性。
9　性能要求
9.1　业务应用
应符合如下要求：
a) 支持的电子票据容量应不小于20亿；
b) 并发性能不小于3000吞吐量；
c) 票据上链服务响应时间不大于3秒；
9.2　业务连续性
应符合如下要求：
a) 应确保区块链财政电子票据系统可用率不低于99.999%；
b) 应实现对区块链财政电子票据系统及应用的全面监控，即监控覆盖率达到100%。
9.3　平台高可用
平台高可用相关要求如下：
a) 宜支持异地多活技术，不同城市建立独立的数据中心，接入高可用架构;
b) 宜实现相距大于150公里的异地多数据中心架构；
c) 宜确保任何单机、单机房或单个城市故障，都不会停止服务，即系统恢复时间（RTO）为0；
d) 宜确保数据恢复时间（RPO）不高于60秒；
e) 宜确保业务功能恢复时间不高于30分钟。

附　录　A
（资料性附录）
区块链电子票据系统部署方式
区块链电子票据系统部署可分为三种模式：
A.1 专网部署方式
区块链电子票据核心系统部署在财政专网内，通过白名单、数字证书、签名密钥的方式向外部需求方提供服务。
A.2 互联网部署方式
区块链电子票据核心系统部署在互联网并提供RESTful服务，外部机构单位可以访问区块链电子票据系统，提交开票、换开、冲红、用票流转等业务。
A.3 专网-互联网互通方式
区块链电子票据系统通常包括前端执收机构管理、RESTful服务、业务中台、区块链组网节点、业务数据库等部分组成。前端执收机构管理、RESTful服务、业务中台 实现了互联网、财政专网的互通。

参 考 文 献
[1] 财综[2017]32号 财政部关于印发《关于稳步推进财政电子票据管理改革的试点方案》的通知
[2] 中华人民共和国财政部令第104号--财政部关于修改《财政票据管理办法》的决定
[3] 网信办[2019]3号 《区块链信息服务管理规定》