一种定义区块链上链数据业务规约及应用业务规约的方法

技术领域

本发明涉及区块链、数据上链、政务领域区块链应用及业务数据模型领域，特别是一种定义区块链上链数据业务规约及应用业务规约的方法。

背景技术

区块链技术是利用块链式数据结构来验证与存储数据、利用分布式节点共识算法来生成和更新数据、利用密码学的方式保证数据传输和访问的安全、利用由自动化脚本代码组成的智能合约来编程和操作数据的一种全新的分布式基础架构与计算范式。

数据上链即把数据写到区块链中，目前市场上不同的区块链有不同的上链方式，对于非审核型的区块链，基本上不论谁，不论什么内容都可以上链。发生的任何一笔交易，都可以带上文本信息。文本内容不受限定，只是文本大小会影响所需费用。该方式的上链基本上不存在签名验证和加密解密，上链规约也不做任何限定，在一定范围内有安全性和存储不足的风险。

对于特定型区块链而言，只有特定类型的数据可上链，其余类型的数据则不能上链。比如区块链发票，交易即开票，开票即报销。整个过程全自动无需用户操心，整个环节都上链了，链上可查。该方式局限了区块链应用的拓展，对特定应用只有一种类型数据可上链，无法为同一个应用提供多种类型的上链数据。随之而来的是当业务发生变化时，更换上链的数据类型产生的成本过高，难以适应市场需求。

目前各行业的数据上链需求不同，会存在频繁的变更，而此类业务，通常都在智能合约层处理，智能合约又是核心的东西，频繁的变更会带来业务风险和漏洞，并且不同时期的上链需求，会变动，所以在业务上需要兼容历史数据。

由于区块链的行业应用非常多，在政务领域，区块链可以塑造很多行业应用，如审批链、监管链、证照链、共享链等。链应用实现过程中各流程阶段复杂，会出现业务上链数据频繁变更、审批流程长、业务数据多的情况，上链数据难以快速适应业务变化，伴随而来最直接的问题就是需要重新开发项目，导致业务流畅性受到影响，项目成本增加。故需要有一个灵活定义上链数据业务规约的方法来解决这个问题。

发明内容

有鉴于此，本发明的目的是提供一种定义区块链上链数据业务规约及应用业务规约的方法，能有效提升上链数据安全问题。

本发明采用以下方案实现：一种定义区块链上链数据业务规约及应用业务规约的方法，包括以下步骤：

步骤S1：创建行业模板，用于沉淀行业上链数据模型：在区块链平台创建行业模板，输入模板名称、模板描述；同时在mysql数据库中创建bc_biz_type表，用于存储创建的行业模板信息即完成沉淀行业上链数据模型；

步骤S2：创建该行业模板的业务类型；

步骤S3：创建该业务类型的业务规约即上链数据模型；

步骤S4：完成行业模板定义之后，区块链平台中的智能合约自动获取定义内容，同时区块链平台管理人员需将开放的API服务和行业模板关联，通过建立关联关系，实现对该行业模板下的业务规约读取使用；

步骤S5：创建开发者授权信息：依据运营人员反馈的需求在区块链平台上为链应用开发者建立授权信息；首先登记开发者的基本信息包括开发者名称、开发者用户名和密码，选取该业务所需的API接口服务；信息记录完毕之后，输出授权信息给开发者，授权信息内容包括授权appkey、secretkey、数字证书，同时提供软件开发工具包即SDK给开发者，开发者通过调用SDK中的pem文件获取具体证书信息及API接口方法；

步骤S6：授权信息登记完之后，链应用开发者需先集成区块链SDK，实现SDK的初始化；通过调用pem文件获取证书信息，并将数值证书本地缓存；通过获取SDK中的网关地址及API服务，来匹配授权信息是否可用；若授权信息匹配，则提示授权信息正确可继续使用；若授权信息不匹配，则提示该授权不正确，请联系管理员，同时读取SDK中biz_name的信息并进行存储；

步骤S7：应用端要将数据上链时，需向SDK端发起交易请求，SDK端及智能合约层需校验应用端用户的数字证书信息是否和创建授权时分发的数字证书一致，同时调用已授权的API服务，通过biz_name读取其应用使用哪个行业模板中哪个业务类型版本的业务规约，SDK获取对应的上链数据规约信息之后，需同应用端发起的请求信息数据格式做比对包括比对格式是否按配置要求传输、字段是否有遗漏和必填字段是否都传输，校验应用端发起的请求信息是否符合其业务规约内容；

步骤S8：针对同一个业务服务，允许多版本同时运行，依据智能合约内容而定，当合约内容定义某一API服务有V1\V2两版本的数据规约同时使用，约定当场景1时使用V1，场景2时使用V2，则智能合约层只需依据关联主键biz_name来决定运行哪个版本的规约即可；

