Blockchain-based trusted oracle system in high-concurrency data environment

Abstract

The application belongs to the technical field of block chain and particularly relates to a trusted oracle system in a high-concurrency data environment based on a block chain. The system comprises a resource node module for providing computing or storage resources and actively publishing an index set when a state changes; each index in the index set contains a timestamp, a signature and a state hash; an oracle node module for executing off-chain data collection and snapshot generation, being responsible for signature verification, bitmap difference detection and timing alignment; a real-time Byzantine small member meeting module for realizing point-to-point communication and data exchange between nodes through a distributed container network; an aggregated contract module for executing trusted aggregation, confidence calculation, global state updating and exception elimination; and a global resource table module for storing the latest trusted aggregation result of each resource and providing a unified read-only interface for an upper-layer smart contract.

Description

Technical Field

[0001] This invention belongs to the field of blockchain technology, specifically relating to a trusted oracle system based on blockchain in a high-concurrency data environment. Background Technology

[0002] With the widespread application of blockchain in fields such as the Internet of Things (IoT) and its gradual expansion into new application scenarios such as energy trading and data element circulation, on-chain smart contracts are increasingly reliant on real-time external trusted data. Oracle systems, acting as a bridge between the blockchain and the real world, play a crucial role in data collection, verification, and on-chain transmission during the execution of on-chain smart contracts. Their main task is to acquire real-world data from multiple external sources and transmit it to on-chain smart contracts in a reliable manner to ensure the automated execution of contracts and the reliability of their results.

[0003] Most current mainstream oracle systems adopt a layered structure of off-chain aggregation and on-chain verification. In this architecture, multiple independent nodes are responsible for collecting external data, calculating the aggregation result through weighted averaging or voting mechanisms, and then submitting the result to the on-chain contract. However, with the rapid increase in the scale and frequency of data interaction, this synchronous aggregation mode has exposed significant bottlenecks. On the one hand, off-chain nodes are prone to problems such as response latency, data backlog, and queue congestion under high-concurrency tasks, resulting in insufficient overall throughput. On the other hand, on-chain contracts are limited by block size and block generation rate during the consensus verification process, making it impossible to synchronize massive amounts of external data in real time. In addition, existing oracle systems mostly lack dynamic task scheduling and load balancing mechanisms, making it difficult to adapt to the needs of elastic node scaling and data bursts in cloud-native environments.

[0004] Regarding data credibility, traditional oracle systems generally rely on static signatures or voting mechanisms to confirm data sources, lacking systematic node reputation assessment models and truth discovery algorithms. This makes it difficult to effectively identify and suppress malicious nodes' erroneous data submissions. Some nodes may generate biased data due to network latency, system overload, or profit-driven motives, causing aggregation results to deviate from the true value and thus affecting the correctness of smart contract execution. Furthermore, the lack of efficient asynchronous collaboration mechanisms between on-chain and off-chain processes means that data collection, aggregation, and evidence storage are often performed sequentially, resulting in long overall system response times and low resource utilization.

[0005] Therefore, it is very important to design a blockchain-based trusted oracle system for high-concurrency data environments that can achieve robustness and interpretability in on-chain aggregation and significantly improve the system's real-time consistency and global trusted state update capabilities in high-concurrency data environments. Summary of the Invention

[0006] This invention aims to overcome the performance bottlenecks in real-time performance, reliability, and throughput of existing oracle systems in cloud-native high-concurrency data environments. It provides a blockchain-based trusted oracle system for high-concurrency data environments that can achieve robustness and interpretability through on-chain aggregation, significantly improving the system's real-time consistency and global trusted state update capabilities in high-concurrency data environments.

[0007] To achieve the above-mentioned objectives, the present invention adopts the following technical solution:

[0008] A trusted oracle system based on blockchain for high-concurrency data environments includes:

[0009] The resource node module is used to provide computing or storage resources and proactively publish indicator sets when the state changes. Each metric contains a timestamp, signature, and state hash;

