CN113872828A

CN113872828A - State monitoring method for block chain prediction machine

Info

Publication number: CN113872828A
Application number: CN202111134684.0A
Authority: CN
Inventors: 吴昊; 李辉忠; 张开翔; 范瑞彬
Original assignee: WeBank Co Ltd
Current assignee: WeBank Co Ltd
Priority date: 2021-09-27
Filing date: 2021-09-27
Publication date: 2021-12-31
Anticipated expiration: 2041-09-27
Also published as: CN113872828B

Abstract

The application provides a block chain prediction machine state monitoring method, wherein a prediction machine node sends a chaining request to a common identification node of a block chain network, after receiving the chaining request, the common identification node adds a monitoring setting transaction to a prediction machine contract when the prediction machine contract is created for the prediction machine node, and the monitoring setting transaction comprises a state monitoring rule for monitoring whether the prediction machine node continuously keeps on-line work in a challenge-response mode within a period of time; after detecting that the predictive engine contract is issued, the nodes of the predictive engines execute monitoring and setting transaction, start to continuously calculate the certification information according to the state monitoring rule and the initial challenge information, then send the certification information to the consensus nodes for verification, and if the verification fails, change the state of the contract of the predictive engines into an inactive state. The technical problem that the state of the nodes of the prediction machine cannot be monitored timely and effectively in the prior art is solved.

Description

State monitoring method for block chain prediction machine

Technical Field

The application relates to the field of financial technology (Fintech), in particular to a block chain prediction machine state monitoring method.

Background

With the development of computer technology, more and more technologies are applied in the financial field, the traditional financial industry is gradually changing to financial technology (Fintech), and a Block chain (Block chain) technology is not an exception, but higher requirements are also put forward on the technology due to the requirements of the financial industry on safety and real-time performance. When the block chain network performs data interaction with the outside, the external data interface of the predictive speaker node connected with the block chain network can be called through an intelligent contract arranged on the block chain to realize the data interaction. If the node of the prediction machine or the external data interface has a problem, the blockchain cannot acquire the external data in time, and the transaction on the blockchain cannot be completed, so that the user generates corresponding loss.

In the prior art, an independent offline monitoring system is generally adopted to independently monitor the health of nodes of a prophetic machine. And pushing the log to an offline monitoring system through the nodes of the prediction machine, and analyzing the log by the offline monitoring system to judge the working state of the server of the nodes of the prediction machine.

However, in the prior art, the monitoring result of the monitoring system cannot be publicly verified on the blockchain, so that the consensus node on the blockchain still has a risk of calling the talker in an abnormal state, and whether the function of part of the talker is abnormal can be analyzed from the log only when the service request of the blockchain is received. Namely, the technical problem that the state of the nodes of the prediction machine cannot be effectively monitored in time exists in the prior art.

Disclosure of Invention

The application provides a block chain prediction machine state monitoring method, which aims to solve the technical problem that the state of a prediction machine node cannot be monitored timely and effectively in the prior art.

In a first aspect, the present application provides a method for monitoring a state of a blockchain predictor, which is applied to a consensus node of a blockchain network, and the method includes:

when a predictive phone node links a chain, adding a monitoring setting transaction in a predictive phone contract, wherein the monitoring setting transaction comprises a state monitoring rule and initial challenge information, the predictive phone contract is an intelligent contract for data interaction between a common identification node and the predictive phone node, and the state monitoring rule is used for judging whether the predictive phone node continuously keeps a normal online working state in a preset time period in a challenge-response mode;

the method comprises the steps that an uplink prediction machine contract is linked, and after monitoring setting transaction is executed, response information returned by a prediction machine node is periodically received, wherein the response information is determined by the prediction machine node according to a preset delay algorithm and initial challenge information in a state monitoring rule after operation in a preset time period;

and judging whether the response information meets the state monitoring rule or not according to the initial challenge information, and if not, updating the state of the nodes of the prediction machine into an inactive state.

According to the method and the system, the state monitoring of the nodes of the predictive speech machine is moved to the block chain network from the line down, and when the nodes of the predictive speech machine are linked, the common identification node can set a corresponding intelligent contract, namely a contract of the predictive speech machine, for the nodes of the predictive speech machine, so that the block chain network can call the nodes of the predictive speech machine to interact with external data. Monitoring setting transactions are also added to the predictive-machine contract when the predictive-machine contract is created, and state monitoring rules are added to the predictive-machine contract. The block chain network utilizes the prediction machine contract to monitor the working state of the prediction machine node on the basis of processing the transaction which is initiated by the user and needs to carry out data interaction with the outside. When the fact that the predictive machine node has a problem is monitored, the state of the predictive machine node is directly updated to be in an inactive state in the predictive machine contract.

In order to monitor whether the prediction machine works normally within a period of time, initial challenge information is sent to the prediction machine node through the prediction machine contract, whether the prediction machine node keeps a normal online working state continuously within a preset time period is judged through a challenge-response mode, and whether the prediction machine node keeps the normal working state within the preset time period can be verified through a one-time challenge-response mode.

By utilizing the new monitoring method, the technical problem that the state of the predictive phone node cannot be effectively monitored in time in the prior art is solved, and after the predictive phone node has a fault, the block chain network can discover that the predictive phone node is already in an inactive state by calling a predictive phone contract, so that the monitoring result is publicly verified on the block chain, and the technical effects of decoupling the monitoring from transaction service initiated by the block chain network and timely discovering the fault of the predictive phone node are achieved.

In a second aspect, the present application provides a method for monitoring a state of a blockchain predictor, which is applied to a predictor node, and the method includes:

sending an uplink request to a common node of the block chain network, wherein the uplink request is used for accessing the predictive speaker node into the block chain network;

after the consensus node is detected to execute the monitoring setting transaction through the language predictive machine contract, continuously calculating response information according to a state monitoring rule and initial challenge information in the monitoring setting transaction, wherein the state monitoring rule is used for judging whether the language predictive machine node continuously keeps a normal online working state in a preset time period in a challenge-response mode;

and sending the response information to the consensus node at a preset moment according to the state monitoring rule so that the consensus node judges whether the response information meets the state monitoring rule or not according to the initial challenge information.

According to the block chain prediction machine state monitoring method, after a prediction machine node submits an uplink request, it is detected that a block chain network generates a prediction machine contract, and the block chain network executes a monitoring setting transaction through the prediction machine contract, so that a state monitoring rule can be transmitted to the prediction machine node, the prediction machine node receives initial challenge information issued by the block chain network, the prediction machine node needs to continuously utilize the state monitoring rule within a preset time period in a challenge-response mode, the certification information of the challenge is determined according to the initial challenge information, and after calculation of the certification information is completed, one or more times of certification information are transmitted to a common identification node of the block chain network for verification.

