An off-chain data acquisition system based on oracle cluster
Through the centralized collaboration and trusted management of the oracle cluster, the problems of low efficiency and insufficient security in the interaction between the blockchain system and external data are solved, efficient and secure off-chain data acquisition is achieved, and the interoperability and availability of the blockchain network are improved.
Patent Information
- Application Number
- CN202410918561.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2024-07-10
- Publication Date
- 2025-09-30
- Estimated Expiration
- 2044-07-10
AI Technical Summary
The blockchain system cannot directly interact with external systems for data, resulting in low data acquisition efficiency and insufficient security. The existing oracle technology in a decentralized mode has coordination and game processes that affect the timeliness and availability of the system.
It adopts an off-chain data acquisition system based on oracle clusters, forms a cluster through centralized oracle nodes, uses databases to implement event locks for collaboration, combines trusted institutions to manage off-chain data sources, and provides a unified interactive interface and high-availability services.
It improves data acquisition efficiency, reduces design complexity, ensures high availability and security of services, avoids the impact of coordination and game processes in a decentralized model on data timeliness, and enhances the interoperability of blockchain with the outside world.
Smart Images

Figure CN119316430B_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of off-chain data acquisition, and specifically to an off-chain data acquisition system based on an oracle cluster. Background Art
[0002] The concept of oracle in the computer field, first proposed by Turing, involves adding a special device called an "oracle" to a Turing machine to input information and help it complete calculations. The blockchain field has adopted this concept, calling the software or hardware that provides information to Turing-complete smart contracts an "oracle," or "foreign machine" in Chinese.
[0003] Blockchain is a deterministic and closed system. Limited by its inherent consensus mechanism, smart contracts cannot directly interact with external systems. Oracles, as crucial infrastructure within the blockchain ecosystem, establish trust through trusted computing or other technologies, providing trusted external data to smart contracts and building a bridge between them and the outside world. Furthermore, oracles, in a broader sense, offer capabilities such as random number generation and triggering the automatic execution of smart contracts. These capabilities not only enhance their traditional role in providing data but also help expand the application of blockchain technology in scenarios such as contract price feeds, insurance, trade, and the Internet of Things, significantly enhancing the practicality and flexibility of blockchain technology. Oracles are no longer simply providing data; they have become powerful tools that enable smart contracts to interact with the real world in more complex and sophisticated ways. Summary of the Invention
[0004] In response to the needs and shortcomings of current technological development, the present invention provides an off-chain data acquisition system based on an oracle cluster, which can improve the efficiency of data acquisition, reduce the complexity of design, and ensure the high availability of services.
[0005] The present invention provides an off-chain data acquisition system based on an oracle cluster, which solves the above technical problems using the following technical solutions:
[0006] An off-chain data acquisition system based on oracle clusters, suitable for Fabric blockchain networks, which includes system contracts, databases, and oracle clusters;
[0007] The system contract includes an oracle contract and a user contract. The oracle contract is responsible for providing the user contract with a unified interactive interface for obtaining external data. After verifying the request parameters of the user contract, it is encapsulated as a chain code event and sent to the oracle cluster. The user contract contains specific business-related logic, calls the corresponding interface in the oracle contract in a cross-contract manner, and then initiates an off-chain data acquisition request. It then accepts the call of the oracle contract to obtain the returned off-chain data and executes subsequent business processing logic.
[0008] The database implements event locks based on data tables. All oracle nodes in the oracle cluster share the same database, and any oracle node in the oracle cluster collaborates with the remaining oracle nodes through event locks.
[0009] The oracle cluster consists of one or more centralized oracle nodes. Each oracle node is responsible for listening to chaincode events from the oracle contract and obtaining the processing rights of chaincode events by preempting the event lock. The oracle node that obtains the processing rights first parses the chaincode event, obtains the off-chain data request parameters, and then assembles the request parameters, initiates a data request to the approved off-chain data source, and parses the response result. Finally, the oracle contract calls back the user contract and writes the response data back to the chain.
[0010] Optionally, the process for the off-chain data acquisition system to obtain off-chain data is as follows:
[0011] (1) Before starting the oracle node in the oracle cluster, perform preparation work: initialize the system contract and register the off-chain data source;
[0012] (2) The oracle node in the oracle cluster starts and obtains off-chain data:
[0013] (2.1) The user selects the target data source, adds relevant parameters, and calls the off-chain data request interface in the user contract;
[0014] (2.2) The user contract's request interface calls the corresponding data request interface in the oracle contract based on the data source type in the additional parameters. The oracle contract verifies the request parameters based on the built-in verification rules. After the verification passes, it returns a globally unique event ID to the user contract, encapsulates the request parameters into a chaincode event, and sends it to the oracle cluster.
[0015] (2.3) All oracle nodes in the oracle cluster monitor the chain code event at the same time and start to seize the event lock. If the event lock is successfully seized, the oracle node obtains the processing right of the chain code event. The oracle node that has not obtained the processing right is responsible for monitoring the processing status of the chain code event.
[0016] (2.4) The oracle node A that obtains the processing right first parses the chain code event, obtains the off-chain data request parameters, and then initiates a request to the data source based on the off-chain data request parameters. The off-chain data source is divided into HTTP type and database type.
[0017] a) For HTTP data sources, assemble the URL, Header, and Body parameters according to the specified request method, initiate an HTTP request, and parse the response result;
[0018] b) For database data sources, assemble the parameters Host, Port, Database, and User to establish a connection based on the specified database type, execute the SQL query, and parse the response results;
[0019] (2.5) Oracle node A assembles the parsed response data and calls the callback interface in the oracle contract. The callback interface in the oracle contract calls the callback interface in the user contract to write the off-chain data to the chain or execute subsequent business processing logic;
[0020] (2.6) The user queries the off-chain data acquisition results based on the event ID.
[0021] Optionally, execute step (1) to initialize the system contract. The specific process includes:
[0022] Call the initialization interface in the system contract to upload the name and identity information of the oracle node to the chain;
[0023] The initialization interface first checks whether this uplink information exists.
[0024] If it exists, return directly.
[0025] If it does not exist, the name of the oracle node is used as the key and the identity information of the oracle node is written into the chain as the value.
[0026] Optionally, before executing step (1), a trusted third-party organization acts as the oracle operator and uses a whitelist security policy to manage and limit the available off-chain data sources before registering the off-chain data source.
[0027] During the registration of an off-chain data source, the data source parameters provided by the oracle operator are first verified. After the verification is passed, the oracle service calls the registration interface in the oracle contract to write the data source parameters and related information to the chain.
[0028] Optionally, when the oracle service calls the registration interface in the oracle contract, it needs to authenticate the caller first, that is, check whether its identity is an oracle node.
[0029] If the authentication fails, the off-chain data source registration fails.
[0030] If the authentication is successful, the off-chain data source is successfully registered, and the data source parameters and related information are written to the chain.
[0031] Further, optionally, for HTTP data sources, the verification process includes: checking whether the request methods GET and POST are supported, whether the URL complies with the specification, and whether the data formats JSON, XML, HTML, and Plain are supported;
[0032] For database-type data sources, the verification process includes checking whether the database type is supported, whether the user has query permissions, and whether there is an injection risk in the SQL statement.
[0033] Further optionally, step (2.3) is executed, and all oracle nodes in the oracle cluster listen to the chain code event at the same time and start to seize the event lock. In this process, a record is inserted into the data table of the database with the event ID as the primary key. The record content contains the event lock version, oracle node name, creation time and update time. The event lock version indicates the number of times the event lock has been seized. The initial value is 1, and the value increases by 1 each time it is seized. If the oracle node successfully inserts the record into the data table, it indicates that the event lock has been seized successfully, and it obtains the processing right of the chain code event.
[0034] Further optionally, when executing step (2.3), the oracle node that has not obtained the processing right is responsible for monitoring the processing status of the chain code event, including: after the processing deadline of the chain code event at a certain stage is reached, checking the status of the chain code event in the database; if the chain code event does not flow as expected, it is considered as a processing timeout, and the oracle node that has not obtained the processing right can re-seize the event lock. If the event lock is successfully seized, the processing right of the chain code event is obtained. The oracle node B that obtains the processing right continues the subsequent processing according to the current status of the chain code event until the chain code event reaches the terminal state;
[0035] When the oracle node that has not obtained the processing right re-seizes the event lock, it uses the event ID, the name of the oracle node that currently seizes the event lock, and the update deadline of the event status as filtering conditions to update the event lock version and oracle node name in the data table. A successful update indicates that oracle node B has successfully seized the event lock, and oracle node A no longer has the processing right for the chaincode event.
[0036] Further optionally, the database is also used to store event processing status, event processing results, and off-chain data sources managed by the oracle operator.
[0037] Compared with the prior art, the off-chain data acquisition system based on the oracle cluster of the present invention has the following beneficial effects:
[0038] 1. The present invention consists of a cluster of centralized oracle nodes. Each node collaborates based on a database-based event lock and can be dynamically expanded according to system load, thereby improving the efficiency of data acquisition and reducing design complexity. It also ensures high service availability and avoids the impact of the coordination and negotiation process required for consensus among multiple nodes in a decentralized operation mode on data timeliness. It also avoids the impact of single point failures on system availability and improves the system's fault tolerance. At the same time, to ensure the authenticity and credibility of off-chain data, a trusted organization is used as the oracle operator, and a whitelist security policy is used to manage and limit available off-chain data sources, reducing potential security risks.
[0039] 2. This invention establishes a trusted data path between the blockchain network and the internet, enabling smart contracts to access internet data, breaking the limitation of smart contracts in accessing off-chain data. This not only improves the blockchain network's ability to interact with the outside world, but also further promotes the development of blockchain technology.
[0040] 3. The present invention adopts a centralized cluster operation mode, which avoids the impact of the coordination and game process between multiple nodes in the decentralized mode on the execution efficiency, and also ensures the high availability of the service; nodes can be dynamically added and deleted according to the load conditions, with good flexibility. BRIEF DESCRIPTION OF THE DRAWINGS
[0041] Attachment Figure 1 It is the system architecture and flow chart of the present invention. DETAILED DESCRIPTION
[0042] In order to make the technical solution, the technical problems solved and the technical effects of the present invention more clear, the technical solution of the present invention is clearly and completely described below in conjunction with specific embodiments.
[0043] The following is an explanation of some of the terms involved in the embodiment.
[0044] An oracle is a tool that provides trusted data to the blockchain, bridging the gap between the blockchain and the real world, allowing smart contracts to securely access and execute operations based on external data. The basic concept of an oracle: An oracle is a mechanism that feeds real-world data into the blockchain, enabling smart contracts to react to external information and becoming the only way for smart contracts to interact with external data. The function of an oracle: By providing external data to the blockchain, an oracle enables smart contracts to execute operations involving that data. Oracles provide a mechanism for closed, deterministic blockchain systems to interact with the uncertain external world. How an oracle works: An oracle obtains data from a reliable external source and transmits it to a smart contract. The smart contract then executes predefined logic based on the oracle data, triggering corresponding on-chain operations. There are three types of oracles: ① Centralized oracles, managed by a single center, may be easier to integrate and control, but carry the risk of centralization; ② Decentralized oracles, which do not rely on a single source, improve the system's reliability and tamper-resistance; ③ Consortium oracles, situated between centralized and decentralized approaches, comprised of multiple trusted nodes to provide data verification.
[0045] Smart contracts are self-executing codes stored on a blockchain that automatically execute, control, or record events and actions related to the contract terms when specific conditions are met. The core advantages of smart contracts lie in their automation, transparency, and immutability, making them particularly suitable for implementing decentralized applications (DApps).
[0046] An oracle contract is a special type of smart contract that can be modified and parameterized based on existing smart contract templates. Oracle contracts allow smart contracts on the blockchain to access external data. Acting as a bridge between the blockchain and the outside world, oracle contracts can provide data not stored on the blockchain (off-chain data), such as internet data, IoT device status, or information from other blockchains.
[0047] User contracts are smart contracts designed specifically for specific users or application scenarios. They can be modified and parameterized based on existing smart contract templates. Unlike oracle contracts, user contracts typically do not interact with external systems, focusing instead on business logic, permission control, and asset operations. User contracts can be customized to meet specific business needs, including asset management, identity verification, and voting systems. They provide users with a way to program and implement custom logic on the blockchain.
[0048] Example 1:
[0049] This embodiment proposes an off-chain data acquisition system based on an oracle cluster, which is applicable to the Fabric blockchain network. The system includes a system contract, a database, and an oracle cluster, wherein:
[0050] The system contract includes an oracle contract and a user contract. The oracle contract is responsible for providing the user contract with a unified interactive interface for obtaining external data. After verifying the request parameters of the user contract, it encapsulates them as chaincode events and sends them to the oracle cluster. The user contract contains specific business-related logic, calls the corresponding interface in the oracle contract in a cross-contract manner, and then initiates an off-chain data acquisition request. It then accepts the call of the oracle contract to obtain the returned off-chain data and executes subsequent business processing logic.
[0051] The database implements event locks based on data tables. All oracle nodes in the oracle cluster share the same database, and any oracle node in the oracle cluster collaborates with the remaining oracle nodes through event locks.
[0052] The oracle cluster consists of one or more centralized oracle nodes. Each oracle node is responsible for listening to chaincode events from the oracle contract and obtaining the processing rights of chaincode events by preempting the event lock. The oracle node that obtains the processing rights first parses the chaincode event, obtains the off-chain data request parameters, and then assembles the request parameters, initiates a data request to the approved off-chain data source, and parses the response result. Finally, the oracle contract calls back the user contract and writes the response data back to the chain.
[0053] The specific process of the off-chain data acquisition system of this embodiment acquiring off-chain data is as described in steps (1) and (2).
[0054] (1) Before starting the oracle node in the oracle cluster, perform the following preparations:
[0055] (1.1) Initialize the system contract. The specific process includes:
[0056] Call the initialization interface in the system contract to upload the name and identity information of the oracle node to the chain;
[0057] The initialization interface first checks whether this uplink information exists.
[0058] If it exists, return directly.
[0059] If it does not exist, the name of the oracle node is used as the key and the identity information of the oracle node is written into the chain as the value.
[0060] (1.2) Registering off-chain data sources. The specific process includes:
[0061] Before registering an off-chain data source, a trusted third-party organization will serve as the oracle operator and adopt a whitelist security policy to manage and limit the available off-chain data sources;
[0062] During the registration of an off-chain data source, the data source parameters provided by the oracle operator are first verified. After the verification passes, the oracle service calls the registration interface in the oracle contract to authenticate the caller, that is, to check whether its identity is an oracle node.
[0063] If the authentication fails, the off-chain data source registration fails.
[0064] If the authentication is successful, the off-chain data source is successfully registered, and the data source parameters and related information are written to the chain.
[0065] It should be added that off-chain data sources are divided into HTTP type and database type.
[0066] It should be added that SSL / TLS encrypted communication protocols are enabled between off-chain data sources and oracle clusters, and between oracle clusters and blockchain services to establish an end-to-end secure transmission channel.
[0067] (2) The oracle node in the oracle cluster starts to obtain off-chain data, including the following operations:
[0068] (2.1) The user selects the target data source, adds relevant parameters, and calls the off-chain data request interface in the user contract.
[0069] (2.2) The request interface of the user contract calls the corresponding data request interface in the oracle contract according to the data source type in the additional parameters. The oracle contract verifies the request parameters based on the built-in verification rules. After the verification is passed, it returns a globally unique event ID to the user contract, encapsulates the request parameters into a chain code event, and sends it to the oracle cluster.
[0070] It should be added that: off-chain data sources are divided into HTTP type and database type;
[0071] For HTTP data sources, the verification process includes: checking whether the request methods GET and POST are supported, whether the URL complies with the standard, and whether the data formats JSON, XML, HTML, and Plain are supported;
[0072] For database-type data sources, the verification process includes checking whether the database type is supported, whether the user has query permissions, and whether there is an injection risk in the SQL statement.
[0073] (2.3) All oracle nodes in the oracle cluster simultaneously monitor the chain code event and start to seize the event lock. That is, with the event ID as the primary key, a record is inserted into the database table. The record content contains the event lock version, oracle node name, creation time and update time. The event lock version indicates the number of times the event lock has been seized. The initial value is 1 and the value increases by 1 each time it is seized. If oracle node A successfully inserts a record into the data table, it indicates that the event lock has been seized successfully and it obtains the processing right of the chain code event.
[0074] The oracle node that has not obtained the processing right is responsible for monitoring the processing status of the chaincode event, including: after the processing deadline of the chaincode event at a certain stage is reached, checking the status of the chaincode event in the database.
[0075] It should be added that: if the chain code event does not flow as expected and is deemed to have timed out, the oracle node that has not obtained the processing right will immediately re-seize the event lock, that is, using the event ID, the name of the oracle node that currently seizes the event lock, and the update deadline of the event status as filtering conditions, and update the event lock version and oracle node name in the data table. A successful update indicates that oracle node B has successfully seized the event lock, and oracle node A no longer has the processing right for the chain code event. The oracle node B that has obtained the processing right will continue to process the subsequent events according to the current status of the chain code event until the chain code event reaches the termination state.
[0076] (2.4) The oracle node A that obtains the processing right first parses the chain code event, obtains the off-chain data request parameters, and then initiates a request to the data source based on the off-chain data request parameters.
[0077] a) For HTTP data sources, assemble the URL, Header, and Body parameters according to the specified request method, initiate an HTTP request, and parse the response result;
[0078] b) For database data sources, assemble the parameters Host, Port, Database, and User to establish a connection based on the specified database type, execute the SQL query, and parse the response results;
[0079] (2.5) Oracle node A assembles the parsed response data and calls the callback interface in the oracle contract. The callback interface in the oracle contract calls the callback interface in the user contract to write the off-chain data to the chain or execute subsequent business processing logic;
[0080] (2.6) The user queries the off-chain data acquisition results based on the event ID.
[0081] In summary, the off-chain data acquisition system based on the oracle cluster of the present invention avoids the impact of the coordination and game process required for reaching consensus between multiple nodes in a decentralized operation mode on data timeliness, and also avoids the impact of single point failures on system availability, thereby improving the system's fault tolerance.
[0082] The above specific examples are used to illustrate the principles and implementation methods of the present invention in detail. These examples are only used to help understand the core technical content of the present invention. Based on the above specific embodiments of the present invention, any improvements and modifications made by those skilled in the art without departing from the principles of the present invention should fall within the scope of patent protection of the present invention.
Claims
1. An off-chain data acquisition system based on oracle cluster, applicable to Fabric blockchain network, characterized by: Including system contracts, databases, and oracle clusters; The system contract includes an oracle contract and a user contract. The oracle contract is responsible for providing the user contract with a unified interactive interface for obtaining external data. After verifying the request parameters of the user contract, it is encapsulated as a chain code event and sent to the oracle cluster. The user contract contains specific business-related logic, calls the corresponding interface in the oracle contract in a cross-contract manner, and then initiates an off-chain data acquisition request. It then accepts the call of the oracle contract to obtain the returned off-chain data and executes subsequent business processing logic. The database implements event locks based on data tables. All oracle nodes in the oracle cluster share the same database, and any oracle node in the oracle cluster collaborates with the remaining oracle nodes through event locks. The oracle cluster consists of one or more centralized oracle nodes. Each oracle node is responsible for listening to chaincode events from the oracle contract and obtaining the processing rights of chaincode events by preempting the event lock. The oracle node that obtains the processing rights first parses the chaincode event, obtains the off-chain data request parameters, and then assembles the request parameters, initiates a data request to the approved off-chain data source, and parses the response result. Finally, the oracle contract calls back the user contract and writes the response data back to the chain.
2. The off-chain data acquisition system based on oracle cluster according to claim 1 is characterized in that: The process of the system obtaining off-chain data is as follows: (1) Before starting the oracle node in the oracle cluster, perform preparation work: initialize the system contract and register the off-chain data source; (2) The oracle node in the oracle cluster starts and obtains off-chain data: (2.1) The user selects the target data source, adds relevant parameters, and calls the off-chain data request interface in the user contract; (2.2) The user contract's request interface calls the corresponding data request interface in the oracle contract based on the data source type in the additional parameters. The oracle contract verifies the request parameters based on the built-in verification rules. After the verification passes, it returns a globally unique event ID to the user contract, encapsulates the request parameters into a chaincode event, and sends it to the oracle cluster. (2.3) All oracle nodes in the oracle cluster monitor the chain code event at the same time and start to seize the event lock. If the event lock is successfully seized, the oracle node obtains the processing right of the chain code event. The oracle node that has not obtained the processing right is responsible for monitoring the processing status of the chain code event. (2.4) The oracle node A that obtains the processing right first parses the chain code event, obtains the off-chain data request parameters, and then initiates a request to the data source based on the off-chain data request parameters. The off-chain data source is divided into HTTP type and database type. a) For HTTP data sources, assemble the URL, Header, and Body parameters according to the specified request method, initiate an HTTP request, and parse the response result; b) For database data sources, assemble the parameters Host, Port, Database, and User to establish a connection based on the specified database type, execute the SQL query, and parse the response results; (2.5) Oracle node A assembles the parsed response data and calls the callback interface in the oracle contract. The callback interface in the oracle contract calls the callback interface in the user contract to write the off-chain data to the chain or execute subsequent business processing logic; (2.6) The user queries the off-chain data acquisition results based on the event ID.
3. The off-chain data acquisition system based on oracle cluster according to claim 2 is characterized in that: Execute step (1) to initialize the system contract. The specific process includes: Call the initialization interface in the system contract to upload the name and identity information of the oracle node to the chain; The initialization interface first checks whether this uplink information exists. If it exists, return directly. If it does not exist, the name of the oracle node is used as the key and the identity information of the oracle node is written into the chain as the value.
4. The off-chain data acquisition system based on oracle cluster according to claim 2 is characterized in that: Execute step (1). Before registering an off-chain data source, a trusted third-party organization will act as the oracle operator and use a whitelist security policy to manage and limit the available off-chain data sources. During the registration of an off-chain data source, the data source parameters provided by the oracle operator are first verified. After the verification is passed, the oracle service calls the registration interface in the oracle contract to write the data source parameters and related information to the chain.
5. The off-chain data acquisition system based on oracle cluster according to claim 4 is characterized in that: When the oracle service calls the registration interface in the oracle contract, it needs to authenticate the caller first, that is, check whether its identity is an oracle node. If the authentication fails, the off-chain data source registration fails. If the authentication is successful, the off-chain data source is successfully registered, and the data source parameters and related information are written to the chain.
6. The off-chain data acquisition system based on oracle cluster according to claim 4 is characterized in that: For HTTP data sources, the verification process includes: checking whether the request methods GET and POST are supported, whether the URL complies with the standard, and whether the data formats JSON, XML, HTML, and Plain are supported; For database-type data sources, the verification process includes checking whether the database type is supported, whether the user has query permissions, and whether there is an injection risk in the SQL statement.
7. The off-chain data acquisition system based on oracle cluster according to claim 2 is characterized in that: Execute step (2.3). All oracle nodes in the oracle cluster listen to the chain code event at the same time and start to seize the event lock. In this process, a record is inserted into the data table of the database with the event ID as the primary key. The record content contains the event lock version, oracle node name, creation time and update time. The event lock version indicates the number of times the event lock has been seized. The initial value is 1, and the value increases by 1 each time it is seized. If the oracle node successfully inserts a record into the data table, it indicates that the event lock has been seized successfully, and it obtains the right to process the chain code event.
8. The off-chain data acquisition system based on oracle cluster according to claim 7 is characterized in that: When executing step (2.3), the oracle node that has not obtained the processing right is responsible for monitoring the processing status of the chain code event, including: after the processing deadline of the chain code event at a certain stage is reached, the status of the chain code event in the database is checked. If the chain code event does not flow as expected, it is considered as a processing timeout. The oracle node that has not obtained the processing right can re-seize the event lock. If the event lock is successfully seized, the processing right of the chain code event is obtained. The oracle node B that obtains the processing right continues the subsequent processing according to the current status of the chain code event until the chain code event reaches the terminal state; When the oracle node that has not obtained the processing right re-seizes the event lock, it uses the event ID, the name of the oracle node that currently seizes the event lock, and the update deadline of the event status as filtering conditions to update the event lock version and oracle node name in the data table. A successful update indicates that oracle node B has successfully seized the event lock, and oracle node A no longer has the processing right for the chaincode event.
9. The off-chain data acquisition system based on oracle cluster according to claim 2 is characterized in that: The database is also used to store event processing status, event processing results, and off-chain data sources that are managed by the oracle operator.
Citation Information
Patent Citations
Digital certificate system and method based on TEE oracle cluster and block chain
CN114465817A
Trusted data uplink method and system based on distributed oracle machine
CN117555910A