Blockchain-based data acquisition method, device, equipment, medium and product

Abstract

Embodiments of the present application disclose a blockchain-based data acquisition method, device, equipment, medium and product. The method comprises: an execution node determining an external data source through a data acquisition event triggered by a business party, obtaining a data acquisition result according to external data acquired from the external data source, and then generating a verification request; a verification node verifying the data acquisition result through the verification request, and then generating a chain-up evidence based on a signature triggered by the verification node when the verification is passed, and sending the chain-up evidence to the business party through a blockchain network. The technical solution of the embodiments of the present application reduces the cost of data acquisition outside the blockchain, and ensures the authenticity of the acquired data outside the blockchain.

Description

Technical Field

[0001] This application relates to the fields of computer and communication technology, and more specifically, to a blockchain-based data acquisition method, a blockchain-based data acquisition device, a blockchain-based data verification device, an electronic device, a computer-readable storage medium, and a computer program product. Background Technology

[0002] In related technologies, business users obtain data outside the blockchain by deploying multiple data capture nodes to capture data and sending it directly to the blockchain. After processing by contracts on the blockchain, the data is then delivered to the business users. However, if there are changes to the processing logic, the contracts on the blockchain need to be replaced. Furthermore, the authenticity of the data obtained in these technologies cannot be guaranteed, resulting in high costs for obtaining data outside the blockchain and an inability to guarantee the authenticity of the data. Summary of the Invention

[0003] To address the aforementioned technical problems, embodiments of this application provide a blockchain-based data acquisition method, a blockchain-based data acquisition device, a blockchain-based data verification device, an electronic device, a computer-readable storage medium, and a computer program product, which reduce the cost of acquiring data outside the blockchain and ensure the authenticity of data outside the blockchain.

[0004] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0005] According to one aspect of the embodiments of this application, a blockchain-based data acquisition method is provided, comprising: detecting a data acquisition event triggered by a business party, and determining an external data source based on the data acquisition event; obtaining a data acquisition result based on external data acquired from the external data source; generating a verification request for the data acquisition result based on the data acquisition result, and sending the verification request to a verification node so that the verification node verifies the data acquisition result contained in the verification request; receiving a signature triggered by the verification node when the data acquisition result is successfully verified; generating on-chain evidence based on the signature of the verification node and the data acquisition result, and sending the on-chain evidence to a blockchain network so as to send the on-chain evidence to the business party through the blockchain network.

[0006] According to one aspect of the embodiments of this application, a blockchain-based data acquisition method is also provided, comprising: receiving a verification request from an execution node; the verification request carrying a data acquisition result obtained by the execution node based on acquired external data, wherein the external data is obtained by the execution node from the external data source after detecting a data acquisition event triggered by a business party and determining an external data source based on the data acquisition event; verifying the data acquisition result contained in the verification request; if the verification of the data acquisition result is successful, signing the data acquisition result; sending the signature to the execution node, so that the execution node generates on-chain evidence based on the signature and the data acquisition result, and sends the on-chain evidence to the business party through a blockchain network.

[0007] According to one aspect of the embodiments of this application, a data acquisition apparatus is provided, the apparatus comprising: a detection and acquisition module, configured to detect a data acquisition event triggered by a business party, and determine an external data source based on the data acquisition event; and obtain a data acquisition result based on external data acquired from the external data source; a generation and sending module, configured to generate a verification request for the data acquisition result based on the data acquisition result, and send the verification request to a verification node so that the verification node verifies the data acquisition result contained in the verification request; a first receiving module, configured to receive a signature triggered by the verification node when the data acquisition result is successfully verified; the generation and sending module is further configured to: generate on-chain evidence based on the signature of the verification node and the data acquisition result, and send the on-chain evidence to a blockchain network so that the on-chain evidence is sent to the business party through the blockchain network.

[0008] In one embodiment of this application, the data acquisition event includes a target execution node identifier and a data acquisition request; the detection and acquisition module includes an acquisition unit, which is configured to determine the external data source according to the data acquisition request if it is determined that the local node identifier matches the target execution node identifier in the data acquisition event, and acquire the corresponding external data from the determined external data source; and generate the data acquisition result according to the external data and the local node identifier.

[0009] In one embodiment of this application, the data acquisition event includes a list of verification nodes, which includes at least two specified verification node identifiers; the generation and sending module includes a sending unit, which is used to send the verification request to a verification node in the verification node cluster that matches the at least two specified verification node identifiers.

[0010] In one embodiment of this application, the data acquisition event includes the number of verification nodes, and the number of verification nodes is at least two; the generation and sending module includes a sending unit, which is used to select a verification node from the verification node cluster that matches the number of verification nodes, and send the verification request to the selected verification node.

[0011] In one embodiment of this application, the data acquisition event includes the number of verification nodes, and the number of verification nodes is at least two; the generation and sending module includes a sending unit, which is used to send the number of verification nodes and the verification request to the node allocator, so that the node allocator selects a verification node from the verification node cluster that matches the number of verification nodes, and forwards the verification request to the selected verification node.

[0012] In one embodiment of this application, the generation and sending module includes a generation unit, which is used to encapsulate the signature of the verification node and the data acquisition result if the number of received signatures exceeds a preset number threshold, and then sign the encapsulated data to obtain the on-chain evidence.

[0013] In one embodiment of this application, the apparatus further includes a first deployment module, which is configured to receive a service acquisition deployment request sent by the business party. The service acquisition deployment request carries a data acquisition service identifier and a list of execution node identifiers to be deployed. If the list of execution node identifiers to be deployed includes a local node identifier, then the data acquisition service corresponding to the data acquisition service identifier is deployed. The data acquisition service is used to acquire external data.

[0014] In one embodiment of this application, the apparatus further includes a first staking module. The first staking module is used by the first deployment module to pledge virtual resources to a virtual resource processor when deploying a data acquisition service corresponding to the data acquisition service identifier, so that the virtual resource processor sends the pledged virtual resources to the blockchain network for storage. If it is necessary to cancel the deployed data acquisition service, the module applies to the virtual resource processor for the return of the pledged virtual resources, so that other execution nodes can challenge the execution process of the local data acquisition service. If other execution nodes fail to successfully challenge within the challenge period, the module receives the virtual resources returned by the virtual resource processor through the blockchain network.

[0015] In one embodiment of this application, the generation and sending module includes a sending unit, which is used to deploy an evidence contract in the blockchain network if no deployed evidence contract is found in the blockchain network; and to send the on-chain evidence to the evidence contract in the blockchain network if a deployed evidence contract is stored in the blockchain network, so that the evidence contract stores the on-chain evidence, and sends the on-chain evidence to the business party according to the callback information of the business party.

[0016] In one embodiment of this application, the generation and sending module includes a generation unit, which is used to sign the data acquisition result and encapsulate the signature and the data acquisition result to generate the verification request.

[0017] According to one aspect of the embodiments of this application, a data verification apparatus is provided, the apparatus comprising: a second receiving module, configured to receive a verification request from an execution node; the verification request carrying an execution result obtained by the execution node based on acquired external data, the external data being obtained by the execution node from the external data source after detecting a data acquisition event triggered by a business party and determining an external data source based on the data acquisition event; a verification module, configured to verify the data acquisition result carried in the verification request; a signature module, configured to sign the data acquisition result if the verification of the data acquisition result is successful; and a sending module, configured to send the signature to the execution node, so that the execution node generates on-chain evidence based on the signature and the data acquisition result, and sends the on-chain evidence to the business party through a blockchain network.

[0018] In one embodiment of this application, the second receiving module is specifically used to receive a verification request sent by the execution node; or to receive a verification request forwarded by the node allocator from the execution node, wherein the verification request is forwarded by the node allocator after selecting the corresponding verification node according to the verification request after receiving the verification request sent by the execution node.

[0019] In one embodiment of this application, the apparatus further includes a second deployment module, which is configured to receive a verification service deployment request sent by a business party. The verification service deployment request carries a verification service identifier and a list of verification node identifiers to be deployed. If the list of verification node identifiers to be deployed includes a local node identifier, a data verification service corresponding to the verification service identifier is deployed. The data verification service is used to verify the data acquisition result contained in the verification request.

[0020] In one embodiment of this application, the apparatus further includes a second staking module. The second staking module is used by the second deployment module to pledge virtual resources to the virtual resource processor when deploying a data verification service corresponding to the data verification service identifier, so that the virtual resource processor sends the pledged virtual resources to the blockchain network for storage. If it is necessary to cancel the deployed data verification service, the module applies to the virtual resource processor for the return of the pledged virtual resources, so that other verification nodes can challenge the execution process of the local data verification service. If other verification nodes fail to successfully challenge within the challenge period, the module receives the virtual resources returned by the virtual resource processor through the blockchain network.

[0021] In one embodiment of this application, the verification module is specifically used to obtain external verification data based on the verification request, and to verify the data acquisition result contained in the verification request based on the external verification data.

[0022] According to one aspect of the embodiments of this application, an electronic device is provided, including one or more processors; and a storage device for storing one or more computer programs, which, when executed by the one or more processors, cause the electronic device to implement the blockchain-based data acquisition method as described above.

[0023] According to one aspect of the embodiments of this application, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor of an electronic device, causes the electronic device to perform the blockchain-based data acquisition method as described above.

[0024] According to one aspect of the embodiments of this application, a computer program product is provided, including a computer program stored in a computer-readable storage medium, wherein a processor of an electronic device reads from the computer-readable storage medium and executes the computer program, causing the electronic device to perform the blockchain-based data acquisition method as described above.

[0025] In the technical solution provided by the embodiments of this application, the execution node determines the external data source through the data acquisition event triggered by the business party, obtains the data acquisition result based on the external data obtained from the external data source, and then generates a verification request; the verification node verifies the data acquisition result through the verification request, and then the execution node generates on-chain evidence based on the signature triggered when the verification node passes the verification and the data acquisition result, thereby sending the on-chain evidence to the business party through the blockchain network; in this way, external data is acquired off-chain through the execution node and verified by the verification node, ensuring the authenticity of the data, and the accuracy of the data is ensured by verifying the data acquisition result. At the same time, compared with the data acquisition scheme of processing logic through contracts on the blockchain in related technologies, the technical solution provided by the embodiments of this application uses off-chain execution nodes and verification nodes to process data. Even if the processing logic is modified, it will not affect the contract on the blockchain network, resulting in low coupling and reducing the cost of data acquisition outside the blockchain.

[0026] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0027] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort. In the drawings:

[0028] Figure 1 This is a schematic diagram of the blockchain network structure;

[0029] Figure 2 This is a diagram illustrating the connection relationships between blocks in a blockchain.

[0030] Figure 3 This is a schematic diagram of one implementation environment involved in this application;

[0031] Figure 4 This is a flowchart illustrating a blockchain-based data acquisition method as an exemplary embodiment of this application;

[0032] Figure 5 This is a flowchart illustrating another blockchain-based data acquisition method, as shown in an exemplary embodiment of this application;