Because the state monitoring rule requires that the predictive engine node continuously performs the calculation of the certification information within a preset time period, if the predictive engine node is always kept in a normal online working state, the calculation result, namely the certification information and the verification information stored in the predictive engine contract, are matched and corresponding, otherwise, the block chain network proves that the predictive engine node is in an abnormal state within the preset time period, and the block chain network changes the active state in the predictive engine contract into an inactive state, so that the block chain network cannot call the abnormal predictive engine node, and the transaction of the user is not influenced by the fault of the predictive engine node. The technical effect of publicly verifying the health state monitoring result of the prediction machine in the block chain in time is achieved.

In a third aspect, the present application provides a device for monitoring a state of a blockchain predictor, comprising:

the system comprises a setting module, a state monitoring module and a scheduling module, wherein the setting module is used for adding monitoring setting transaction in a predictive machine contract when a predictive machine node links a chain, the monitoring setting transaction comprises a state monitoring rule and initial challenge information, the predictive machine contract is an intelligent contract for performing data interaction between a common identification node and the predictive machine node, and the state monitoring rule is used for judging whether the predictive machine node continuously keeps a normal online working state in a preset time period in a challenge-response mode;

the setting module is also used for chaining the forecast contract and executing the monitoring and setting transaction;

the receiving module is used for periodically receiving response information returned by the nodes of the prediction machine, wherein the response information is determined by the nodes of the prediction machine after operation in a preset time period according to a preset delay algorithm and initial challenge information in a state monitoring rule;

and the monitoring module is used for judging whether the response information meets the state monitoring rule or not according to the initial challenge information, and if not, updating the state of the nodes of the prediction machine into an inactive state.

In a fourth aspect, the present application provides a device for monitoring the status of a blockchain predictor, comprising:

a sending module, configured to send an uplink request to a common node of a blockchain network, where the uplink request is used to access a talker node to the blockchain network;

a processing module to:

and the sending module is further used for sending the response information to the consensus node at a preset moment according to the state monitoring rule so that the consensus node judges whether the response information meets the state monitoring rule or not according to the initial challenge information.

In a fifth aspect, the present application provides an electronic device, comprising:

a memory for storing program instructions;

and the processor is used for calling and executing the program instructions in the memory to execute any one of the possible item storage information determination methods provided by the first aspect.

In a sixth aspect, the present application provides an electronic device, comprising:

a memory for storing program instructions;

and the processor is used for calling and executing the program instructions in the memory to execute any one of the possible item storage information determination methods provided by the second aspect.

In a seventh aspect, the present application provides a storage medium, where a computer program is stored in the storage medium, where the computer program is configured to execute any one of the possible blockchain predictor state monitoring methods provided in the first aspect.

In an eighth aspect, the present application provides a storage medium, where a computer program is stored in the storage medium, where the computer program is used to execute any one of the possible methods for monitoring the state of the blockchain predictor provided in the second aspect.

In a ninth aspect, the present application further provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, the computer program implements any one of the possible blockchain predictor state monitoring methods provided in the first aspect.

In a tenth aspect, the present application further provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, the computer program implements any one of the possible blockchain predictor state monitoring methods provided in the second aspect.

The application provides a block chain prediction machine state monitoring method, wherein a prediction machine node sends a chaining request to a common identification node of a block chain network, after receiving the chaining request, the common identification node adds a monitoring setting transaction to a prediction machine contract when the prediction machine contract is created for the prediction machine node, and the monitoring setting transaction comprises a state monitoring rule for monitoring whether the prediction machine node continuously keeps on-line work in a challenge-response mode within a period of time; after detecting that the predictive engine contract is issued, the nodes of the predictive engines execute monitoring and setting transaction, start to continuously calculate the certification information according to the state monitoring rule and the initial challenge information, then send the certification information to the consensus nodes for verification, and if the verification fails, change the state of the contract of the predictive engines into an inactive state. The technical problem that the state of the nodes of the prediction machine cannot be monitored timely and effectively in the prior art is solved. The monitoring result is publicly verified on the blockchain, and the technical effect that monitoring and transaction service initiated by the blockchain network are decoupled, so that the fault of the prediction machine node can be timely discovered is achieved.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and together with the description, serve to explain the principles of the application.

Fig. 1 is a schematic diagram of a block chain provided in the present application for data interaction with the outside through a prediction machine;

fig. 2 is a schematic flowchart illustrating a method for monitoring a state of a blockchain predictor provided in the present application;

FIG. 3 is a schematic diagram of a predictive phone registration transaction provided in accordance with an embodiment of the present application;

fig. 4 is a schematic flowchart of another method for monitoring a state of a blockchain predictor provided in the present application;

FIG. 5 is a schematic diagram of a monitoring setup transaction provided in an embodiment of the present application;

FIG. 6 is a schematic diagram of a predictive engine contract provided by an embodiment of the present application;

FIG. 7 is a schematic diagram of an attestation transaction provided by an embodiment of the application;

fig. 8 is a schematic structural diagram of a state monitoring apparatus for a blockchain predictor according to an embodiment of the present disclosure;

fig. 9 is a schematic structural diagram of another apparatus for monitoring a state of a blockchain predictor according to an embodiment of the present disclosure;

fig. 10 is a schematic structural diagram of an electronic device provided in the present application.

With the above figures, there are shown specific embodiments of the present application, which will be described in more detail below. These drawings and written description are not intended to limit the scope of the inventive concepts in any manner, but rather to illustrate the inventive concepts to those skilled in the art by reference to specific embodiments.

Detailed Description

In order to make the objects, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all the embodiments. All other embodiments, including but not limited to combinations of embodiments, which can be derived by a person skilled in the art from the embodiments disclosed herein without making any inventive step are within the scope of the present application.

The terms "first," "second," "third," "fourth," and the like in the description and in the claims of the present application and in the drawings described above, if any, are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used is interchangeable under appropriate circumstances such that the embodiments of the application described herein are, for example, capable of operation in sequences other than those illustrated or otherwise described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed, but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.

The following explanations are made for terms to which this application refers:

block chains: the blockchain is a brand new distributed infrastructure and computing mode which utilizes a blockchain type data structure to verify and store data, utilizes a distributed node consensus algorithm to generate and update data, utilizes a cryptographic mode to ensure the safety of data transmission and access, and utilizes an intelligent contract composed of automatic script codes to program and operate data.

And (3) consensus nodes: running a consensus algorithm in the block chain, performing consensus on the newly generated blocks, determining whether the newly generated blocks pass or not, and if the newly generated blocks pass, adding the consensus algorithm to the tail of the block chain to enable the contents of the block chain to reach a consistent node.