[0010] The oracle node module is used to perform off-chain data collection and snapshot generation, and is responsible for signature verification, bitmap difference detection and timing alignment;

[0011] The Real-Time Byzantine Small Members Module is used to enable point-to-point communication and data exchange between nodes through a distributed container network.

[0012] The aggregation contract module is used to perform trusted aggregation, confidence calculation, global state update, and anomaly removal.

[0013] The global resource table module stores the latest trusted aggregation results for each resource, providing a unified read-only interface for upper-layer smart contracts.

[0014] Preferably, the oracle node module adopts a "dual-channel task queue + dynamic token bucket rate limiting mechanism" model to achieve load adaptation in a high-concurrency environment; wherein, the dual-channel task queue specifically includes:

[0015] Fast Track It is used to handle requests with high real-time requirements;

[0016] Buffer Channel , used to perform delay-tolerant batch processing;

[0017] The scheduler is based on system latency With task backlog Calculate the channel allocation weights for fast channel and cached communication. : ;

[0018] The weights are dynamically adjusted; changes in weights drive tasks to migrate between the two queues in real time, thereby maintaining the steady-state throughput of the system.

[0019] Preferably, the dynamic token bucket rate limiting mechanism specifically includes the following process:

[0020] For each channel, two independent token buckets are set. The corresponding release rates are as follows: ;

[0021] in and These are the sending rates for the fast channel and the buffered channel, respectively. and These represent the number of requests waiting to be processed in the current queue within the same time window for each of the two channels. To average out the time to process a request, the system dynamically adjusts the bucket capacity when resource availability changes suddenly or network latency increases. : ;

[0022] in For the adjusted bucket capacity, For adjustment coefficients, This represents the current load volatility.

[0023] Preferably, the real-time Byzantine small member meeting module includes member verification logic and a freshness tracking mechanism; in the real-time Byzantine small member meeting module, each resource node and... Each oracle node is bound together to form a Byzantine fault-tolerant structure, satisfying... ,in It represents the number of malicious oracle nodes;

[0024] The member verification logic includes the following process:

[0025] Each member node Received resource status Calculation and average deviation : ;

[0026] like If so, the corresponding member node is determined to be valid, where The value is a preset positive integer; otherwise, the corresponding member node is removed and a re-collection process is triggered.

[0027] Setting members will aggregate results for: ;

[0028] The freshness tracking mechanism includes the following process:

[0029] Resource node generates bitmap Identify the changed field; The rate of change of resources is calculated by dividing the change in resources by the total amount of resources. Exceeding the threshold or exceeding the maximum silence time This will trigger snapshot generation, as shown in the following formula: .

[0030] in, For trigger signals that can be detected by oracle nodes, The threshold for the rate of change of resources that we set.

[0031] Preferably, the trusted aggregation in the aggregation contract module specifically includes the following process:

[0032] Configure each node to maintain a reputation value as follows: ;

[0033] in, To improve the success rate of submissions, For stability, The penalty coefficient is... , and All are weighted parameters;

[0034] The real-time normalization of the reputation score is expressed by the following formula: ;

[0035] In the sliding time window Internally, the snapshots from each node are weighted and aggregated. The aggregation result at time t: ;

[0036] in This refers to the snapshot value reported by the node.

[0037] Preferably, the confidence calculation in the aggregation contract module specifically includes the following process:

[0038] Set the confidence level of the aggregation results. for: ;

[0039] in Standard deviation It is a preset positive integer. This is the average value of the data across all nodes.

[0040] when If the result is satisfactory, it is considered reliable and written to the global resource table; otherwise, a re-collection is triggered. This is the minimum confidence threshold we set.

[0041] Preferably, the global state update in the aggregation contract module specifically includes the following process:

[0042] Set on-chain aggregation within a continuous sliding time window Execute within the current time, where t is the current time.

