Blockchain-based warehouse data interaction log notarization system and method

Abstract

The application relates to the technical field of blockchains, and discloses a warehouse data interaction log evidence storage system and method based on a blockchain, which comprises the following steps: in a gateway forwarding module, an edge aggregation buffer is opened to obtain an original log item set, the current credit weight parameter of a target intelligent agent is calculated, and the data packaging threshold dynamically adjusted is updated and determined to be maintained or forced to be rewritten; the number of collected items in the buffer is monitored in real time, a packaging trigger instruction is output when the data packaging threshold is reached, the core field set is extracted from the original log item set, and a hash splicing is performed to construct a local state tree; the root node hash value is chained to obtain a cloud storage reply and construct a local evidence library, and when an audit trigger occurs, the tampered log position information is located through hash value comparison; the application dynamically controls the packaging granularity according to the credit state of the intelligent agent, and balances the blockchain consensus overhead and the ability of fine-grained positioning of tamper-proofing auditing.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and more specifically, to a blockchain-based system and method for storing interactive logs of warehouse data. Background Technology

[0002] With the construction of smart logistics systems, massive numbers of intelligent agents are deployed within warehousing systems to perform operations such as handling and sorting. Log data generated during the interaction of these agents serves as crucial evidence for tracing operational processes and investigating safety incidents. Introducing blockchain technology to store these interaction logs on the blockchain has become an important means of ensuring the immutability of warehousing data.

[0003] Patent CN113055171B discloses a blockchain-based method for secure log parsing and storage. This method generates a log template digest through parsing, performs digital signing and encryption, stores the original log on a cloud server, and publishes the digest hash on the blockchain. This technology reduces the time overhead of generating new blocks and improves system efficiency. Document CN117370283A discloses a blockchain-based log data processing method, apparatus, device, and medium. It determines the target packaging granularity based on the attributes of the log data, selects logs with the same attributes, combines them, performs hash processing, and uploads them to the blockchain. This technology overcomes the technical limitation of the mismatch between massive log volumes and blockchain throughput, improving blockchain utilization.

[0004] However, existing log packaging and evidence storage mechanisms based on fixed time windows or fixed attribute granularity often suffer from delayed evidence storage response when dealing with sudden abnormal states in the warehouse. When a specific intelligent agent (such as a shuttle car performing intensive handling tasks or a temperature and humidity sensor node) encounters external network sniffing or occasional protocol violations during operation, the generated abnormal interaction logs are still buffered at the edge gateway according to a pre-set fixed threshold. Since the fixed mechanism cannot detect the current abnormal state of the equipment, the abnormal logs will generate an evidence storage vacuum period of up to tens of seconds during the buffering period. Once the abnormal process takes advantage of the evidence storage vacuum period to erase or replace the buffered logs in the gateway, the subsequently generated overall hash value cannot reflect the real original interaction process, resulting in the loss of accurate underlying evidence for traceability during subsequent audits. This leads to the inability to isolate abnormal equipment in a timely manner, which can easily trigger a chain of safety accidents such as collisions with warehouse equipment or temperature control failures. Summary of the Invention

[0005] In warehousing scenarios, there are diverse types of intelligent agents with significantly different operational rhythms. Traditional edge gateway-based evidence storage solutions typically aggregate raw interaction logs by a fixed number of entries or time windows, generate a unified hash, and then upload it to the blockchain. The underlying logic of this mechanism is the assumption that all devices maintain the same reliability at all times. In actual operation, when devices are subjected to signal interference, hardware aging, or network attacks, their communication behavior will deviate from the normal baseline. If a fixed log packaging strategy is continued, it will not only fail to provide a rapid evidence storage response to abnormal states but will also provide an opportunity for tampering. The conventional data aggregation process lacks dynamic and continuous assessment of the credibility of the data source, forcing high-risk interaction logs generated by devices in a suspicious state to remain in the local buffer until the batch threshold is reached. The aforementioned delays extend the time that critical evidence is exposed to unprotected edge environments, putting data before consensus confirmation at risk of being overwritten. On the other hand, when anti-tampering audits intervene, because local log records have been covered up and lack fine-grained correlation verification structures, a single, partial on-chain evidence receipt cannot penetrate down to locate the specific tampered log entry, ultimately causing the entire evidence traceability chain to break.

[0006] To overcome the shortcomings of existing technologies, such as the lack of evidence storage during abnormal states and the difficulty in locating tampering afterward, caused by the use of fixed log aggregation strategies, this invention provides a blockchain-based warehouse data interaction log evidence storage system and method. By opening an edge aggregation buffer in the gateway forwarding module and dynamically calculating the current reputation weight parameter based on the historical log records of the target intelligent agent, a reputation-driven dynamic adjustment mechanism for data packaging thresholds is constructed. Combined with the hash concatenation operation of the local state tree and the dual-source linkage evidence tracing architecture, this reduces the blockchain consensus resource overhead under normal operation, while enabling logs generated when the device is abnormal to be immediately packaged and uploaded to the chain. When facing external audits, the built-in hash value comparison method is used to lock down the precise location information of the tampered logs layer by layer.

[0007] To achieve the above objectives, the present invention provides the following technical solution:

[0008] Blockchain-based methods for storing warehouse data interaction logs include:

[0009] In the gateway forwarding module, an edge aggregation buffer is opened to obtain the original log entry set of the target agent, calculate the current reputation weight parameter of the target agent, update the data packaging threshold of the edge aggregation buffer to the dynamically adjusted data packaging threshold, and decide whether to maintain or forcibly rewrite the dynamically adjusted data packaging threshold based on the current reputation weight parameter.

[0010] The system monitors the number of security interaction log entries collected in the edge aggregation buffer in real time. When the number of collected security interaction log entries is greater than or equal to the dynamically adjusted data packaging threshold, a packaging trigger command is output. Based on the packaging trigger command, the system extracts fields from the original log entry set in the edge aggregation buffer to generate a core field set. The system performs hash concatenation operation on the core field set to build a local state tree and generate a root node hash value. The root node hash value is uploaded to the blockchain to obtain a cloud-based evidence receipt and build a local evidence library. When an audit is triggered, the system locates the position information of the tampered security interaction log by comparing the hash value.

[0011] A blockchain-based warehouse data interaction log storage system is used to implement the aforementioned blockchain-based warehouse data interaction log storage method. The system includes:

[0012] Reputation threshold adjustment module: used to open an edge aggregation buffer in the gateway forwarding module, obtain the original log entry set of the target agent, calculate the current reputation weight parameter of the target agent, update the data packaging threshold of the edge aggregation buffer to the dynamically adjusted data packaging threshold; and decide whether to maintain or forcibly rewrite the dynamically adjusted data packaging threshold based on the current reputation weight parameter.

[0013] Log Packaging and Extraction Module: Used to monitor the number of security interaction log entries collected in the edge aggregation buffer in real time. When the number of collected security interaction log entries is greater than or equal to the dynamically adjusted data packaging threshold, a packaging trigger command is output. Based on the packaging trigger command, the module performs field extraction on the original log entry set in the edge aggregation buffer to generate a core field set.

[0014] The evidence storage audit and location module is used to perform hash concatenation operations on the core field set to build a local state tree and generate a root node hash value. The root node hash value is uploaded to the blockchain to obtain the cloud evidence storage receipt, build a local evidence library, and locate the location information of the tampered security interaction log by comparing the hash value when the audit is triggered.

[0015] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0016] This invention establishes a reputation-driven dynamic adjustment mechanism for data packaging thresholds by creating an edge aggregation buffer in the gateway forwarding module and calculating the current reputation weight parameter based on the original log entry set of the target intelligent agent. This overcomes the technical problem that fixed aggregation batches cannot balance processing latency and on-chain resource consumption, enabling the number of secure interaction log entries to be packaged adaptively according to the real-time trust status of the device, thus avoiding delays in evidence storage response under abnormal attack conditions. Based on the packaging trigger command, the original log entry set is processed to extract fields to form a core field set. A local state tree is constructed using hash concatenation operations, and the generated root node hash value is submitted to the blockchain to obtain a cloud-based evidence storage receipt. Combined with a synchronously constructed local evidence library, a dual-source linkage evidence tracing architecture is established. This allows for the direct use of the system's built-in hash value comparison method to pinpoint the exact location of tampered secure interaction logs layer by layer down the local state tree when faced with external audit trigger requirements. While compressing the single consensus protocol interaction payload, it provides a closed-loop evidence collection and judgment basis with a complete logical traceability chain. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a flowchart of the blockchain-based warehouse data interaction log storage method in this invention;

[0019] Figure 2 This is a schematic diagram of the target intelligent agent in the warehouse site according to the present invention;

[0020] Figure 3 This is a flowchart of the reputation-aware packaging threshold adjustment process in this invention;

[0021] Figure 4 This is a schematic diagram of the sliding time window acquisition scenario in this invention;

[0022] Figure 5 This is a schematic diagram illustrating the batch differentiation of the reverse coupling constraint function in this invention;

[0023] Figure 6 This is a schematic diagram of a local state tree in this invention;

[0024] Figure 7 This is a flowchart illustrating the audit tampering location locating process in this invention;

[0025] Figure 8This is a functional module diagram of the blockchain-based warehouse data interaction log storage system of the present invention. Detailed Implementation

[0026] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0027] Example 1:

[0028] Please see Figure 1 As shown, this embodiment provides a blockchain-based method for storing warehouse data interaction logs, including:

[0029] Step S10: Open an edge aggregation buffer in the gateway forwarding module, obtain the original log entry set of the target agent, calculate the current reputation weight parameter of the target agent, update the data packaging threshold of the edge aggregation buffer to the dynamically adjusted data packaging threshold; decide whether to maintain or forcibly rewrite the dynamically adjusted data packaging threshold based on the current reputation weight parameter.

[0030] Specifically, the gateway forwarding module refers to the edge-side protocol forwarding node deployed between multiple target intelligent agents and the cloud blockchain. It is responsible for organizing the security interaction logs uploaded by each target intelligent agent in batches and forwarding them to the cloud blockchain for storage. It possesses local caching, local hash calculation, and processing capabilities for interaction with the cloud blockchain. Target intelligent agents refer to the edge-side business entities participating in data interaction in a warehousing scenario. (See [link to relevant documentation]). Figure 2 This is a schematic diagram of the target intelligent agent in the warehouse provided in this embodiment. Figure 2 The diagram illustrates multiple entities involved in data interaction at the warehouse site and the logical architecture for forming a security interaction log. Figure 2 As shown in the example, target intelligent agents include, but are not limited to, the control unit of the aisle shuttle, the onboard industrial control computer of the stacker crane, the inbound / outbound barcode scanner, the temperature and humidity sensor node, and the human-machine interaction terminal of the workstation. This embodiment, by deploying these five typical end-side business entities on the warehouse site, can cover multiple dimensions of warehousing scenarios, including logistics handling, item storage and retrieval, inbound / outbound barcode scanning, environmental monitoring, and personnel intervention. Each target intelligent agent initiates encrypted communication with the gateway forwarding module using pre-configured identity credentials. The secure interaction log refers to the process record generated each time a target intelligent agent initiates identity authentication, encrypted communication, and data reporting with the gateway forwarding module. See [link to relevant documentation] for further details. Figure 2In the diagram, data generated by each target agent during operation is uniformly collected through communication links to generate corresponding security interaction logs, thereby achieving centralized management of multi-source interaction data in the warehouse. A single security interaction log entry includes at least the target agent's identity, timestamp, encryption algorithm type used, authentication dimension employed, data integrity status, and a summary value of the transmitted business fields. The original log entry set refers to the set of all security interaction logs collected by the gateway forwarding module for a single target agent in the edge aggregation buffer that have not yet been packaged and uploaded to the blockchain. Entries within the set are arranged in ascending order of timestamp. The edge aggregation buffer is implemented as follows: Independent storage areas are allocated in the gateway forwarding module's runtime memory according to the target agent's identity. Each target agent corresponds to an independent edge aggregation buffer, preventing the security interaction logs of multiple target agents from mixing and causing inaccurate assignment of subsequent root node hash values. During operation, the edge aggregation buffer appends security interaction logs in a first-in, first-out order, and removes the uploaded log entries after each batch packaging is completed. The current reputation weight parameter is used to quantify the credibility of the target agent's behavior during the most recent observation period. Its value ranges from 0 to 1, with a higher value indicating a higher level of compliance. The dynamically adjusted data packaging threshold refers to the number of log entries used by the edge aggregation buffer to determine whether to trigger a batch packaging action. This threshold is recalculated in step S12 each time a sliding time window passes, based on the reverse coupling constraint function. The current reputation weight parameter used for this calculation is obtained from the statistical analysis performed on the reputation-aware statistical sample set in step S11. Comparing the current reputation weight parameter with the preset suspicious reputation threshold and determining whether to maintain or forcibly rewrite the dynamically adjusted data packaging threshold based on the comparison result is an additional correction mechanism introduced in step S10 beyond the regular dynamic adjustment: when the target agent exhibits suspicious characteristics, it is changed to immediately package and upload the data to the blockchain for every single secure interaction log generated, compressing the tampering window to the millisecond level. Step S10 embeds the reputation awareness mechanism into the batch threshold control of the edge aggregation buffer, making the originally fixed data packaging threshold flexible according to the credibility of the target intelligent agent's behavior. This allows the security interaction logs of trusted target intelligent agents to be uploaded to the chain in larger batches, saving consensus protocol overhead and on-chain storage overhead, while allowing the security interaction logs of suspicious target intelligent agents to be uploaded to the chain in small batches or even single entries, thus improving the timeliness of storage verification.

[0031] See Figure 3 Furthermore, step S10 includes:

[0032] Step S11: Open an edge aggregation buffer in the gateway forwarding module, collect all security interaction logs generated by the target agent within the preset sliding time window, obtain the current sliding time window log sample set and append it to the original log entry set; from the reputation perception statistical sample set composed of the sliding time window log sample sets corresponding to the past M sliding time windows, count the number of successful authentications, the number of successful encryption verifications, and the number of data integrity anomalies of the target agent in the past M sliding time windows, and perform weighted calculation on the number of successful authentications, the number of successful encryption verifications, and the number of data integrity anomalies to obtain the current reputation weight parameter of the target agent;

[0033] Specifically, see Figure 4 This is a schematic diagram of a sliding time window acquisition scenario provided in this embodiment. Figure 4 The diagram illustrates multiple sliding time windows continuously divided along the time axis t, the security interaction logs recorded within each sliding time window, and the backtracking lengths of M sliding time windows composed of these multiple sliding time windows. Figure 4 Taking the example shown, the preset sliding time window refers to the basic statistical unit for the gateway forwarding module to divide and sample security interaction logs according to equal time intervals, with the time length denoted as Tw. The preset sliding time window is determined as follows: the typical time required for a single target agent to generate one to several security interaction logs under nominal operating conditions is used as the lower limit benchmark, and the maximum evidence storage response delay allowed by the gateway forwarding module is used as the upper limit benchmark. A time interval between the lower and upper limits is selected that can simultaneously accommodate multiple identity authentications and multiple data reports. If the value of Tw is too small, the number of security interaction log samples within each sliding time window is too small, and the statistically obtained current reputation weight parameter will fluctuate wildly due to single, occasional abnormal disturbances; if the value of Tw is too large, changes in the target agent's behavior cannot be reflected in the current reputation weight parameter in a timely manner. For example, for target agents with a work cycle of several seconds, Tw is set to 30 seconds; for target agents with a work cycle of tens of seconds, Tw is set to 120 seconds. See also... Figure 4Within each sliding time window of duration Tw, multiple corresponding security interaction logs are generated over time. Collecting all security interaction logs generated by the target agent within the preset sliding time window means that the gateway forwarding module maintains an independent sliding time window timer for each target agent. After the timer starts, newly generated security interaction logs are appended to the corresponding edge aggregation buffer in arrival order. When the timer reaches Tw, appending stops, and the entire set of written security interaction logs is submitted as the sliding time window log sample set for the current sliding time window to the subsequent statistical stage. Simultaneously, the current sliding time window log sample set is appended to the target agent's original log entry set in the edge aggregation buffer in ascending timestamp order. Security interaction logs that have been batch-packaged and uploaded to the chain are removed from the original log entry set according to the cleanup rules in step S20, but their copies are still retained in the reputation-aware statistical sample set as a sliding time window log sample set until the slide exceeds M sliding time window backtracking lengths. The statistical sample set for reputation perception is used to count the number of successful authentications, successful encryption verifications, and data integrity anomalies of a target agent within the past M sliding time windows. This means that the gateway forwarding module, using the most recently ended sliding time window as a baseline, traces back M-1 adjacent sliding time windows, using the complete set of sliding time window log samples within those M adjacent sliding time windows as the statistical sample. M is the traceback length for reputation perception, combined with... Figure 4 It is known that the backtracking length of the M sliding time windows spans M consecutive sliding time windows, providing a statistical basis for a sufficient time span. The method for determining M is as follows: During the calibration phase, long-term no-load and light-load tests are conducted on gateway forwarding modules with the same deployment mode under two working conditions: no-load and light-load. The no-load working condition refers to the target intelligent agent maintaining only heartbeat-level authentication refresh and minimum data reporting, without undertaking formal operation instructions. The light-load working condition refers to the target intelligent agent running at the lower limit of the actual on-site work schedule, undertaking only some routine business operations. During the test, the statistical mean of the three indicators—the number of successful authentications, the number of successful encryption verifications, and the number of data integrity anomalies—is recorded as the backtracking length increases, under the condition of no abnormal injection. The backtracking length corresponding to the first three consecutive times when the fluctuation amplitude is lower than the set stability threshold is taken as the value of M. The set stability threshold is 5% of the long-term mean of the corresponding indicators. When M is too small, the statistical sample size is insufficient, and fluctuations in indicators caused by short-term random disturbances may be incorrectly identified as changes in behavior. When M is too large, the statistical sample will contain too many outdated security interaction logs, and the latest behavioral changes will be diluted by earlier compliance records. For example, when Tw is 30 seconds, M can be 6 to 10 sliding time windows. The number of successful authentications refers to the number of times the target agent initiates and successfully authenticates with the gateway forwarding module within M sliding time windows, denoted as N. authThe number of successful encryption verifications refers to the number of times that encrypted messages sent by the target agent pass through the gateway forwarding module for integrity and legitimacy verification within M sliding time windows, denoted as N. crypt The number of data integrity anomalies refers to the number of times within M sliding time windows, the data digest value carried in the security interaction log of the target agent's uplink is inconsistent with the digest value recalculated by the gateway forwarding module, and the number of times the data frames of the target agent's uplink have abnormal lengths, missing fields, or protocol format violations. The combined count of these two is denoted as N. anom It should be noted that the range of anomaly types covered by the number of data integrity anomalies is wider than that of the data integrity status field in the core fields described in step S21. The data integrity status field only records whether the data digest value of a single security interaction log passes integrity verification, while the number of data integrity anomalies, in addition to data digest value verification, also includes format violation events at the protocol layer, so that the reputation perception mechanism can simultaneously detect suspicious behavior at both the data layer and the protocol layer. The current reputation weight parameter of the target agent is obtained by weighting the number of successful authentications, the number of successful encryption verifications, and the number of data integrity anomalies, denoted as W. rep Perform the following formula:

[0034] W rep =α×(N auth / N auth , max )+β×(N crypt / N crypt , max )-γ×(N anom / N anom , ref );

[0035] The calculated result is then truncated to limit the current reputation weight parameter to between 0 and 1; that is, when the calculated result is greater than 1, it is set to 1, and when it is less than 0, it is set to 0. Where N... auth , max The maximum number of authentication attempts that a target agent can theoretically initiate under the nominal operating state within the corresponding duration of M sliding time windows is obtained by the gateway forwarding module by dividing the total duration of the M sliding time windows by the authentication protocol refresh cycle of the target agent. The authentication protocol refresh cycle refers to the nominal duration between two consecutive authentication attempts initiated by the target agent to the gateway forwarding module under the nominal operating state. It is reported by the target agent to the gateway forwarding module through a device registration message when it first accesses the gateway forwarding module, and the gateway forwarding module registers it in the local configuration table using the target agent's identity identifier as the index key; N crypt , maxThe maximum number of encrypted messages that the target agent can theoretically send up within the M sliding time windows under the nominal operating state is obtained by the gateway forwarding module by dividing the total duration of the M sliding time windows by the data reporting cycle of the target agent. The data reporting cycle refers to the nominal duration between two consecutive encrypted messages actively sent up to the gateway forwarding module by the target agent under the nominal operating state, and the registration method is consistent with the authentication protocol refresh cycle; N anom , refThe baseline number of permissible data integrity anomalies is calculated by the gateway forwarding module by multiplying the bit error rate (BER) of the communication link during the calibration phase by the total number of data frames within M sliding time windows. α, β, and γ are the weighting coefficients for authentication, encryption, and anomaly dimensions, respectively. The values ​​of α and β satisfy the condition that α plus β equals 1 and are both positive, while γ is positive and greater than the smaller of α and β. This ensures that the anomaly dimension has a stronger effect on lowering the current reputation weight parameter than the authentication and encryption dimensions have an effect on raising it, conforming to the asymmetric mechanism of slow accumulation of compliant behavior and rapid weakening of anomaly behavior. The method for determining α, β, and γ is as follows: First, classify the business types undertaken by the target intelligent agent. Target intelligent agents primarily receiving external control commands are classified as command-controlled; those primarily collecting upstream data are classified as data-acquisition; and those exhibiting both receiving control commands and collecting upstream data are classified as comprehensive interaction. The lane shuttle control unit and the stacker crane's onboard industrial control computer are classified as command-controlled; temperature and humidity sensor nodes are classified as data-acquisition; and warehouse entry / exit scanners and human-machine interaction terminals are classified as comprehensive interaction. Second, based on the business classification results, rank the relative importance of the three dimensions: authentication, encryption, and data integrity. The command-controlled category prioritizes identity legitimacy, the data-acquisition category prioritizes data integrity, and the comprehensive interaction category treats both dimensions equally. Since the data integrity dimension is carried by an independent weighting coefficient γ, while α and β are only allocated between the authentication and encryption dimensions, further... Agreement: When the primary dimension is identity legitimacy, α is the primary term among α and β relative to β; when the primary dimension is data integrity, β is the primary term among α and β relative to α because the encryption dimension is responsible for protecting the integrity of data in the transmission channel; when the two dimensions are treated equally, both α and β are set to 0.5; in the third step, the on-site maintenance personnel allocate the values ​​of α and β according to the sorting results during the calibration phase. The weighting coefficient corresponding to the primary term of α and β is set to the larger value and falls within the range of 0.6 to 0.7, and the weighting coefficient corresponding to the non-primary term of α and β is set to the smaller value and falls within the range of 0.3 to 0.4, and the sum of α and β is always 1; in the fourth step, the value of γ is determined according to the on-site tolerance limit for abnormal events. The stricter the tolerance limit, the larger the value of γ is and falls within the range of 0.7 to 0.9, and the value of γ is always greater than the smaller of α and β, to ensure that the effect of the abnormal dimension on lowering the current reputation weight parameter is stronger than the effect of the compliance dimension on raising it. When α is too small, the contribution of the authentication dimension to the current reputation weight parameter is weakened; when α is too large, target agents that frequently authenticate but lack effective data interaction obtain an excessively high current reputation weight parameter; when β is too small or too large, the reflective strength of the encryption dimension is distorted accordingly; when γ is too small, suspicious behavior is unlikely to lower the current reputation weight parameter below the suspicious reputation threshold; when γ is too large, even minor occasional anomalies can cause a significant drop in the current reputation weight parameter, and trusted target agents are frequently misjudged.For example, for target intelligent agents such as temperature and humidity sensor nodes, α is 0.3, β is 0.7, and γ is 0.8; for target intelligent agents such as lane shuttle control units, α is 0.6, β is 0.4, and γ is 0.7. The denominators of each weighting term in the formula are the theoretical maximum or benchmark value of the corresponding dimension, making the current reputation weight parameter dimensionless and preventing distortion due to differences in message frequency among different target intelligent agents. The weighting terms for compliant behavior are preceded by a positive sign, and the weighting terms for abnormal behavior are preceded by a negative sign, ensuring that the direction of change of the current reputation weight parameter is strictly consistent with the direction of change of the target intelligent agent's credibility. Step S11 generates the current reputation weight parameters using a sliding time window as the statistical sample boundary, M sliding time windows as the backtracking length, and a three-dimensional weighting method. This refines the target agent's credibility from a coarse-grained judgment that originally relied on binary identity authentication results to a continuous, comparable, and dynamically changing credibility metric over time. This provides the input variable for the inverse coupling constraint function in step S12 and the judgment quantity for comparison with the suspicious reputation threshold in step S13. Without step S11, the inverse coupling constraint function would lose its input variable, and step S13 would have no judgment quantity to input. The reputation-aware elastic batch control advocated in step S10 would degenerate into batch packaging triggered by a fixed threshold.

[0036] Step S12: Establish a reverse coupling constraint function between the current reputation weight parameter and the maximum number of log entries allowed in a single aggregation batch, and solve for the value of the maximum number of log entries through the reverse coupling constraint function; based on the value of the maximum number of log entries, dynamically adjust the data packing threshold of the edge aggregation buffer to the maximum number of log entries, and obtain the dynamically adjusted data packing threshold;

[0037] Specifically, see Figure 5 This is a schematic diagram of batch differentiation of reverse coupling constraint functions provided in this embodiment. Figure 5 The comparison illustrates the strategy of large-batch on-chain uploads for trusted target agents versus the strategy of small-batch or even single-item immediate on-chain uploads for suspicious target agents. Figure 5 Taking the example shown, the reverse coupling constraint function refers to a nonlinear monotonic mapping function relationship established between the current reputation weight parameter and the maximum number of log entries allowed in a single aggregation batch. This ensures that the larger the current reputation weight parameter, the larger the maximum number of log entries allowed, and vice versa. The "reverse coupling" refers to the fact that when the target agent exhibits suspicious characteristics causing the current reputation weight parameter to decrease, the batch size shrinks in the reverse direction from expansion to the minimum number of log entries, or even to a single log entry being immediately uploaded to the chain. This results in a reverse coupling characteristic between the evidence storage response delay and the change in credibility. The two are not simply proportional; rather, after nonlinear mapping, they embody a differentiated batch control mechanism of strong constraints for low reputation and wide allowances for high reputation. The maximum number of log entries allowed in a single aggregation batch is denoted as N.pack The reverse coupling constraint function is calculated using the following formula:

[0038] N pack =N min +(N max -N min )×W rep k ;