Intelligent contract: an intelligent contract is code that is deployed on a blockchain to perform a particular function. The identity is a mainstream intelligent contract programming language, and an intelligent contract written by the identity language is called the identity contract. When an intelligent contract is deployed on a blockchain, a contract address is generated, and a user can call the intelligent contract through the contract address. The function defined in the intelligent contract is called a contract interface, and the calling of the intelligent contract is to call a certain contract interface in the contract through a contract address.

Prophetic machine (Oracle machine): the blockchain system is a decentralized system, and in order to ensure that the blockchain data of each node in the system is consistent, it is generally necessary to avoid external data access (such as real-time exchange rate of external money market) causing inconsistency between nodes. When a user desires a blockchain to obtain external data, a predictive engine is typically used. The mechanism by which information outside the blockchain is written inside the blockchain is commonly referred to as a oracle. The intelligent contract interaction method allows the determined intelligent contract to react to the uncertain external world, is a way for the intelligent contract to interact data with the outside, and is also an interface for the block chain to interact data with the real world.

Delay Function (Delay Function): the effect of the delay function is that even in the case of multiple processors and in parallel, the result can only be obtained after a specified time.

Verifiable Delay Function (VDF): the verifiable delay function is a delay function which meets the condition of the delay function and has the effect of quick verification. I.e. it needs to run a certain number of steps at the time of computation, but the output of the function can be verified quickly. The algorithm definition of VDF is shown in equation (1):

F(x)=y，π (1)

where, π is the calculation result of VDF in this F (x) operation, also called proof, and y is the input value x of the next F (x) operation.

In order to obtain y, the node in the normal state takes t length of time, and for the abnormal node, even if the abnormal node has a plurality of Central Processing Units (CPUs) and the capability of parallel computation, the F (x) computation cannot be completed within t time, namely, the accurate y value cannot be obtained.

And by proving the value pi, anyone can quickly verify the correctness of y.

The Trapdoor Function (VTF) can be verified: the verifiable trapdoor function is one of verifiable delay functions. The difference is that the person with the trapdoor secret can calculate the result without delay. The algorithm definition of VTF can be divided into two aspects, one is that without trapdoor secret, the definition is shown in formula (1), and with trapdoor secret, the definition is shown in formula (2):

F(x，trapdoor)=y，π (2)

here, trapwood is a trap secret, and values of y and pi can be calculated without delay as long as the trap secret is input at the time of calculation. While those without trapdoor secrets can only take t length of time to complete the calculation as shown in equation (1).

The working principle of the prediction machine in the blockchain is described as follows:

taking the ChainLink of the current mainstream language predictive machine as an example, the construction and the work flow of one language predictive machine are as follows.

Fig. 1 is a schematic diagram of data interaction between a blockchain provided in the present application and the outside world through a prediction machine. As shown in fig. 1, there is a Blockchain (Blockchain) network 10, implementing a prediction machine, and first, a Contract, called a ChainLink prediction machine Contract 101(CHAINLINK-SC Contract), needs to be deployed on the Blockchain to accept an external data access request from a USER Contract (USER-SC Contract) 102. Then, a ChainLink predicting machine Node 20(ChainLink Node) needs to be deployed for monitoring the request event on the ChainLink predicting machine contract 101 and making a response, and the External Interface 30(External Application Programming Interface) for acquiring the External data acquires the requested External data and transmits the External data to uplink to return to the user contract 102. Thereby allowing the user contract 102 to effect the retrieval of external data.

The specific work flow is as follows:

(1) the user contract 102 sends a request to the ChainLink predictive engine contract 101 to retrieve external data, which is done on the chain.

(2) The ChainLink predictive engine contract records the request event.

(3) The ChainLink node 20 and Core 201(Core) accept the event and route the task to the Adapter 202 (Adapter).

(4) The ChainLink adapter 202 calls the external interface 30 to obtain the external data to be queried by the user.

(5) The ChainLink adapter 202 processes the response and passes it back to the core 201.

(6) The ChainLink core 201 reports data to the ChainLink president contract 101.

(7) The ChainLink president contract 101 aggregates the responses and passes them back to the user contract 102 as a single reply to the user contract 102.

The inventor of the present application finds that, in the above work flow, the ChainLink predictive engine node 20 and the external interface 30 are separated from the blockchain network 10, and after a problem occurs in the ChainLink predictive engine node 20 or the external interface 30, the normal operation of the blockchain or the normal uplink of the transaction may be affected, thereby causing a loss to the user.

Such as: the user contract 102 initiates an external data request that no external data is available from the prediction engine at a later time. This may cause the user to miss the appropriate transaction period, resulting in a loss. Specifically, for example, a user performs a transaction related to an exchange rate, the user regards the current exchange rate, sends a transaction to the blockchain network 10, the transaction operates the user contract 102, and accesses the ChainLink predictive engine contract 101 to obtain the exchange rate to complete the transaction, but the ChainLink predictive engine node 20 or the external interface 30 cannot provide the exchange rate information on time, so that the transaction cannot be completed successfully, and the transaction cannot be verified and linked up.

Traditional health monitoring systems usually employ log pushing and analysis. The monitoring system judges the working state of the server by analyzing the logs pushed by the server to which the nodes of the prediction machine belong. The prediction machine is used as a server, and can also be applied or carried by the health monitoring system. However, the application of this system in the blockchain prediction machine has several problems:

1. the monitoring result of the health monitoring system cannot be publicly verified on the blockchain.

2. Whether the functions of part of the prediction machines are abnormal or not can be analyzed from the logs corresponding to the service requests only when the prediction machines receive the service requests. When a service request is not made in the block chain network, it is difficult to judge whether the service of the prediction machine node is normal through the log, and the problem cannot be reported in time.

In order to solve the above problems, the inventive concept of the present application is:

to solve the problem of timely reporting whether an exception exists in a predictor node, the inventor of the application firstly thinks of using a challenge-response type verification mode. However, the conventional challenge-response authentication method can only authenticate the server state at one time, and if the authentication is frequent, the authentication method will bring a large network and computational burden to the authentication program, so that the authentication efficiency is low.

For this reason, a new challenge-response approach needs to be designed to implement: the health state monitoring of the nodes of the prediction machine in a time period can be completed by only initiating one challenge and obtaining one response, so that the network burden is greatly reduced, and the verification efficiency is improved.

And the intelligent contract of the block chain is used for managing a monitoring strategy, namely a state monitoring rule, and storing the state of the prediction machine. The proof of the prediction machine, i.e. the response to the challenge, is sent to the blockchain network via the transaction, and the state of the prediction machine is publicly verified by the intelligent contract.

And finally, when the response verification of the intelligent contract to the predicting machine fails, namely the predicting machine is found to be incapable of providing continuous and reliable service, closing the contract of the predicting machine in time and stopping the service. This can make things convenient for the user to know the situation of predicting the machine in time to prevent to predict that the machine is unusable abnormal state brings the loss for the user.