[0033] Figure 6 This is a flowchart illustrating another blockchain-based data acquisition method in an exemplary embodiment of this application;

[0034] Figure 7 This is a flowchart illustrating another blockchain-based data acquisition method in an exemplary embodiment of this application;

[0035] Figure 8 This is a flowchart illustrating another blockchain-based data acquisition method in an exemplary embodiment of this application;

[0036] Figure 9 This is a flowchart illustrating another blockchain-based data acquisition method in an exemplary embodiment of this application;

[0037] Figure 10 This is a flowchart illustrating another blockchain-based data acquisition method in an exemplary embodiment of this application;

[0038] Figure 11 This is a flowchart illustrating another blockchain-based data acquisition method in an exemplary embodiment of this application;

[0039] Figure 12 This is a flowchart illustrating another blockchain-based data acquisition method in an exemplary embodiment of this application;

[0040] Figure 13 This is a flowchart illustrating another blockchain-based data acquisition method in an exemplary embodiment of this application;

[0041] Figure 14 This is a flowchart illustrating a blockchain-based data acquisition method, as shown in another exemplary embodiment of this application.

[0042] Figure 15 This is a flowchart illustrating another exemplary embodiment of the present application, showing another blockchain-based data acquisition method;

[0043] Figure 16 This is a flowchart illustrating another exemplary embodiment of the present application, showing another blockchain-based data acquisition method;

[0044] Figure 17 This is a flowchart illustrating another exemplary embodiment of the present application, showing another blockchain-based data acquisition method;

[0045] Figure 18 This is a flowchart illustrating another exemplary embodiment of the present application, showing another blockchain-based data acquisition method;

[0046] Figure 19 This is a flowchart illustrating another exemplary embodiment of the present application, showing another blockchain-based data acquisition method;

[0047] Figure 20This is a flowchart illustrating a blockchain-based data acquisition method based on an oracle network and a blockchain network, as shown in another exemplary embodiment of this application.

[0048] Figure 21 This is a flowchart illustrating the workflow of a node in an oracle network, as shown in yet another exemplary embodiment of this application.

[0049] Figure 22 This is a structural block diagram illustrating a blockchain-based data acquisition device in an exemplary embodiment of this application;

[0050] Figure 23 This is a structural block diagram of a blockchain-based data verification device illustrated in an exemplary embodiment of this application;

[0051] Figure 24 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown. Detailed Implementation

[0052] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0053] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0054] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0055] It should also be noted that "multiple" as mentioned in this application refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0056] The technical solutions of the embodiments of this application relate to the field of blockchain technology. Before introducing the technical solutions of the embodiments of this application, blockchain technology will be briefly introduced first.

[0057] Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and cryptographic algorithms. Essentially, a blockchain is a decentralized database, a chain of data blocks (i.e., blocks) linked together using cryptographic methods. Each data block contains information about a batch of network transactions, used to verify the validity of the information (anti-counterfeiting) and to generate the next block. A blockchain can include an underlying platform, a platform product and service layer, and an application service layer.

[0058] As mentioned above, a blockchain is essentially a decentralized database, and it is maintained collaboratively by nodes within a blockchain network. For example, please refer to [link to relevant documentation]. Figure 1 ,exist Figure 1 The blockchain network shown may include multiple nodes 101, which can be various servers or terminals forming the blockchain network. Each node 101, in its normal operation, receives input information and maintains shared data within the blockchain network based on this information. To ensure information exchange within the blockchain network, information connections can exist between each node, allowing for information transmission. For example, when any node in the blockchain network receives input information, other nodes in the network obtain this input information according to a consensus algorithm and store it as shared data, ensuring consistency of data stored on all nodes in the blockchain network.

[0059] Each node in a blockchain network has a corresponding node identifier, and each node can store the node identifiers of other nodes. This allows for the broadcast of generated blocks to other nodes in the blockchain network based on their node identifiers. Each node can maintain a list of node identifiers, storing the node name and its corresponding node identifier in this list. The node identifier can be an IP (Internet Protocol) address or any other information that can be used to identify the node.

[0060] See Figure 1 The blockchain network shown includes nodes, and the functions of each node include:

[0061] 1) Routing: A basic function of nodes used to support communication between nodes.

[0062] 2) Applications are deployed within the blockchain to implement specific business functions based on actual business needs. They record data related to these functions, forming record data. This record data carries a digital signature to indicate the source of the task data. The record data is then sent to other nodes in the blockchain system. Upon successful verification of the record data's source and integrity, other nodes add the record data to a temporary block. The business functions implemented by these applications include: smart contracts. A smart contract is a computerized protocol that executes the terms of a contract. It is implemented through code deployed on a shared ledger that executes when certain conditions are met. Based on actual business needs, this code is used to automate transactions. Of course, smart contracts are not limited to executing contracts for transactions; they can also execute contracts for processing received data.

[0063] Please see Figure 2 A blockchain consists of multiple blocks. The genesis block includes a block header and a block body. The block header stores input information features, version number, timestamp, and difficulty value, while the block body stores the input information. The next block after the genesis block is the parent block of the genesis block. The next block also includes a block header and a block body. The block header stores the input information features of the current block, the block header features of the parent block, version number, timestamp, and difficulty value, and so on. This ensures that the block data stored in each block is related to the block data stored in the parent block, guaranteeing the security of the input information in the blocks.

[0064] It is understood that nodes in a blockchain network can be servers or terminals. Servers can be independent physical servers, server clusters or distributed systems composed of multiple physical servers, or cloud servers providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and intelligent platforms. Terminals can be smartphones, tablets, laptops, desktop computers, smart speakers, smartwatches, terminals used in vehicles, aircraft, etc., but are not limited to these. Nodes can be directly or indirectly connected via wired or wireless communication, and this application does not impose any restrictions on this.

[0065] The technical solutions of this application specifically relate to blockchain technology. The technical solutions of this application are described in detail below:

[0066] Please see Figure 3 , Figure 3This is a schematic diagram of an implementation environment involved in this application. The implementation environment mainly includes a business party 301, an oracle network 302, and a blockchain network 303.

[0067] Among them, business party 301 is the initiator of the data request; it can initiate the request to obtain data through any terminal with an input interface; the terminal includes, but is not limited to, smartphones, tablets, laptops, computers, smart voice interaction devices, smart home appliances, terminals used in automobiles, aircraft, etc., and the input interface includes, but is not limited to, touch screens, keyboards, physical buttons, audio pickup devices, etc.

[0068] Oracle Network 302 is a party that responds to a business's request to obtain data. It can obtain the specified data corresponding to the request, verify the specified data, and then upload the verified data to the blockchain network, i.e., store it in the blockchain network. The oracle network can be deployed on any server; the server can be a server providing various services, which can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and intelligent platforms. This document does not impose any restrictions on this.

[0069] Blockchain network 303 refers to the aforementioned blockchain network, which feeds back the stored data to the business party. There can be one or more blockchain networks 303; this is not a limitation.

[0070] Please refer to the following: Figure 3 Oracle network 302 is a decentralized network, mainly comprising execution node cluster 3021, verification node cluster 3022, virtual resource processor 3023, and node allocator 3024; among which:

[0071] Execution node cluster 3021 includes at least two execution nodes. Figure 3 (Only 3 execution nodes are shown in the example). Each execution node can be used to: detect the data acquisition event triggered by the business party, determine the external data source based on the data acquisition event, obtain the data acquisition result based on the external data obtained from the external data source, generate a verification request for the data acquisition result based on the data acquisition result, and send the verification request to the verification node. Then, it receives the signature triggered by the verification node when the data acquisition result is successfully verified; generate on-chain evidence based on the signature of the verification node and the data acquisition result, and send the on-chain evidence to the blockchain network 303.

[0072] Validation node cluster 3022 includes at least two validation nodes. Figure 3 (Only 3 verification nodes are shown in the example). Each verification node can be used to: receive verification requests from execution nodes, verify the data acquisition results contained in the verification requests; if the data acquisition results are successfully verified, sign the data acquisition results; and then send the signature to the execution nodes.

[0073] The virtual resource processor 3023 can be used to manage the virtual resources staked by nodes (such as execution nodes and / or verification nodes) when joining the oracle network. It will upload the staked virtual resources of nodes in oracle network 302 to blockchain network 303 for storage. Specifically, when a node joins oracle network 302, it needs to stake virtual resources in the virtual resource processor 3023. When a node leaves oracle network 302, it can apply to unlock its virtual resources. If the node performed its business normally during its time in oracle network 302 and did not engage in malicious activities, all virtual resources on blockchain network 303 will be returned. If the node did not perform its business normally during its time in oracle network 302, or even engaged in malicious activities, its virtual resources can be confiscated, and a higher amount of virtual resources can be added, or the node can be forced to leave oracle network 302, depending on the specific agreement between oracle network 302 and the node.

[0074] The virtual resources corresponding to different nodes can be the same or different. Understandably, the nodes in an oracle network typically correspond to different resource providers. When a business initiates a data request, it can choose a node with the corresponding computing resources. These computing resources include, but are not limited to, a central processing unit (CPU), memory, and hard disk, thereby forming a decentralized network resource market and achieving stability in the network resource market.

[0075] The node allocator 3024 can be used to: collect execution nodes and verification nodes in the oracle network, maintain the node set of the entire oracle network, and allocate nodes (such as execution nodes and / or verification nodes) that have joined the oracle network. These nodes can be located in or outside the oracle network.

[0076] It should be noted that in the specific implementation of this application, if the acquired data involves objects, then when the embodiments of this application are applied to specific products or technologies, permission or consent from the objects is required, and the collection, use and processing of related data must comply with the relevant regulations and standards of the relevant countries and regions.

[0077] The following details the various implementation details of the technical solutions in the embodiments of this application:

[0078] like Figure 4 As shown, Figure 4 This is a flowchart illustrating a blockchain-based data acquisition method according to an embodiment of this application. This method can be applied to... Figure 3 The implementation environment shown indicates that this method can be implemented by Figure 3 The execution nodes in the execution node cluster 3021 shown are used to execute the data acquisition method based on blockchain, which may include steps S410 to S440, as detailed below:

[0079] S410. Detect the data acquisition event triggered by the business party, determine the external data source based on the data acquisition event, and obtain the data acquisition result based on the external data obtained from the external data source.

[0080] In this embodiment, a data acquisition event refers to an event triggered by a business entity that indicates a need to acquire specified data. The business entity can trigger the data acquisition event through an operation, such as clicking a control on the execution node screen that indicates a need to acquire data. The execution node then detects whether the control has been clicked to determine whether the business entity has triggered the data acquisition event. Alternatively, the business entity can trigger the data acquisition event through information, such as detecting whether a specified message has been received from the business entity. If a specified message from the business entity is detected, it is determined that the business entity has triggered the data acquisition event.

[0081] In this embodiment of the application, when a data acquisition event is detected that the business party has triggered it, the execution node determines the external data source based on the data acquisition event.

