区块链预言机状态监控方法与流程

1.本技术涉及金融科技(fintech)领域，尤其涉及一种区块链预言机状态监控方法。


背景技术：

2.随着计算机技术的发展，越来越多的技术应用在金融领域，传统金融业正在逐步向金融科技(fintech)转变，区块链(block chain)技术也不例外，但由于金融行业的安全性、实时性要求，也对技术提出的更高的要求。区块链网络与外界进行数据交互时，可以通过设置在区块链上的智能合约调用与区块链网络连接的预言机节点的外部数据接口来实现。如果预言机节点或外部数据接口出现问题，那么区块链就无法及时获取到外部数据，造成区块链上的交易无法完成，从而使得用户产生了相应的损失。
3.现有技术一般采用独立的线下监控系统单独对预言机节点进行健康监控。通过预言机节点向线下监控系统推送日志，线下监控系统分析日志，判断预言机节点的服务器的工作状态。
4.但是现有技术存在线下监控系统的监控结果无法在区块链上公开验证，导致区块链上的共识节点依旧有调用非正常状态的预言机的风险，并且，部分预言机的功能是否异常只有在接收到区块链的服务请求时才能从日志中分析出来，当区块链网络没有发起服务请求时，难以从日志中及时发现预言机节点是否存在故障。即现有技术中存在无法对预言机节点的状态进行及时有效地监控的技术问题。


技术实现要素：