The following describes the technical solutions of the present application and how to solve the above technical problems with specific embodiments. The following several specific embodiments may be combined with each other, and details of the same or similar concepts or processes may not be repeated in some embodiments. Embodiments of the present application will be described below with reference to the accompanying drawings.

Fig. 2 is a flowchart illustrating a method for monitoring a state of a blockchain predictor according to an embodiment of the present disclosure. As shown in fig. 2, the method for monitoring the state of the blockchain predictor includes the following steps:

s201, sending an uplink request to a common node of the block chain network.

In this step, the uplink request is used to access the talker node to the blockchain network.

Specifically, the speaker node constructs a speaker registration transaction and sends the transaction to the consensus node participating in the blockchain consensus.

Fig. 3 is a schematic diagram of a dialer registration transaction according to an embodiment of the present disclosure. As shown in fig. 3, the predictive-machine registration transaction includes: timestamp, transaction submitter address From, transaction receiver address To, quantity Amount, random number Nonce, transaction type TxType, transaction Data Data, and digital Signature.

The transaction Data declares the basic functions which can be realized by the nodes of the prediction machine, and the basic functions comprise: obtaining the exchange rate GetExchangeRate, verifying the exchange rate VerifyExchangeRate and the like. It is understood that the person skilled in the art can define the basic functions of the prediction machine node in the transaction Data according to the actual needs, and the application is not limited.

S202, when the node of the prediction machine links the chain, monitoring and setting transaction is added in the prediction machine contract.

In this step, the monitoring setup transaction includes a state monitoring rule and initial challenge information, the language predictive machine contract is an intelligent contract for data interaction between the consensus node and the language predictive machine node, and the state monitoring rule is used for judging whether the language predictive machine node continuously maintains a normal online working state in a preset time period in a challenge-response manner.

In this embodiment, after receiving the talker registration transaction sent by the talker node, the consensus node verifies the talker registration transaction, packages the blocks, and additionally generates a monitoring setup transaction corresponding to the talker node to set a state monitoring rule for the talker node and an input value of a first challenge in a challenge-response manner, that is, initial challenge information.

It should be noted that, in order to solve the problem that the challenge-response method can only verify the health status of the predictive node at a certain time at a time, but cannot verify the health status for a certain period of time, the verifiable delay function is adopted as the verification tool in the embodiment. That is to say, the consensus node sends a challenge value to the predictive engine node, the predictive engine node performs operation for a duration of t as an input value of the verifiable delay function, as shown in formula (1), y and pi are obtained and fed back to the consensus node as response information, the consensus node quickly verifies whether the calculation of the predictive engine node is correct within a very short time by using the same verifiable delay function, the challenge value and y and pi, if so, the predictive engine node is proved to be in a normal online working state within the duration of t, otherwise, the predictive engine node is abnormal or failed.

In one possible design, the condition monitoring rule includes: verifying the frequency and verifiable delay function, the steps comprising:

establishing a monitoring setting transaction according to a preset transaction template;

setting in a data field of a monitoring setup transaction: verifying frequency, initial challenge information, parameters of a verifiable delay function and comparison data of each verification;

wherein the comparison data is determined based on the verifiable delay function, the initial challenge information, and the verification total.

It should be noted that the Data field is transaction Data; the verification frequency is used for defining the time between each verification; parameters of the verifiable delay function can enable the prediction machine node to construct the verifiable delay function which is the same as the common node; the comparison data means that when the book of the prediction machine is created, the consensus node calculates the standard value of each verification in advance so as to save the time required by each verification.

It should be noted that the computation time of the verification frequency and the computation time of the verifiable delay function are not necessarily the same, and there is no coupling relationship or corresponding relationship between the two, and those skilled in the art can set the two times according to actual needs, and the present application is not limited.

S203, the uplink prediction machine contract is sent, and monitoring and setting transaction is executed.

In this step, after the consensus node completes the generation of the monitoring setup transaction, the consensus node packs the monitoring setup transaction and the prediction machine registration transaction together to generate a block, and distributes the block to other consensus nodes on the block chain. And then, the block chain runs a consensus algorithm to perform consensus on the block, if the consensus is successful, the uplink publishing of the predictive machine node is completed, and a predictive machine contract capable of calling the predictive machine node is created for the block chain. The oracle contract is successfully created, i.e. represents that the oracle node successfully accesses the blockchain. The talker node may serve its basic functions for the blockchain. And meanwhile, executing monitoring setting transaction, so that the prediction machine node starts to continuously calculate the verifiable delay function in a preset time period according to the state monitoring rule set in the prediction machine contract.

And S204, continuously calculating response information according to the state monitoring rule in the monitoring setting transaction and the initial challenge information.

In this step, after the language predictive machine node detects that the consensus node executes the monitoring setting transaction through the language predictive machine contract, the language predictive machine needs to start generation of the certification information of the verifiable delay function according to the first challenge in the language predictive machine contract.

Specifically, a verifiable delay function set by a state monitoring rule is constructed according to parameters in monitoring and setting transactions;

and continuously performing at least one verification calculation within a preset time period according to the initial challenge information by using a verifiable delay function so as to determine the certification information of each verification.

The certification information includes an output value of the current verification and an input value of the next verification. As shown in formula (1), the output values y and pi of the verification are used as the input values of the next verification.

It should be noted that, for the response information, there are various embodiments, and the calculation result of the verifiable delay function may be directly used as the response information, or the calculation result of one or more times may be compressed first, and the compressed data is used as the response information, so that the data space may be saved, the data transmission speed may be increased, and the verification efficiency may be improved. In any embodiment, when the predictive engine contract is created, the standard comparison data can be stored in the predictive engine contract in the same way or a corresponding way, so that the verification time is reduced, and the verification efficiency is improved.

And S205, sending the response information to the consensus node at a preset moment according to the state monitoring rule.

In this step, the state monitoring rule sets a verification frequency, that is, a time interval of each verification, and the predictive node only needs to pack or compress all the certification information in the time interval, that is, the certification information for one or more times, into response information in a preset manner, and send the response information to the consensus node for verification.

And S206, periodically receiving response information returned by the nodes of the prediction machine.

In this step, the response information is determined by the node of the prediction machine after a preset time period of operation according to a preset delay algorithm and initial challenge information in the state monitoring rule.

And S207, judging whether the response information meets the state monitoring rule or not according to the initial challenge information.

In this step, if yes, no operation is performed, and the next verification is waited to be performed, and if no, the state of the predictive node is updated to the inactive state. Namely, the Status flag Status of the predicted machine contract is changed into InActive InActive.