[0082] Optionally, external data sources may include URLs (Uniform Resource Locators) on the network, IPFS (Interplanetary File System), search engines, cross-chain data (data connecting different blockchains), DApps (decentralized applications), or other data sources, without limitation.

[0083] The data acquisition result is obtained based on external data acquired from external data sources. External data refers to data outside the blockchain network. This data acquisition result can be the acquired external data itself, or it can be data that has undergone preprocessing, such as cleaning or transforming the external data.

[0084] S420. Generate a verification request for the data acquisition results based on the data acquisition results, and send the verification request to the verification node so that the verification node can verify the data acquisition results contained in the verification request.

[0085] In this embodiment of the application, after the execution node obtains the data acquisition result, it generates a verification request based on the data acquisition result. The verification request includes at least the data acquisition result. The verification request is used to instruct the verification node to verify the data acquisition result. After the verification request is sent to the verification node, the verification node verifies the data acquisition result contained in the verification request to determine the authenticity of the data acquisition result.

[0086] S430, The signature triggered by the receiving verification node when the data acquisition result is successfully verified.

[0087] In this embodiment, the verification node verifies the data acquisition result, and triggers the signing of the data acquisition result when the verification is successful, and then the execution node receives the signature triggered by the verification node.

[0088] S440. Generate on-chain evidence based on the signature of the verification node and the data acquisition result, and send the on-chain evidence to the blockchain network so that the on-chain evidence can be sent to the business party through the blockchain network.

[0089] After receiving the signature from the verification node, the execution node generates on-chain evidence based on the signature of the verification node and the data acquisition result. This on-chain evidence represents the final data result obtained by the execution node in response to the data acquisition event of the business party, and the data result is verified and guaranteed by the verification node. The execution node sends the on-chain evidence to the blockchain network for storage, and then sends the on-chain evidence to the business party through the blockchain network.

[0090] In this embodiment, external data is obtained off-chain through execution nodes and verified through verification nodes, ensuring the authenticity of the data. Compared with related technologies that process data through contracts on the blockchain and off-chain execution and verification nodes, the technical solution provided by this embodiment does not affect the contracts on the blockchain network when the processing logic is modified, resulting in lower coupling and reducing the cost of obtaining data from outside the blockchain.

[0091] In one embodiment of this application, another blockchain-based data acquisition method is provided, which can be applied to... Figure 3 The implementation environment shown indicates that this method can be implemented by Figure 3 The execution nodes in the execution node cluster 3021 shown are used for execution, such as Figure 5As shown, the blockchain-based data acquisition method may include steps S510-S530 and S420-S440. In step S510, the data acquisition event includes a target execution node identifier and a data acquisition request. The data acquisition request instructs the execution node to determine an external data source and acquire external data. The target execution node identifier indicates which execution nodes acquire the external data, and the target execution node identifier may include at least one node identifier.

[0092] Steps S510 to S530 are described in detail below:

[0093] S510, Detect data acquisition events triggered by the business party.

[0094] Please participate in the process of detecting data acquisition events. Figure 4 The process of detecting the data acquisition event triggered by the business party in step S410 shown will not be described again here.

[0095] S520. If it is determined that the local node identifier matches the target execution node identifier in the data acquisition event, then the external data source is determined according to the data acquisition request, and the corresponding external data is obtained from the determined external data source.

[0096] Understandably, each execution node is pre-configured with a unique node identifier. When an execution node detects a data acquisition event, it extracts the target execution node identifier from the data acquisition event and determines whether the local node identifier (i.e., its own node identifier) ​​matches the target execution node identifier. If the target execution node identifier includes the local node identifier, then the data acquisition request is extracted from the data acquisition event.

[0097] In the example of Embodiment 1 of this application, the data acquisition request includes the requirement for the data to be acquired, such as the requirement to acquire data of a specified type. Then, the execution node searches for an external data source corresponding to the specified data type requirement and acquires the corresponding external data from the external data source.

[0098] In another example of the embodiments of this application, the data acquisition request includes a specified external data source, that is, the business party instructs the execution node to acquire external data from a specified location, and then the execution node acquires data of a specified type from the specified external data source, thereby obtaining the external data.

[0099] S530: Generate data acquisition results based on external data and local node identifiers.

[0100] After obtaining external data, the execution node generates a data acquisition result based on the external data and the local node identifier. In the example of Embodiment 1 of this application, the external data and the local node identifier are packaged to generate the data acquisition result. At this time, the data acquisition result also includes the local node identifier to indicate which execution node performed the data acquisition process.

[0101] In another example of the embodiments of this application, external data can be associated with local node identifiers, and the associated external data can be used as the data acquisition result, so that it can be directly known which execution node performed the data acquisition process.

[0102] It should be noted that, Figure 5 For further details on steps S420 to S440 shown, please refer to [link to relevant documentation]. Figure 4 Steps S420 to S440 shown will not be repeated here.

[0103] This application embodiment can accurately determine whether to execute the external data acquisition process by matching the local node identifier and the target node identifier in the data acquisition event. Furthermore, by generating data acquisition results through external data and local node identifiers, the executor of the external data acquisition process can be quickly located, facilitating later traceability.

[0104] This application provides another blockchain-based data acquisition method, which can be applied to... Figure 3 The implementation environment shown indicates that this method can be implemented by Figure 3 The execution nodes in the execution node cluster 3021 shown are used for execution, such as Figure 6 As shown, this blockchain-based data acquisition method... Figure 4 A step S610 is added between S410 and S420 shown in the diagram. Step S610 is described in detail below:

[0105] S610. Sign the data acquisition result and encapsulate the signature and data acquisition result to generate a verification request.

[0106] In this embodiment of the application, the execution node signs the data acquisition result, making the execution node responsible for the data acquisition result. The data acquisition result can be signed based on the execution node's private key. Then, the execution node's signature and the data acquisition result are encapsulated to generate a verification request. The encapsulation can be performed using the encapsulation tool in the execution node's local SDK (Software Development Kit).

[0107] It should be noted that, Figure 6 For detailed information on steps S410 to S440 shown, please refer to [link to relevant documentation]. Figure 4Steps S410 to S440 shown will not be repeated here.

[0108] This application embodiment signs the data acquisition results, making the execution node responsible for the data acquisition results, and generates a verification request through the signature and data acquisition results, which facilitates the quick location of the generator of the verification request.

[0109] This application also provides another blockchain-based data acquisition method, which can be applied to... Figure 3 The implementation environment shown indicates that this method can be implemented by Figure 3 The execution nodes in the execution node cluster 3021 shown are used for execution, such as Figure 7 As shown, this blockchain-based data acquisition method... Figure 4 A step S710 is added between S420 and S430 as shown. Wherein, Figure 7 The data acquisition event in step S410 shown includes a list of verification nodes, which includes at least two specified verification node identifiers, i.e., the business party specifies which verification nodes will perform the data verification process.

[0110] Step S710 is described in detail below:

[0111] S710. Send the verification request to the verification node in the verification node cluster that matches at least two specified verification node identifiers.

[0112] Understandably, the verification node cluster consists of multiple verification nodes, each configured with a unique node identifier. Therefore, after an execution node detects a data acquisition event, it extracts at least two specified verification node identifiers from the verification node list contained in the data acquisition event, then selects a verification node from the verification node cluster that matches at least two specified verification node identifiers, and sends the verification request to the selected verification node.

[0113] For example, a data acquisition event includes a list of verification nodes, which includes verification node identifiers A, B, and C. The execution node sends the verification request to verification node 1, which matches verification node identifier A; verification node 2, which matches verification node B; and verification node 3, which matches verification node C. Verification nodes 1, 2, and 3 then perform the data verification process respectively.

[0114] It should be noted that, Figure 7 For further details on steps S410 to S440 shown, please refer to [link to relevant documentation]. Figure 4 Steps S410 to S440 shown in the diagram will not be repeated here.

[0115] This application embodiment uses a list of verification nodes included in the data acquisition event to easily and quickly send verification requests to verification nodes that match the verification node identifiers contained in the list for verification; and since there are at least two verification nodes, it avoids the phenomenon of a single verification node acting maliciously and improves the accuracy of verification.

[0116] In one embodiment of this application, another blockchain-based data acquisition method is also provided, which can be applied to... Figure 3 The implementation environment shown indicates that this method can be implemented by Figure 3 The execution nodes in the execution node cluster 3021 shown are used for execution, such as Figure 8 As shown, this blockchain-based data acquisition method... Figure 4 A step S810 is added between S420 and S430 as shown. Figure 8 The data acquisition event in step S410 shown includes the number of verification nodes. The number of verification nodes is at least two, meaning that the business side has specified that a certain number of verification nodes will perform the data verification process, but has not specified which verification nodes will specifically perform the verification.

[0117] Step S810 is described in detail below:

[0118] S810: Select a verification node from the verification node cluster that matches the number of verification nodes, and send the verification request to the selected verification node.

[0119] It should be noted that the verification node selected from the verification node cluster can be a currently idle verification node, that is, a node that has not performed any verification process; or it can be a node that is currently performing a verification process. In this case, the verification request is sent to the selected verification node, and then the data verification process corresponding to the verification request is executed after the verification node finishes the current verification process.

[0120] Among them, the number of verification nodes in the verification node cluster is greater than or equal to the number of verification nodes included in the data acquisition event.

[0121] In some embodiments of this application, if the number of verification nodes included in the data acquisition event is greater than the number of verification nodes in the verification node cluster, the execution node can send a message to the business party that there are not enough verification nodes in the verification node cluster, so that the business party can re-specify the number of verification nodes.

[0122] In one example of this application embodiment, after the execution node detects a data acquisition event, it extracts the number of verification nodes from the data acquisition event, and then the execution node directly selects a verification node from the verification node cluster that matches the number of verification nodes, and sends the verification request to the selected verification node.

[0123] Optionally, the execution node can randomly select verification nodes from the verification node cluster that match the number of verification nodes; for example, if the data acquisition event includes 4 verification nodes, the execution node can randomly select 4 verification nodes from the verification node cluster and then send the verification request to these 4 verification nodes respectively.

[0124] Optionally, the execution node can also select verification nodes from the verification node cluster according to a certain rule, matching the number of verification nodes. For example, it can select verification nodes according to the order in which they come online, where the online status of a verification node indicates that it can execute the data verification process. Assuming the data acquisition event involves three verification nodes, with verification node 1 coming online first, followed by verification node 3 and then verification node 4, the execution node selects verification nodes 1, 3, and 4, and then sends the verification request to them respectively. Another example is selecting verification nodes based on the number of verification processes currently pending execution, i.e., prioritizing verification nodes with fewer pending verification processes.

[0125] In another example of the embodiments of this application, the node allocator may select a verification node from the verification node cluster that matches the number of verification nodes. The execution node sends a verification node allocation request to the node allocator based on the number of verification nodes, so that the node allocator selects a verification node from the verification node cluster that matches the number of verification nodes based on the verification node allocation request and returns the identifier of the verification node. Then the execution node sends the verification request to the verification node that matches the identifier of the verification node.