[0043] The window length is dynamically adjusted as follows: ;

[0044] in This represents the current data update frequency. For window length, Maximum window length;

[0045] State updates are stored using a hash digest method, as shown in the following formula: ;

[0046] in The hash value for state updates. As a unique identifier for resource nodes, For timestamps, To aggregate relevant metadata (such as reputation summaries). Use a hash function to perform hash operations;

[0047] And record the version number: ;

[0048] in, This is the current version number. This is the previous version number;

[0049] Final global resource table storage structure as follows: ;

[0050] Each aggregation result generates a snapshot index. : ;

[0051] The contract provides an asynchronous interface, verifySnapshot(Index), for node replay or external verification.

[0052] Preferably, the anomaly removal in the aggregation contract module specifically includes the following process:

[0053] After each round of aggregation, the reputation is updated based on the node deviation: ;

[0054] in, For the updated reputation, The learning rate is used to adjust the rate of change in reputation.

[0055] when Once a time node enters a cooldown period, no more tasks will be assigned.

[0056] System each After round aggregation, global reputation normalization is performed.

[0057] As a preferred option, a cross-membership consensus verification module is also included, which specifically includes the following process:

[0058] When the same resource node is in multiple partitions or clusters, different members will output local results. Second-level consistency verification needs to be performed on-chain, and the specific formula is as follows: ;

[0059] in, Aggregate results for all member associations; if the differences between different member associations exceed the cross-member association difference threshold... If so, cross-member aggregation will be retried.

[0060] Compared with the prior art, the beneficial effects of this invention are: (1) Proposing a high-concurrency trusted oracle collaborative architecture driven by on-chain aggregation: This invention constructs a two-layer collaborative architecture with on-chain aggregation as the core and off-chain real-time collection as the support; the system realizes concurrent collection and cross-verification of multi-source data through a three-layer structure of resource nodes, oracle nodes and small member associations; the on-chain aggregation contract uniformly executes snapshot verification and trusted result generation, forming a closed-loop mechanism from off-chain real-time collection to on-chain global state update; this architecture can achieve high-concurrency processing and consistent updates in a large-scale dynamic resource environment, breaking through the performance bottleneck of traditional oracle linear aggregation and asynchronous on-chain; (2) Designing a trusted collection mechanism combining real-time Byzantine small member associations and freshness tracking: This invention introduces a real-time Byzantine small member association (RT-BFT) structure in the off-chain data collection layer, and realizes fault-tolerant verification through node binding and redundant collection, so that trusted results can still be obtained even if any single node fails or acts maliciously. ; At the same time, combined with the freshness tracking mechanism (FreshBit), the resource node generates a state bitmap and performs field-level change detection. When the indicator exceeds the threshold or is not updated within the time limit, a snapshot is automatically triggered for reporting. This mechanism ensures the high reliability and real-time performance of data collection, so that the on-chain aggregation process is always based on the latest and most reliable data input. (3) An on-chain trusted update method based on sliding window aggregation and confidence assessment is proposed: This invention designs a sliding time window mechanism in the aggregation contract layer, dynamically collects snapshots of multiple oracle nodes and performs weighted aggregation, uses majority voting, weighted median or anomaly elimination algorithm to generate the final trusted result, and calculates the data confidence score. The aggregation result is stored and indexed in real time through the global resource table (GRT), providing a unified trusted query interface for the upper-layer smart contract. (4) This invention realizes the robustness and interpretability of on-chain aggregation, and significantly improves the real-time consistency and global trusted state update capability of the system in a high-concurrency data environment. Attached Figure Description

[0061] Figure 1 This is a schematic diagram of a trusted oracle system based on blockchain in a high-concurrency data environment, according to the present invention. Detailed Implementation

[0062] To more clearly illustrate the embodiments of the present invention, specific implementation methods will be described below with reference to the accompanying drawings. Obviously, the drawings described below are merely some embodiments of the present invention. For those skilled in the art, other drawings and other implementation methods can be obtained based on these drawings without any creative effort.