The embodiment of the application provides a block chain prediction machine state monitoring method, wherein a prediction machine node sends a chaining request to a common identification node of a block chain network, after receiving the chaining request, the common identification node adds a monitoring setting transaction to a prediction machine contract when the prediction machine contract is created for the prediction machine node, and the monitoring setting transaction comprises a state monitoring rule for monitoring whether the prediction machine node continuously keeps on-line work in a challenge-response mode within a period of time; after detecting that the predictive engine contract is issued, the nodes of the predictive engines execute monitoring and setting transaction, start to continuously calculate the certification information according to the state monitoring rule and the initial challenge information, then send the certification information to the consensus nodes for verification, and if the verification fails, change the state of the contract of the predictive engines into an inactive state. The technical problem that the state of the nodes of the prediction machine cannot be monitored timely and effectively in the prior art is solved. The monitoring result is publicly verified on the blockchain, and the technical effect that monitoring and transaction service initiated by the blockchain network are decoupled, so that the fault of the prediction machine node can be timely discovered is achieved.

Fig. 4 is a schematic flowchart of another method for monitoring a state of a blockchain predictor provided in the present application. As shown in fig. 4, the method for monitoring the state of the blockchain predictor comprises the following steps:

s401, sending an uplink request to a common node of the blockchain network.

S402, when the nodes of the prediction machine are linked, a monitoring setting transaction is established according to a preset transaction template.

In this step, the monitoring setup transaction is used for setting a state monitoring rule for the predictive machine contract and the predictive machine node, the monitoring setup transaction includes the state monitoring rule and initial challenge information, the predictive machine contract is an intelligent contract for performing data interaction between the consensus node and the predictive machine node, and the state monitoring rule is used for judging whether the predictive machine node continuously maintains a normal online working state in a preset time period in a challenge-response manner.

In this embodiment, the condition monitoring rule includes: verify frequency and verifiable delay function.

Fig. 5 is a schematic diagram of a monitoring setup transaction according to an embodiment of the present application. As shown in fig. 5, monitoring setup transactions includes: timestamp, transaction submitter address From, transaction receiver address To, quantity Amount, random number Nonce, transaction type TxType, transaction Data Data, and digital Signature.

S403, setting in a data field of the monitoring setting transaction: verification frequency, initial challenge information, parameters of verifiable delay functions, and comparison data for each verification.

In this step, comparison data is determined according to the verifiable delay function, the initial challenge information, and a verification total.

As shown in fig. 5, the monitoring sets the verification frequency, i.e. the time interval VerifyRate for each verification, to be 1 hour in the Data field of the transaction, i.e. the transaction Data, as well as the initial Challenge information Challenge1, the parameters prarameters of the verifiable delay function, and the comparison Data TagList.

Optionally, the verifiable delay function includes a verifiable trapdoor function, and the generation of the contrast data may be implemented according to the following manner:

creating a trapdoor secret using a verifiable trapdoor function;

with the verifiable trapdoor function, the normal input values and the normal output values are determined without delay based on the trapdoor secret, the initial challenge information, and the verification total.

Specifically, setting the parameters of the verifiable trapdoor function so that the party who does not possess the trapdoor secret trapdoor needs to take a preset time period, such as 1 hour, to obtain the calculation result when calculating the function shown in formula (1).

The consensus node randomly generates a numerical value as initial challenge information by using a random algorithm, namely, an input value of a trapdoor function can be verified, meanwhile, a trapdoor secret is input, as shown in formula (2), calculation results y and pi can be obtained without delay or within a very short time, y is used as an input value of the next verification, the calculation of the verification result is carried out for the second time, and the steps are repeated until all verification results specified by the verification total number are calculated. For example, if 720 operations are executed, a party without trap door secret enough, namely a prophetic node, calculates for 30 days, namely one month, to obtain a certificate set Verifier { y1, pi 1, y2, pi 2, y3, pi 3,. once.y 720, pi 720 }. Since the consensus node possesses the trapdoor secret, this set of proofs is obtained without delay.

For the comparative data, this step includes various embodiments:

first, all data in the attestation set is written directly into the TagList shown in fig. 5.

Second, to save space on the blockchain, the comparison data is determined from one or more output key-value pairs (i.e., y and π) using a predetermined compression algorithm.

For example, the preset compression algorithm is a hash algorithm, and when one output key value pair is used for determining the comparison data, the comparison data is the hash value of the output key value pair;

when the comparison data is determined by using a plurality of output key value pairs, the comparison data is a multiple hash value of the output key value pairs, and the multiple hash value is calculated by taking a calculation result of the last hash algorithm as an input value of the current hash algorithm.

For example, Hash (y1, π 1), or Hash (y1, π 1)), or Hash (y1, π 1), Hash (y2, π 2)), etc., is stored as the contrast data in the tagList. It should be noted that, those skilled in the art can select an appropriate compression algorithm according to the needs of the actual application scenario, and the method is not limited herein.

S404, the uplink prediction machine contract and the monitoring and setting transaction are executed.

Fig. 6 is a schematic diagram of a predictive engine contract according to an embodiment of the present application. As shown in fig. 6, a predictive engine contract comprises: the name OracleName of the predicting machine, the Address of the contract, the Owner of the contract, initialization time InitTime, Function, Status identification Status, initial Challenge information Challenge1, verification frequency VerifyRate, parameters prarameters, comparison data TagList, latest certification information LatestProof, and the like.

The latest certification information LatestProof is updated when the verification is passed each time, the state identification Status represents the verification result, if the verification is not passed, the Status is in an inactive state, and if the verification is passed, the Status is in an active state, when the node is in the active state, the node of the predictive speaker can be normally called, and when the node is in the inactive state, the node of the predictive speaker cannot be called.

S405, according to parameters in the prediction machine contract, a verifiable delay function set by the state monitoring rule is constructed.

In this step, after the predicting machine node detects that the consensus node executes the monitoring setting transaction through the predicting machine contract, specifically, the predicting machine node constructs the verifiable delay function f (x) ═ y, pi through the parameters in the predicting machine contract.

S406, continuously performing at least one verification calculation within a preset time period by using a verifiable delay function according to the initial challenge information to determine the certification information of each verification.

In this step, the certification information includes an output value of the present verification and an input value of the next verification.

Specifically, Challenge1 in fig. 6 is used as an input value x of the verifiable delay function f (x) to calculate the proof of the first Challenge. After a preset duration (which is set by the parameters of the verifiable delay function), y1, π 1 is calculated. One proof calculation is completed. Then, with y1 as the input value of the next verification, the calculation of the proof is continued until all verified proof information is completed.

Optionally, after the certification calculation is completed each time, response information is immediately generated according to the certification information and fed back to the blockchain network.