[0039] Where, N min W represents the minimum number of log entries allowed within a single aggregation batch. rep Batch size when N is 0; max W represents the maximum number of log entries allowed within a single aggregation batch. rep The batch size is set to 1; k is the non-linear amplification index used to control W. rep With N pack The degree of nonlinear mapping between them is such that when k equals 1, the inverse coupling constraint function degenerates into a linear mapping; when k is greater than 1, the inverse coupling constraint function exhibits concave function characteristics, making N pack In W rep As it increases from 0 to 1, it exhibits a non-linear growth pattern, initially slow and then accelerating, thus suppressing the batch expansion rate within the medium confidence interval. Its value is greater than 1. min The method for determining N is as follows: the minimum bandwidth and minimum computation required for the gateway forwarding module to complete one consensus protocol interaction are used as a reference lower limit, so that the number of log entries in a single aggregation batch will not lead to frequent consensus protocol interactions due to the value being too small. min Is the reverse coupling constraint function in W rep ≥W susp For N within the interval pack The lower bound constraint does not apply to the forced rewrite action in step S13; step S13 is in W rep <W susp The overlay action, which sets the data packing threshold to 1, directly bypasses the inverse coupling constraint function. min In this case, it is no longer used as the lower bound of the data packing threshold. N min When the value is too small, the batch packaging frequency is too high in suspicious cases, causing an increase in processing latency in the gateway forwarding module; N min When the value is too large, the batch packaging frequency is insufficient in suspicious cases, thus lengthening the time window for tampering. For example, N min The value can be 1 to 3. N max The method for determining the maximum number of leaf nodes that the gateway forwarding module can handle in a single local state tree construction is used as a reference upper limit, combined with a reasonable upper limit for the batch size corresponding to a single evidence storage receipt in the cloud blockchain, to avoid the local state tree construction time exceeding the sliding time window duration. maxWhen the value is too small, the trusted target agent cannot enjoy the benefits of reduced consensus protocol interaction times brought about by batch on-chain storage, and the on-chain storage overhead remains high; N max When the value is too large, the time taken to build a single local state tree exceeds expectations, and the time taken to locate the location after a hash value mismatch increases. For example, N max The value ranges from 50 to 200. The nonlinear amplification index k is determined based on the strength of the demand in the field for asymmetric mechanisms—that the rate of batch reduction under low-reputation conditions needs to be faster than the rate of batch expansion under high-reputation conditions. If k is too small, the reverse coupling constraint function degenerates into linearity, and the rate of batch reduction under questionable conditions is insufficient to converge the evidence response delay to an acceptable range. If k is too large, the reverse coupling constraint function becomes excessively concentrated in W. rep Batch expansion is only permitted when the value falls into the high range close to 1; many moderately reliable target agents can still only be expanded with values ​​close to N. min Small batches are uploaded to the chain. For example, k takes values ​​from 1.5 to 3.0. The power function form W... rep k The reason it was chosen is that this form can simultaneously regulate W with a single nonnegative parameter k. rep Rapid descent rate and W near 0 rep The slow rate of increase near 1 does not require the introduction of additional shape parameters or piecewise representation; meanwhile, the value of this form is within W... rep The value is monotonically continuous and differentiable throughout the entire effective interval [0,1], facilitating real-time numerical calculation by the gateway forwarding module and rounding down to the integer batch size. Solving for the maximum log entry value using the reverse coupling constraint function means that the gateway forwarding module substitutes the newly output current reputation weight parameter from step S11 into the above formula after each sliding time window to calculate N. pack The numerical value is rounded down to satisfy the integer physical meaning. Dynamically adjusting the data packing threshold of the edge aggregation buffer to the maximum log entries refers to the gateway forwarding module using the solved N... pack The threshold obtained by covering the data packing threshold used in the previous sliding time window is the dynamically adjusted data packing threshold. In the formula, W... rep The power term is the core of the inverse coupling nonlinearity: W rep When W decreases from 1 to 0 rep k The value decreases from 1 to 0 at a rate faster than linear, causing N to... pack By N max To N min The rate of decline accelerates as credibility decreases; W rep When W increases from 0 to 1 rep k The value of N increases from 0 to 1 at a rate slower than linear, causing N to... pack By Nmin To N max The expansion rate was deliberately suppressed in the medium confidence range, only in W rep After N enters the interval greater than or equal to the sufficiently confident threshold pack Only then could we get close to N max The intermediate confidence interval refers to the range of values ​​for which the current reputation weight parameter is greater than or equal to the preset suspicious reputation threshold but is not sufficiently close to 1. The lower bound of the interval is the preset suspicious reputation threshold, and the upper bound is the preset sufficiently confident threshold. An intermediately confident target agent is one whose current reputation weight parameter falls within the intermediate confidence interval; it is neither judged as suspicious because its current reputation weight parameter is lower than the suspicious reputation threshold, nor as sufficiently confident because its current reputation weight parameter is sufficiently close to 1. The sufficiently confident threshold is used to define the boundary between the intermediate and sufficiently confident states. Its value range is greater than the suspicious reputation threshold and less than 1. The determination method is as follows: during the calibration phase, record the steady-state value of the current reputation weight parameter after the target agent has continuously run for no less than M sliding time windows without introducing any abnormal injection. The current reputation weight parameter value corresponding to the lower deviation of the steady-state value not exceeding 5% is taken as the value of the sufficiently confident threshold. For example, the sufficiently confident threshold value is between 0.85 and 0.95. Step S12 uses the reverse coupling constraint function to... rep Mapping to specific batch sizes changes the batch organization method of the gateway forwarding module from triggering indiscriminately based on a fixed number of entries to triggering differently based on trust level. If step S12 is missing, the current reputation weight parameter is just an unused intermediate value, and the batch packaging action in step S20 will still be triggered based on a fixed threshold, making reputation-driven flexible batch control impossible to implement.

[0040] Step S13: Compare the current reputation weight parameter with the preset suspicious reputation threshold to obtain the reputation anomaly judgment result. When the current reputation weight parameter is less than the preset suspicious reputation threshold, the dynamically adjusted data packaging threshold is forcibly rewritten to 1. When the current reputation weight parameter is greater than or equal to the preset suspicious reputation threshold, the dynamically adjusted data packaging threshold is maintained.

[0041] Specifically, the preset suspicious reputation threshold is used to define the boundary for determining whether a target agent moves from a trusted state to a suspicious state, denoted as W. suspThe value ranges from 0 to 1. The method for determining the suspicious reputation threshold is as follows: During the calibration phase, various abnormal events of different magnitudes—such as forged identity requests, encrypted message tampering, and data integrity breaches—are injected sequentially into the gateway forwarding module. The current reputation weight parameter value output in step S11 is recorded under different abnormal injection ratios. The lower limit of the current reputation weight parameter corresponding to the point where the gateway forwarding module can stably identify the injected abnormality as suspicious behavior is taken as the suspicious reputation threshold value. If the suspicious reputation threshold value is too small, step S13 will only trigger forced rewriting after a large number of abnormal events occur. Target agents that have already shown obvious suspicious characteristics will still be added to the chain in loose batches, extending the time window for tampering. If the suspicious reputation threshold value is too large, a small number of random abnormal events will trigger forced rewriting, needlessly consuming the benefits of batch adding trusted target agents to the chain. For example, the suspicious reputation threshold value is between 0.3 and 0.5. The reputation anomaly determination result is obtained by comparing the current reputation weight parameter with the preset suspicious reputation threshold. This means that after each sliding time window and after updating the current reputation weight parameter, the gateway forwarding module compares the current reputation weight parameter with the suspicious reputation threshold: if it is less than the suspicious reputation threshold, the determination result points to a suspicious state; if it is greater than or equal to the suspicious reputation threshold, the determination result points to a trusted state. When the current reputation weight parameter is less than the suspicious reputation threshold, the dynamically adjusted data packaging threshold is forcibly rewritten to 1. This means that the gateway forwarding module directly overwrites the N calculated in step S12. pack The numerical value sets the data packing threshold of the edge aggregation buffer to 1, and the priority of the forced rewrite action is higher than N given by the reverse coupling constraint function. min Lower bound constraint, even if the current N min The calibration value is greater than 1, and the data packaging threshold after forced rewriting remains constant at 1. The physical meaning is: starting from the current sliding time window, for every security interaction log generated by the target agent, the edge aggregation buffer immediately triggers a batch packaging action, causing the generated security interaction logs to construct a local state tree in single-log form and upload the root node hash value to the chain. Forced rewriting to 1 correspondingly increases the difficulty of tampering with the already uploaded security interaction logs of a suspicious target agent: a tamperer must complete the tampering within an extremely short time window after the generation of a single security interaction log and before the root node hash value is uploaded and the receipt is returned to possibly forge a consistent root node hash value. This extremely short time window is typically on the order of milliseconds within the edge node, lower than the normal time required for tampering. Maintaining the dynamically adjusted data packaging threshold when the current reputation weight parameter is greater than or equal to the suspicious reputation threshold means that the gateway forwarding module does not... pack For any overlay, the edge aggregation buffer is set to N. pack Continue accumulating security interaction logs as a data packaging threshold until the number of collected entries is greater than or equal to N. pack When the batch packaging action in step S20 is triggered, such as Figure 5 As shown in the case of trusted target agents, a single aggregation batch of a trusted target agent can accumulate and accommodate multiple secure interaction logs, fully leveraging the advantage of large-batch on-chain storage in saving consensus overhead. Step S13 introduces a jump-correction mechanism in addition to the continuous mapping established in step S12, so that when the current reputation weight parameter falls into the suspicious range, the batch size immediately changes from a smooth change to a forced 1, forming a two-layer batch control structure of continuous mapping plus jump correction with steps S11 and S12. If step S13 is missing, the reverse coupling constraint function in W... rep N mapped when falling into the lower interval pack The value is still greater than or equal to N min The security interaction logs of suspicious target agents still need to be accumulated to N. min Batch packaging can only be triggered after the condition is met; the correction speed of step S10 is affected by N. min It is constrained and cannot reach the millisecond level.

[0042] In warehouse settings, shuttle vehicles, stacker cranes, inbound / outbound scanners, temperature and humidity sensor nodes, and human-machine interaction terminals generate a massive amount of authentication, encrypted communication, and data reporting records every second during continuous operation. These records are the sole source of evidence for locating tampering and tracing responsibility when audits are triggered, and must be stored on the blockchain in a manner acceptable to the cloud-based blockchain consensus protocol. However, the number of target intelligent agents in a warehouse can easily reach tens of thousands, and the reporting frequency can range from sub-seconds to minutes, spanning three orders of magnitude. If each security interaction log is directly uploaded to the blockchain as a single entry, the number of consensus protocol interactions and on-chain storage overhead will be magnified exponentially. If the logs are organized into fixed, large batches before being uploaded, if a target intelligent agent is compromised or exhibits anomalies, the security interaction logs that have been uploaded but not yet uploaded to the blockchain within a batch will provide a window of opportunity for tampering, lasting tens of seconds or even minutes. Traditional edge aggregation and evidence storage solutions often employ batch packaging triggered by a fixed number of records or a fixed time window. This approach implicitly assumes that the secure interactions of all target agents maintain the same level of trustworthiness at all times. However, the reality of warehousing scenarios is quite the opposite. Shuttle vehicles in aisles are at risk of having their control commands forged by external access during long-distance transport; temperature and humidity sensor nodes are at risk of data distortion due to hardware aging under long-term exposure; and entry / exit scanners are at risk of temporary misuse of identification credentials during shift changes. Fixed-batch solutions either sacrifice normal overhead for rapid response in abnormal situations, or vice versa—it's difficult to achieve both simultaneously. Furthermore, fixed-batch solutions lack their own judgment criteria when facing unknown threats, relying solely on external security devices to pre-deliver batch parameters.