[0063] This invention addresses the performance bottlenecks of oracle systems in terms of real-time performance, reliability, and throughput in cloud-native high-concurrency data environments by proposing a reliable oracle system based on blockchain for such environments.

[0064] The system achieves rapid consistency maintenance of multi-source dynamic data in the on-chain global state table through a closed-loop trusted update model of "off-chain real-time collection - on-chain trusted aggregation - snapshot lightweight on-chain".

[0065] Specifically, the system principle proposed in this invention is as follows: Figure 1 As shown, the overall system mainly consists of 5 modules, as described below:

[0066] Resource nodes, oracle nodes, Real-time Byzantine Fault Tolerance Committee (RT-BFT Committee), Aggregation Contract, Global Resource Table (GRT).

[0067] The resource node module is used to provide computing or storage resources and proactively publish indicator sets when the state changes. Each metric contains a timestamp, signature, and state hash;

[0068] The oracle node module is used to perform off-chain data collection and snapshot generation, and is responsible for signature verification, bitmap difference detection and timing alignment;

[0069] The Real-Time Byzantine Small Member Meeting module is used to enable point-to-point communication and data exchange between nodes through a distributed container network; each resource node and Each oracle node is bound together to form a Byzantine fault-tolerant structure, satisfying... ,in It represents the number of malicious oracle nodes; it can still maintain consistent output even when some nodes fail.

[0070] The aggregation contract module is used to perform trusted aggregation, confidence calculation, global state update, and anomaly removal.

[0071] The global resource table module stores the latest trusted aggregation results for each resource, providing a unified read-only interface for upper-layer smart contracts.

[0072] The overall information flow path of the system is as follows:

[0073] Resource Node → Oracle Node → Real-time Byzantine Small Member Meeting → Aggregate Contract → Global Resource Table.

[0074] Furthermore, the oracle node module adopts a "dual-channel task queue + dynamic token bucket rate limiting mechanism" model to achieve load adaptation in high-concurrency environments; wherein, the dual-channel task queue specifically includes:

[0075] Fast Track It is used to handle requests with high real-time requirements;

[0076] Buffer Channel , used to perform delay-tolerant batch processing;

[0077] The scheduler is based on system latency With task backlog Calculate the allocation weights for fast channel and cached communication. : ;

[0078] The weights are dynamically adjusted; changes in weights drive tasks to migrate between the two queues in real time, thereby maintaining the steady-state throughput of the system.

[0079] The dynamic token bucket rate limiting mechanism specifically includes the following process:

[0080] For each channel, two independent token buckets are set. The corresponding release rates are as follows: ;

[0081] in and These are the sending rates for the fast channel and the buffered channel, respectively. and These represent the number of requests waiting to be processed in the current queue within the same time window for each of the two channels. To average out the time to process a request, the system dynamically adjusts the bucket capacity when resource availability changes suddenly or network latency increases. : ;

[0082] in For the adjusted bucket capacity, For adjustment coefficients, This represents the current load volatility.

[0083] This mechanism ensures a stable response time even under high-concurrency burst input.

[0084] Furthermore, the real-time Byzantine small group meeting module includes member verification logic and a freshness tracking mechanism;

[0085] The member verification logic includes the following process:

[0086] Each member node Received resource status Calculation and average deviation : ;

[0087] like If so, the corresponding member node is determined to be valid, where The value is a sufficiently small positive integer; otherwise, the corresponding member node is removed and a re-collection process is triggered.

[0088] Setting members will aggregate results for: ;

[0089] The freshness tracking mechanism includes the following process:

[0090] Resource node generates bitmap Identify the changed field; The rate of change of resources is calculated by dividing the change in resources by the total amount of resources. Exceeding the threshold or exceeding the maximum silence time This will trigger snapshot generation, as shown in the following formula: .