Optionally, after the preset number of times of certification calculation is completed, combining a plurality of pieces of calculated certification information into response information and feeding back the response information to the block chain network.

And S407, combining the certification information verified for one or more times into response information according to the verification frequency in the state monitoring rule, and sending the response information to the consensus node.

In this step, the certification information may be directly sent to the consensus node, or the response information may be determined according to the certification information verified once or multiple times according to a preset compression algorithm. That is, the certification information may be compressed once or more times and then transmitted to the common node.

Specifically, a hash value of the certification information is determined according to the certification information verified at one time by using a hash algorithm, and the response information comprises the hash value;

or,

and determining multiple hash values of the certification information according to the certification information verified for multiple times by using a hash algorithm, wherein the multiple hash values are calculated by taking the calculation result of the last hash algorithm as the input value of the hash algorithm, and the response information comprises the multiple hash values.

It should be noted that, in the present embodiment, the response message is sent to the blockchain network in the form of a proof transaction.

And S408, periodically receiving response information returned by the nodes of the prediction machine.

In this step, when receiving the certification transaction sent by the prediction machine at a preset time, executing a block to which the certification transaction belongs to determine an execution result, wherein the execution result comprises response information; and when the certification transaction sent by the predictive phone is not received in the preset time, the response information is null, and correspondingly, the state monitoring rule is not satisfied.

Fig. 7 is a schematic diagram of an attestation transaction provided by an embodiment of the present application. As shown in fig. 7, certifying the transaction includes: timestamp, transaction submitter address From, transaction receiver address To, quantity Amount, random number Nonce, transaction type TxType, transaction Data Data, and digital Signature.

Wherein, the transaction Data includes: challenge number TagNumber, response information TagOrigin, etc.

In one possible design, the preset time is greater than or equal to the standard time, and the preset time is less than or equal to the fault-tolerant time, which is greater than the standard time. The standard time is a time interval corresponding to the verification frequency, such as 1 hour, and the fault tolerance time is an operable deviation time, such as 15-30 minutes after the standard time. It should be noted that the deviation time must be before the next standard time.

And S409, judging whether the response information meets the state monitoring rule or not according to the initial challenge information.

In the step, when receiving the certification transaction sent by the prediction machine at the preset time, judging whether the response information is matched with the comparison data; if yes, the state monitoring rule is satisfied, and if not, the state monitoring rule is not satisfied.

For example, if the prediction engine remains available, a trapdoor function f (x) y, pi may be constructed according to its parameters, and the Challenge in Challenge1 is calculated as x. And calculating 720 times in succession, wherein each challenge is the y value calculated by the last challenge, and all the results are Prover { y1, pi 1, y2, pi 2, y3, pi 3,. eta.. y720, pi 720}, if the consensus node can be verified successfully in F (x) -y, pi by using Verifier { y1, y2, y3,. eta.. y720} and Prover { pi 1, pi 2, pi 3,. eta.,. pi 720}, or if Verifier { y1, pi 1, y2, pi 2, y3, pi 3,. eta.. y720, pi 720} and Prover { y1, pi 1, y2, pi 2, y3, pi 3,. eta.. 720,. pi } can be matched, the result proves that the online work state of the machine node is kept in the online working state within the preset working period.

Optionally, after receiving the certification transaction, the consensus node verifies the certification transaction. As shown in fig. 7, the verification point includes: whether the To address is the correct address of the talker node; whether the From address is the same as an owner (owner) address of the predictive machine contract; whether the digital signature is correct, etc.; if the verification is successful, the transaction is certified to be packaged and linked.

After completing this certification transaction, the propheter node takes the calculated y1 value as input for computing a second certification and continues the certification computation until the cycle completes the verification total, e.g., 720 rounds of challenge-response verification.

And when the certification transaction sent by the predictive phone is not received in the preset time, if the response information is null, the state monitoring rule is not satisfied.

In one possible design, the response information includes a result of each calculation by the predictor node using the verifiable delay function, the result including: the output value of the verification and the input value of the next verification, namely the prediction machine node directly sends the calculation result to the block chain network, and at the moment, the consensus node respectively compares the output value with the standard output value and the input value with the standard input value; and if the two comparison results are consistent, the state monitoring rule is satisfied, otherwise, the state monitoring rule is not satisfied.

In another possible design, the response information includes compression data determined by the prediction machine node according to one or more results calculated by the verifiable trapdoor function by using a preset compression algorithm, and at this time, the common identification node compares the compression data with the comparison data; if the comparison result is consistent, the state monitoring rule is satisfied, otherwise, the state monitoring rule is not satisfied. It should be noted that, in this case, the comparison data is also a value compressed by the same compression algorithm, for example, when the consensus node creates the prediction machine contract, in order to save space on the blockchain, only the Hash value Hash (y1, pi 1)) of y1, pi 1 is used, and we refer to this value as Tag, if the prover, i.e., the prediction machine node, can provide the original image of the Hash, i.e., Hash (y1, pi 1). It can also be shown that the proof information Prover does produce a proof result for the pair. The verifier, i.e., the common identification node, generates these tags and stores them in the TagList shown in fig. 5 and 6.

It should be noted that, for the first challenge, when executing the block corresponding to the certification transaction, the consensus node of the block chain verifies whether the hash (tagorigin) in the certification transaction matches the first Tag in the TagList in the intelligent contract, i.e. the language prediction machine contract, and if the hash (tagorigin) matches the first Tag in the TagList in the language prediction machine contract, the language prediction machine is proved to be continuously providing the service for a period of time in the past, e.g. 1 hour. The lastproof in the prediction engine contract as shown in figure 6 is updated. And, the value in the lastproof is updated later every time the verification passes, so that the identification is the verification for the second time.

If the attestation transaction is executed, it is found that the hash (tagorigin) in the attestation transaction does not match the first Tag in the TagList in the smart contract, i.e. the president contract. The prediction machine does not provide continuous service for a past period of time, such as 1 hour. And updating information in the prediction machine contract shown in the figure 6, changing the state identification (Status) into an Inactive InActive state, and closing the prediction machine node.

In one possible design, when it is determined whether the response information satisfies the status monitoring rule according to the initial challenge information that the number of verifications reaches the total number of verifications, the monitoring setting transaction is resent to the pre-senter contract to reset the status monitoring rule.

Specifically, if the prediction engine exceeds 1.5 hours (1 hour standard time +0.5 hour fault tolerance time, which may be set) and does not send a certification transaction, it may be considered that the prediction engine does not provide continuous service, and when the blockchain executes to a block 1.5 hours away from the contract InitTime, the contract state is changed to InActive.

If the 720 (30 days) tags are used up, the consensus node of the blockchain can send the monitoring setup transaction (Oracle _ Monitor _ Setting) again to reset the status monitoring rule.