[0043] Step S10 embeds an elastic threshold control structure driven by the target agent's own behavior into the batch organization stage of the gateway forwarding module. This replaces the fixed data packaging threshold with a dynamically adjusted threshold driven in real-time by the current reputation weight parameter. In addition to the dynamic adjustment, a jump-type correction gate guarded by a preset suspicious reputation threshold is configured. The technical solution unfolds into four interconnected processes: First, a mechanism for solving the current reputation weight parameter is constructed using a sliding time window as the statistical basis for reputation perception, M sliding time windows as the backtracking length, and compliance accumulation of authentication and encryption dimensions combined with asymmetric weakening of the anomaly dimension. Second, a nonlinear reverse-coupling constraint function maps continuous trust metrics to discrete batch sizes, resulting in differentiated responses of high-reputation, wide-allowed, and low-reputation, strong-constrained batch sizes. Third, a preset suspicious reputation threshold defines the boundary between trustworthy and suspicious cases. Fourth, a jump-type forced rewriting converges the batch size to 1 within the suspicious interval, immediately reducing the evidence storage response delay to the millisecond level.

[0044] Without relying on external security protection equipment, step S10 enables the gateway forwarding module to proactively perceive the trustworthiness of the target intelligent agent in the batch organization stage of edge aggregation and evidence storage, and allocate differentiated batch sizes to security interaction logs with different trustworthiness levels accordingly. This allows the trustworthy target intelligent agent's security interaction logs to enjoy the benefits of reduced consensus protocol interaction times and on-chain storage overhead brought about by large batches of on-chain storage, while allowing the suspicious target intelligent agent's security interaction logs to obtain the minimum tampering time window brought about by immediate single-log storage. An edge aggregation buffer is established, and the original log entry set is stored in isolation according to the target agent's identity. This allows reputation perception, batch organization, and root node hash value generation to operate independently at the target agent level. A sliding time window, backtracking length, and three-dimensional weighted calculation are introduced to obtain the current reputation weight parameter, refining the credibility level from a binary result to a continuous metric. A nonlinear reverse coupling constraint function is introduced to map the continuous metric to the batch size. Under normal operation, the number of consensus protocol interactions is compressed as the batch size of trusted target agents increases, and the evidence storage response delay converges as the batch size of suspicious target agents shrinks when anomalies occur. A preset suspicious reputation threshold is introduced, and the batch size is forcibly rewritten to 1 when falling into the suspicious interval, causing the evidence storage response delay to immediately converge to the millisecond level, making it difficult for tamperers to complete the modification of the original log entry set before the root node hash value on-chain receipt is returned. The nonlinear suppression of the medium credibility interval in the continuous mapping stage ensures that only fully trustworthy target agents can obtain values ​​close to N. maxThe batch size, in turn, ensures that the jump correction stage does not need to introduce additional preventative shrinkage to combat the large batch size remaining in the medium confidence interval when judging suspiciousness; the hard constraint of a batch size of 1 set by the jump correction stage for the suspicious interval, in turn, ensures that the continuous mapping stage does not need to reserve too much safety margin to prevent extreme cases in the medium confidence interval; the continuous refresh of the sliding time window gives the coupling between the confidence metric and the batch size real-time feedback characteristics. Once a suspicious feature appears in the trusted target agent, the batch size can be changed from N to N within one sliding time window. max The nearest jump is directly to 1. This overall effect allows the field extraction, hash concatenation, root node hash value uploading to the chain, and local evidence library construction in step S20 to operate stably according to the differentiated batch rhythm determined by step S10. This enables the entire solution to maintain low consensus protocol interaction overhead and ensure the ability to locate tampering when audits are triggered, even under the pressure of concurrent evidence storage by multi-objective intelligent agents in the warehousing scenario.

[0045] Step S20: Monitor the number of security interaction log entries collected in the edge aggregation buffer in real time. When the number of collected security interaction log entries is greater than or equal to the dynamically adjusted data packaging threshold, output a packaging trigger command. Based on the packaging trigger command, perform field extraction on the original log entry set in the edge aggregation buffer to generate a core field set. Perform hash concatenation operation on the core field set to build a local state tree and generate a root node hash value. Upload the root node hash value to the blockchain to obtain a cloud-based evidence receipt and build a local evidence library. When an audit is triggered, locate the location information of the tampered security interaction log by comparing the hash value.

[0046] Specifically, real-time monitoring of the number of security interaction log entries collected in the edge aggregation buffer means that after the gateway forwarding module completes each append write of a security interaction log in the edge aggregation buffer, it increments the number of security interaction log entries currently collected in the edge aggregation buffer and compares the increment count result with the dynamically adjusted data packaging threshold output in step S10. The packaging trigger command is an internal trigger signal generated by the gateway forwarding module when the auto-incrementing counter result is greater than or equal to the dynamically adjusted data packaging threshold. The packaging trigger command carries the identity identifier of the target agent currently corresponding to the edge aggregation buffer and the current batch identifier, enabling subsequent field extraction, hash concatenation operations, and on-chain evidence storage to locate the specific target agent and batch. The current batch identifier is a unique index string assigned to the current batch by the gateway forwarding module each time a packaging trigger command is generated. It consists of the target agent identity identifier, batch number, and generation timestamp concatenated. The batch number is obtained by incrementing a monotonically increasing counter maintained by the gateway forwarding module for each target agent by 1 each time a packaging trigger command is generated. The generation timestamp is read from the gateway forwarding module's local time synchronization source at the instant the packaging trigger command is generated. All hash operations in step S20 use the same family of hash algorithms, and the output length of the hash algorithm is denoted as L. hash L hash The method for determining L is as follows: Based on the family of hash algorithms allowed by the cloud blockchain, select the minimum output length that, under publicly disclosed attacks, still covers the search space jointly formed by the batch identifier, the target agent's identity identifier, and the timestamp. hash L hash When the value is too small, the probability of a hash collision being constructed increases, giving attackers the opportunity to construct a hash result identical to the real root node's hash value using a forged set of original log entries; L hash When the value is too large, the hash concatenation operation time of each level of the local state tree increases, and the number of bytes transmitted in a single consensus protocol interaction of the cloud blockchain increases in tandem with the on-chain storage overhead. For example, L hash The value is 256 bits. Step S20 connects the elastic threshold control completed in step S10 with the batch organization, state tree construction, dual-source evidence storage and audit location completed in step S20 itself to form a complete working chain in which the batch granularity is determined by the dynamically adjusted data packaging threshold, the local state tree size is determined by the batch granularity, the number of local state tree layers is determined by the local state tree size, and the audit traceability granularity is determined by the number of local state tree layers.

[0047] Further, step S20 includes:

[0048] Step S21: Monitor the number of security interaction log entries collected in the edge aggregation buffer in real time. When the number of security interaction log entries collected is greater than or equal to the dynamically adjusted data packaging threshold, output a packaging trigger command. Perform field extraction on the original log entry set in the edge aggregation buffer according to the packaging trigger command. Extract the three core fields of encryption algorithm type, authentication dimension and data integrity status from each security interaction log in the original log entry set to obtain the core field set.

[0049] Specifically, the real-time monitoring is implemented as follows: the gateway forwarding module configures an event-driven auto-incrementing counter for the edge aggregation buffer. Each time the edge aggregation buffer completes an append write to a security interaction log, the auto-incrementing counter is incremented by 1. Immediately after the increment, the dynamically adjusted data packaging threshold is read and a greater than or equal to condition is determined. If the condition is met, a packaging trigger command is generated. Compared to fixed-interval polling, the event-driven approach triggers the packaging action the instant the greater than or equal to condition is met, ensuring that the evidence storage response delay is determined solely by the time consumed by the increment and numerical comparison. The packaging trigger command carries the target agent's identity and the current batch identifier. The target agent's identity is used to distribute the packaging trigger command to the corresponding field extraction and processing path, and the current batch identifier is used as an index key when constructing the local evidence library in step S23. Field extraction refers to the process by which the gateway forwarding module, after receiving the packaging trigger command, parses the message structure of each security interaction log entry, starting from the first security interaction log entry in the original log entry set and ending with the last security interaction log entry that meets the dynamically adjusted data packaging threshold. It then extracts three core fields—encryption algorithm type, authentication dimension, and data integrity status—according to a pre-agreed field offset position, and concatenates these three core fields in a fixed order to obtain a core field record. The encryption algorithm type refers to the type of encryption algorithm negotiated between the target agent and the gateway forwarding module when generating the current security interaction log. This is carried in the core field record as a byte sequence of encryption algorithm identifiers agreed upon in the field, reflecting the cryptographic protection strength of the communication channel. The encryption algorithm type and the encryption algorithm identifier recorded in the local encrypted archive's encrypted metadata in step S23 belong to two independent cryptographic operations. The former is used for encryption of the communication channel between the target agent and the gateway forwarding module, while the latter is used for the gateway forwarding module's symmetric encryption of the local encrypted archive itself. The authentication dimension refers to the combination of identity authentication dimensions passed by the target intelligent agent during the generation of the current secure interaction log, reflecting whether the identity legitimacy process is complete. The data integrity status refers to whether the data digest value of the target intelligent agent in the current secure interaction log passes the integrity check, reflecting whether the business field has been modified during transmission. The three core fields correspond to three independent dimensions: communication channel security, identity legitimacy, and data integrity. They jointly characterize the trustworthiness of a single secure interaction log. Even if non-core fields of a single secure interaction log are cut off due to bandwidth jitter during edge transmission, the core field set can still support subsequent evidence storage and auditing. The core field set is arranged in ascending order of the timestamp of the corresponding secure interaction log, and each core field record has a unique timestamp within the core field set. Step S21 provides a hash processing object with the core field set as input for step S22.If step S21 is missing, the hash concatenation operation will be forced to be applied directly to the entire set of original log entries, increasing both the computational load and the number of bytes added to the chain. It also includes redundant fields such as headers and sequence numbers that are irrelevant to the core audit objectives. When an audit is triggered, the redundant fields must be stripped before the key content can be compared, thus lengthening the audit tracing path.

