区块链交易验证方法、装置、存储介质及电子设备与流程

1.本技术涉及区块链技术领域，尤其是涉及到一种区块链交易验证方法、 装置、存储介质及电子设备。


背景技术：

2.区块链是分布式数据存储、点对点传输、共识机制、加密算法等计算机 技术的新型应用模式。由于区块链具有去中心化、不可篡改、全程留痕、可 以追溯、集体维护、公开透明等特点。这些特点保证了区块链的“诚实”与“透 明”，因此，基于区块链的交易能够解决信息不对称问题，实现多个主体之间 的协作信任与一致行动。
3.现有的区块链交易过程中，交易文件的签名验证都是需要去调用服务端 的一些接口去验证的，其中，验证算法是在服务端内部定义的，这种黑盒的 模式导致出错时不好排查，也无从得知算法是否正确。并且由于前端页面需 要通过http协议去请求服务，服务器的状态会影响结果的返回，若是服务器宕 机，则请求无效，因此这种方法服务不够稳定；此外，由于建立http请求需要 花费时间并且增加数据开销和功耗，因此导致验证效率低；并且，前端与服 务端建立的通信有可能被中间人攻击，安全性较低。


技术实现要素：

4.有鉴于此，本技术提供了一种区块链交易验证方法、装置、介质及设备， 在客户端完成区块链交易文件的签名验证，解决了现有方法中调用服务端接 口验证签名所导致的问题。
5.根据本技术的一个方面，提供了一种区块链交易验证方法，应用于区块 链交易系统中的客户端，方法包括：
6.响应于来自用户的基于区块链的交易验证请求，获取与所述请求对应的 交易文件；
7.解析所述交易文件，得到所述交易文件中的签名信息；
8.调用验证逻辑文件，并利用所述验证逻辑文件验证所述签名信息，得到 与所述签名信息对应的验证结果。
9.可选地，所述调用验证逻辑文件，并利用所述验证逻辑文件验证所述签 名信息，具体包括：
10.利用javascript调用所述验证逻辑文件中的验证接口，利用与所述验证接 口对应的验证方法验证所述签名信息的哈希值；
11.若所述哈希值为真，则所述验证结果为通过验证，否则所述验证结果为 未通过验证。
12.可选地，所述调用验证逻辑文件之前，还包括：
13.利用go语言生成与所述验证逻辑文件对应的初始文件；
14.利用webassembly命令，将所述初始文件转换成为所述验证逻辑文件，其 中，所述
验证逻辑文件包括所述验证接口以及所述验证方法，所述验证方法 用于验证所述签名信息。
15.可选地，所述验证逻辑文件是wasm格式的二进制文件。
16.可选地，所述利用javascript调用所述验证逻辑文件中的验证接口之前， 还包括：
17.搭建沙盒环境，其中，所述沙盒环境用于运行所述验证逻辑文件。
18.可选地，所述方法还还包括：
19.基于vue框架，搭建所述客户端，其中，所述客户端利用javascript编写。
20.可选地，所述得到与所述签名信息对应的验证结果之后，还包括：
21.解析所述交易文件，得到所述交易文件中的交易信息；
22.在所述客户端展示所述交易信息以及所述验证结果。
23.根据本技术的另一方面，提供了一种区块链交易验证装置，应用于区块 链交易系统中的客户端，所述装置包括：
24.获取模块，用于响应于来着用户的基于区块链的交易验证请求，获取与 所述请求对应的交易文件；
25.解析模块，用于客户端解析所述交易文件，得到所述交易文件中的签名 信息；
26.验证模块，用于调用验证逻辑文件，并利用所述验证逻辑文件验证所述 签名信息，得到与所述签名信息对应的验证结果。
27.可选地，所述验证模块，具体用于：
28.利用javascript调用所述验证逻辑文件中的验证接口，利用与所述验证接 口对应的验证方法验证所述签名信息的哈希值；
29.若所述哈希值为真，则所述验证结果为通过验证，否则所述验证结果为 未通过验证。
30.可选地，所述装置还包括初始化模块，具体用于：
31.利用go语言生成与所述验证逻辑文件对应的初始文件；
32.利用webassembly命令，将所述初始文件转换成为所述验证逻辑文件，其 中，所述验证逻辑文件包括所述验证接口以及所述验证方法，所述验证方法 用于验证所述签名信息。
33.可选地，所述验证逻辑文件是wasm格式的二进制文件。
34.可选地，所述装置还包括环境搭建模块，具体用于：
35.搭建沙盒环境，其中，所述沙盒环境用于运行所述验证逻辑文件。
36.可选地，所述初始化模块还用于：
37.基于vue框架，搭建所述客户端，其中，所述客户端利用javascript编写。
38.可选地，所述解析模块还用于：
39.解析所述交易文件，得到所述交易文件中的交易信息；
40.所述装置还包括展示模块，具体用于：
41.在所述客户端展示所述交易信息以及所述验证结果。
42.根据本技术又一个方面，提供了一种存储介质，其上存储有计算机程序， 所述计算机程序被处理器执行时实现上述区块链交易验证方法。
43.根据本技术再一个方面，提供了一种电子设备，包括存储介质、处理器 及存储在存储介质上并可在处理器上运行的计算机程序，所述处理器执行所 述计算机程序时实现上述区块链交易验证方法。
44.借由上述技术方案，本技术客户端通过验证逻辑文件完成签名信息的验 证，得到验证结果，针对签名信息的验证逻辑写在验证逻辑文件内，在出现 错误时，这种白盒的模式可根据验证逻辑文件进行排查，排错效率更高。此 外，本实施例无需调用服务端，不需要额外部署服务端代码，也不会因服务 端宕机等影响验证过程的稳定性。进一步地，本实施例不与服务器建立http 请求，而是本地运行的速度去执行验证过程，避免在通信上耗费时间，同时 也避免建立的通信被中间人攻击，提高了验证效率以及安全性。
45.上述说明仅是本技术技术方案的概述，为了能够更清楚了解本技术的技 术手段，而可依照说明书的内容予以实施，并且为了让本技术的上述和其它 目的、特征和优点能够更明显易懂，以下特举本技术的具体实施方式。
附图说明
46.此处所说明的附图用来提供对本技术的进一步理解，构成本技术的一部 分，本技术的示意性实施例及其说明用于解释本技术，并不构成对本技术的 不当限定。在附图中：
47.图1示出了本技术实施例提供的一种区块链交易验证方法的流程示意图；
48.图2示出了本技术实施例提供的另一种区块链交易验证方法的确定目标 语句预处理的流程示意图；
49.图3示出了本技术实施例提供的另一种区块链交易验证方法的确定目标 标准疾病名称的流程示意图；
50.图4示出了本技术实施例提供的一种区块链交易验证装置的结构框图。
具体实施方式
51.在本实施例中提供了一种区块链交易验证方法，应用于区块链交易系统 中的客户端，如图1所示，该方法包括：
52.步骤101，响应于来自用户的基于区块链的交易验证请求，获取与请求对 应的交易文件；
53.本技术实施例提供的区块链交易验证方法，适用于验证区块链交易是否 有效。
54.在该步骤中，用户向客户端发出交易验证请求，客户端接收到交易验证 请求后，通过验证签名信息的方式来验证交易文件是否真实可信。因此，首 先获取与请求对应的交易文件，进而对交易文件中进行分析，得到验证结果。
55.进一步地，用户可通过点击按钮或语音输入指令等方式发出交易验证请 求，也可采用直接将交易文件加载至客户端等方式发出交易请求。其中，可 通过拖拽交易文件至客户端的交易验证页面内实现交易文件的加载。
56.步骤102，解析交易文件，得到交易文件中的签名信息；
57.具体地，交易文件包括签名信息，签名信息是只有信息的发送者才能产 生的别人无法伪造的一段数字串，这段数字串同时也是对信息的发送者发送 信息真实性的一个有效证明。根据签名信息，可以验证交易文件的真实性以 及完整性。
58.步骤103，利用验证逻辑文件，验证签名信息，得到与签名信息对应的验 证结果。
59.在该步骤中，有别于现有技术中请求调用服务端的接口验证签名信息的 方法，本实施例不与服务端进行交互，也不调用http接口，而是利用客户端 进行整个验证操作。其中，客户端可为浏览器。
60.具体地，由于区块链通常采用go语言或java语言等进行开发，而客户端 通常采用javascript语言进行开发，因此，客户端无法直接解析go语言或java 语言等，也即无法直接对区块链交易文件的签名信息进行验证。基于此，本 实施例设计了用于验证签名信息的验证逻辑文件，使得客户端可通过验证逻 辑文件来验证签名信息，得到与之对应的验证结果。
61.其中，若验证结果为通过验证，则可认为交易文件真实有效，反之则认 为交易文件无效。
62.通过应用本实施例的技术方案，客户端通过验证逻辑文件完成签名信息 的验证，得到验证结果，针对签名信息的验证逻辑写在验证逻辑文件内，在 出现错误时，这种白盒的模式可根据验证逻辑文件进行排查，排错效率更高。 此外，本实施例无需调用服务端，不需要额外部署服务端代码，也不会因服 务端宕机等影响验证过程的稳定性。进一步地，本实施例不与服务器建立http 请求，而是本地运行的速度去执行验证过程，避免在通信上耗费时间，同时 也避免建立的通信被中间人攻击，提高了验证效率以及安全性。
63.进一步地，作为上述实施例具体实施方式的细化和扩展，为了完整说明 本实施例的具体实施过程，提供了另一种区块链交易验证方法，如图2所示， 调用验证逻辑文件，并利用验证逻辑文件验证签名信息，具体包括：
64.步骤201，利用javascript调用验证逻辑文件中的验证接口，利用与验证 接口对应的验证方法验证签名信息的哈希值；
65.步骤202，若哈希值为真，则验证结果为通过验证，否则验证结果为未通 过验证。
66.在步骤201-202中，客户端从交易文件中获取签名信息，然后针对签名进 行校验。其中，客户端根据签名信息的哈希值判断是否通过验证。可以理解 的是，哈希(hash)值是是根据文件内容的数据，通过逻辑运算得到的数值,不 同的文件(即使是相同的文件名)得到的哈希值是不同的。因此。若两个文件的 哈希值不同，可认为这两个文件是不同的文件。基于这样的原理，可认为若 签名信息有任何篡改，其对应的哈希值也会发生变化，因此，本实施例利用 哈希值来验证签名信息，若哈希值是真实有效的，则认为签名信息也是真实 有效的，因此验证结果为通过验证；反之验证结果为未通过验证。
67.在具体验证过程中，客户端利用javascript语言来调用验证逻辑文件中的 验证接口，其中，在验证逻辑文件中包括与验证接口对应的验证方法。客户 端通过验证接口将签名信息传递至验证方法，验证方法根据签名信息的哈希 值判断签名信息是否真实有效，得到验证结果，并通过验证接口将验证结果 返回至客户端。
68.该实施例的验证逻辑文件提供了验证接口，并可通过验证接口调用验证 方法，利用验证方法来实现验证过程，有效解决了现有的验证方法中，由于 客户端无法直接解析区块链常用的go语言或java语言所导致的只能调用服务 端接口，以利用服务端进行验证的问题。此外，利用哈希值的特征判断签名 信息是否真实有效，保证了验证结果的准确性。
69.进一步地，在另一种区块链交易验证方法中，如图3所示，调用验证逻 辑文件之
前，还包括：
70.步骤301，利用go语言生成与验证逻辑文件对应的初始文件；
71.步骤302，利用webassembly命令，将初始文件转换成为验证逻辑文件， 其中，验证逻辑文件包括验证接口以及验证方法，验证方法用于验证签名信 息。
72.在步骤301-302中，首先利用go语言编写初始文件，初始文件可实现对 区块链交易文件的签名信息的验证逻辑。由于javascript无法解析go语言， 因此在初始文件编制完成后，利用webassembly命令执行文件转换操作，将 初始文件编译成为验证逻辑文件，从而使得客户端可利用javascript调用验证 逻辑文件中的接口。
73.其中，验证逻辑文件包括验证接口和与验证接口对应的验证方法，验证 方法可验证签名信息的真伪，验证接口则为验证方法与javascript提供了交互 通道，使得javascript的方法可调用验证接口，以利用验证接口调用验证方法， 进而执行验证方法中的步骤，实现签名信息的验证。
74.该实施例利用webassembly命令将初始文件转换成为验证逻辑文件，利 用验证逻辑文件作为区块链开发所使用的go语言以及客户端所使用的 javascript语言之间的桥梁，解决了客户端无法直接验证区块链交易文件，只 能调用服务端接口验证的问题。
75.进一步地，在另一种区块链交易验证方法中，验证逻辑文件是wasm格式 的二进制文件。
76.在该实施例中，验证逻辑文件是wasm格式的二进制文件，可以理解的是， wasm是用于前端脚本的低级、可移植的字节码格式，是一种运行在现代网络 浏览器中的新型代码。wasm作为一层中间语言，上层对接java、python、rust、 cpp，让这些语言都能编译成统一的格式，用于在客户端中运行，有效解决了 客户端无法运行go语言的问题。
77.此外，相较于客户端中运行的javascript等语言，wasm的字节码可以用 更少的字节表示相同的指令，并且在webassembly模块依然处于下载期间就 可以被编译，因此，wasm格式的二进制文件的效率更高。进一步地，wasm 格式的文件具有可读可调试的特点，在运行出现错误时，便于调试查找bug。
78.进一步地，在另一种区块链交易验证方法中，利用javascript调用验证逻 辑文件中的验证接口之前，还包括：
79.步骤401，搭建沙盒环境，其中，沙盒环境用于运行验证逻辑文件。
80.在该实施例中，wasm格式的文件需要在沙盒中运行，因此，在调用验证 逻辑文件的验证接口之前，在客户端中搭建用于运行验证逻辑文件的沙盒环 境。
81.其中，可利用quickjs来搭建沙盒环境，也可选择其他的沙盒环境，在此 不做限定。
82.在沙盒中，除了初始化时程序主动提供的内容，无法访问其他主机的内 存和函数。并且运行时产生的变化可以随后删除，不会对系统产生永久性影 响。这意味着，webassembly不会损坏主机进程内存，也无法随意访问文件系 统或与其他设备通信，进一步提高了整个验证过程中的安全性。
83.进一步地，在另一种区块链交易验证方法中，方法还包括：
84.步骤501，基于vue框架，搭建客户端，其中，客户端利用javascript编写。
85.在该实施例中，利用javascript编写浏览器的前端页面，并基于vue框架搭 建。其
中，vue是一套构建用户界面的渐进式前端框架，可用于动态构建前端 界面。相较于传统的客户端，基于vue框架搭建的客户端具有编码简洁、体积 较小、运行效率高等特点。
86.进一步地，客户端还可基于angular框架或react框架搭建。
87.进一步地，在另一种区块链交易验证方法中，得到与签名信息对应的验 证结果之后，还包括：
88.步骤601，解析交易文件，得到交易文件中的交易信息；
89.步骤602，在客户端展示交易信息以及验证结果。
90.在该实施例中，在验证签名信息，得到与签名信息对应的验证结果之后， 在客户端中展示验证结果，验证结果为通过验证或未通过验证。
91.此外，还可将交易文件中的交易信息与验证结果一并展示出来，使得用 户可直观地获知是哪个交易文件通过验证或未通过验证。其中，交易信息中 包括交易双方身份、交易项目详细信息等。
92.进一步地，作为上述区块链交易验证方法的具体实现，本技术实施例提 供了一种区块链交易验证装置，如图4所示，该区块链交易验证装置包括：获 取模块、解析模块以及验证模块。
93.获取模块，用于响应于来自用户的基于区块链的交易验证请求，获取与 请求对应的交易文件；
94.解析模块，用于解析交易文件，得到交易文件中的签名信息
95.验证模块，用于调用验证逻辑文件，并利用验证逻辑文件验证签名信息， 得到与签名信息对应的验证结果。
96.在具体的应用场景中，可选地，验证模块，具体用于：
97.利用javascript调用验证逻辑文件中的验证接口，利用与验证接口对应的 验证方法验证签名信息的哈希值；
98.若哈希值为真，则验证结果为通过验证，否则验证结果为未通过验证。
99.在具体的应用场景中，可选地，装置还包括初始化模块，具体用于：
100.利用go语言生成与验证逻辑文件对应的初始文件；
101.利用webassembly命令，将初始文件转换成为验证逻辑文件，其中，验证 逻辑文件包括验证接口以及验证方法，验证方法用于验证签名信息。
102.在具体的应用场景中，可选地，验证逻辑文件是wasm格式的二进制文件。
103.在具体的应用场景中，可选地，装置还包括环境搭建模块，具体用于：
104.搭建沙盒环境，其中，沙盒环境用于运行验证逻辑文件。
105.在具体的应用场景中，可选地，初始化模块还用于：
106.基于vue框架，搭建客户端，其中，客户端利用javascript编写。
107.在具体的应用场景中，可选地，解析模块还用于：
108.解析交易文件，得到交易文件中的交易信息
109.装置还包括展示模块，具体用于：
110.在客户端展示交易信息以及验证结果。
111.根据本技术又一个方面，提供了一种存储介质，其上存储有计算机程序， 程序或指令被处理器执行时实现上述区块链交易验证方法。
112.根据本技术再一个方面，提供了一种电子设备，包括存储介质、处理器 及存储在存储介质上并可在处理器上运行的计算机程序，处理器执行程序时 实现上述区块链交易验证方法。
113.需要说明的是，本技术实施例提供的一种区块链交易验证装置所涉及各 功能模块的其他相应描述，可以参考图1至图3中的对应描述，在此不再赘 述。
114.基于上述如图1至图3所示方法，相应的，本技术实施例还提供了一种 存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述如图1 至图3所示的区块链交易验证方法。
115.基于这样的理解，本技术的技术方案可以以软件产品的形式体现出来， 该软件产品可以存储在一个非易失性存储介质(可以是cd-rom，u盘，移 动硬盘等)中，包括若干指令用以使得一台电子设备(可以是个人计算机， 服务器，或者网络设备等)执行本技术各个实施场景所述的方法。
116.基于上述如图1至图3所示的方法，以及图4所示的区块链交易验证装 置实施例，为了实现上述目的，本技术实施例还提供了一种电子设备，具体 可以为个人计算机、服务器、网络设备等，该电子设备包括存储介质和处理 器；存储介质，用于存储计算机程序；处理器，用于执行计算机程序以实现 上述如图1至图3所示的区块链交易验证方法。
117.可选地，该电子设备还可以包括用户接口、网络接口、摄像头、射频(radiofrequency，rf)电路，传感器、音频电路、wi-fi模块等等。用户接口可以 包括显示屏(display)、输入单元比如键盘(keyboard)等，可选用户接口 还可以包括usb接口、读卡器接口等。网络接口可选的可以包括标准的有线 接口、无线接口(如蓝牙接口、wi-fi接口)等。
118.本领域技术人员可以理解，本实施例提供的一种电子设备结构并不构成 对该电子设备的限定，可以包括更多或更少的部件，或者组合某些部件，或 者不同的部件布置。
119.存储介质中还可以包括操作装置、网络通信模块。操作装置是管理和保 存电子设备硬件和软件资源的程序，支持信息处理程序以及其它软件和/或程 序的运行。网络通信模块用于实现存储介质内部各控件之间的通信，以及与 该实体设备中其它硬件和软件之间通信。
120.通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本申 请可以借助软件加必要的通用硬件平台的方式来实现，也可以通过硬件实现。
121.本领域技术人员可以理解附图只是一个优选实施场景的示意图，附图中 的单元或流程并不一定是实施本技术所必须的。本领域技术人员可以理解实 施场景中的装置中的单元可以按照实施场景描述进行分布于实施场景的装置 中，也可以进行相应变化位于不同于本实施场景的一个或多个装置中。上述 实施场景的单元可以合并为一个单元，也可以进一步拆分成多个子单元。
122.上述本技术序号仅仅为了描述，不代表实施场景的优劣。以上公开的仅 为本技术的几个具体实施场景，但是，本技术并非局限于此，任何本领域的 技术人员能思之的变化都应落入本技术的保护范围。