[0126] For example, a data acquisition event includes three verification nodes. The execution node sends a verification node allocation request to the node allocator, which carries the required number of verification nodes, i.e., three verification nodes. Then, the node allocator selects verification nodes 1, 2, and 3, and feeds back the verification node identifiers A, B, and C corresponding to verification nodes 1, 2, and 3 to the execution node. The execution node then sends the verification request to the verification nodes 1, 2, and 3 that match the verification node identifiers A, B, and C.

[0127] When the node allocator selects a verification node from the verification node cluster that matches the number of verification nodes based on the verification node allocation request, the node allocator can select randomly or according to a certain rule. For details, please refer to the description of the aforementioned embodiments, which will not be repeated here.

[0128] It should be noted that, Figure 8 For further details on steps S410 to S440 shown, please refer to [link to relevant documentation]. Figure 4Steps S410 to S440 shown will not be repeated here.

[0129] This application embodiment obtains the number of verification nodes included in the data acquisition event. The execution node can easily and quickly send the verification request to the verification node that matches the number of verification nodes for verification. Furthermore, there are at least two verification nodes, which avoids the phenomenon of a certain verification node acting maliciously and improves the accuracy of verification.

[0130] This application provides another blockchain-based data acquisition method, which includes methods applicable to... Figure 3 The implementation environment shown indicates that this method can be implemented by Figure 3 The execution nodes in the execution node cluster 3021 shown are used for execution, such as Figure 9 As shown, this blockchain-based data acquisition method... Figure 4 A step S910 is added between S420 and S430 as shown. Wherein, Figure 9 The data acquisition event in step S410 shown includes the number of verification nodes. The number of verification nodes is at least two, meaning that the business side has specified that a certain number of verification nodes will perform the data verification process, but has not specified which specific verification nodes will perform the verification.

[0131] Step S910 is described in detail below:

[0132] S910. Send the number of verification nodes and verification requests to the node allocator so that the node allocator can select verification nodes from the verification node cluster that match the number of verification nodes and forward the verification requests to the selected verification nodes.

[0133] In this embodiment, the node allocator selects verification nodes that match the number of verification nodes, and the node allocator forwards verification requests from the execution nodes to the selected verification nodes. That is, the node allocator specifies which verification nodes will perform verification and forwards the verification requests sent by the execution nodes to the specified verification nodes.

[0134] For example, a data acquisition event includes three verification nodes. The execution node sends the number of three verification nodes and a verification request to the node allocator. The node allocator selects verification nodes 1, 2, and 3, and then forwards the verification request to verification nodes 1, 2, and 3 respectively.

[0135] When the node allocator selects a verification node from the verification node cluster that matches the number of verification nodes based on the verification node allocation request, the node allocator can select randomly or according to a certain rule. For details, please refer to the description of the aforementioned embodiments, which will not be repeated here.

[0136] This application embodiment reduces the processing pressure on business processing nodes by acquiring the number of verification nodes included in the data acquisition event and having the node allocator select the verification nodes for verification. This can be applied to a wider range of application scenarios and avoid the situation where execution nodes and verification nodes collude to commit malicious acts, making data verification more reliable.

[0137] It should be noted that, Figure 9 For further details on steps S410 to S440 shown, please refer to [link to relevant documentation]. Figure 4 Steps S410 to S440 shown in the diagram will not be repeated here.

[0138] It is worth noting that at this time, when receiving the signature triggered by the verification node when the data acquisition result is successfully verified in step S430, the execution node can directly receive the signature sent by the verification node; or the execution node can receive the signature from the verification node forwarded by the node allocator. The signature of the verification node is forwarded by the node allocator after receiving the signature sent by the verification node; that is, the verification node sends the signature to the node allocator, and then the node allocator forwards the signature to the execution node.

[0139] This application provides another blockchain-based data acquisition method, which includes methods applicable to... Figure 3 The implementation environment shown indicates that this method can be implemented by Figure 3 The execution nodes in the execution node cluster 3021 shown are used for execution, such as Figure 10 As shown, this blockchain-based data acquisition method... Figure 4 A step S1010 is added between S430 and S440 shown. Step S1010 is described in detail below:

[0140] S1010. If the number of received signatures exceeds the preset threshold, the signatures of the verification node and the data acquisition results are encapsulated, and the encapsulated data is signed to obtain on-chain evidence.

[0141] It should be noted that the execution node can receive signatures from multiple verification nodes, and then determine whether the number of received signatures exceeds a preset threshold. In one example of this application embodiment, the preset threshold can be flexibly set by the execution node or the business party.

[0142] In another example of this application embodiment, the preset quantity threshold can also be flexibly set according to the business requirements of the business party and the total number of verification nodes performing the data verification process. For example, if the business party has strict business requirements for the data and there are 50 verification nodes performing the data verification process, the preset quantity threshold can be set to four-fifths of the number of verification nodes. That is, if the number of received signatures exceeds 40, the signatures of the verification nodes and the data acquisition results will be encapsulated. Of course, the preset quantity threshold can also be flexibly set only according to the total number of verification nodes performing the data verification process, such as setting the preset quantity threshold to two-thirds of the number of verification nodes.

[0143] After the execution node encapsulates the signature and data acquisition results of the verification node, it signs the encapsulated data to obtain on-chain evidence, making the execution node responsible for the on-chain evidence, which facilitates the identification or location of the responsible party in the future.

[0144] In this embodiment, if the number of received signatures does not exceed a preset threshold, the execution node does not perform the process of generating on-chain evidence. In one example, the execution node can re-execute the process of obtaining external data and then verifying the data again through the verification node. In another example, the execution node can also reselect a verification node or reselect a verification node through the node allocator, and then have the reselected verification node perform the data verification process. The execution node can also provide feedback to the business party on the reason for not generating on-chain evidence, so that the business party can reselect an execution node to execute the process of obtaining external data and then verify the data through the verification node.

[0145] It should be noted that, Figure 10 For detailed information on steps S410 to S440 shown in the diagram, please refer to [link / reference]. Figure 4 Steps S410 to S440 shown in the diagram will not be repeated here.

[0146] In this embodiment of the application, after receiving a sufficient number of signatures, on-chain evidence is generated to ensure the authenticity and reliability of the on-chain evidence.

[0147] This application provides another blockchain-based data acquisition method, which includes methods applicable to... Figure 3 The implementation environment shown indicates that this method can be implemented by Figure 3 The execution nodes in the execution node cluster 3021 shown are used for execution, such as Figure 11 As shown, this blockchain-based data acquisition method... Figure 4 Steps S1110 to S1120 are added after S440 shown. Steps S1110 to S1120 are described in detail below:

[0148] S1110. If no deployed evidence contract exists in the blockchain network, then deploy the evidence contract in the blockchain network.

[0149] It's important to note that if multiple execution nodes perform the same task, the evidence contract address generated by each node will be identical. To prevent contract duplication, only one evidence contract will be successfully deployed on the blockchain network for the same task. Therefore, before sending the on-chain evidence to the blockchain network, each execution node will first check if another execution node has already deployed an evidence contract. An evidence contract is a smart contract within the blockchain network used to store the on-chain evidence.

[0150] If no evidence contract has been deployed in the blockchain network, the execution node needs to deploy an evidence contract in the blockchain network to send the on-chain evidence to the evidence contract in the blockchain network.

[0151] S1120. If a deployed evidence contract is stored in the blockchain network, the on-chain evidence is sent to the evidence contract in the blockchain network so that the evidence contract stores the on-chain evidence and sends the on-chain evidence to the business party according to the callback information from the business party.

[0152] If there is an evidence contract deployed by the execution node itself or by other execution nodes in the blockchain network, the on-chain evidence will be sent directly to the evidence contract already deployed in the blockchain network.

[0153] In this embodiment, after the on-chain evidence is sent to the evidence contract on the blockchain network, the evidence contract stores the on-chain evidence and sends it to the business party according to the callback information from the business party. The callback information from the business party represents the receiving address for the business party to receive data from the blockchain network. This callback information can be obtained by the execution node from the business party and stored in the evidence contract during deployment.

[0154] It should be noted that, Figure 11 For detailed information on steps S410 to S440 shown, please refer to [link to relevant documentation]. Figure 4 Steps S410 to S440 shown in the diagram will not be repeated here.

[0155] This application embodiment determines whether a deployed evidence contract exists in the blockchain network. If not, the execution node deploys the evidence contract, avoiding duplicate deployment of the evidence contract. The on-chain evidence is then sent to the evidence contract for storage, facilitating later retrieval.

[0156] It is worth noting that this application embodiment provides another blockchain-based data acquisition method, which can be applied to... Figure 3The implementation environment shown indicates that this method can be implemented by Figure 3 The execution nodes in the execution node cluster 3021 shown are used for execution, such as Figure 12 As shown, this blockchain-based data acquisition method... Figure 4 The steps S1210 to S1220 are added before S410 shown. Steps S1210 to S1220 are the service deployment process for the execution node, detailed below:

[0157] S1210. Receive a service deployment request sent by the business party. The service deployment request carries a data acquisition service identifier and a list of node identifiers to be deployed.

[0158] In this embodiment of the application, when a business wants an execution node to perform a specific task, it can send a corresponding service deployment request to the execution node, and then the execution node will deploy the corresponding service to perform the corresponding task.

[0159] The execution node receives a service deployment request sent by the business party. The service deployment request carries a data acquisition service identifier and a list of execution node identifiers to be deployed. The data acquisition service identifier is used to uniquely identify the data acquisition service, that is, the business party specifies the execution nodes to deploy the data acquisition service and specifies which execution nodes to deploy it to. The data acquisition service can be developed by the business party or by a third party trusted by the business party.

[0160] S1220. If the list of node identifiers to be deployed includes a local node identifier, then deploy the data acquisition service corresponding to the data acquisition service identifier; wherein, the data acquisition service is used to acquire external data.

[0161] The execution node extracts a list of execution node identifiers to be deployed from the service deployment request. If it is determined that the list of execution node identifiers to be deployed contains a local node identifier, it extracts the data acquisition service identifier from the service deployment request and then deploys the data acquisition service corresponding to the data acquisition service identifier.

[0162] Understandably, the execution node can pre-store multiple business services, and then determine and deploy the data acquisition service corresponding to the data acquisition service identifier from among these services. Alternatively, the execution node can obtain the data acquisition service corresponding to the data acquisition service identifier from a third party trusted by the business party, and then deploy that data acquisition service. After deploying the data acquisition service, the execution node can acquire external data based on that data acquisition service.

[0163] It should be noted that, Figure 12 For detailed information on steps S410 to S440 shown, please refer to [link to relevant documentation]. Figure 4Steps S410 to S440 shown in the diagram will not be repeated here.

[0164] In this embodiment, a data acquisition service is deployed by sending a service deployment request from the business party, so as to provide support for the subsequent acquisition of corresponding external data based on the data acquisition service.