[0050] Step S22: Perform a hash operation on each core field record in the core field set to generate a set of leaf node hash values. Perform hash concatenation operation on the leaf node hash value set layer by layer in a pairwise pairing manner to construct a local state tree and generate the root node hash value of the local state tree. Upload the root node hash value to the cloud blockchain for notarization through the consensus protocol and obtain the cloud notarization receipt returned by the cloud blockchain.

[0051] Specifically, see Figure 6 This is a schematic diagram of a local state tree provided in this embodiment. Figure 6 The diagram illustrates a tree-like hierarchical structure where core field records are cascaded to generate the root node's hash value. Figure 6 Taking the example shown, performing a hash operation on each core field record in the core field set refers to the gateway forwarding module using L... hash The hash function for output length performs a hash calculation on the byte sequence of each core field record in the core field set, obtaining a hash value uniquely corresponding to each core field record. This hash value is called the leaf node hash value. Figure 6 As can be seen, each core field record corresponds to an independent leaf node hash value. All leaf node hash values ​​are arranged in the order of their corresponding core field records in the core field set, forming a leaf node hash value set. The pairwise pairing and layer-by-layer hash concatenation operation means that the gateway forwarding module starts from the beginning of the leaf node hash value set, groups adjacent leaf node hash values ​​together, concatenates the two hash values ​​in each group according to a fixed order, and then performs another L operation. hash The length is hashed to obtain the hash value of an intermediate node in the previous layer; for example... Figure 6 As shown, the hash values ​​of two adjacent leaf nodes are used to generate an associated intermediate node hash value. These intermediate node hash values ​​are then paired again to generate higher-level hash values. When the number of nodes in the current layer is odd, the unpaired hash value of the last node is copied to itself to form a virtual node pair, and then a hash concatenation operation is performed to ensure that the number of nodes in the current layer is halved after mapping to the next layer. The same rules are applied to the intermediate node hash values ​​in the previous layer, pairing and concatenating hash values ​​until the number of nodes in the previous layer converges to 1. The resulting unique node hash value is the root node hash value of the local state tree. Figure 6The local state tree is the only node that ultimately converges and generates. It possesses complete path traceability from the root node to the leaf nodes. If any core field record is tampered with, the corresponding leaf node hash value changes. After being passed up layer by layer through pairwise hash concatenation, the root node hash value of the local state tree will inevitably change, giving it the characteristic of being a holistic credential covering all core field records in the core field set. Uploading the root node hash value to the cloud blockchain for notarization via a consensus protocol means that the gateway forwarding module constructs a notarization transaction using the root node hash value of the local state tree, the current batch identifier, the target agent's identity identifier, and the generation timestamp as payloads. After signing, it is delivered to multiple consensus nodes in the cloud blockchain via the consensus protocol. Once the consensus nodes reach a consensus according to the protocol, they write the notarization transaction into a block in the cloud blockchain. The consensus protocol refers to a pre-agreed distributed coordination protocol in the cloud blockchain that enables multiple distributed consensus nodes to agree on the writing order of a transaction. One of the following protocols can be used: Practical Byzantine Fault Tolerance Protocol, Proof-of-Stake Protocol, or Proof-of-Authority Protocol. The cloud-based evidence receipt refers to the confirmation credential sent back to the gateway forwarding module by the consensus node after the evidence-based transaction is completed and entered into the chain. The cloud-based evidence receipt includes the on-chain transaction number, the block height, the on-chain timestamp, the root node hash value, and the consensus node signature. Step S22 condenses the core field set obtained from the edge-side batch organization into one L. hash The root node hash value of the specified length is then delivered to the cloud blockchain. This compresses the number of bytes carried by a single consensus protocol interaction in the cloud blockchain to the length of a root node hash value. Furthermore, leveraging the holistic credential characteristics of the local state tree, the root node hash value stored in the cloud blockchain can cover all core field records in the core field set. If step S22 is missing, each core field record in the core field set must be submitted separately to the cloud blockchain consensus protocol for notarization. The number of consensus protocol interactions increases linearly with the size of the core field set, rapidly consuming the cloud blockchain's notarization throughput per unit time.

[0052] Step S23: Encrypt and encapsulate each core field record in the core field set together with the corresponding leaf node hash value in the leaf node hash value set to obtain a local encrypted archive. Index and associate the local encrypted archive with the cloud evidence receipt through a common batch identifier and store it in the long-term retention medium of the edge node to build a local evidence library.

[0053] Specifically, encryption encapsulation refers to the gateway forwarding module using a symmetric encryption algorithm to encrypt the byte-by-byte concatenation result of each core field record in the core field set and the leaf node hash values ​​at the same index position in the leaf node hash value set. The resulting ciphertext, along with encrypted metadata, is aggregated into a single local encrypted archive based on the current batch identifier. The encrypted metadata includes the encryption algorithm identifier, key reference, and initialization vector, enabling the gateway forwarding module to locate the corresponding key and perform decryption when an audit is triggered. The key length used in the symmetric encryption algorithm is denoted as L. key L key The method for determining L is as follows: based on the long-term security requirements of the environment in which the gateway forwarding module operates, select a key length whose computational cost for exhaustive key lookup under a publicly known attack exceeds the upper limit of the computational power that the tamper can mobilize as L. key L key If the value is too small, the time required to exhaustively obtain the key for the locally encrypted archive decreases to a level that is acceptable for tampering. This allows the tampered local encrypted archive and the forged cloud-based evidence receipt to be replaced simultaneously before an audit is triggered; L key When the value is too large, the time consumed by both encryption encapsulation and decryption extraction triggered by audits increases, resulting in a corresponding decrease in the effective read / write throughput of the long-term storage medium at edge nodes. For example, L... key The value ranges from 128 bits to 256 bits. Associating the local encrypted archive and the cloud-based evidence receipt using a common batch identifier means that the gateway forwarding module writes the same batch identifier into the metadata of both the local encrypted archive and the cloud-based evidence receipt. This batch identifier follows the one defined in step S20 and is carried by the packaging trigger instruction, making the local encrypted archive and the cloud-based evidence receipt form a one-to-one dual-source certificate. Long-term retention media refers to non-volatile storage devices on the edge node where the gateway forwarding module is located, possessing long-term power-off retention and resistance to mechanical wear. Flash memory arrays, magnetic storage arrays, or hybrid storage arrays combining both can be selected. The minimum retention period for long-term retention media is denoted as T. keep T keep The method for determining the lower limit is as follows: the longer of the statutory traceability period applicable to warehouse responsibility traceability and the operator's internal traceability practice is used as the lower limit benchmark, and a redundancy period is superimposed on the lower limit benchmark as T. keep The redundancy period is used to cover the interval between the actual commencement of the audit and the completion of evidence collection. keep If the value is too small, the local encrypted archives that have exceeded the retention period will be overwritten or cleaned up. When the audit is triggered, the corresponding batch of local encrypted archives cannot be retrieved from the local evidence library, and the audit traceability fails; T keep When the value is too large, the capacity occupancy of long-term storage media continues to rise, increasing the pressure on edge nodes to expand their capacity. For example, T... keepThe timeframe is 3 to 10 years. The local evidence repository refers to a searchable structure formed by indexing and organizing all locally encrypted archives and cloud-based evidence receipts based on batch identifiers. Each batch identifier corresponds to a pair of locally encrypted archives and cloud-based evidence receipts; the absence of any pair of credentials will be detected by the local evidence repository's index scan. Step S23 uses dual-source credentials to lock the core field set and leaf node hash value set stored encrypted on the edge side with the root node hash value recorded on the cloud blockchain in the post-audit query path. The locally encrypted archives on the edge side and the cloud-based evidence receipts serve as mutual verification bases. If step S23 is missing, the local node will not have a set of core fields available for decryption and extraction when the audit is triggered. The root node hash value stored on the cloud blockchain cannot be independently verified by the auditor due to the lack of local data available for recalculation, resulting in a broken audit traceability link.

[0054] Step S24: See Figure 7 When an audit is triggered, the system decrypts and extracts the local encrypted archive from the local evidence repository, retrieves the core field records from the core field set of the local encrypted archive, re-performs hash operations and hash concatenation operations on the core field records to obtain the audit-side root node hash value, compares the audit-side root node hash value with the root node hash value recorded in the cloud-based evidence receipt byte by byte to obtain the comparison result, and when the comparison result is inconsistent, performs hash value comparison layer by layer from the root node to the leaf node along the local state tree to locate the first inconsistent leaf node path and obtain the location information of the tampered security interaction log.