5.本技术提供一种区块链预言机状态监控方法，以解决现有技术中存在的无法对预言机节点的状态进行及时有效地监控的技术问题。
6.第一个方面，本技术提供一种区块链预言机状态监控方法，应用于区块链网络的共识节点，该方法包括：
7.在预言机节点上链时，在预言机合约中添加监控设置交易，该监控设置交易包括状态监控规则以及初始挑战信息，预言机合约为共识节点与预言机节点进行数据交互的智能合约，状态监控规则用于通过挑战
‑
响应的方式判断预言机节点在预设时段内是否持续保持正常的在线工作状态；
8.上链预言机合约，并执行监控设置交易后，周期性地接收预言机节点返回的响应信息，响应信息为预言机节点根据状态监控规则中的预设延迟算法以及初始挑战信息，经过预设时段的运算后而确定的；
9.根据初始挑战信息判断响应信息是否满足状态监控规则，若否，则将预言机节点的状态更新为非激活状态。
10.本技术将预言机节点的状态监控从线下移到了区块链网络中，在预言机节点上链时，共识节点会为该预言机节点设置对应的智能合约即预言机合约，以使区块链网络能够调用该预言机节点与外界数据进行交互。在创建预言机合约时将监控设置交易也添加到了
预言机合约中，为预言机合约添加了状态监控规则。使得区块链网络利用预言机合约在处理用户发起的需要与外界进行数据交互的交易的基础上，也同时对预言机节点的工作状态进行监控。在监控到预言机节点存在问题时，直接在预言机合约中将预言机节点的状态更新为非激活状态。
11.而为了监控在一段时间内预言机是否都正常工作，通过预言机合约向预言机节点发送初始挑战信息，通过挑战
‑
响应的方式判断预言机节点在预设时段内是否持续保持正常的在线工作状态，并且，只需要一次挑战
‑
响应的方式就能够验证出在一个预设时段内预言机节点是否一直保持着正常工作状态，因为预言机的响应信息是要经过预设时段的计算才得到的，这就突破了挑战
‑
响应的方式只能验证某一时刻的状态这一技术障碍。
12.利用这种新的监控方法，解决了现有技术中存在的无法对预言机节点的状态进行及时有效地监控的技术问题，使得预言机节点出现故障后，区块链网络只要调用预言机合约，就会发现预言机节点已经处于非激活状态，实现了将监控结果在区块链上进行公开验证，也达到了将监控与区块链网络发起的交易服务进行解耦，使得预言机节点的故障能够被及时发现的技术效果。
13.第二方面，本技术提供一种区块链预言机状态监控方法，应用于预言机节点，该方法包括：
14.向区块链网络的共识节点发送上链请求，上链请求用于将预言机节点接入区块链网络；
15.检测到共识节点通过预言机合约执行了监控设置交易后，根据监控设置交易中的状态监控规则以及初始挑战信息连续不断地计算响应信息，状态监控规则用于通过挑战
‑
响应的方式判断预言机节点在预设时段内是否持续保持正常的在线工作状态；
16.根据状态监控规则，在预设时刻将响应信息发送给共识节点，以使共识节点根据初始挑战信息判断响应信息是否满足状态监控规则。
17.本技术提供的区块链预言机状态监控方法，预言机节点在提交了上链请求后，检测到区块链网络已经生成了预言机合约，并且区块链网络通过预言机合约执行了监控设置交易，这样就能够将状态监控规则传递给预言机节点，使得预言机节点接收到区块链网络发布的初始挑战信息，通过挑战
‑
响应的方式，预言机节点需要在预设时段内不断地利用状态监控规则，根据初始挑战信息，确定本次挑战的证明信息，完成了证明信息的计算后，将一次或多次的证明信息发送给区块链网络的共识节点进行验证。
18.由于状态监控规则要求预言机节点在预设时段内不断地进行证明信息的计算，如果预言机节点的一直保持着正常的在线工作状态，那么该计算结果即证明信息与保存在预言机合约中的验证信息应该是匹配对应的，否则，证明在该预设时段内，预言机节点发生了异常状况，区块链网络就会将预言机合约中的激活状态改为非激活状态，这样，区块链网络就无法调用异常的预言机节点，保证了用户的交易不会由于预言机节点的故障而受到影响。达到了及时在区块链中公开验证预言机健康状态监控结果的技术效果。
19.第三方面，本技术提供一种区块链预言机状态监控装置，包括：
20.设置模块，用于在预言机节点上链时，在预言机合约中添加监控设置交易，监控设置交易包括状态监控规则以及初始挑战信息，预言机合约为共识节点与预言机节点进行数据交互的智能合约，状态监控规则用于通过挑战
‑
响应的方式判断预言机节点在预设时段
内是否持续保持正常的在线工作状态；
21.设置模块，还用于上链预言机合约，并执行监控设置交易；
22.接收模块，用于周期性地接收预言机节点返回的响应信息，响应信息为预言机节点根据状态监控规则中的预设延迟算法以及初始挑战信息，经过预设时段的运算后而确定的；
23.监控模块，用于根据初始挑战信息判断响应信息是否满足状态监控规则，若否，则将预言机节点的状态更新为非激活状态。
24.第四方面，本技术提供一种区块链预言机状态监控装置，包括：
25.发送模块，用于向区块链网络的共识节点发送上链请求，上链请求用于将预言机节点接入区块链网络；
26.处理模块，用于：
27.检测到共识节点通过预言机合约执行了监控设置交易后，根据监控设置交易中的状态监控规则以及初始挑战信息连续不断地计算响应信息，状态监控规则用于通过挑战
‑
响应的方式判断预言机节点在预设时段内是否持续保持正常的在线工作状态；
28.发送模块，还用于根据状态监控规则，在预设时刻将响应信息发送给共识节点，以使共识节点根据初始挑战信息判断响应信息是否满足状态监控规则。
29.第五个方面，本技术提供一种电子设备，包括：
30.存储器，用于存储程序指令；
31.处理器，用于调用并执行所述存储器中的程序指令，执行第一方面所提供的任意一种可能的物品存储信息确定方法。
32.第六个方面，本技术提供一种电子设备，包括：
33.存储器，用于存储程序指令；
34.处理器，用于调用并执行所述存储器中的程序指令，执行第二方面所提供的任意一种可能的物品存储信息确定方法。
35.第七方面，本技术提供一种存储介质，所述可读存储介质中存储有计算机程序，所述计算机程序用于执行第一方面所提供的任意一种可能的区块链预言机状态监控方法。
36.第八方面，本技术提供一种存储介质，所述可读存储介质中存储有计算机程序，所述计算机程序用于执行第二方面所提供的任意一种可能的区块链预言机状态监控方法。
37.第九方面，本技术还提供一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现第一方面所提供的任意一种可能的区块链预言机状态监控方法。
38.第十方面，本技术还提供一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现第二方面所提供的任意一种可能的区块链预言机状态监控方法。
39.本技术提供了一种区块链预言机状态监控方法，通过预言机节点向区块链网络的共识节点发送上链请求，共识节点在接收到该上链请求后，在为预言机节点创建预言机合约时，将监控设置交易添加到预言机合约中，该监控设置交易包含了在一段时间内通过挑战
‑
响应方式监控预言机节点是否持续保持在线工作的状态监控规则；预言机节点检测到预言机合约发布后，通过执行监控设置交易，开始持续不断地根据状态监控规则以及初始挑战信息进行证明信息的计算，然后将证明信息发送给共识节点进行验证，如果验证不通过，则将预言机合约的状态更改为非激活状态。解决了现有技术中存在的无法对预言机节
点的状态进行及时有效地监控的技术问题。实现了将监控结果在区块链上进行公开验证，也达到了将监控与区块链网络发起的交易服务进行解耦，使得预言机节点的故障能够被及时发现的技术效果。
附图说明
40.此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本技术的实施例，并与说明书一起用于解释本技术的原理。
41.图1为本技术提供的区块链通过预言机与外界进行数据交互的示意图；
42.图2为本技术提供的一种区块链预言机状态监控方法的流程示意图；
43.图3为本技术实施例提供的一种预言机注册交易的示意图；
44.图4为本技术实施提供的另一种区块链预言机状态监控方法的流程示意图；
45.图5为本技术实施例提供的一种监控设置交易的示意图；
46.图6为本技术实施例提供的一种预言机合约的示意图；
47.图7为本技术实施例提供的一种证明交易的示意图；
48.图8为本技术实施例提供的一种区块链预言机状态监控装置的结构示意图；
49.图9为本技术实施例提供的另一种区块链预言机状态监控装置的结构示意图；
50.图10为本技术提供的一种电子设备的结构示意图。
51.通过上述附图，已示出本技术明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本技术构思的范围，而是通过参考特定实施例为本领域技术人员说明本技术的概念。
具体实施方式
52.为使本技术实施例的目的、技术方案和优点更加清楚，下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，包括但不限于对多个实施例的组合，都属于本技术保护的范围。
53.本技术的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本技术的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
54.下面对本技术所涉及到的专业名词作出解释：
55.区块链：区块链是利用块链式数据结构来验证与存储数据、利用分布式节点共识算法来生成和更新数据、利用密码学的方式保证数据传输和访问的安全、利用自动化脚本代码组成的智能合约来编程和操作数据的一种全新的分布式基础架构与计算方式。
56.共识节点：区块链中运行共识算法，对新产生的区块进行共识，确认是否通过，如
果通过则加在区块链的尾部，使区块链内容达成一致的节点。
57.智能合约：智能合约是部署在区块链上，完成特定功能的代码。solidity是一种主流的智能合约编程语言，用solidity语言编写的智能合约，叫solidity合约。当智能合约被部署到区块链上时，会产生合约地址，用户可通过合约地址调用此智能合约。智能合约中定义的函数，称为合约接口，对智能合约的调用，就是通过合约地址调用合约中的某个合约接口。
58.预言机(oracle machine)：区块链系统是一个去中心化系统，为了保证在这个系统中每个节点的区块链数据保持一致，通常需要避免导致节点间出现不一致的外部数据访问(如：外部货币市场的实时汇率)。当用户期望区块链能获取外部数据时，通常会使用到预言机。区块链外信息写入区块链内的机制，一般被称为预言机。它允许确定的智能合约对不确定的外部世界作出反应，是智能合约与外部进行数据交互的途径，也是区块链与现实世界进行数据交互的接口。
59.延迟函数(delay function)：延迟函数的作用是，即使在使用多个处理器和并行的情况下，也只能在规定时间之后得到结果。
60.可验证延迟函数(verifiable delay function，vdf)：可验证延迟函数是一种延迟函数，它满足延迟函数的条件又具备可快速验证的效果。即它在计算的时候需要运行一定数量的步骤，但函数的输出可以被快速验证。vdf的算法定义如公式(1)所示：
61.f(x)=y，π
ꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀ
(1)
62.其中，π为vdf在本次f(x)运算的计算结果，也称为证明，y为下次f(x)运算的输入值x。
63.为了计算得到y，正常状态下的节点需要花费t长度的时间，而对于异常节点，即使异常节点有多个中央运算单元cpu以及并行计算的能力，也无法在t时间内完成f(x)计算，即无法得到正确的y值。
64.而通过证明值π，任何人都可以快速验证y的正确性。
65.可验证陷门函数(verifiable trapdoor function,vtf)：可验证陷门函数是可验证延迟函数中的一种。区别在于拥有陷门秘密的人可以无延迟地计算出结果。vtf的算法定义可以分成两个方面，一个是不具备陷门秘密时，其定义如公式(1)所示，而具备陷门秘密时，其定义如公式(2)所示：
66.f(x，trapdoor)=y，π
ꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀ
(2)
67.其中，trapdoor为陷门秘密，只要在计算时输入陷门秘密，就能够无延迟地计算出y和π的值。而没有陷门秘密的只能够花费t长度的时间来完成如公式(1)所示的计算。
68.下面介绍区块链中预言机的工作原理：
69.以当前主流的预言机chainlink为例，一个预言机的构造和工作流程如下。
70.图1为本技术提供的区块链通过预言机与外界进行数据交互的示意图。如图1所示，存在一个区块链(blockchain)网络10，实现一个预言机，首先，需要在区块链上部署一个合约，叫chainlink预言机合约101(chainlink
‑
sc contract)，接受来自用户合约(user
‑
sc contract)102的外部数据访问请求。然后，需要部署一个chainlink预言机节点20(chainlink node)，用于监听chainlink预言机合约101上的请求事件，并作出相应，从获取外部数据的外部接口30(external application programming interface)获取所请求的
外部数据，并将其传输上链，返回给用户合约102。从而让用户合约102实现对外部数据的获取。
71.具体的工作流程如下：
72.(1)用户合约102向chainlink预言机合约101发送获取外部数据的请求，该操作在链上进行。
73.(2)chainlink预言机合约记录该请求事件。
74.(3)chainlink节点20和核心201(core)接受该事件并路由任务到适配器202(adapter)。
75.(4)chainlink适配器202调用外部接口30获取用户要查询的外部数据。
76.(5)chainlink适配器202处理响应并将其传递回核心201。
77.(6)chainlink核心201报告数据发送到chainlink预言机合约101。
78.(7)chainlink预言机合约101汇总响应并将其传回用户合约102，作为对用户合约102的单一答复。
79.本技术发明人发现，在上述工作流程中，chainlink预言机节点20及外部接口30，和区块链网络10是相互分离的，chainlink预言机节点20或外部接口30出现问题后，可能影响区块链的正常运作或交易的正常上链，从而给用户带来损失。
80.比如：用户合约102发起了一个外部数据请求迟迟无法从预言机中获得外部数据。这可能使得用户错过了合适的交易时期，从而产生损失。具体的，比如，用户进行一笔与汇率相关的交易，用户看准了当前的汇率，向区块链网络10发送了一笔交易，该交易操作用户合约102，并访问chainlink预言机合约101获取该汇率以完成该交易，但由于chainlink预言机节点20或外部接口30无法按时提供该汇率信息，从而使得交易无法顺利完成，因而无法通过交易验证并上链。
81.传统的健康监控系统，通常采用日志推送和分析的方式。监控系统通过分析来自预言机节点所属服务器推送的日志，判断服务器的工作状态。预言机作为一种服务器，也可以应用或承载这种健康监控系统。但这种系统应用在区块链预言机中存在以下几个问题：
82.1.健康监控系统的监控结果，无法被在区块链上被公开验证。
83.2.部分预言机的功能是否异常，只有在预言机接收到服务请求时才能从该服务请求对应的日志中分析出来。当区块链网络中没有提出服务请求时，难以通过日志判断预言机节点的服务是否正常，无法及时报告问题。
84.为解决上述问题，本技术的发明构思是：
85.为解决及时报告预言机节点是否存在异常，本技术发明人首先想到的是使用挑战
‑
响应式的验证方式。然而，传统的挑战
‑
响应式的验证方式使用起来，每次只能验证一个时刻的服务器状态，如果验证频繁，则会给验证程序带来较大的网络和计算的负担，使得验证效率低下。
86.为此，需要设计一种新的挑战
‑
响应方式来实现：只需要发起一次挑战，获得一次响应，就能够完成对预言机节点在一个时间段内的健康状态监控大大降低网络负担，提升验证效率。
87.并且，通过区块链的智能合约来管理监控策略即状态监控规则，保存预言机的状态。预言机的证明即对挑战的响应，通过交易发送到区块链网络，由智能合约公开验证预言
机的状态。
88.最后，当智能合约对预言机的响应验证失败时，即发现预言机未能提供持续可靠的服务时，及时关闭预言机合约，停止服务。这可以方便用户及时了解预言机的状况，从而防止预言机不可用的异常状态为用户带来损失。
89.下面以具体地实施例对本技术的技术方案以及本技术的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本技术的实施例进行描述。
90.图2为本技术实施例提供的一种区块链预言机状态监控方法的流程示意图。如图2所示，该区块链预言机状态监控方法的具体步骤，包括：
91.s201、向区块链网络的共识节点发送上链请求。
92.在本步骤中，上链请求用于将预言机节点接入区块链网络。
93.具体的，预言机节点构造一笔预言机注册交易，并发送给参与区块链共识的共识节点。
94.图3为本技术实施例提供的一种预言机注册交易的示意图。如图3所示，预言机注册交易包括：时间戳timestamp，交易提交方地址from，交易接收方地址to，数量amount，随机数nonce，交易类型txtype，交易数据data，以及数字签名signature。
95.其中，交易数据data中声明了预言机节点所能实现的基本功能，包括：获取汇率getexchangerate，验证汇率verifyexchangerate等等。可以理解的是，本领域技术人员可以根据实际需要，在交易数据data中定义预言机节点的基本功能，本技术不作限定。
96.s202、在预言机节点上链时，在预言机合约中添加监控设置交易。
97.在本步骤中，该监控设置交易包括状态监控规则以及初始挑战信息，预言机合约为共识节点与预言机节点进行数据交互的智能合约，状态监控规则用于通过挑战
‑
响应的方式判断预言机节点在预设时段内是否持续保持正常的在线工作状态。
98.在本实施例中，共识节点在接收到预言机节点发送的预言机注册交易后，对该预言机注册交易进行验证，并打包区块，同时额外生成一笔与该预言机节点对应的监控设置交易，以设定对该预言机节点的状态监控规则，以及挑战
‑
响应方式的第一个挑战的输入值，即初始挑战信息。
99.需要说明的是，为了解决挑战
‑
响应方式一次只能验证某一时刻预言机节点的健康状况，而无法验证一段时间的健康状况的问题，本实施例中采用可验证延迟函数作为验证工具。也就是说，共识节点向预言机节点发送一个挑战值，预言机节点将该挑战值作为可验证延迟函数的输入值进行一个持续t时间长度的运算，如公式(1)所示，得到y和π，并将其作为响应信息反馈给共识节点，共识节点利用同样的可验证延迟函数、挑战值以及y和π，在极短的时间内快速验证预言机节点的计算是否正确，若正确，则证明在t时间长度内，预言机节点都保持正常的在线工作状态，否则，预言机节点出现了异常或故障。
100.在一种可能的设计中，状态监控规则包括：验证频率以及可验证延迟函数，本步骤包括：
101.根据预设交易模板创建监控设置交易；
102.在监控设置交易的数据字段中设置：验证频率、初始挑战信息、可验证延迟函数的参数以及每次验证的对比数据；
103.其中，对比数据是根据可验证延迟函数、初始挑战信息以及验证总数而确定的。
104.需要说明的是，数据字段即为交易数据data；验证频率用于定义每次验证所间隔的时间；可验证延迟函数的参数可以使得预言机节点构造出与共识节点相同的可验证延迟函数；对比数据是指在预言机合约创建时，共识节点就把每次验证的标准值都提前运算好，以节省每次验证所需要的时间。
105.还需要说明的是，验证频率和可验证延迟函数的计算时间不一定相同，两者没有耦合关系或对应关系，本领域技术人员可以根据实际需要对两个时间进行设定，本技术不作限定。
106.s203、上链预言机合约，并执行监控设置交易。
107.在本步骤中，共识节点在完成监控设置交易的生成后，将其与预言机注册交易一起打包生成区块，并将区块分发给区块链上的其它共识节点。然后，区块链运行共识算法对该区块进行共识，若共识成功，则完成预言机节点的上链发布，并且为区块链创建了能够调用该预言机节点的预言机合约。预言机合约创建成功，即代表预言机节点成功接入了该区块链。预言机节点即可为区块链提供其基础功能服务。同时，执行监控设置交易，使得预言机节点根据预言机合约中设置的状态监控规则，开始在预设时段内持续不断地运算可验证延迟函数。
108.s204、根据监控设置交易中的状态监控规则以及初始挑战信息连续不断地计算响应信息。
109.在本步骤中，预言机节点在检测到共识节点通过预言机合约执行了监控设置交易后，预言机需要根据预言机合约中的第一个挑战开始进行可验证延迟函数的证明信息的生成。
110.具体的，根据监控设置交易中的参数，构造出状态监控规则设置的可验证延迟函数；
111.利用可验证延迟函数，根据初始挑战信息，在预设时段内连续进行至少一次验证计算，以确定每次验证的证明信息。
112.需要说明的是，证明信息包括本次验证的输出值以及下一次验证的输入值。如公式(1)所示，本次验证的输出值y和π，将y作为下次验证的输入值。
113.还需要说明的是，对于响应信息，其有多种实施方式，可以直接将可验证延迟函数的计算结果作为响应信息，也可以先将一次或多次的计算结果进行压缩，将压缩后的数据作为响应信息，这样可以节省数据空间，加快数据的传输速度，提高验证效率。无论对于哪一种实施方式，都可以在创建预言机合约时，将标准的对比数据以相同的方式或者相对应的方式存入预言机合约中，以减少验证的时间，提高验证效率。
114.s205、根据状态监控规则，在预设时刻将响应信息发送给共识节点。
115.在本步骤中，状态监控规则中设定了验证频率即每次验证的时间间隔，预言机节点只需将在该时间间隔中所有的证明信息，即一次或多次的证明信息，打包或以预设方式压缩成响应信息，发送给共识节点进行验证。
116.s206、周期性地接收预言机节点返回的响应信息。
117.在本步骤中，响应信息为预言机节点根据状态监控规则中的预设延迟算法以及初始挑战信息，经过预设时段的运算后而确定的。
118.s207、根据初始挑战信息判断响应信息是否满足状态监控规则。
119.在本步骤中，若是，则不用进行任何操作，等待执行下一次验证，若否，则将预言机节点的状态更新为非激活状态。即将预言机合约的状态标识status更改为非激活inactive。
120.本技术实施例提供了一种区块链预言机状态监控方法，通过预言机节点向区块链网络的共识节点发送上链请求，共识节点在接收到该上链请求后，在为预言机节点创建预言机合约时，将监控设置交易添加到预言机合约中，该监控设置交易包含了在一段时间内通过挑战
‑
响应方式监控预言机节点是否持续保持在线工作的状态监控规则；预言机节点检测到预言机合约发布后，通过执行监控设置交易，开始持续不断地根据状态监控规则以及初始挑战信息进行证明信息的计算，然后将证明信息发送给共识节点进行验证，如果验证不通过，则将预言机合约的状态更改为非激活状态。解决了现有技术中存在的无法对预言机节点的状态进行及时有效地监控的技术问题。实现了将监控结果在区块链上进行公开验证，也达到了将监控与区块链网络发起的交易服务进行解耦，使得预言机节点的故障能够被及时发现的技术效果。
121.图4为本技术实施提供的另一种区块链预言机状态监控方法的流程示意图。如图4所示，该区块链预言机状态监控方法的具体步骤包括：
122.s401、向区块链网络的共识节点发送上链请求。
123.在本步骤中，上链请求用于将预言机节点接入区块链网络。
124.具体的，预言机节点构造一笔预言机注册交易，并发送给参与区块链共识的共识节点。
125.s402、在预言机节点上链时，根据预设交易模板创建监控设置交易。
126.在本步骤中，监控设置交易用于为预言机合约以及预言机节点设置状态监控规则，该监控设置交易包括状态监控规则以及初始挑战信息，预言机合约为共识节点与预言机节点进行数据交互的智能合约，状态监控规则用于通过挑战
‑
响应的方式判断预言机节点在预设时段内是否持续保持正常的在线工作状态。
127.在本实施例中，状态监控规则包括：验证频率以及可验证延迟函数。
128.图5为本技术实施例提供的一种监控设置交易的示意图。如图5所示，监控设置交易包括：时间戳timestamp，交易提交方地址from，交易接收方地址to，数量amount，随机数nonce，交易类型txtype，交易数据data，以及数字签名signature。
129.s403、在监控设置交易的数据字段中设置：验证频率、初始挑战信息、可验证延迟函数的参数以及每次验证的对比数据。
130.在本步骤中，对比数据是根据所述可验证延迟函数、所述初始挑战信息以及验证总数而确定的。
131.如图5所示，监控设置交易的数据字段即交易数据data中声明了验证频率即每次验证的时间间隔verifyrate为1个小时，以及初始挑战信息challenge1，可验证延迟函数的参数prameters，以及对比数据taglist。
132.可选的，可验证延迟函数包括可验证陷门函数，则对比数据的生成可以根据以下方式实现：
133.利用可验证陷门函数创建陷门秘密；
134.利用可验证陷门函数，根据陷门秘密、初始挑战信息以及验证总数，无延迟地循环确定标准输入值以及标准输出值。
135.具体的，设定可验证陷门函数的参数parameters使得不拥有陷门秘密trapdoor的一方，在计算公式(1)所示的函数时，需要花费预设时长如1个小时的时间才能得到计算结果。
136.共识节点利用随机算法随机生成一个数值作为初始挑战信息，即可验证陷门函数的输入值，同时输入陷门秘密，如公式(2)所示，即可无延迟地或者说在极短的时间内得到计算结果y和π，将y作为下一次验证的输入值，进行第二次验证结果的计算，如此往复，直到完成验证总数规定的所有验证结果的计算。比如运行720次运算，足够没有陷门秘密的一方，即预言机节点计算30天即一个月，得到证明集verifier{y1,π1,y2,π2,y3,π3,.....y720,π720}。由于共识节点拥有陷门秘密，因此，此证明集是无延迟地得到的。
137.对于对比数据，本步骤中包含了多种实施方式：
138.第一种，直接将证明集中的所有数据写入图5所示的taglist当中。
139.第二种，为了节省区块链上的空间，利用预设压缩算法，根据一个或多个输出键值对(即y和π)，确定对比数据。
140.例如，预设压缩算法为哈希算法，当利用一个输出键值对确定对比数据时，对比数据为输出键值对的哈希值；
141.当利用多个输出键值对确定对比数据时，对比数据为输出键值对的多重哈希值，多重哈希值是由上一次哈希算法的计算结果作为本次哈希算法的输入值而计算得到的。
142.例如，将hash(y1,π1)，或者hash(hash(y1,π1))，或者hash(hash(y1,π1)，hash(y2,π2))等等，作为对比数据存入taglist当中。需要说明的是，本领域技术人员可以根据实际应用场景的需要选择合适的压缩算法，在此不作限定。
143.s404、上链预言机合约，并执行监控设置交易。
144.在本步骤中，共识节点在完成监控设置交易的生成后，将其与预言机注册交易一起打包生成区块，并将区块分发给区块链上的其它共识节点。然后，区块链运行共识算法对该区块进行共识，若共识成功，则完成预言机节点的上链发布，并且为区块链创建了能够调用该预言机节点的预言机合约。预言机合约创建成功，即代表预言机节点成功接入了该区块链。预言机节点即可为区块链提供其基础功能服务。同时，执行监控设置交易，使得预言机节点根据预言机合约中设置的状态监控规则，开始在预设时段内持续不断地运算可验证延迟函数。
145.图6为本技术实施例提供的一种预言机合约的示意图。如图6所示，预言机合约包括：预言机名称oraclename，合约地址address，合约拥有者owner，初始化时间inittime，功能function，状态标识status，初始挑战信息challenge1，验证频率verifyrate，参数prameters，对比数据taglist，最新证明信息latestproof等等。
146.其中，最新证明信息latestproof在每次验证通过时进行更新，状态标识status代表着验证的结果，如果验证不通过则为非激活状态，验证通过则为激活状态，激活状态时，预言机节点可以被正常调用，非激活状态时，预言机节点不能被调用。
147.s405、根据预言机合约中的参数，构造出状态监控规则设置的可验证延迟函数。
148.在本步骤中，预言机节点在检测到共识节点通过预言机合约执行了监控设置交易
后，具体的，预言机节点通过预言机合约中的prameters构造出可验证延迟函数f(x)＝y,π。
149.s406、利用可验证延迟函数，根据初始挑战信息，在预设时段内连续进行至少一次验证计算，以确定每次验证的证明信息。
150.在本步骤中，证明信息包括本次验证的输出值以及下一次验证的输入值。
151.具体的，将图6中的challenge1作为可验证延迟函数f(x)的输入值x，计算第一个挑战的证明。经过预设时长(该预设时长由可验证延迟函数的参数来设定)后，计算得到y1,π1。完成一次证明计算。然后以y1为下一次验证的输入值，继续进行证明的计算，直至完成所有的验证的证明信息。
152.可选的，在每次完成证明计算后，立即根据证明信息生成响应信息，反馈给区块链网络。
153.可选的，在完成预设次数的证明计算后，将若干个已经计算得到的证明信息组合成响应信息反馈给区块链网络。
154.s407、根据状态监控规则中的验证频率，将一次或多次验证的证明信息组合成响应信息发送给共识节点。
155.在本步骤中，可以直接将证明信息发送给共识节点，也可以根据预设压缩算法，根据一次或多次验证的证明信息，确定响应信息。即，也可以将一次或多次的证明信息进行压缩后再发送给共识节点。
156.具体的，利用哈希算法，根据一次验证的证明信息，确定证明信息的哈希值，响应信息包括哈希值；
157.或者，
158.利用哈希算法，根据多次验证的证明信息，确定证明信息的多重哈希值，多重哈希值是由上一次哈希算法的计算结果作为本次哈希算法的输入值而计算得到的，响应信息包括多重哈希值。
159.需要说明的是，在本实施例中，响应信息是以一笔证明交易的形式发送至区块链网络中的。
160.s408、周期性地接收预言机节点返回的响应信息。
161.在本步骤中，当在预设时间接收到预言机发送的证明交易时，执行证明交易所属的区块，以确定执行结果，该执行结果包括响应信息；当在预设时间没有接收到预言机发送的证明交易时，响应信息为空，对应的，不满足状态监控规则。
162.图7为本技术实施例提供的一种证明交易的示意图。如图7所示，证明交易包括：时间戳timestamp，交易提交方地址from，交易接收方地址to，数量amount，随机数nonce，交易类型txtype，交易数据data，以及数字签名signature。
163.其中，交易数据data中包括：挑战编号tagnumber，响应信息tagorigin等等。
164.在一种可能的设计中，预设时间大于或等于标准时间，并且预设时间小于或等于容错时间，容错时间大于标准时间。标准时间为验证频率所对应的时间间隔，如1个小时，容错时间为可运行的偏差时间，如标准时间之后的15～30分钟。需要注意的是偏差时间必须在下一次标准时间之前。
165.s409、根据初始挑战信息判断响应信息是否满足状态监控规则。
166.在本步骤中，当在预设时间接收到预言机发送的证明交易时，判断响应信息与对
比数据是否相匹配；若是，则满足状态监控规则，若否，则不满足状态监控规则。
167.例如，预言机如果保持可用则，可以按照该陷门函数的参数构造陷门函数f(x)＝y,π，并将challenge1中的挑战作为x，进行计算。接连计算720次，每次的挑战都是上一次挑战所计算得到的y值，得出所有结果prover{y1,π1,y2,π2,y3,π3,.....y720,π720}，如果共识节点用verifier{y1，y2,y3,....y720}和prover{π1,π2,π3,...,π720}能在f(x)＝y,π中验证成功，或者如果verifier{y1,π1,y2,π2,y3,π3,.....y720,π720}和prover{y1,π1,y2,π2,y3,π3,.....y720,π720}能匹配，则说明证明在预言机节点在预设时段内不停歇的保持在线工作状态。
168.可选的，共识节点收到证明交易后，先对证明交易进行验证。如图7所示，验证点包括：to地址是否是预言机节点的正确地址；from地址与预言机合约的拥有者(owner)地址是否相同的；数字签名signature是否正确的等等；若验证成功则证明交易被打包上链。
169.完成这个证明交易后，预言机节点以计算得到的y1值作为计算第二个证明的输入，继续进行证明计算直到循环完成验证总数如720轮挑战
‑
响应的验证。
170.当在预设时间没有接收到预言机发送的证明交易时，响应信息为空，则不满足状态监控规则。
171.在一种可能的设计中，响应信息包括预言机节点每一次利用可验证延迟函数计算出的结果，结果包括：本次验证的输出值以及下一次验证的输入值，即预言机节点直接把计算结果发送给了区块链网络，此时，共识节点将输出值与标准输出值，以及输入值与标准输入值，分别进行对比；若两个对比结果均一致，则满足状态监控规则，否则不满足状态监控规则。
172.在另一种可能的设计中，响应信息包括预言机节点利用预设压缩算法，根据可验证陷门函数计算出的一个或多个结果，所确定的压缩数据，此时，共识节点将压缩数据与对比数据进行对比；若对比结果一致，则满足状态监控规则，否则不满足状态监控规则。需要说明的是，此时，对比数据也为利用相同的压缩算法压缩后的数值，例如，共识节点在创建预言机合约时，为了节省区块链上的空间，仅将y1,π1的哈希值hash(hash(y1,π1))，我们把这个值称作tag，如果证明者即预言机节点能提供hash的原像，即hash(y1,π1)。同样可以表明证明信息prover确实产生了对的证明结果。验证者即共识节点生成了这些tag后存放至图5和图6所示的taglist中。
173.需要说明的是，对于第一次挑战，区块链的共识节点在执行证明交易所对应的区块时，验证该证明交易中hash(tagorigin)与智能合约即预言机合约中的taglist中第一个tag是否相互匹配，如果匹配则证明该预言机在过去的一段时间内，如1小时内，是持续在提供服务的。更新如图6所示的预言机合约中的latestproof。并且，以后每次验证通过都更新latestproof中的值，以便于识别是第几次验证。
174.如果执行该证明交易时，发现该证明交易中hash(tagorigin)与智能合约即预言机合约中的taglist中第一个tag并不匹配。则该预言机在过去的过去的一段时间内，如1小时内并未提供持续服务。更新如图6所示的预言机合约中的信息，将状态标识(status)改为inactive非激活状态，关闭该预言机节点。
175.在一种可能的设计中，当根据初始挑战信息判断响应信息是否满足状态监控规则的验证次数达到验证总数时，重新向预言机合约发送监控设置交易，以重新设置状态监控
规则。
176.具体的，如果预言机超出1.5小时(1小时的标准时间+0.5小时的容错时间，这个容错长度可以设定)没有发送证明交易，则可能认为预言机没有提供持续服务，当区块链执行到距离合约inittime有1.5小时的区块时，将合约状态改为inactive.
177.如果720次(30天)的tag已用完，区块链的共识节点可以再次发送监控设置交易(oracle_monitor_setting)重新设定状态监控规则。
178.通过以上方法，进行预言机节点的健康监控。观察是否在持续提供服务，对于工作不正常的预言机，状态设置成inactive。防止被用户调用，从而给用户带来损失。
179.本技术实施例提供了一种区块链预言机状态监控方法，通过预言机节点向区块链网络的共识节点发送上链请求，共识节点在接收到该上链请求后，在为预言机节点创建预言机合约时，将监控设置交易添加到预言机合约中，该监控设置交易包含了在一段时间内通过挑战
‑
响应方式监控预言机节点是否持续保持在线工作的状态监控规则；预言机节点检测到预言机合约发布后，通过执行监控设置交易，开始持续不断地根据状态监控规则以及初始挑战信息进行证明信息的计算，然后将证明信息发送给共识节点进行验证，如果验证不通过，则将预言机合约的状态更改为非激活状态。解决了现有技术中存在的无法对预言机节点的状态进行及时有效地监控的技术问题。实现了将监控结果在区块链上进行公开验证，也达到了将监控与区块链网络发起的交易服务进行解耦，使得预言机节点的故障能够被及时发现的技术效果。
180.图8为本技术实施例提供的一种区块链预言机状态监控装置的结构示意图。该区块链预言机状态监控装置800可以通过软件、硬件或者两者的结合实现。
181.如图8所示，该区块链预言机状态监控装置800包括：
182.设置模块801，用于在预言机节点上链时，在预言机合约中添加监控设置交易，监控设置交易包括状态监控规则以及初始挑战信息，预言机合约为共识节点与预言机节点进行数据交互的智能合约，状态监控规则用于通过挑战
‑
响应的方式判断预言机节点在预设时段内是否持续保持正常的在线工作状态；
183.设置模块801，还用于上链预言机合约，并执行监控设置交易；
184.接收模块802，用于周期性地接收预言机节点返回的响应信息，响应信息为预言机节点根据状态监控规则中的预设延迟算法以及初始挑战信息，经过预设时段的运算后而确定的；
185.监控模块803，用于根据初始挑战信息判断响应信息是否满足状态监控规则，若否，则将预言机节点的状态更新为非激活状态。
186.在一种可能的设计中，状态监控规则包括：验证频率以及可验证延迟函数，设置模块801，用于根据预设交易模板创建监控设置交易；在监控设置交易的数据字段中设置：验证频率、初始挑战信息、可验证延迟函数的参数以及每次验证的对比数据；
187.其中，对比数据是根据可验证延迟函数、初始挑战信息以及验证总数而确定的。
188.在一种可能的设计中，对比数据包括下一次验证的标准输入值以及本次验证的标准输出值，可验证延迟函数包括可验证陷门函数，对应的，设置模块801，用于利用可验证陷门函数创建陷门秘密；利用可验证陷门函数，根据陷门秘密、初始挑战信息以及验证总数，无延迟地循环确定标准输入值以及标准输出值。
189.在一种可能的设计中，设置模块801，用于：
190.利用可验证陷门函数创建陷门秘密；
191.将初始挑战信息作为首次验证的输入值，根据可验证延迟函数、陷门秘密以及验证总数，无延迟地循环确定每一次验证的输出键值对，输出键值对包括下一次验证的标准输入值以及本次验证的标准输出值；
192.利用预设压缩算法，根据一个或多个输出键值对，确定对比数据。
193.在一种可能的设计中，设置模块801，用于：
194.当利用一个输出键值对确定对比数据时，对比数据为输出键值对的哈希值；
195.当利用多个输出键值对确定对比数据时，对比数据为输出键值对的多重哈希值，多重哈希值是由上一次哈希算法的计算结果作为本次哈希算法的输入值而计算得到的。
196.在一种可能的设计中，接收模块802，用于当在预设时间接收到预言机发送的证明交易时，执行证明交易所属的区块，以确定执行结果，执行结果包括响应信息；
197.监控模块803，用于：
198.判断响应信息与对比数据是否相匹配；
199.若是，则满足状态监控规则，若否，则不满足状态监控规则。
200.可选的，预设时间大于或等于标准时间，并且预设时间小于或等于容错时间，容错时间大于标准时间。
201.在一种可能的设计中，接收模块802，用于当在预设时间没有接收到预言机发送的证明交易时，响应信息为空，对应的，监控模块803，用于判定不满足状态监控规则。
202.在一种可能的设计中，设置模块801，还用于当根据初始挑战信息判断响应信息是否满足状态监控规则的验证次数达到验证总数时，重新向预言机合约发送监控设置交易，以重新设置状态监控规则。
203.值得说明的是，图8所示实施例提供的装置，可以执行上述任一方法实施例中所提供的方法中共识节点侧的功能，其具体实现原理、技术特征、专业名词解释以及技术效果类似，在此不再赘述。
204.图9为本技术实施例提供的另一种区块链预言机状态监控装置的结构示意图。该区块链预言机状态监控装置900可以通过软件、硬件或者两者的结合实现。
205.如图9所示，该区块链预言机状态监控装置900包括：
206.发送模块901，用于向区块链网络的共识节点发送上链请求，上链请求用于将预言机节点接入区块链网络；
207.处理模块902，用于：
208.检测到共识节点通过预言机合约执行了监控设置交易后，根据监控设置交易中的状态监控规则以及初始挑战信息连续不断地计算响应信息，状态监控规则用于通过挑战
‑
响应的方式判断预言机节点在预设时段内是否持续保持正常的在线工作状态；
209.发送模块901，还用于根据状态监控规则，在预设时刻将响应信息发送给共识节点，以使共识节点根据初始挑战信息判断响应信息是否满足状态监控规则。
210.在一种可能的设计中，处理模块902，用于：
211.根据预言机合约中的参数，构造出状态监控规则设置的可验证延迟函数；
212.利用可验证延迟函数，根据初始挑战信息，在预设时段内连续进行至少一次验证
计算，以确定每次验证的证明信息，证明信息包括本次验证的输出值以及下一次验证的输入值；
213.发送模块901，用于根据状态监控规则中的验证频率，将一次或多次验证的证明信息组合成响应信息发送给共识节点。
214.在一种可能的设计中，发送模块901，用于根据预设压缩算法，根据一次或多次验证的证明信息，确定响应信息。
215.可选的，预设压缩算法包括哈希算法，发送模块901，用于利用哈希算法，根据一次验证的证明信息，确定证明信息的哈希值，响应信息包括哈希值；
216.或者，利用哈希算法，根据多次验证的证明信息，确定证明信息的多重哈希值，多重哈希值是由上一次哈希算法的计算结果作为本次哈希算法的输入值而计算得到的，响应信息包括多重哈希值。
217.值得说明的是，图9所示实施例提供的装置，可以执行上述任一方法实施例中所提供的方法中预言机节点侧的功能，其具体实现原理、技术特征、专业名词解释以及技术效果类似，在此不再赘述。
218.图10为本技术实施例提供的一种电子设备的结构示意图。如图10所示，该电子设备1000，可以包括：至少一个处理器1001和存储器1002。图10示出的是以一个处理器为例的电子设备。
219.存储器1002，用于存放程序。具体地，程序可以包括程序代码，程序代码包括计算机操作指令。
220.存储器1002可能包含高速ram存储器，也可能还包括非易失性存储器(non
‑
volatile memory)，例如至少一个磁盘存储器。
221.处理器1001用于执行存储器1002存储的计算机执行指令，以实现以上各方法实施例所述的方法。
222.其中，处理器1001可能是一个中央处理器(central processing unit，简称为cpu)，或者是特定集成电路(application specific integrated circuit，简称为asic)，或者是被配置成实施本技术实施例的一个或多个集成电路。
223.可选地，存储器1002既可以是独立的，也可以跟处理器1001集成在一起。当所述存储器1002是独立于处理器1001之外的器件时，所述电子设备1000，还可以包括：
224.总线1003，用于连接所述处理器1001以及所述存储器1002。总线可以是工业标准体系结构(industry standard architecture，简称为isa)总线、外部设备互连(peripheral component，pci)总线或扩展工业标准体系结构(extended industry standard architecture，eisa)总线等。总线可以分为地址总线、数据总线、控制总线等，但并不表示仅有一根总线或一种类型的总线。
225.可选的，在具体实现上，如果存储器1002和处理器1001集成在一块芯片上实现，则存储器1002和处理器1001可以通过内部接口完成通信。
226.本技术实施例还提供了一种计算机可读存储介质，该计算机可读存储介质可以包括：u盘、移动硬盘、只读存储器(read
‑
only memory，rom)、随机存取存储器(random access memory，ram)、磁盘或者光盘等各种可以存储程序代码的介质，具体的，该计算机可读存储介质中存储有程序指令，程序指令用于上述各方法实施例中的方法。
227.本技术实施例还提供一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现上述各方法实施例中的方法。
228.本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本技术的其它实施方案。本技术旨在涵盖本技术的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本技术的一般性原理并包括本技术未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本技术的真正范围和精神由本技术的权利要求书指出。
229.应当理解的是，本技术并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本技术的范围仅由所附的权利要求书来限制。