[0165] This application provides another blockchain-based data acquisition method, which includes methods applicable to... Figure 3 The implementation environment shown indicates that this method can be implemented by Figure 3 The execution nodes in the execution node cluster 3021 shown are used for execution, such as Figure 13 As shown, this blockchain-based data acquisition method... Figure 12 Steps S1310 to S1330 have been added between S1220 and S1410. Steps S1310 to S1330 describe the process by which the execution node pledges virtual resources and applies for their return, detailed below:

[0166] S1310. When deploying the data acquisition service corresponding to the data acquisition service identifier, pledge virtual resources to the virtual resource processor so that the virtual resource processor can send the pledged virtual resources to the blockchain network for storage.

[0167] In this embodiment of the application, when the execution node deploys the data acquisition service corresponding to the data acquisition service identifier, it indicates that the execution node has joined. Figure 3 The oracle network shown requires staking virtual resources with a virtual resource processor. By staking virtual resources with the processor, the reliability of the execution process when the execution node performs data acquisition services is ensured as much as possible. The virtual resource processor then sends the staked virtual resources to the blockchain network for storage, thereby locking the staked virtual resources.

[0168] After pledging virtual resources to the virtual resource processor, the execution node can enter the data acquisition step when it needs to perform data acquisition, that is, it can enter step S410.

[0169] S1320. If it is necessary to cancel the deployed data acquisition service, apply to the virtual resource processor for the return of the pledged virtual resources so that other execution nodes can challenge the execution process of the local data acquisition service.

[0170] In this embodiment, if the execution node needs to cancel the deployed data acquisition service, it indicates that the execution node is exiting. Figure 3The oracle network shown requests the return of staked virtual resources from the virtual resource processor. When the virtual resource processor receives the request from the execution node, it sends a challenge message to other execution nodes. In turn, other execution nodes challenge the execution process of their local data acquisition service, that is, they determine whether the execution process of their local data acquisition service is normal, such as whether there is any malicious or unreasonable behavior.

[0171] S1330. If other execution nodes fail to complete the challenge during the challenge period, the virtual resources returned by the virtual resource processor through the blockchain network will be received.

[0172] It should be noted that, starting from the time the executing node applies for the return of virtual resources, if other executing nodes fail to successfully challenge during the challenge period, it indicates that the execution process of the executing node's data acquisition service is normal, and the virtual resource processor extracts the virtual resources pledged by the executing node from the blockchain network and sends them to the executing node. If other executing nodes successfully challenge during the challenge period, the virtual resources pledged by the executing node belong to the other executing nodes that successfully challenged.

[0173] Optionally, the challenge period can be flexibly adjusted by the virtual resource processor according to the actual situation, such as setting the challenge period to 7 days.

[0174] It should be noted that, Figure 13 For a detailed description of steps S410 to S440 shown, please refer to [link to relevant documentation]. Figure 4 Steps S410 to S440 shown are as follows: Figure 13 For a detailed description of steps S1210 to S1220 shown, please refer to [link to relevant documentation]. Figure 12 Steps SS1210 to S1220 shown in the diagram will not be repeated here.

[0175] This application embodiment pledges virtual resources to the virtual resource processor when deploying the data acquisition service, and applies for the return of virtual resources when canceling the deployed data acquisition service. This method uses virtual resources to supervise the normal execution of the data acquisition service by the execution node, ensuring the authenticity and reliability of the acquired external data.

[0176] Figures 4 to 13 The illustrated embodiment is presented from the perspective of the execution node. The following is combined with... Figures 14 to 19 The implementation details of the technical solution in this application embodiment are described in detail from the perspective of the verification node:

[0177] Please see Figure 14 , Figure 14 This is a flowchart illustrating a blockchain-based data acquisition method according to an embodiment of this application. The method can be... Figure 3 The verification nodes in the verification node cluster 3022 shown are used to execute the command. Figure 14 As shown, the blockchain-based data acquisition method may include steps S1410 to S1440, which are described in detail below:

[0178] S1410. Receive a verification request from the execution node; the verification request carries the data acquisition result obtained by the execution node based on the acquired external data. The external data is obtained by the execution node from the external data source after detecting the data acquisition event triggered by the business party and determining the external data source based on the data acquisition event.

[0179] As mentioned above, the verification request is used to instruct the verification node to verify the data acquisition result, which is obtained by the execution node based on the acquired external data. The process of acquiring external data can be found in step S410 or step S520, and will not be described in detail here.

[0180] S1420. Verify the data retrieval results contained in the verification request.

[0181] Therefore, after receiving a verification request, the verification node will verify the data retrieval results contained in the verification request to verify whether the data retrieval results contained in the verification request are correct.

[0182] S1430. If the data acquisition result is successfully verified, then the data acquisition result is signed.

[0183] If the verification node verifies that the data acquisition result is correct, it means that the data acquisition result has been successfully verified. The verification node can then sign the data acquisition result using its private key, and the signature represents the verification node's approval.

[0184] If the verification node verifies that the data acquisition result is incorrect, it indicates that the verification of the data acquisition result has failed. In one example, the verification node will not perform any action; in another example, the verification node can provide feedback on the failure to the execution node.

[0185] S1440. Send the signature to the execution node so that the execution node can generate on-chain evidence based on the signature and data acquisition results, and send the on-chain evidence to the business party through the blockchain network.

[0186] In this embodiment of the application, after the verification node signs the data acquisition result, it sends the signature to the execution node. After receiving the signature of the verification node, the execution node can know the verification node's approval opinion, generate on-chain evidence based on the signature of the verification node and the data acquisition result, and send it to the blockchain network for storage. Then, the on-chain evidence is sent to the business party through the blockchain network.

[0187] In this embodiment, the results obtained by the execution node are verified off-chain through the verification node, which ensures the authenticity of the data. Furthermore, the data processing logic is performed through the off-chain execution node and verification node. Modifying the processing logic will not affect the contract on the blockchain network, resulting in low coupling and reducing the cost of obtaining data outside the blockchain.

[0188] This application provides another blockchain-based data acquisition method, which can be applied to... Figure 3 The implementation environment shown indicates that this method can be implemented by Figure 3 The verification nodes in the verification node cluster 3022 shown are used to execute the command, as follows: Figure 15 As shown, the blockchain-based data acquisition method may include steps S1510, S1420 to S1440. Step S1510 is described in detail below:

[0189] S1510, Receive the verification request sent by the execution node.

[0190] The verification node can directly receive verification requests sent by the execution node without going through an intermediate forwarder.

[0191] It should be noted that, Figure 15 For detailed information on steps S1420 to S1440 shown, please refer to [link to relevant documentation]. Figure 14 Steps S1420 to S1440 shown in the diagram will not be repeated here.

[0192] It is worth noting that this application embodiment provides another blockchain-based data acquisition method, which can be applied to... Figure 3 The implementation environment shown indicates that this method can be implemented by Figure 3 The verification nodes in the verification node cluster 3022 shown are used to execute the command, as follows: Figure 16 As shown, the blockchain-based data acquisition method may include steps S1610, S1420 to S1440. Step S1610 is described in detail below:

[0193] S1610. The receiving node allocator forwards the verification request from the execution node. The verification request is forwarded by the node allocator after selecting the corresponding verification node based on the verification request after receiving the verification request sent by the execution node.

[0194] In this embodiment, the verification node indirectly receives the verification request sent by the execution node. Specifically, the execution node sends the verification request to the node allocator, which then selects the corresponding verification node based on the verification request and forwards the verification request to the selected node. The process by which the node allocator selects the corresponding verification node based on the verification request is detailed in the above embodiments and will not be repeated here.

[0195] It should be noted that, Figure 16 For detailed information on steps S1420 to S1440 shown, please refer to [link to relevant documentation]. Figure 14 Steps S1420 to S1440 shown in the diagram will not be repeated here.

[0196] The embodiments of this application obtain verification requests from the execution node in at least two ways, which can be applied to a wider range of application scenarios and provide support for subsequent verification processes based on verification requests.

[0197] It is worth noting that this application embodiment provides another blockchain-based data acquisition method, which can be applied to... Figure 3 The implementation environment shown indicates that this method can be implemented by Figure 3 The verification nodes in the verification node cluster 3022 shown are used to execute the command, as follows: Figure 17 As shown, the blockchain-based data acquisition method includes steps S1410, S1710, and S1420-S1430. Step S1710 is described in detail below:

[0198] S1710. Obtain external verification data based on the verification request, and verify the data acquisition result contained in the verification request based on the external verification data.

[0199] As mentioned above, the verification request includes at least the data acquisition result and the signature of the execution node, and the data acquisition result includes at least the external data acquired by the execution node. In one example of this application embodiment, the verification request also includes the external data source where the execution node acquires the external data, so that after receiving the verification request, the verification node can acquire external verification data from the external data source based on the verification request.

[0200] In another example of this application embodiment, the process of the execution node acquiring external data and the process of the verification node performing data verification are set up in a coordinated manner. That is, if the verification node acquires external verification data from a specified external data source, the execution node can then know the specified external data source and acquire external verification data from the specified external data source.

[0201] In one example of an embodiment of this application, the verification node compares the external verification data with the external data in the data acquisition result. If it is determined that the external verification data matches the external data in the data acquisition result, such as the data being completely identical, then the data acquisition result is normal and the verification of the data acquisition result is successful. If the external verification data does not match the external data in the data acquisition result, such as the data being missing or the data being partially different, then the data acquisition result is abnormal and the verification of the data acquisition result fails.

[0202] In another example of this application embodiment, the data acquisition result includes external data acquired by the execution node and an execution node identifier; the verification node acquires external verification data from the external data source based on the verification request, and also acquires a node identifier from the data records of the external data source. The node identifier indicates which execution nodes acquired external data from the external data source. Then, the verification node verifies the external data in the data acquisition result based on the external verification data, and verifies the execution node identifier in the data acquisition result based on the node identifier acquired from the data records of the external data source. If the external data in the data acquisition result is successfully verified, and the execution node identifier in the data acquisition result is successfully verified, then the data acquisition result is successfully verified.

[0203] It should be noted that, Figure 17 For detailed information on steps S1410, S1430 to S1440 shown, please refer to [link to relevant documentation]. Figure 14 Steps S1410, S1430 to S1440 shown in the diagram will not be repeated here.

[0204] This application embodiment verifies the external data in the data acquisition result by obtaining external verification data through the verification node, which can quickly and easily verify the authenticity of the data.

[0205] It is worth noting that this application embodiment provides another blockchain-based data acquisition method, which can be applied to... Figure 3 The implementation environment shown indicates that this method can be implemented by Figure 3 The verification nodes in the verification node cluster 3022 shown are used to execute the command, as follows: Figure 18 As shown, this blockchain-based data acquisition method... Figure 14 Steps S1810 to S1820 have been added before step S1410. Steps S1810 to S1820 constitute the service deployment process for the verification node, detailed below:

[0206] S1810. Receive the verification service deployment request sent by the business party. The verification service deployment request carries the verification service identifier and the list of verification node identifiers to be deployed.