[0091] in, For trigger signals that can be detected by oracle nodes, The threshold for the rate of change of resources that we set.

[0092] This mechanism ensures the freshness and timeliness of aggregated data on the blockchain.

[0093] Furthermore, the trusted aggregation in the aggregation contract module specifically includes the following process:

[0094] Configure each node to maintain a reputation value as follows: ;

[0095] in, To improve the success rate of submissions, For stability, The penalty coefficient is... , and All are weighted parameters;

[0096] The real-time normalization of the reputation score is expressed by the following formula: ;

[0097] In the sliding time window Internally, the snapshots from each node are weighted and aggregated. The aggregation result at time t: ;

[0098] in This refers to the snapshot value reported by the node.

[0099] Preferably, the confidence calculation in the aggregation contract module specifically includes the following process:

[0100] Set the confidence level of the aggregation results. for: ;

[0101] in Standard deviation The value is a sufficiently small positive integer. This is the average value of the data across all nodes.

[0102] when If the result is satisfactory, it is considered reliable and written to the global resource table; otherwise, a re-collection is triggered. This is the minimum confidence threshold we set.

[0103] The global state update in the aggregation contract module specifically includes the following process:

[0104] Set on-chain aggregation within a continuous sliding time window Execute within the current time, where t is the current time.

[0105] The window length is dynamically adjusted as follows: ;

[0106] in This represents the current data update frequency. For window length, Maximum window length;

[0107] State updates are stored using a hash digest method, as shown in the following formula: ;

[0108] in The hash value for state updates. As a unique identifier for resource nodes, For timestamps, To aggregate relevant metadata (such as reputation summaries). Use a hash function to perform hash operations;

[0109] And record the version number: ;

[0110] in, This is the current version number. This is the previous version number;

[0111] Final global resource table storage structure as follows: ;

[0112] Each aggregation result generates a snapshot index. : ;

[0113] The contract provides an asynchronous interface, verifySnapshot(Index), for node replay or external verification.

[0114] The verification logic is as follows:

[0115] 1. Check the incrementality of the snapshot serial number: ;

[0116] 2. Verify timestamp offset: ;

[0117] 3. Verify the validity of the signature and the consistency of the hash.

[0118] If the verification passes, the snapshot status is set to valid; otherwise, an exception log is recorded and arbitration is triggered.

[0119] The anomaly removal process in the aggregation contract module specifically includes the following steps:

[0120] After each round of aggregation, the reputation is updated based on the node deviation: ;

[0121] in, For the updated reputation, The learning rate is used to adjust the rate of change in reputation.

[0122] when Once a time node enters a cooldown period, no more tasks will be assigned.

[0123] System each After round aggregation, global reputation normalization is performed to prevent reputation imbalance and improve the fairness of node participation.

[0124] This system also includes a cross-membership consistency verification module, which specifically includes the following processes:

[0125] When the same resource node is in multiple partitions or clusters, different members will output local results. Second-level consistency verification needs to be performed on-chain, and the specific formula is as follows:

[0126] ;

[0127] in, Aggregate results for all member associations; if the differences between different member associations exceed the cross-member association difference threshold... Then cross-member aggregation will be retried.

[0128] Based on the technical solution of this invention, the implementation process of this invention in practical applications will be illustrated through the following case scenarios. The specific application implementation scheme is as follows:

[0129] (1) System overall structure and implementation ideas

[0130] The trusted oracle system proposed in this invention has completed prototype-level verification and cloud deployment. The system adopts a closed-loop structure of "collection—verification—aggregation—update—access". The connection relationships and operation modes of each component are explained below in conjunction with the specific product structure and operation process.

[0131] (2) Implementation example of resource node layer