[0055] Specifically, audit triggering refers to the query action initiated by the auditor when, based on complaints, spot checks, regulatory requirements, or abnormal alarms, the auditor requests a review of the authenticity of security interaction logs generated by one or more target intelligent agents within a certain period in the warehouse. The query conditions submitted by the auditor include the target intelligent agent's identity and the audit time range. Decrypting and extracting local encrypted archives from the local evidence library means that after the gateway forwarding module locates the corresponding batch's local encrypted archive and cloud-based evidence receipt in the local evidence library based on the batch identifier matched by the query conditions, it looks up the key used during encryption and encapsulation based on the key reference in the encrypted metadata of the local encrypted archive, and uses symmetric decryption operations to restore the core field set and leaf node hash value set stored at that time. Re-performing hash operations and hash concatenation operations on the core field records to obtain the audit-side root node hash value means that the gateway forwarding module uses the same L in step S22. hashThe length hash function re-hashes each core field record obtained from decryption to obtain the audit-side leaf node hash value. The audit-side leaf node hash value is then hashed layer by layer according to the same pairing, same odd-number padding, and same sequential concatenation rules used in step S22. The final unique hash value is the audit-side root node hash value. Comparing the audit-side root node hash value byte-by-byte with the root node hash value recorded in the cloud-based evidence receipt refers to the gateway forwarding module using L... hashBased on length, each byte of the hash values ​​of the two root nodes is compared for binary equality from the first byte to the last byte. If all bytes are equal, the comparison result is considered consistent; if any byte is unequal, the comparison result is considered inconsistent. When the comparison result is consistent, the auditor considers all security interaction logs within the audit batch to have remained unchanged between edge aggregation and cloud blockchain uploading. When the comparison result is inconsistent, hash value comparison is performed layer by layer along the local state tree from the root node to the leaf node. This means the gateway forwarding module performs the following two steps: First, based on the decrypted leaf node hash value set, the first local state tree is reconstructed according to rule S22, and the root node hash value of the first local state tree is calculated. The root node hash value of the first local state tree is compared byte by byte with the root node hash value recorded in the cloud evidence receipt. If they are consistent, it is determined that the decrypted leaf node hash value set has not been changed in the long-term storage medium, and the first local state tree is used as the audit benchmark tree. If they are inconsistent, it is directly determined that the local encrypted archive has been tampered with, and the comparison result is reported to the auditor. Second... The core field record obtained from decryption is re-hashed according to the rules in step S22 to obtain the set of hash values ​​of the leaf nodes on the audit side. The second local state tree is reconstructed according to the rules in step S22 using the set of hash values ​​of the leaf nodes on the audit side as the audit verification tree. Starting from the root node of the audit reference tree and the root node of the audit verification tree, the hash values ​​of the nodes at the same level and position of the two trees are compared in sequence—left child node to left child node, right child node to right child node. After identifying which side has a hash value inconsistency first, the comparison continues to the lower level along the side of inconsistency until the comparison reaches the leaf node level. The core field record corresponding to the first leaf node in the audit verification tree that is inconsistent with the audit reference tree points to the tampered security interaction log. The location information includes the target intelligent agent identity identifier, batch identifier, batch sequence number and the timestamp of the corresponding original log entry set. Step S24 uses a coarse-grained screening method by comparing the root node hash value on the audit side with the root node hash value recorded in the cloud-based evidence receipt, and a fine-grained positioning method by comparing the audit benchmark tree with the audit verification tree from top to bottom. When the comparison results are consistent, a single root node hash value comparison is sufficient to complete the entire batch audit. When the comparison results are inconsistent, the number of hash value comparisons required increases logarithmically with the batch size, but does not increase linearly with the increase in batch size. If step S24 is missing, the cloud-based evidence receipt is only a static on-chain record, and it is impossible to establish an executable verification channel between the on-chain root node hash value and the actual data on the edge side. The location information of the tampered security interaction log cannot be generated.

[0056] In warehousing scenarios, if the massive amounts of security interaction logs generated by the target intelligent agent are only collected at the edge, there is a lack of irrefutable on-chain evidence when an audit is triggered, and the logs cannot withstand the retention pressure over several years. If all logs are directly delivered to the cloud blockchain one by one, the number of consensus protocol interactions and on-chain storage overhead will increase exponentially, and the cloud blockchain's per-unit-time evidence storage throughput will be rapidly consumed. The legal attributes of warehousing responsibility traceability further impose hard requirements on the retention period and searchability of the local evidence repository. Any security interaction log that has occurred but cannot be retrieved or verified will become a blind spot for responsibility traceability. Traditional evidence storage solutions mostly adopt two approaches: one is to put the full text of the security interaction log on the blockchain, at the cost of the cloud blockchain being unable to withstand the write pressure in high-concurrency scenarios; the other is to only record the log summary value on the blockchain and keep the full text of the log locally, at the cost of the lack of an executable mutual verification channel between the local and on-chain when an audit is triggered. Once the local log is synchronously tampered with, the on-chain summary value cannot independently point out the location of the tampering. Fixed-batch solutions often have to choose between consensus protocol interaction overhead and audit traceability granularity. Moreover, most existing solutions lack a dual-source credential structure that matches the batch organization rhythm of the edge side. When an audit is triggered, it can only provide a coarse-grained batch-level judgment and cannot lock the tampering to a specific single security interaction log.

[0057] The core idea of ​​step S20 is to use the dynamically adjusted data packaging threshold output in step S10 as the batch granularity basis to build a complete pipeline at the edge, driven by packaging trigger commands, covering field extraction, hash concatenation, dual-source evidence storage, and audit location. Real-time monitoring and packaging trigger commands implement the elastic threshold of step S10 to specific batch trigger times, transforming the elastic threshold control from a numerical convention into an executable batch start and stop signal; field extraction compresses each security interaction log from the original message into a core field record consisting of three core fields, so that the size of the subsequent hash processing object and the number of bytes transmitted in the consensus protocol interaction decrease synchronously; the local state tree constructed by hash concatenation allows any tampering with any core field record in the core field set to be amplified along the hash value transmission path to the root node hash value, giving the root node hash value the overall credential characteristic of covering the entire batch of security interaction logs; dual-source credentials use local encrypted archiving to assume the responsibility of detailed retention and cloud-based evidence storage receipts to assume the responsibility of non-repudiation credentials, and are locked together by batch identifiers, so that the absence or alteration of credentials on one side will be detected by credentials on the other side. Without exceeding the throughput of the cloud blockchain consensus protocol interaction and the on-chain storage capacity, step S20 ensures that each batch of secure interaction logs can obtain an undeniable on-chain root credential, and upon audit triggering, possesses fine-grained traceability capabilities to pinpoint the specific tampered secure interaction log from the root node hash value layer by layer downwards. The dynamically adjusted data packaging threshold output by step S10 continuously changes with the trustworthiness of the target agent. As the batch size of trusted target agents increases, the number of leaf nodes in the local state tree constructed in step S20 increases synchronously, and the scope of the overall credential carried by a single consensus protocol interaction is expanded at once, while the on-chain storage overhead is diluted as the batch size increases. When the batch size of suspicious target agents shrinks to one, the local state tree in step S20 degenerates into a single-node structure, with one secure interaction log corresponding to one root node hash value uploaded to the chain. Upon audit triggering, it is not necessary to trace down the local state tree to directly lock the tampered secure interaction log. This bidirectional adaptation allows step S20 to enjoy the batch expansion benefits of step S10 under normal conditions and the batch contraction benefits of step S10 under abnormal conditions. The number of hash value comparisons required for audit traceability is always kept at the logarithmic level that matches the batch granularity at that time. Under the pressure of long-term stable operation of multi-objective intelligent agents in the warehousing scenario, it maintains low consensus protocol interaction overhead and ensures the ability to locate tampering when audit is triggered.

[0058] Example 2:

[0059] This embodiment, based on Embodiment 1, provides a blockchain-based warehouse data interaction log storage system, such as... Figure 8 As shown, it includes:

[0060] Reputation threshold adjustment module: used to open an edge aggregation buffer in the gateway forwarding module, obtain the original log entry set of the target agent, calculate the current reputation weight parameter of the target agent, update the data packaging threshold of the edge aggregation buffer to the dynamically adjusted data packaging threshold; and decide whether to maintain or forcibly rewrite the dynamically adjusted data packaging threshold based on the current reputation weight parameter.

[0061] Log Packaging and Extraction Module: Used to monitor the number of security interaction log entries collected in the edge aggregation buffer in real time. When the number of collected security interaction log entries is greater than or equal to the dynamically adjusted data packaging threshold, a packaging trigger command is output. Based on the packaging trigger command, the module performs field extraction on the original log entry set in the edge aggregation buffer to generate a core field set.

[0062] The evidence storage audit and location module is used to perform hash concatenation operations on the core field set to build a local state tree and generate a root node hash value. The root node hash value is uploaded to the blockchain to obtain the cloud evidence storage receipt, build a local evidence library, and locate the location information of the tampered security interaction log by comparing the hash value when the audit is triggered.

[0063] Furthermore, in the reputation threshold control module, the method for obtaining the original log entry set includes:

[0064] Based on a preset sliding time window, collect all security interaction logs generated by the target agent within the sliding time window, obtain the current sliding time window log sample set, and append it to the original log entry set.

[0065] The calculation method for the current reputation weight parameter includes:

[0066] The reputation perception statistical sample set, composed of the log sample sets corresponding to the past M sliding time windows, is used to count the number of successful authentications, the number of successful encryption verifications, and the number of data integrity anomalies of the target intelligent agent in the past M sliding time windows. The weighted calculation is then performed to obtain the current reputation weight parameter of the target intelligent agent.

[0067] The method for updating the data packing threshold of the edge aggregation buffer to a dynamically adjusted data packing threshold includes:

[0068] Establish a reverse coupling constraint function between the current reputation weight parameter and the maximum number of log entries allowed in a single aggregation batch, and solve for the value of the maximum number of log entries through the reverse coupling constraint function; based on the value of the maximum number of log entries, dynamically adjust the data packing threshold of the edge aggregation buffer to the maximum number of log entries, and obtain the dynamically adjusted data packing threshold.

[0069] The method for determining whether to maintain or forcibly rewrite the dynamically adjusted data packaging threshold based on the current reputation weight parameter includes:

[0070] The current reputation weight parameter is compared with the preset suspicious reputation threshold to obtain the reputation anomaly judgment result. When the current reputation weight parameter is less than the preset suspicious reputation threshold, the dynamically adjusted data packaging threshold is forcibly rewritten to 1. When the current reputation weight parameter is greater than or equal to the preset suspicious reputation threshold, the dynamically adjusted data packaging threshold is maintained.

[0071] Furthermore, in the log packaging and extraction module, the method for generating the core field set includes:

[0072] Extract the three core fields—encryption algorithm type, authentication dimension, and data integrity status—from each security interaction log from the original log entry set, and concatenate them in a fixed order to obtain a core field record. All core field records constitute the core field set.

[0073] Furthermore, in the evidence storage auditing and location module, the method for constructing a local state tree and generating a root node hash value includes:

[0074] For each core field record in the core field set, perform a hash operation to generate a set of leaf node hash values. Then, perform a hash concatenation operation on the leaf node hash value set layer by layer in a pairwise manner to construct a local state tree and generate the root node hash value of the local state tree.

[0075] The methods and systems of this application may be implemented in many ways. For example, they may be implemented by software, hardware, firmware, or any combination of software, hardware, and firmware. The above-described order of steps for the method is for illustrative purposes only, and the steps of the method of this application are not limited to the order specifically described above, unless otherwise specifically stated.

[0076] In addition, the parts of the technical solutions provided in the embodiments of this application that are consistent with the implementation principles of the corresponding technical solutions in the prior art have not been described in detail, so as to avoid excessive elaboration.

[0077] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the invention. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A blockchain-based method for storing warehouse data interaction logs, characterized in that, The method includes: In the gateway forwarding module, an edge aggregation buffer is opened to obtain the original log entry set of the target agent, calculate the current reputation weight parameter of the target agent, update the data packaging threshold of the edge aggregation buffer to the dynamically adjusted data packaging threshold, and decide whether to maintain or forcibly rewrite the dynamically adjusted data packaging threshold based on the current reputation weight parameter. The system monitors the number of security interaction log entries collected in the edge aggregation buffer in real time. When the number of collected security interaction log entries is greater than or equal to the dynamically adjusted data packaging threshold, a packaging trigger command is output. Based on the packaging trigger command, the system extracts fields from the original log entry set in the edge aggregation buffer to generate a core field set. The system performs hash concatenation operation on the core field set to build a local state tree and generate a root node hash value. The root node hash value is uploaded to the blockchain to obtain a cloud-based evidence receipt and build a local evidence library. When an audit is triggered, the system locates the position information of the tampered security interaction log by comparing the hash value.

2. The blockchain-based warehouse data interaction log storage method according to claim 1, characterized in that, The method for obtaining the original log entry set includes: Based on a preset sliding time window, collect all security interaction logs generated by the target intelligent agent within the sliding time window, obtain the current sliding time window log sample set, and append it to the original log entry set. The calculation method for the current reputation weight parameter includes: The reputation perception statistical sample set, composed of the log sample sets corresponding to the past M sliding time windows, is used to count the number of successful authentications, the number of successful encryption verifications, and the number of data integrity anomalies of the target intelligent agent in the past M sliding time windows. The weighted calculation is then performed to obtain the current reputation weight parameter of the target intelligent agent.

3. The blockchain-based warehouse data interaction log storage method according to claim 1, characterized in that, The method for updating the data packing threshold of the edge aggregation buffer to a dynamically adjusted data packing threshold includes: Establish a reverse coupling constraint function between the current reputation weight parameter and the maximum number of log entries allowed in a single aggregation batch, and solve for the value of the maximum number of log entries through the reverse coupling constraint function; based on the value of the maximum number of log entries, dynamically adjust the data packing threshold of the edge aggregation buffer to the maximum number of log entries, and obtain the dynamically adjusted data packing threshold.

4. The blockchain-based warehouse data interaction log storage method according to claim 1, characterized in that, The method for determining whether to maintain or forcibly rewrite the dynamically adjusted data packaging threshold based on the current reputation weight parameter includes: The current reputation weight parameter is compared with the preset suspicious reputation threshold to obtain the reputation anomaly judgment result. When the current reputation weight parameter is less than the preset suspicious reputation threshold, the dynamically adjusted data packaging threshold is forcibly rewritten to 1. When the current reputation weight parameter is greater than or equal to the preset suspicious reputation threshold, the dynamically adjusted data packaging threshold is maintained.

5. The blockchain-based warehouse data interaction log storage method according to claim 1, characterized in that, The method for generating the core field set includes: Extract the three core fields—encryption algorithm type, authentication dimension, and data integrity status—from each security interaction log from the original log entry set, and concatenate them in a fixed order to obtain a core field record. All core field records constitute the core field set.

6. The blockchain-based warehouse data interaction log storage method according to claim 5, characterized in that, The method for constructing a local state tree and generating a root node hash value includes: For each core field record in the core field set, perform a hash operation to generate a set of leaf node hash values. Then, perform a hash concatenation operation on the leaf node hash value set layer by layer in a pairwise manner to construct a local state tree and generate the root node hash value of the local state tree.

7. The blockchain-based warehouse data interaction log storage method according to claim 6, characterized in that, The implementation method of performing hash concatenation operations layer by layer in a pairwise pairing manner is as follows: Starting from the beginning of the set of leaf node hash values, each pair of adjacent leaf node hash values ​​is grouped together. The two hash values ​​in each group are concatenated according to a fixed order and then hashed again to obtain the hash value of an intermediate node in the next layer. When the number of nodes in the current layer is odd, the unpaired node hash value at the end is copied to itself to form a pair of virtual nodes and then hash concatenation is performed. The same rules are continued to pair and hash concatenate the intermediate node hash values ​​in the next layer until the number of nodes in the next layer converges to 1. The resulting unique node hash value is the hash value of the root node of the local state tree.

8. The blockchain-based warehouse data interaction log storage method according to claim 7, characterized in that, The method for constructing a local evidence base includes: Each core field record in the core field set, along with the corresponding leaf node hash value in the leaf node hash value set, is encrypted and encapsulated to obtain a local encrypted archive. The local encrypted archive and the cloud-based evidence receipt are indexed and associated through a common batch identifier and stored in the long-term retention medium of the edge node to build a local evidence library.

9. The blockchain-based warehouse data interaction log storage method according to claim 8, characterized in that, The method for locating the position information of the tampered security interaction log includes: When an audit is triggered, the local encrypted archive is decrypted and extracted from the local evidence repository. The core field records in the core field set are obtained from the local encrypted archive. The hash operation and hash concatenation operation are re-performed on the core field records to obtain the hash value of the audit-side root node. The hash value of the audit-side root node is compared byte by byte with the root node hash value recorded in the cloud evidence receipt to obtain the comparison result. When the comparison result is inconsistent, the hash value comparison is performed layer by layer from the root node to the leaf node along the local state tree to locate the first inconsistent leaf node path and obtain the location information of the tampered security interaction log.

10. The blockchain-based warehouse data interaction log storage method according to claim 1, characterized in that, The implementation method for opening an edge aggregation buffer in the gateway forwarding module is as follows: In the runtime memory of the gateway forwarding module, independent storage areas are divided according to the identity of the target intelligent agent. Each target intelligent agent corresponds to an independent edge aggregation buffer. During the operation of the edge aggregation buffer, the security interaction log is appended in a first-in-first-out order. After each batch packaging is completed, the log entries that have been put on the chain are removed.

11. A blockchain-based warehouse data interaction log storage system, used to implement the blockchain-based warehouse data interaction log storage method according to any one of claims 1-10, characterized in that, The system includes: Reputation threshold adjustment module: used to open an edge aggregation buffer in the gateway forwarding module, obtain the original log entry set of the target agent, calculate the current reputation weight parameter of the target agent, update the data packaging threshold of the edge aggregation buffer to the dynamically adjusted data packaging threshold; and decide whether to maintain or forcibly rewrite the dynamically adjusted data packaging threshold based on the current reputation weight parameter. Log Packaging and Extraction Module: Used to monitor the number of security interaction log entries collected in the edge aggregation buffer in real time. When the number of collected security interaction log entries is greater than or equal to the dynamically adjusted data packaging threshold, a packaging trigger command is output. Based on the packaging trigger command, the module performs field extraction on the original log entry set in the edge aggregation buffer to generate a core field set. The evidence storage audit and location module is used to perform hash concatenation operations on the core field set to build a local state tree and generate a root node hash value. The root node hash value is uploaded to the blockchain to obtain the cloud evidence storage receipt, build a local evidence library, and locate the location information of the tampered security interaction log by comparing the hash value when the audit is triggered.

Images