[0207] In this embodiment of the application, when a business wants to verify that a node is performing a specific task, it can send a corresponding service deployment request to the verification node, and then the verification node will deploy the corresponding service to perform the corresponding task.

[0208] The verification node receives a verification service deployment request sent by the business party. The verification service deployment request carries a verification service identifier and a list of verification node identifiers to be deployed. The verification service identifier is used to uniquely identify the data verification service, that is, the business party specifies the verification nodes to deploy the data verification service and specifies which verification nodes to deploy. The data verification service can be developed by the business party or by a third party trusted by the business party.

[0209] S1820. If the list of verification node identifiers to be deployed includes a local node identifier, then deploy the data verification service corresponding to the verification service identifier; wherein, the data verification service is used to verify the data acquisition result contained in the verification request.

[0210] The verification node extracts a list of verification node identifiers to be deployed from the verification service deployment request. If it is determined that the list of verification node identifiers to be deployed contains a local node identifier, the verification service identifier is extracted from the verification service deployment request, and then the data verification service corresponding to the verification service identifier is deployed.

[0211] Understandably, verification nodes can pre-store multiple business services, and then determine and deploy the data verification service corresponding to the verification service identifier from among these services. Execution nodes can also obtain the data verification service corresponding to the verification service identifier from a third party trusted by the business party, and then deploy that data verification service. After deploying the data verification service, the verification node can verify the data acquisition results contained in the verification request based on this data verification service.

[0212] It should be noted that, Figure 18 For detailed information on steps S1410 to S1440 shown, please refer to [link to relevant documentation]. Figure 14 Steps S1410 to S1440 shown in the diagram will not be repeated here.

[0213] This application embodiment deploys a data verification service through a verification service deployment request sent by the business party, so as to provide support for the subsequent verification of external data based on the data verification service.

[0214] This application also provides another blockchain-based data acquisition method, which can be applied to... Figure 3 The implementation environment shown indicates that this method can be implemented by Figure 3 The verification nodes in the verification node cluster 3022 shown are used to execute the command, as follows: Figure 19 As shown, this blockchain-based data acquisition method... Figure 18The steps between S1820 and S1410 shown in the diagram can include S1910 to S1930. Steps S1910 to S1930 are the process by which the verification node pledges virtual resources and applies for the return of the pledged virtual resources, detailed below:

[0215] S1910. When deploying the data verification service corresponding to the data verification service identifier, pledge virtual resources to the virtual resource processor so that the virtual resource processor can send the pledged virtual resources to the blockchain network for storage.

[0216] In this embodiment of the application, when the verification node deploys the data verification service corresponding to the data verification service identifier, it indicates that the verification node has joined... Figure 3 The oracle network shown requires staking virtual resources with a virtual resource processor. By staking virtual resources with the processor, the reliability of the verification node's data verification service is ensured. The virtual resource processor then sends the staked virtual resources to the blockchain network for storage, thus locking the staked virtual resources.

[0217] After pledging virtual resources to the virtual resource processor, if a verification request from the execution node is required, proceed to step S1410.

[0218] S1920. If it is necessary to cancel the deployed data verification service, apply to the virtual resource processor for the return of the pledged virtual resources so that other verification nodes can challenge the execution process of the local data verification service.

[0219] In this embodiment, if a verification node needs to cancel the deployed data verification service, it indicates that the verification node is exiting. Figure 3 The oracle network shown requests the return of staked virtual resources from the virtual resource processor. When the virtual resource processor receives the request from the verification node, it sends a challenge message to other verification nodes. In turn, other verification nodes challenge the execution process of their local data verification service, that is, they determine whether the execution process of their local data verification service is normal, such as whether there is any malicious or unreasonable behavior.

[0220] S1930. If other verification nodes fail to succeed in the challenge during the challenge period, the virtual resources returned by the virtual resource processor through the blockchain network will be received.

[0221] It should be noted that, starting from the time a validator applies for the return of virtual resources, if other validators fail to successfully challenge during the challenge period, it indicates that the data verification service of the validator node is functioning normally, and the virtual resource processor extracts the virtual resources staked by the validator node from the blockchain network and sends them to the validator node. If other validators successfully challenge during the challenge period, the virtual resources staked by the validator node belong to the other validators who successfully challenged.

[0222] Optionally, the challenge period can be flexibly adjusted by the virtual resource processor according to the actual situation, such as setting the challenge period to 7 days.

[0223] It should be noted that, Figure 19 For detailed information on steps S1410 to S1440 shown, please refer to [link to relevant documentation]. Figure 14 Steps S1410 to S1440 shown are... Figure 19 For detailed information on steps S1810 to S1820 shown, please refer to [link to relevant documentation]. Figure 18 Steps S1810 to S1820 shown in the diagram will not be repeated here.

[0224] This application embodiment pledges virtual resources to the virtual resource processor when deploying the data verification service, and applies for the return of virtual resources when canceling the deployed data verification service. This method uses virtual resources to supervise the normal execution of the data verification service by the verification node, thereby ensuring the authenticity and reliability of external data verification.

[0225] For ease of understanding, the following is based on Figure 3 The implementation environment shown below provides a detailed description of the blockchain-based data acquisition method provided in this application embodiment:

[0226] It should be noted that the following preliminary preparations are required before the execution node and verification node execute the blockchain-based data acquisition method:

[0227] When a business needs an oracle, it develops its own oracle contract, data acquisition service, and data verification service. The business deploys the oracle contract to the blockchain network and the data acquisition service and data verification service to the oracle network. The business also deploys a business contract on the blockchain network. This business contract is a data acquisition request initiated by a smart contract in the blockchain network. The business contract is used to call the oracle contract, and the oracle contract is used to respond to the call of the business contract by initiating a data acquisition request to the oracle network and feeding back the on-chain data to the business contract through the blockchain network.

[0228] When a business deploys a data acquisition service to an oracle network, it needs to specify a list of execution node IDs to be deployed. That is, it specifies the execution nodes in the oracle network's execution node cluster to deploy the data acquisition service. The data acquisition service is stored in the execution nodes of the oracle network's execution node cluster and is run by the execution nodes. The execution nodes provide a Docker container runtime environment to acquire external data through the execution data acquisition service. Subsequently, the execution nodes will deploy the corresponding evidence contract in the blockchain network. This evidence contract is used to store the data uploaded to the blockchain by the execution nodes and to feed the uploaded data back to the business contract.

[0229] It should be noted that if the business party designates multiple execution nodes to deploy the data acquisition service, the evidence contract address generated by each execution node is the same. Therefore, only one evidence contract will be successfully deployed on the blockchain. Before uploading data to the blockchain, the execution node needs to check whether there is an evidence contract in the blockchain network. If not, the evidence contract needs to be deployed in the blockchain network. If it exists, there is no need to deploy the evidence contract again.

[0230] When a business deploys a data verification service to an oracle network, it needs to specify a list of verification node IDs (Identity documents) to be deployed. That is, it specifies the verification nodes in the verification node cluster of the oracle network to deploy the data verification service. The data verification service will be stored on the verification nodes, and the verification nodes will execute the data verification service to verify the results of the execution nodes.

[0231] Optionally, the data verification service consumes fewer resources than the data acquisition service. If the business has high security requirements, it can choose to deploy multiple verification nodes to verify the results of the execution nodes. However, this will increase costs, which the business must weigh against its own priorities.

[0232] Based on the above preliminary preparations, please refer to Figure 20 , Figure 20 This is a flowchart of a blockchain-based data acquisition method based on oracle networks and blockchain networks. The method includes:

[0233] S2010, The business contract of the business party calls the oracle contract, carrying the relevant business information and the node ID of the specified oracle network.

[0234] When a business needs external data, it triggers a business contract, which in turn calls an oracle contract, carrying relevant business information. This business information can be the type of external data needed by the business and the business's callback information, specifying the oracle node ID, including the execution node ID and the verification node ID.

[0235] In S2020, oracle contracts will be triggered, leaving an event record on the blockchain network.

[0236] This triggers a data acquisition event. The data acquisition event record includes at least the execution node ID and the verification node ID, as well as a data acquisition request containing business information.

[0237] S2030: Execution nodes in the oracle network subscribe to events on the blockchain network to obtain relevant information from event records.

[0238] The execution nodes in the oracle network will detect event records on the blockchain network. If the running execution node ID is detected to match the execution node ID in the event record, the relevant information in the event record will be retrieved.

[0239] S2040, The execution node in the oracle network requests external data.

[0240] The execution node constructs an external call request based on the relevant information in the event log to request external data.

[0241] S2050, the execution node obtains external data.

[0242] The execution node obtains external data from an external data source.

[0243] S2060, the execution nodes and verification nodes within the oracle network reach a consensus.

[0244] After obtaining external data, the execution node calls the encapsulated SDK provided by the oracle network to encapsulate the list of verification node IDs and the external data to be verified, triggers the construction of a verification request, and sends the verification request to the verification node corresponding to the verification node ID in the event log, striving to obtain the verification node's approval opinion (i.e., signature). If the execution node receives enough signatures from verification nodes, the execution node and the verification node reach a consensus.

[0245] S2070, The execution node constructs on-chain evidence and sends the on-chain evidence to the evidence contract in the blockchain network.

[0246] The execution node constructs on-chain evidence based on the signature of the verification node and external data, and sends the on-chain evidence, oracle contract callback address and parameters to the evidence contract.

[0247] S2080, the evidence contract stores the on-chain evidence and submits the external data in the on-chain evidence to the oracle contract.

[0248] The evidence contract stores on-chain evidence and submits external data from the on-chain evidence to the oracle contract according to the oracle contract callback address and parameters.

[0249] S2090, the oracle contract calls back the business contract, delivering external data to the business contract.

[0250] This completes the acquisition of data from outside the blockchain network. The operations described above, including the acquisition of external data by the execution node, the verification between the execution node and the verification node, the construction of on-chain evidence by the execution node, and the storage of on-chain evidence in the evidence contract, can be automatically executed by the oracle network.

[0251] based on Figure 20 Please refer to the provided technical solutions. Figure 21 , Figure 21 This is a flowchart illustrating the workflow of nodes in an oracle network. The execution flow of the execution node and the verification node includes:

[0252] S2110, Execute the node to detect data acquisition events in the blockchain network.

[0253] The system detects data retrieval events triggered by the invocation of oracle contracts, matches the local ID of the execution node with the execution node ID specified in the data retrieval event, and if a match is found, captures information from the data retrieval event, including the data retrieval request, the number of verification nodes required before on-chain processing or a list of specified verification node IDs, and whether a node allocator is used. The number of verification nodes must be at least two, and the list of specified verification node IDs must include at least two specified verification node IDs. If a number of verification nodes is specified, it is necessary to specify whether a node allocator is used.

[0254] S2120, The execution node obtains external data based on the data acquisition event and generates a verification request.

[0255] The execution node calls the corresponding external data source service based on the data acquisition request in the data acquisition event to obtain external data. After the acquisition is completed, the execution node packages the external data, the number of verification nodes required before uploading to the chain or the specified list of verification node IDs, whether to use a node allocation party, and the execution node ID to generate an execution result (i.e., the data acquisition result), signs the execution result, and assembles it into a verification request consisting of the execution result and the execution node signature.