[0132] In this embodiment, the system is deployed in a cloud-native environment consisting of thousands of resource nodes, several oracle nodes, and chain nodes. Each resource node runs a lightweight daemon process to monitor device metrics such as CPU, memory, latency, bandwidth, and throughput. The daemon process is written in Go and uses a combination of polling and event triggering to automatically generate a status report when performance fluctuations exceed a set threshold or when there has been no update for an extended period.

[0133] In this embodiment, the message includes at least the following fields: Resource Node Identifier (RID), a set of resource performance metrics (including CPU utilization, memory usage, network latency and throughput, etc.), timestamp (ts), local incrementing sequence number (seq), and digital signature (sigR) generated based on the node's private key.

[0134] Among them, the resource node identifier can be generated by hashing the host identifier and the unique identifier; the performance index is used to reflect the current operating status of the resource; the timestamp is used to identify the time when the data was generated; the sequence number is used to ensure the order of messages; and the digital signature is used to ensure the authenticity and integrity of the data source.

[0135] The generated status message is sent in parallel to multiple bound oracle nodes via an encrypted communication channel. This multi-path reporting mechanism ensures that even if individual nodes malfunction, data interruption or delay will not occur.

[0136] (3) Implementation example of oracle node layer

[0137] The oracle node layer is the core computing unit of the entire system, used to receive state packets from resource nodes and perform verification and snapshot generation. Upon receiving data, the node immediately checks the signature validity and uses a FreshBit bitmap to detect changed fields. If significant changes are found or a time threshold is exceeded, a snapshot structure is generated, recording only the changed fields and their hashes to reduce communication load.

[0138] The snapshot includes at least the following: Resource Node Identifier (RID), Oracle Node Identifier (OID), set of changed indicator fields, corresponding indicator values, bitmap of field changes, timestamp (ts), hash or Merkle proof used to prove the consistency of data source, and digital signature (sigO) generated by the oracle node.

[0139] Among them, the field set and bitmap are used to identify which indicators have changed, thereby avoiding the repeated transmission of unchanged data; the proof field is used to enhance data verifiability; and the signature is used to ensure the credibility of the snapshot source.

[0140] The snapshot is then entered into the scheduling queue and submitted to the chain according to the priority policy.

[0141] (4) Real-time Byzantine small member meeting implementation example

[0142] A real-time Byzantine small member module is deployed above the off-chain layer, with each resource node corresponding to a small member consisting of four oracle nodes. This structure enables peer-to-peer communication and data exchange between nodes through a distributed container network.

[0143] Once members have collected three or more snapshots, a reliable result is calculated based on the median rule: ;

[0144] If a node's result deviates beyond a preset threshold, its data is removed, and its reputation value is automatically reduced on the chain. Members will complete the aggregation within a short time window and package the signed results into a snapshot package. Then, it is submitted to the submitCommitteeSnapshot() method of the on-chain aggregation contract via a remote call interface.

[0145] (5) Implementation example of on-chain aggregation contract layer

[0146] The on-chain aggregation contract is written in Solidity and runs on an EVM-compatible blockchain platform. The contract receives snapshot data reported by multiple members within a sliding time window. Perform weighted aggregation calculations internally.

[0147] The weight of each node is determined based on its reputation score: ;

[0148] in, To improve the node submission success rate, For node stability, The number of times a penalty is imposed.

[0149] The formula for calculating the aggregate value is: ;

[0150] The confidence level is calculated using the following formula: ;

[0151] When the confidence level reaches a preset threshold, the aggregation result is written to the global resource table; otherwise, the system triggers a re-collection process. The contract sends an event log upon successful update, recording the version number, resource identifier, and confidence level.

[0152] (6) Global resource table and user contract layer instance

[0153] The aggregation results are written to the Global Resource Table (GRT) to store the latest trusted status of each resource node.

[0154] For each resource node, the resource table records at least the following information:

[0155] The current status version number (ver) is used to identify the number of status updates;

[0156] Last update time (ts) is used to reflect the timeliness of data;