步骤S9：SDK对应用端信息校验完毕通过之后，SDK收到上链请求数据，需要求应用端开发者调用数字证书对上链信息进行签名，将发送者的身份信息和数据绑定，用以防止他人冒用发送者，保证信息的防篡改的同时认证发送者的身份，防止抵赖；

步骤S10：SDK将请求信息发送给智能合约，智能合约运行对应的API服务，通过biz_name获取该API服务关联的行业模板对应的业务类型中哪个版本的数据规约；智能合约依据规约范式，将数据发送到区块链节点中；

步骤S11：同一个应用SDK允许运行多个智能合约，以符合不同的API服务需要，支持多个合约来调度运行；

步骤S12：数据发送到区块链节点后，就形成了一个区块链交易并进入到上链出来的阶段，后续链上的处理就进入到区块链共识流程。

进一步地，所述步骤S2的具体内容为：通过区块链平台添加业务类型，添加该模板的业务类型，添加内容包括业务类型中文名、英文名和版本号；即在bc_biz_type表中插入业务类型中文名、英文名和版本号内容，针对该行业的不同业务场景需要，创建不同的业务类型。

进一步地，所述步骤S3的具体内容为：通过区块链平台添加数据模型，数据模型内容包括中文名、英文名、数据类型、是否必填和是否设置交易主键；步骤S1至步骤S3完成之后，行业模板定义完成。

与现有技术相比，本发明具有以下有益效果：

本发明依据不同业务需要，定义不同的上链数据规约，同时随着业务的发展，规约支持多版本发行，支持不同业务情形下使用该特地业务的数据规约。

附图说明

图1为本发明实施例的方法框图。

具体实施方式

下面结合附图及实施例对本发明做进一步说明。

应该指出，以下详细说明都是例示性的，旨在对本申请提供进一步的说明。除非另有指明，本文使用的所有技术和科学术语具有与本申请所属技术领域的普通技术人员通常理解的相同含义。

需要注意的是，这里所使用的术语仅是为了描述具体实施方式，而非意图限制根据本申请的示例性实施方式。如在这里所使用的，除非上下文另外明确指出，否则单数形式也意图包括复数形式，此外，还应当理解的是，当在本说明书中使用术语“包含”和/或“包括”时，其指明存在特征、步骤、操作、器件、组件和/或它们的组合。

如图1所示，本实施例提供一种定义区块链上链数据业务规约及应用业务规约的方法，包括以下步骤：

步骤S1：创建行业模板，用于沉淀行业上链数据模型：在区块链平台创建行业模板，输入模板名称、模板描述；同时在mysql数据库中创建bc_biz_type表，用于存储创建的行业模板信息即完成沉淀行业上链数据模型；

步骤S2：创建该行业模板的业务类型；

步骤S3：创建该业务类型的业务规约即上链数据模型；

步骤S4：完成行业模板定义之后，区块链平台中的智能合约自动获取定义内容，同时区块链平台管理人员需将开放的API服务和行业模板关联，通过建立关联关系，实现对该行业模板下的业务规约读取使用；

步骤S5：创建开发者授权信息：依据运营人员反馈的需求在区块链平台上为链应用开发者建立授权信息；首先登记开发者的基本信息包括开发者名称、开发者用户名和密码，选取该业务所需的API接口服务；信息记录完毕之后，输出授权信息给开发者，授权信息内容包括授权appkey、secretkey、数字证书，同时提供软件开发工具包即SDK给开发者，开发者通过调用SDK中的pem文件获取具体证书信息及API接口方法；

步骤S6：授权信息登记完之后，链应用开发者需先集成区块链SDK，实现SDK的初始化；通过调用pem文件获取证书信息，并将数值证书本地缓存；通过获取SDK中的网关地址及API服务，来匹配授权信息是否可用；若授权信息匹配，则提示授权信息正确可继续使用；若授权信息不匹配，则提示该授权不正确，请联系管理员，同时读取SDK中biz_name的信息并进行存储；

步骤S7：应用端要将数据上链时，需向SDK端发起交易请求，SDK端及智能合约层需校验应用端用户的数字证书信息是否和创建授权时分发的数字证书一致，同时调用已授权的API服务，通过biz_name读取其应用使用哪个行业模板中哪个业务类型版本的业务规约，SDK获取对应的上链数据规约信息之后，需同应用端发起的请求信息数据格式做比对包括比对格式是否按配置要求传输、字段是否有遗漏和必填字段是否都传输，校验应用端发起的请求信息是否符合其业务规约内容；