[0256] S2130, The execution node sends the verification request to the node allocator.

[0257] If the data acquisition result specifies the required number of verification nodes, the execution node needs to check whether the node allocator field is used. If not, the execution node can directly randomly select verification nodes to send verification requests, but this process may involve collusion and malicious behavior, depending on whether the business can bear it. If the node allocator is used, the execution node can send the verification request to the node allocator.

[0258] If the data acquisition result specifies a list of verification node IDs, the execution node can directly send a verification request to the verification nodes in the list of verification node IDs.

[0259] S2140. The node allocator selects a verification node from the verification node cluster that matches the number of verification nodes, and forwards the verification request to the verification node.

[0260] The node allocator randomly selects verification nodes from the verification node cluster that match the number of verification nodes.

[0261] S2150, The verification node obtains external verification data and verifies the data acquisition results.

[0262] The verification node calls the verification service of an external data source to obtain external verification data, and then matches the external verification data with the external data in the data acquisition results.

[0263] S2160. If the data acquisition result is successfully verified, the verification node signs the data acquisition result and sends the signature to the node allocator.

[0264] If the external verification data completely matches the external data in the data acquisition result, the data acquisition result is verified successfully. The data acquisition result is then signed and the signature is sent to the node allocator to indicate approval.

[0265] Optionally, if the verification of the data acquisition result fails, the verification node can send the failure feedback to the node assigner.

[0266] S2170. The node allocator collects the verification results of each verification node and returns the results to the execution node.

[0267] The node allocator collects the signatures of the verification nodes and sends the signatures of the verification nodes to the execution nodes.

[0268] S2180. The execution node receives enough signatures, constructs on-chain evidence based on the signatures of the verification node and the data acquisition results, and sends it to the evidence contract in the blockchain network.

[0269] The execution node assembles the data acquisition results, the verification node's signature, and the execution node's signature into on-chain evidence and sends it to the evidence contract.

[0270] S2190, the evidence contract stores the on-chain evidence and delivers the external data in the data acquisition results to the oracle contract.

[0271] Optionally, step Sa1 involves the execution node staking virtual resources with the virtual resource processor when joining the oracle network. Further, step Sa2 involves the virtual resource processor sending the staked virtual resources, its signature, and the execution node's signature to the virtual resource contract on the blockchain network, so that the virtual resource contract is associated, on-chain, and stored.

[0272] Optionally, step Sb1 involves the validator node staking virtual resources with the virtual resource processor when joining the oracle network. Further, step Sb2 involves the virtual resource processor sending the staked virtual resources, its signature, and the validator node's signature to the virtual resource contract on the blockchain network, so that the virtual resource contract is associated, on-chain, and stored.

[0273] If an execution node or validator node wants to leave the oracle network, it can apply to the virtual resource processor to unstake virtual resources. After a challenge period, it can retrieve the corresponding virtual resources from the evidence contract and return them to the execution node or validator node. In practical applications, the oracle network will form a system where high-reputation, technically capable, and resource-rich node service providers compete and check each other, creating decentralization and ultimately achieving network stability.

[0274] This invention proposes a blockchain-based data acquisition method based on a decentralized oracle network. The business needs to deploy data acquisition and data verification services within the oracle network. Execution nodes detect data acquisition events on the blockchain, and the data acquisition service retrieves external data based on these events. This data is then handed over to the verification node's data verification service for verification. After successful verification, the execution node delivers the data to the blockchain contract, thus completing the acquisition of external blockchain data. The entire process is secured, stable, and decentralized thanks to the oracle network.

[0275] The apparatus embodiments described herein can be used to execute the blockchain-based data acquisition method in the above embodiments of this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the blockchain-based data acquisition method described above.

[0276] This application provides a blockchain-based data acquisition device, such as... Figure 22 As shown, this blockchain-based data acquisition device can be configured in an execution node, and the device includes:

[0277] The detection and acquisition module 2210 is used to detect data acquisition events triggered by the business party, determine the external data source based on the data acquisition events, and obtain the data acquisition result based on the external data obtained from the external data source.

[0278] The generation and sending module 2220 is used to generate a verification request for the data acquisition result based on the data acquisition result, and send the verification request to the verification node so that the verification node can verify the data acquisition result contained in the verification request;

[0279] The first receiving module 2230 is used to receive the signature triggered by the verification node when the data acquisition result is successfully verified;

[0280] The generation and sending module 2220 is also used to: generate on-chain evidence based on the signature of the verification node and the data acquisition result, and send the on-chain evidence to the blockchain network so as to send the on-chain evidence to the business party through the blockchain network.

[0281] In one embodiment of this application, based on the aforementioned scheme, the data acquisition event includes a target execution node identifier and a data acquisition request; the detection and acquisition module 2210 includes an acquisition unit, which is used to determine an external data source according to the data acquisition request if it is determined that the local node identifier matches the target execution node identifier in the data acquisition event, and to acquire the corresponding external data from the determined external data source; and to generate a data acquisition result based on the external data and the local node identifier.

[0282] In one embodiment of this application, based on the aforementioned scheme, the data acquisition event includes a list of verification nodes, which includes at least two specified verification node identifiers; the generation and sending module 2220 includes a sending unit, which is used to send the verification request to the verification node in the verification node cluster that matches the at least two specified verification node identifiers.

[0283] In one embodiment of this application, based on the aforementioned scheme, the data acquisition event includes the number of verification nodes, and the number of verification nodes is at least two; the generation and sending module 2220 includes a sending unit, which is used to select a verification node from the verification node cluster that matches the number of verification nodes, and send the verification request to the selected verification node.

[0284] In one embodiment of this application, based on the aforementioned scheme, the data acquisition event includes the number of verification nodes, and the number of verification nodes is at least two; the generation and sending module 2220 includes a sending unit, which is used to send the number of verification nodes and the verification request to the node allocator, so that the node allocator selects a verification node from the verification node cluster that matches the number of verification nodes, and forwards the verification request to the selected verification node.

[0285] In one embodiment of this application, based on the aforementioned scheme, the generation and sending module 2220 includes a generation unit. The generation unit is used to encapsulate the signature of the verification node and the data acquisition result if the number of received signatures exceeds a preset number threshold, and to sign the encapsulated data to obtain on-chain evidence.

[0286] In one embodiment of this application, based on the foregoing scheme, the device further includes a first deployment module, which is used to receive a service deployment request sent by the business party. The service deployment request carries a data acquisition service identifier and a list of execution node identifiers to be deployed. If the list of execution node identifiers to be deployed includes a local node identifier, then the data acquisition service corresponding to the data acquisition service identifier is deployed. The data acquisition service is used to acquire external data.

[0287] In one embodiment of this application, based on the aforementioned scheme, the device further includes a first staking module. The first staking module is used by the first deployment module to pledge virtual resources to the virtual resource processor when deploying the data acquisition service corresponding to the data acquisition service identifier, so that the virtual resource processor sends the pledged virtual resources to the blockchain network for storage; if it is necessary to cancel the deployed data acquisition service, the module applies to the virtual resource processor for the return of the pledged virtual resources, so that other execution nodes can challenge the execution process of the local data acquisition service; if other execution nodes fail to challenge successfully during the challenge period, the module receives the virtual resources returned by the virtual resource processor through the blockchain network.

[0288] In one embodiment of this application, based on the aforementioned scheme, the generation and sending module 2220 includes a sending unit. The sending unit is used to deploy an evidence contract in the blockchain network if no deployed evidence contract exists in the blockchain network; if a deployed evidence contract exists in the blockchain network, the on-chain evidence is sent to the evidence contract in the blockchain network so that the evidence contract stores the on-chain evidence and sends the on-chain evidence to the business party according to the callback information from the business party.

[0289] In one embodiment of this application, based on the aforementioned scheme, the generation and sending module 2220 includes a generation unit, which is used to sign the data acquisition result and encapsulate the signature and the data acquisition result to generate a verification request.

[0290] This application provides a blockchain-based data verification device, such as... Figure 23 As shown, this blockchain-based data verification device can be configured in a verification node, and the device includes:

[0291] The second receiving module 2310 is used to receive a verification request from the execution node. The verification request carries the execution result obtained by the execution node based on the acquired external data. The external data is obtained by the execution node from the external data source after detecting the data acquisition event triggered by the business party and determining the external data source based on the data acquisition event.

[0292] The verification module 2320 is used to verify the data acquisition results carried in the verification request;

[0293] The signature module 2330 is used to sign the data acquisition result if the data acquisition result is successfully verified.

[0294] The sending module 2340 is used to send the signature to the execution node, so that the execution node can generate on-chain evidence based on the signature and data acquisition results, and send the on-chain evidence to the business party through the blockchain network.

[0295] In one embodiment of this application, based on the aforementioned scheme, the second receiving module 2310 is specifically used to receive a verification request sent by the execution node; or to receive a verification request forwarded by the node allocator from the execution node. The verification request is forwarded by the node allocator after selecting the corresponding verification node based on the verification request received from the execution node.

[0296] In one embodiment of this application, based on the foregoing scheme, the device further includes a second deployment module, which is used to receive a verification service deployment request sent by the business party. The verification service deployment request carries a verification service identifier and a list of verification node identifiers to be deployed. If the list of verification node identifiers to be deployed includes a local node identifier, then a data verification service corresponding to the verification service identifier is deployed. The data verification service is used to verify the data acquisition result contained in the verification request.

[0297] In one embodiment of this application, based on the aforementioned scheme, the device further includes a second staking module. The second staking module is used by the second deployment module to pledge virtual resources to the virtual resource processor when deploying the data verification service corresponding to the data verification service identifier, so that the virtual resource processor sends the pledged virtual resources to the blockchain network for storage; if it is necessary to cancel the deployed data verification service, the module applies to the virtual resource processor for the return of the pledged virtual resources, so that other verification nodes can challenge the execution process of the local data verification service; if other verification nodes fail to challenge successfully during the challenge period, the module receives the virtual resources returned by the virtual resource processor through the blockchain network.

[0298] In one embodiment of this application, based on the aforementioned scheme, the verification module 2320 is specifically used to obtain external verification data based on the verification request, and to verify the data acquisition result contained in the verification request based on the external verification data.

[0299] It should be noted that the apparatus provided in the above embodiments and the method provided in the above embodiments belong to the same concept, and the specific way in which each module and unit performs operations has been described in detail in the method embodiments, and will not be repeated here.

[0300] Embodiments of this application also provide an electronic device, including one or more processors and a storage device, wherein the storage device is used to store one or more computer programs, which, when executed by one or more processors, enable the electronic device to implement the blockchain-based data acquisition method described above.

[0301] Figure 24 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown.

[0302] It should be noted that, Figure 24 The computer system 2400 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application, wherein the electronic device may be a terminal or a server.