[0157] The resource status summary (metricsHash) is a fixed-length representation obtained by hashing the aggregation result.

[0158] The confidence score (conf) describes the degree of confidence in the current state.

[0159] The resource table is stored using resource node identifiers as indexes and provides a read-only access interface through smart contracts for upper-layer applications to query and call.

[0160] (7) System Deployment and Environment Description

[0161] During deployment, resource nodes, oracle nodes, member nodes, and blockchain nodes all run in a containerized manner. Containers are isolated and maintain secure communication through a service mesh network, and the entire system synchronizes its clock via NTP. On-chain contracts and off-chain modules interact via RPC interfaces for message exchange and event callbacks, thus forming a stable asynchronous communication mechanism.

[0162] The system can operate stably under large-scale deployment conditions, with on-chain state update latency in the hundreds of milliseconds range, and the concurrent processing capabilities of resource nodes and oracle nodes can support large-scale data input.

[0163] (8) Summary of Cases

[0164] Through the aforementioned engineering implementation, the trusted oracle system of this invention forms a complete, practically deployable example. The interfaces between modules are clear, the interaction relationships are explicit, and the data flow is orderly, achieving a closed loop from off-chain real-time data collection to on-chain trusted aggregation and state updates.

[0165] This embodiment verifies the feasibility and operability of the present invention, and provides a directly reproducible implementation path for trusted data synchronization in high-concurrency blockchain scenarios.

[0166] The innovative aspects of this invention are as follows:

[0167] 1. Implement a multi-queue parallel scheduling mechanism off-chain to ensure the stability of the data input end;

[0168] 2. Introduce a weighted aggregation mechanism based on reputation and sliding window on the blockchain to ensure the verifiability and credibility of data truth.

[0169] 3. By significantly reducing on-chain write burden through lightweight snapshot and indexing mechanisms, millisecond-level synchronous updates are achieved;

[0170] 4. Introduce a dynamic confidence evaluation function and a real-time Byzantine committee to resist malicious node behavior and transient interference.

[0171] The above description is merely a detailed explanation of preferred embodiments and principles of the present invention. For those skilled in the art, there may be changes in specific implementation methods based on the ideas provided by the present invention, and these changes should also be considered within the scope of protection of the present invention.

Claims

1. A trusted oracle system for high-concurrency data environments based on blockchain, characterized in that: include: The resource node module is used to provide computing or storage resources and actively publishes a set of metrics when the state changes; each metric in the set contains a timestamp, signature, and state hash. The oracle node module is used to perform off-chain data collection and snapshot generation, and is responsible for signature verification, bitmap difference detection and timing alignment; The Real-Time Byzantine Small Members Module is used to enable point-to-point communication and data exchange between nodes through a distributed container network. The aggregation contract module is used to perform trusted aggregation, confidence calculation, global state update, and anomaly removal. The global resource table module stores the latest trusted aggregation results for each resource, providing a unified read-only interface for upper-layer smart contracts.

2. The trusted oracle system for high-concurrency data environments based on blockchain as described in claim 1, characterized in that, The oracle node module adopts a "dual-channel task queue + dynamic token bucket rate limiting mechanism" model to achieve load adaptation in a high-concurrency environment; wherein, the dual-channel task queue specifically includes: Fast Track It is used to handle requests with high real-time requirements; Buffer Channel , used to perform delay-tolerant batch processing; The scheduler is based on system latency With task backlog Calculate the allocation weights for fast channel and cached communication. : ； The weights are dynamically adjusted; changes in weights drive tasks to migrate between the two queues in real time, thereby maintaining the steady-state throughput of the system.

3. The trusted oracle system for high-concurrency data environments based on blockchain according to claim 2, characterized in that, The dynamic token bucket rate limiting mechanism specifically includes the following process: For each channel, two independent token buckets are set. The corresponding release rates are as follows: ； in and These are the sending rates for the fast channel and the buffered channel, respectively. and These represent the number of requests waiting to be processed in the current queue within the same time window for each of the two channels. To average the time to process a request; When resource availability changes suddenly or network latency increases, the system dynamically adjusts the bucket capacity. : ； in For the adjusted bucket capacity, For adjustment coefficients, This represents the current load volatility.