步骤S8：针对同一个业务服务，允许多版本同时运行，依据智能合约内容而定，当合约内容定义某一API服务有V1\V2两版本的数据规约同时使用，约定当场景1时使用V1，场景2时使用V2，则智能合约层只需依据关联主键biz_name来决定运行哪个版本的规约即可；

步骤S9：SDK对应用端信息校验完毕通过之后，SDK收到上链请求数据，需要求应用端开发者调用数字证书对上链信息进行签名，将发送者的身份信息和数据绑定，用以防止他人冒用发送者，保证信息的防篡改的同时认证发送者的身份，防止抵赖；

步骤S10：SDK将请求信息发送给智能合约，智能合约运行对应的API服务，通过biz_name获取该API服务关联的行业模板对应的业务类型中哪个版本的数据规约；智能合约依据规约范式，将数据发送到区块链节点中；

步骤S11：同一个应用SDK允许运行多个智能合约，以符合不同的API服务需要，支持多个合约来调度运行；

步骤S12：数据发送到区块链节点后，就形成了一个区块链交易并进入到上链出来的阶段，后续链上的处理就进入到区块链共识流程。

在本实施例中，所述步骤S2的具体内容为：通过区块链平台添加业务类型，添加该模板的业务类型，添加内容包括业务类型中文名、英文名和版本号；即在bc_biz_type表中插入业务类型中文名、英文名和版本号内容，针对该行业的不同业务场景需要，创建不同的业务类型。

在本实施例中，所述步骤S3的具体内容为：通过区块链平台添加数据模型，数据模型内容包括中文名、英文名、数据类型、是否必填和是否设置交易主键；步骤S1至步骤S3完成之后，行业模板定义完成。

较佳的，本实施例通过对区块链上链数据业务规约的灵活设定，解决区块链管理平台对上链数据规约存在的频繁变更，多版本运行，合规性校验等问题。通过区块链平台对业务规约的灵活设定，在业务端实现上链规约灵活配置，多版本应用，在应用端实现SDK对规约及用户身份安全性检验，上链规约合规性检验。在平台端实现通过简单的数据模型，实现适应多种区块链应用场景，同时沉淀规约快速建模，提高应用效率缩减项目研发人力成本、停机部署的时间成本、业务应用不流畅产生的应用成本。

在本实施例中，区块链管理平台提供对区块链应用上链数据业务规约灵活配置方法，配置内容包括行业模板配置、业务类型配置、业务规约或数据模型配置。且配置的精细度支持到数据类型、是否业务主键、中英文名。让原先需代码逻辑配置的部分转移到业务端定义。增强业务灵活性，确保上链数据规约适应业务变换。

业务规约的配置支持多版本，并且规约配置完成后可通过SDK自动读取，无需进行区块链网络的部署，减少各项成本。通过SDK校验业务规约安全性及合规性，避免数据上链不规范，提高上链数据的门槛，提升上链数据有效性，保障链上数据的质量；业务规约配置时，可提供业务追溯时的主键配置，业务端自行定义业务主键，实现通过主键内容对整个业务行为进行追溯。该配置对应用端开放，实现业务场景规划灵活设计无需受主键的限制，做到上链追溯跟上业务。

本实施例依据不同业务需要，定义不同的上链数据规约，同时随着业务的发展，规约支持多版本发行，支持不同业务情形下使用该特地业务的数据规约。

本实施例将不同业务场景使用的上链数据规约沉淀形成行业模板，供下次该行业的其他区块链网络创建时快速复用。

本实施例提供灵活的校验方式，支持SDK及智能合约层的校验，根据业务的流量来控制。

本实施例对上链数据的中文名、英文名、数据类型、是否必填之类的配置之外，还提供交易主键的配置。实现对整个业务行为发生之后的追溯。是基于区块链平台“Key-Value”的存储结构的读写效率极高优势基础上，解决数据复杂查询的问题。

本实施例能有效提升上链数据安全问题，通过SDK层实现上链数据在智能合约的校验，上链数据模型在智能合约中备案。数据校验内容包括上链规约内容是否和各节点共识通过的规则一致、校验交易请求者的身份信息是否和授权的信息一致。

本实施例提供一种灵活上链数据业务规约的方法，通过沉淀行业应用模板，实现在不同项目中的快速复用推广和迭代。在不同行业模板下可设置不同业务分类，不同分类下配置上链数据模型，模型内容包括数据的中文名、英文名、数据类型、是否必填等。一个行业应用可支持多个版本的业务分类，支持不同版本数据模型一起执行，并且可在线实时更新。同时还提供交易主键的配置。实现对整个业务行为发生之后的追溯。

以上所述仅为本发明的较佳实施例，凡依本发明申请专利范围所做的均等变化与修饰，皆应属本发明的涵盖范围。