[0303] like Figure 24 As shown, the computer system 2400 includes a central processing unit (CPU) 2401, which can perform various appropriate actions and processes, such as executing the methods described in the above embodiments, based on a program stored in read-only memory (ROM) 2402 or a program loaded from storage portion 2408 into random access memory (RAM) 2403. The RAM 2403 also stores various programs and data required for system operation. The CPU 2401, ROM 2402, and RAM 2403 are interconnected via a bus 2404. An input / output (I / O) interface 2405 is also connected to the bus 2404.

[0304] In some embodiments, the following components are connected to the I / O interface 2405: an input section 2406 including a keyboard, mouse, etc.; an output section 2407 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 2408 including a hard disk, etc.; and a communication section 2409 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 2409 performs communication processing via a network such as the Internet. A drive 2410 is also connected to the I / O interface 2405 as needed. A removable medium 2411, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 2410 as needed so that computer programs read from it can be installed into the storage section 2408 as needed.

[0305] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program including a computer program for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 2409, and / or installed from removable medium 2411. When the computer program is executed by processor (CPU) 2401, it performs various functions defined in the system of this application.

[0306] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory, flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying a computer-readable computer program. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The computer program contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0307] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and a computer program.

[0308] The units or modules described in the embodiments of this application can be implemented in software or hardware, and can also be located in a processor. The names of these units or modules do not necessarily limit the specific unit or module itself.

[0309] Another aspect of this application provides a computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the method described above. This computer-readable storage medium may be included in the electronic device described in the above embodiments, or it may exist independently and not assembled into the electronic device.

[0310] Another aspect of this application provides a computer program product comprising a computer program stored in a computer-readable storage medium. A processor of an electronic device reads the computer program from the computer-readable storage medium and executes the computer program, causing the electronic device to perform the methods described above in the various embodiments.

[0311] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0312] Other embodiments of this application will readily conceive of by considering the specification and practicing the embodiments disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein.

[0313] The above content is merely a preferred exemplary embodiment of this application and is not intended to limit the implementation of this application. Those skilled in the art can easily make corresponding modifications or alterations based on the main concept and spirit of this application. Therefore, the scope of protection of this application should be determined by the scope of protection claimed in the claims.

Claims

1. A data acquisition method based on blockchain, characterized in that, The method includes: The system detects data acquisition events triggered by the business unit, whereby the data acquisition events include the target execution node identifier and the data acquisition request. If the local node identifier is determined to match the target execution node identifier in the data acquisition event, then the external data source is determined according to the data acquisition request, and the corresponding external data is acquired from the determined external data source; a data acquisition result is generated based on the external data and the local node identifier. A verification request is generated based on the data acquisition result, and the verification request is sent to a verification node. The verification node then retrieves external verification data from the external data source based on the verification request, and obtains a node identifier from the data records of the external data source. The node identifier represents the execution node that has retrieved external data from the external data source. The external data in the data acquisition result is verified based on the external verification data, and the local node identifier in the data acquisition result is verified based on the node identifier obtained from the data records of the external data source. Receive the signature triggered by the verification node when the data acquisition result is successfully verified; If the number of received signatures exceeds a preset threshold, on-chain evidence is generated based on the signature of the verification node and the data acquisition result, and the on-chain evidence is sent to the blockchain network so that the on-chain evidence can be sent to the business party through the blockchain network.

2. The method according to claim 1, characterized in that, The data acquisition event includes a list of verification nodes, which includes at least two specified verification node identifiers. Sending the verification request to the verification node includes: The verification request is sent to a verification node in the verification node cluster that matches the at least two specified verification node identifiers.

3. The method according to claim 1, characterized in that, The data acquisition event includes the number of verification nodes, wherein the number of verification nodes is at least two; sending the verification request to the verification nodes includes: Select a verification node from the verification node cluster that matches the number of verification nodes, and send the verification request to the selected verification node.

4. The method according to claim 1, characterized in that, The data acquisition event includes the number of verification nodes, wherein the number of verification nodes is at least two; sending the verification request to the verification nodes includes: The number of verification nodes and the verification request are sent to the node allocator, so that the node allocator selects a verification node from the verification node cluster that matches the number of verification nodes, and forwards the verification request to the selected verification node.

5. The method according to claim 1, characterized in that, The step of generating on-chain evidence based on the signature of the verification node and the data acquisition result includes: The signature of the verification node and the data acquisition result are encapsulated, and the encapsulated data is signed to obtain the on-chain evidence.

6. The method according to claim 1, characterized in that, The method further includes: Receive a service deployment request sent by the business party, wherein the service deployment request carries a data acquisition service identifier and a list of nodes to be deployed and executed; If the list of node identifiers to be deployed contains a local node identifier, then the data acquisition service corresponding to the data acquisition service identifier is deployed; wherein, the data acquisition service is used to acquire external data.

7. The method according to claim 6, characterized in that, The method further includes: When deploying the data acquisition service corresponding to the data acquisition service identifier, virtual resources are pledged to the virtual resource processor so that the virtual resource processor sends the pledged virtual resources to the blockchain network for storage. If it is necessary to cancel the deployed data acquisition service, apply to the virtual resource processor for the return of the pledged virtual resources so that other execution nodes can challenge the execution process of the local data acquisition service; If other execution nodes fail to complete the challenge during the challenge period, the virtual resources will be returned by the virtual resource processor through the blockchain network.

8. The method according to claim 1, characterized in that, Sending the on-chain evidence to the blockchain network includes: If no deployed evidence contract exists in the blockchain network, then deploy the evidence contract in the blockchain network. If the blockchain network stores a deployed evidence contract, the on-chain evidence is sent to the evidence contract in the blockchain network so that the evidence contract stores the on-chain evidence and sends the on-chain evidence to the business party according to the callback information of the business party.

9. The method according to any one of claims 1 to 8, characterized in that, The step of generating a verification request for the data acquisition result includes: The data acquisition result is signed, and the signature and the data acquisition result are encapsulated to generate the verification request.

10. A data acquisition method based on blockchain, characterized in that, The method includes: Receive a verification request from the execution node; the verification request carries the data acquisition result obtained by the execution node based on the acquired external data, the external data being the data acquisition event triggered by the business party, whereby the execution node determines the external data source according to the data acquisition request if the local node identifier matches the target execution node identifier in the data acquisition event, and acquires the corresponding external data from the determined external data source; generated based on the external data and the local node identifier; Based on the verification request, external verification data is obtained from the external data source, and a node identifier is obtained from the data records of the external data source. The node identifier is used to indicate the execution node that has obtained external data from the external data source. The external data in the data acquisition result is verified based on the external verification data, and the local node identifier in the data acquisition result is verified based on the node identifier obtained from the data records of the external data source. If the data acquisition result is successfully verified, then the data acquisition result is signed; The signature is sent to the execution node so that if the number of signatures received exceeds a preset threshold, the execution node generates on-chain evidence based on the signature and the data acquisition result, and sends the on-chain evidence to the business party through the blockchain network.

11. The method according to claim 10, characterized in that, Receiving a verification request from the execution node includes: Receive the verification request sent by the execution node; or The receiving node allocator forwards a verification request from the execution node. The verification request is forwarded by the node allocator after selecting the corresponding verification node based on the verification request received from the execution node.

12. The method according to claim 10, characterized in that, The method further includes: Receive a verification service deployment request sent by the business party, wherein the verification service deployment request carries a verification service identifier and a list of verification node identifiers to be deployed; If the list of verification node identifiers to be deployed includes a local node identifier, then a data verification service corresponding to the verification service identifier is deployed; wherein, the data verification service is used to verify the data acquisition result contained in the verification request.

13. The method according to claim 12, characterized in that, The method further includes: When deploying the data verification service corresponding to the data verification service identifier, virtual resources are pledged to the virtual resource processor so that the virtual resource processor sends the pledged virtual resources to the blockchain network for storage. If it is necessary to cancel the deployed data verification service, apply to the virtual resource processor for the return of the pledged virtual resources so that other verification nodes can challenge the execution process of the local data verification service; If other verification nodes fail to complete the challenge during the challenge period, the virtual resources will be returned by the virtual resource processor through the blockchain network.

14. A data acquisition device based on blockchain, characterized in that, The device includes: The detection and acquisition module is used to detect data acquisition events triggered by the business party. The data acquisition event includes a target execution node identifier and a data acquisition request. If it is determined that the local node identifier matches the target execution node identifier in the data acquisition event, an external data source is determined according to the data acquisition request, and the corresponding external data is acquired from the determined external data source. A data acquisition result is generated based on the external data and the local node identifier. The generation and sending module is configured to generate a verification request for the data acquisition result based on the data acquisition result, send the verification request to a verification node, so that the verification node can obtain external verification data from the external data source based on the verification request, and obtain a node identifier from the data records of the external data source, the node identifier being used to indicate the execution node that has obtained external data from the external data source; verify the external data in the data acquisition result based on the external verification data, and verify the local node identifier in the data acquisition result based on the node identifier obtained from the data records of the external data source; The first receiving module is used to receive the signature triggered by the verification node when the data acquisition result is successfully verified; The generation and sending module is further configured to: if the number of received signatures exceeds a preset threshold, generate on-chain evidence based on the signature of the verification node and the data acquisition result, and send the on-chain evidence to the blockchain network so as to send the on-chain evidence to the business party through the blockchain network.

15. A blockchain-based data verification device, characterized in that, The device includes: The second receiving module is used to receive a verification request from the execution node; the verification request carries the execution result obtained by the execution node based on the acquired external data. The external data is generated by the execution node when detecting a data acquisition event triggered by the business party, and when it determines that the local node identifier matches the target execution node identifier in the data acquisition event, it determines the external data source according to the data acquisition request, and obtains the corresponding external data from the determined external data source; and it is generated based on the external data and the local node identifier. The verification module is used to obtain external verification data from the external data source based on the verification request, and to obtain a node identifier from the data records of the external data source, wherein the node identifier is used to indicate the execution node that has obtained external data from the external data source; to verify the external data in the data acquisition result based on the external verification data, and to verify the local node identifier in the data acquisition result based on the node identifier obtained from the data records of the external data source; The signature module is used to sign the data acquisition result if the data acquisition result is successfully verified. The sending module is used to send the signature to the execution node, so that the execution node can generate on-chain evidence based on the signature and the data acquisition result, and send the on-chain evidence to the business party through the blockchain network.

16. An electronic device, characterized in that, include: One or more processors; A storage device for storing one or more computer programs, which, when executed by the one or more processors, cause the electronic device to perform the method of any one of claims 1 to 9, or the method of any one of claims 10 to 14.

17. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed by the processor of the electronic device, causes the electronic device to perform the method described in any one of claims 1 to 9, or the method described in any one of claims 10 to 14.

18. A computer program product, characterized in that, The computer program product includes a computer program stored in a computer-readable storage medium, wherein a processor of an electronic device reads from and executes the computer program, causing the electronic device to perform the method of any one of claims 1 to 9, or to perform the method of any one of claims 10 to 14.

Images