4. The trusted oracle system for high-concurrency data environments based on blockchain as described in claim 3, characterized in that, The real-time Byzantine small member meeting module includes member verification logic and a freshness tracking mechanism; in the real-time Byzantine small member meeting module, each resource node and... Each oracle node is bound together to form a Byzantine fault-tolerant structure, satisfying... ,in It represents the number of malicious oracle nodes; The member verification logic includes the following process: Each member node Received resource status Calculate and average deviation : ； like If so, the corresponding member node is deemed valid. The value is a preset positive integer; otherwise, the corresponding member node is removed and a re-collection process is triggered. Setting members will aggregate results for: ； in, This is a function for taking intermediate values; The freshness tracking mechanism includes the following process: Resource node generates bitmap Identify the changed field; The rate of change of resources is calculated by dividing the change in resources by the total amount of resources. Exceeding the threshold or exceeding the maximum silence time This will trigger snapshot generation, as shown in the following formula: ； in, For trigger signals that can be detected by oracle nodes, The threshold for the set resource change rate.

5. The trusted oracle system for high-concurrency data environments based on blockchain according to claim 4, characterized in that, The trusted aggregation in the aggregation contract module specifically includes the following process: Configure each node to maintain a reputation value as follows: ； in, To improve the success rate of submissions, For stability, The penalty coefficient is... , and All are weighted parameters; The real-time normalization of the reputation score is expressed by the following formula: ； In the sliding time window Internally, weighted aggregation is performed on snapshots from each node: ； in The snapshot value reported by the node; This represents the aggregation result at time t.

6. The trusted oracle system for high-concurrency data environments based on blockchain according to claim 5, characterized in that, The confidence calculation in the aggregation contract module specifically includes the following process: Set the confidence level of the aggregation results. for: ； in Standard deviation It is a preset positive integer. This is the average value of the data across all nodes. when When the result is considered reliable, it is written to the global resource table; Otherwise, trigger a re-collection, in which The minimum confidence threshold is set.

7. The trusted oracle system for high-concurrency data environments based on blockchain according to claim 6, characterized in that, The global state update in the aggregation contract module specifically includes the following process: Set on-chain aggregation within a continuous sliding time window Execute within the current time, where t is the current time. The window length is dynamically adjusted as follows: ； in This represents the current data update frequency. For window length, Maximum window length; State updates are stored using a hash digest method, as shown in the following formula: ； in, The hash value for state updates. As a unique identifier for resource nodes, For timestamps, To aggregate relevant metadata, For hash functions; And record the version number: ； in, This is the current version number. This is the previous version number; Final global resource table storage structure as follows: ； Each aggregation result generates a snapshot index. : ； The contract provides an asynchronous interface for node replay or external verification.

8. The trusted oracle system for high-concurrency data environments based on blockchain according to claim 7, characterized in that, The anomaly removal process in the aggregation contract module specifically includes the following steps: After each round of aggregation, the reputation is updated based on the node deviation: ； in, For the updated reputation, The learning rate is used to adjust the rate of change in reputation. when Once a time node enters a cooldown period, no more tasks will be assigned. System each After round aggregation, global reputation normalization is performed.

9. The trusted oracle system for high-concurrency data environments based on blockchain as described in claim 8, characterized in that, It also includes a cross-membership consistency verification module, which specifically includes the following processes: When the same resource node is in multiple partitions or clusters, different members will output local results. Second-level consistency verification needs to be performed on-chain, and the specific formula is as follows: ； in, Aggregate results for all member associations; if the differences between different member associations exceed the cross-member association difference threshold... If so, cross-member aggregation will be retried.

Images