Through the method, the health monitoring of the nodes of the prediction machine is carried out. And observing whether the service is continuously provided or not, and setting the state to Inactive for the prediction machine with abnormal work. The calling by the user is prevented, and therefore loss is brought to the user.

Fig. 8 is a schematic structural diagram of a device for monitoring a state of a blockchain predictor according to an embodiment of the present disclosure. The blockchain predictor state monitoring apparatus 800 may be implemented by software, hardware, or a combination of both.

As shown in fig. 8, the apparatus 800 for monitoring the state of the blockchain predictor comprises:

the setting module 801 is configured to add a monitoring setup transaction in a predictive engine contract when a predictive engine node links a chain, where the monitoring setup transaction includes a state monitoring rule and initial challenge information, the predictive engine contract is an intelligent contract in which a common identification node and the predictive engine node perform data interaction, and the state monitoring rule is used to determine whether the predictive engine node continuously maintains a normal online working state in a preset time period in a challenge-response manner;

the setting module 801 is further configured to link the forecast contract and perform monitoring and setting transaction;

a receiving module 802, configured to periodically receive response information returned by the node of the predictive speaker, where the response information is determined by the node of the predictive speaker after operation of a preset time period according to a preset delay algorithm and initial challenge information in the state monitoring rule;

and the monitoring module 803 is configured to determine whether the response information satisfies a state monitoring rule according to the initial challenge information, and if not, update the state of the talker node to an inactive state.

In one possible design, the condition monitoring rule includes: a verification frequency and verifiable delay function, a setting module 801 for creating a monitoring setting transaction according to a preset transaction template; setting in a data field of a monitoring setup transaction: verifying frequency, initial challenge information, parameters of a verifiable delay function and comparison data of each verification;

In one possible design, the comparison data includes a standard input value for the next verification and a standard output value for the current verification, and the verifiable delay function includes a verifiable trapdoor function, and correspondingly, the setting module 801 is configured to create a trapdoor secret using the verifiable trapdoor function; with the verifiable trapdoor function, the normal input values and the normal output values are determined without delay based on the trapdoor secret, the initial challenge information, and the verification total.

In one possible design, a module 801 is provided for:

creating a trapdoor secret using a verifiable trapdoor function;

taking the initial challenge information as an input value for first verification, and circularly determining an output key value pair for each verification without delay according to a verifiable delay function, a trapdoor secret and a verification total number, wherein the output key value pair comprises a standard input value for next verification and a standard output value for the verification;

the comparison data is determined from the one or more output key-value pairs using a predetermined compression algorithm.

In one possible design, a module 801 is provided for:

when determining the comparison data by utilizing one output key value pair, the comparison data is the hash value of the output key value pair;

In one possible design, the receiving module 802 is configured to, when receiving the certification transaction sent by the predicting machine at a preset time, execute a block to which the certification transaction belongs to determine an execution result, where the execution result includes response information;

a monitoring module 803, configured to:

judging whether the response information is matched with the comparison data;

if yes, the state monitoring rule is satisfied, and if not, the state monitoring rule is not satisfied.

Optionally, the preset time is greater than or equal to the standard time, and the preset time is less than or equal to the fault-tolerant time, and the fault-tolerant time is greater than the standard time.

In one possible design, the receiving module 802 is configured to, when the certification transaction sent by the prediction engine is not received at the preset time, send a response message to be null, and correspondingly, the monitoring module 803 is configured to determine that the status monitoring rule is not satisfied.

In one possible design, the setting module 801 is further configured to send a monitoring setting transaction to the pre-senter contract again to reset the status monitoring rule when the number of times of verification that the response information satisfies the status monitoring rule is determined to reach the total verification number according to the initial challenge information.

It should be noted that the apparatus provided in the embodiment shown in fig. 8 can perform the function of the consensus node side in the method provided in any of the above method embodiments, and the specific implementation principle, technical features, technical noun explanations, and technical effects thereof are similar and will not be described again here.

Fig. 9 is a schematic structural diagram of another apparatus for monitoring a state of a blockchain predictor according to an embodiment of the present disclosure. The blockchain predictor state monitoring apparatus 900 can be implemented by software, hardware or a combination of both.

As shown in fig. 9, the apparatus 900 for monitoring the state of the blockchain predictor comprises:

a sending module 901, configured to send an uplink request to a common node of a blockchain network, where the uplink request is used to access a talker node to the blockchain network;

a processing module 902 configured to:

the sending module 901 is further configured to send the response information to the consensus node at a preset time according to the state monitoring rule, so that the consensus node determines whether the response information meets the state monitoring rule according to the initial challenge information.

In one possible design, the processing module 902 is configured to:

constructing a verifiable delay function set by a state monitoring rule according to parameters in the prediction machine contract;

continuously performing at least one verification calculation within a preset time period according to the initial challenge information by using a verifiable delay function to determine the certification information of each verification, wherein the certification information comprises an output value of the verification and an input value of the next verification;

a sending module 901, configured to combine the certification information verified once or multiple times into response information according to the verification frequency in the status monitoring rule, and send the response information to the consensus node.

In one possible design, the sending module 901 is configured to determine the response information according to a preset compression algorithm and according to the certification information verified once or multiple times.

Optionally, the preset compression algorithm includes a hash algorithm, and the sending module 901 is configured to determine, by using the hash algorithm, a hash value of the certification information according to the certification information verified at one time, where the response information includes the hash value;

or, determining multiple hash values of the certification information according to the certification information verified for multiple times by using a hash algorithm, wherein the multiple hash values are calculated by taking the calculation result of the last hash algorithm as the input value of the hash algorithm, and the response information comprises the multiple hash values.

It should be noted that the apparatus provided in the embodiment shown in fig. 9 can execute the function of the node side of the prediction machine in the method provided in any of the above method embodiments, and the specific implementation principle, technical features, technical noun explanation and technical effects thereof are similar and will not be described again here.

Fig. 10 is a schematic structural diagram of an electronic device according to an embodiment of the present application. As shown in fig. 10, the electronic device 1000 may include: at least one processor 1001 and memory 1002. Fig. 10 shows an electronic device as an example of a processor.

The memory 1002 stores programs. In particular, the program may include program code including computer operating instructions.

The memory 1002 may comprise high-speed RAM memory, and may also include non-volatile memory (non-volatile memory), such as at least one disk memory.

The processor 1001 is configured to execute computer-executable instructions stored by the memory 1002 to implement the methods described in the method embodiments above.

The processor 1001 may be a Central Processing Unit (CPU), an Application Specific Integrated Circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present application.

Alternatively, the memory 1002 may be separate or integrated with the processor 1001. When the memory 1002 is a device independent of the processor 1001, the electronic device 1000 may further include:

a bus 1003 is used to connect the processor 1001 and the memory 1002. The bus may be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, an Extended ISA (EISA) bus, or the like. Buses may be classified as address buses, data buses, control buses, etc., but do not represent only one bus or type of bus.

Alternatively, in a specific implementation, if the memory 1002 and the processor 1001 are integrated into a chip, the memory 1002 and the processor 1001 may communicate via an internal interface.

An embodiment of the present application further provides a computer-readable storage medium, where the computer-readable storage medium may include: various media that can store program codes, such as a usb disk, a removable hard disk, a read-only memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and in particular, the computer-readable storage medium stores program instructions for the methods in the above method embodiments.

An embodiment of the present application further provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, the computer program implements the method in the foregoing method embodiments.

Other embodiments of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the invention following, in general, the principles of the application and including such departures from the present disclosure as come within known or customary practice within the art to which the invention pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the application being indicated by the following claims.

It will be understood that the present application is not limited to the precise arrangements described above and shown in the drawings and that various modifications and changes may be made without departing from the scope thereof. The scope of the application is limited only by the appended claims.

Claims

1. A method for monitoring the state of a blockchain predictor is applied to a consensus node of a blockchain network, and comprises the following steps:

when a prophetic machine node links a chain, adding a monitoring setting transaction in a prophetic machine contract, wherein the monitoring setting transaction comprises a state monitoring rule and initial challenge information, the prophetic machine contract is an intelligent contract for performing data interaction between the common identification node and the prophetic machine node, and the state monitoring rule is used for judging whether the prophetic machine node continuously keeps a normal online working state in a preset time period in a challenge-response mode;

linking the prophetic contract, and periodically receiving response information returned by a prophetic node after executing the monitoring setting transaction, wherein the response information is determined by the prophetic node after the operation of a preset time period according to a preset delay algorithm and the initial challenge information in the state monitoring rule;

2. The blockchain predictor state monitoring method of claim 1, wherein the state monitoring rules comprise: verifying frequency and verifiable delay function, adding monitoring setup transaction in the predictive phone contract when uplink is carried out on the predictive phone node, comprising:

creating the monitoring setting transaction according to a preset transaction template;

setting in a data field of the monitoring setup transaction: the verification frequency, the initial challenge information, parameters of the verifiable delay function, and comparison data for each verification;

wherein the comparison data is determined according to the verifiable delay function, the initial challenge information, and a verification total.

3. The blockchain predictive machine state monitoring method according to claim 2, wherein the comparison data includes a standard input value for a next verification and a standard output value for a current verification, the verifiable delay function includes a verifiable trapdoor function, and the setting the comparison data in the data field of the monitoring setup transaction includes:

creating a trapdoor secret using a verifiable trapdoor function;

determining the standard input value and the standard output value in a loop without delay based on the trapdoor secret, the initial challenge information, and the verification total using the verifiable trapdoor function.

4. The blockchain predictor state monitoring method of claim 2, wherein the setting the comparison data in the data field of the monitoring setting transaction comprises:

creating a trapdoor secret using a verifiable trapdoor function;

taking the initial challenge information as an input value of first verification, and circularly determining an output key value pair of each verification without delay according to the verifiable delay function, the trapdoor secret and the verification total number, wherein the output key value pair comprises a standard input value of next verification and a standard output value of the verification;

and determining the comparison data according to one or more output key value pairs by using a preset compression algorithm.

5. The method according to claim 4, wherein the predetermined compression algorithm is a hash algorithm, and correspondingly, the determining the comparison data according to one or more output key-value pairs by using the predetermined compression algorithm comprises:

when the comparison data is determined by using one output key-value pair, the comparison data is the hash value of the output key-value pair;

when the comparison data is determined by using a plurality of output key value pairs, the comparison data is a multiple hash value of the output key value pairs, and the multiple hash value is calculated by taking a calculation result of a last hash algorithm as an input value of the current hash algorithm.

6. The method for monitoring the state of a blockchain predictor according to claim 2, wherein the periodically receiving response information returned by the predictor node comprises:

when receiving the certification transaction sent by the language predicting machine at preset time, executing a block to which the certification transaction belongs to determine an execution result, wherein the execution result comprises the response information;

correspondingly, the determining whether the response information satisfies the status monitoring rule according to the initial challenge information includes:

judging whether the response information is matched with the comparison data;

7. The method as claimed in claim 6, wherein the predetermined time is greater than or equal to a standard time, and the predetermined time is less than or equal to a fault-tolerant time, and the fault-tolerant time is greater than the standard time.

8. The method of claim 2, further comprising:

and when the verification times of judging whether the response information meets the state monitoring rule according to the initial challenge information reach the verification total number, re-sending the monitoring setting transaction to the prompter contract so as to re-set the state monitoring rule.

9. A block chain prediction machine state monitoring method is applied to a prediction machine node, and comprises the following steps:

sending an uplink request to a common node of a blockchain network, wherein the uplink request is used for accessing the prophone node into the blockchain network;

after the fact that the consensus node executes the monitoring setting transaction through the language predictive machine contract is detected, response information is continuously calculated according to a state monitoring rule and initial challenge information in the monitoring setting transaction, wherein the state monitoring rule is used for judging whether the language predictive machine node continuously keeps a normal online working state in a preset time period in a challenge-response mode;

10. The blockchain predictor state monitoring method of claim 9, wherein continuously calculating response information according to the state monitoring rules in the monitoring setting transaction and initial challenge information comprises:

according to parameters in the prediction machine contract, a verifiable delay function set by the state monitoring rule is constructed;

continuously performing at least one verification calculation within the preset time period according to the initial challenge information by using the verifiable delay function to determine the certification information of each verification, wherein the certification information comprises an output value of the verification and an input value of the next verification;

the sending the response information to the consensus node at a preset time according to the state monitoring rule includes:

and combining the certification information verified for one time or multiple times into the response information according to the verification frequency in the state monitoring rule, and sending the response information to the consensus node.

11. The method as claimed in claim 10, wherein said combining the one or more verified certification messages into the response message and sending the response message to the consensus node comprises:

and determining the response information according to the certification information verified for one or more times according to a preset compression algorithm.

12. The method according to claim 11, wherein the predetermined compression algorithm comprises a hash algorithm, and the determining the response information according to the predetermined compression algorithm from the certification information verified one or more times comprises:

determining a hash value of the certification information according to the certification information verified at one time by using the hash algorithm, wherein the response information comprises the hash value;

or,

and determining a multiple hash value of the certification information according to the certification information verified for multiple times by using the hash algorithm, wherein the multiple hash value is calculated by taking a calculation result of the last hash algorithm as an input value of the hash algorithm, and the response information comprises the multiple hash value.