Markov chain-based internet of things device data evidence preservation method, device and medium

Abstract

This application discloses a method, apparatus, and medium for data notarization of IoT devices based on Markov chains. Device nodes predict the network state within a preset time period using a dynamically updated transition matrix. Based on the predicted network state, the node determines whether to directly upload the data to be notified to the blockchain. The transition matrix is ​​trained using data adapted to the business region to which the device node belongs. When the predicted network state indicates future network instability, the device node temporarily stores the data to be notified in its local ledger. After the network recovers, the device node uploads the data from its local ledger to the target blockchain for notarization. Therefore, this method allows device nodes to dynamically notarize data based on the predicted network state, avoiding data upload failures under poor network conditions and preventing the device node from repeatedly uploading the same data to the blockchain.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to a method, apparatus and storage medium for storing data of Internet of Things devices based on Markov chains. Background Technology

[0002] Currently, to ensure the consistency and integrity of data in IoT devices used for law enforcement, it is necessary to store the data in a blockchain to guarantee its security and integrity.

[0003] However, in practical applications, it is often impossible to guarantee that the network environment of the location of IoT devices will remain stable. For example, IoT devices used for law enforcement at border crossings (especially individual soldier devices) may be in a coupled state, which can easily lead to the failure of IoT devices to store data on the blockchain. If IoT devices continuously retransmit the failed data to the blockchain when data storage fails (data storage failure), it will continuously consume the power of the IoT devices, making it impossible to guarantee the effective use of the IoT devices.

[0004] There is currently no effective solution to the technical problem of data storage failure caused by IoT devices being in a sporadic connection state in the existing technology. Summary of the Invention

[0005] The embodiments of this disclosure provide a data evidence storage method, apparatus, and storage medium to at least solve the technical problem in the prior art where data evidence storage fails due to IoT devices being in a coupled state.

[0006] According to one aspect of the present disclosure, a data notarization method is provided, comprising: a device node dynamically updating the transition matrix in a Markov chain prediction model based on its own historical network state data, and predicting the network state in a future period based on the updated Markov chain prediction model and the current network state; wherein the transition matrix is ​​used to characterize the transition probability between network states, and the initial Markov chain prediction model is a probability model applicable to the business area to which the device node belongs for predicting network state transitions; if the network state of the device node is unstable in the future period, storing the data to be notarized generated in the future period in a local ledger corresponding to the target blockchain, wherein the data to be notarized is stored in the local ledger in the data format required by the blockchain ledger; if the network state is stable in the future period, uploading the data to be notarized to the target blockchain for notarization; wherein the target blockchain is maintained by multiple device nodes in the same business area; and after the actual network state recovers and stabilizes, sending the data to be notarized stored in the local blockchain to the main blockchain for notarization.

[0007] According to another aspect of the present disclosure, a storage medium is also provided, the storage medium including a stored program, wherein, when the program is executed, a processor performs any of the methods described above.

[0008] According to another aspect of the present disclosure, a data storage device is also provided, comprising: a prediction module, configured to dynamically update the transition matrix in a Markov chain prediction model by a device node based on its own historical network state data, and predict the network state in a future period based on the updated Markov chain prediction model and the current network state; wherein the transition matrix is ​​used to characterize the transition probability between network states, and the initial Markov chain prediction model is a probability model applicable to the business area to which the device node belongs for predicting network state transitions; a judgment module, configured to, if the network state of the device node is unstable in the future period, store the data to be stored in the local ledger corresponding to the target blockchain, wherein the data to be stored is stored in the local ledger in the data format required by the blockchain ledger, and if the network state is stable in the future period, upload the data to be stored to the target blockchain for storage; and a storage module, configured to, after the actual network state recovers and stabilizes, upload the data to be stored in the local ledger to the target blockchain for storage.

[0009] According to another aspect of the present disclosure, a data storage device is also provided, comprising: a processor; and a memory connected to the processor, configured to provide the processor with instructions to perform the following processing steps: dynamically updating the transition matrix in a Markov chain prediction model based on its own historical network state data, and predicting the network state in a future period based on the updated Markov chain prediction model and the current network state; wherein the transition matrix is ​​used to characterize the transition probability between network states, and the initial Markov chain prediction model is a probability model applicable to the business area to which the device node belongs for predicting network state transitions; if the network state is unstable in the future period, storing the data to be stored in the future period in a local ledger corresponding to the target blockchain, wherein the data to be stored is stored in the local ledger in the data format required by the blockchain ledger; if the network state is stable in the future period, uploading the data to be stored to the target blockchain for storage; wherein a target blockchain is maintained by multiple device nodes in the same business area; and after the actual network state recovers and stabilizes, uploading the data to be stored in the local ledger to the target blockchain for storage.

[0010] In this embodiment, the device node predicts the network state within a preset time period using a dynamically updated transition matrix. Based on the predicted network state, it determines whether to directly send the data to be stored to the target blockchain. The transition matrix is ​​trained using data adapted to the business region of the device node, ensuring relatively accurate network state prediction. When the predicted network state indicates future instability, the device node first stores the data to be stored in a local ledger, which can be in the form of a blockchain ledger, storing the data according to the required format. After network recovery, the device node uploads the data to be stored from the local ledger to the target blockchain for storage. The target blockchain is maintained by multiple device nodes within the same business region. If the network is stable, the device node directly uploads the data to be stored to the target blockchain. Therefore, this method allows the device node to adaptively store the data based on the predicted network state. That is, when the network status of the device node is poor, the data is first stored in the local ledger. After the local node network is restored, the data stored in the local ledger is then uploaded to the local blockchain. This avoids the failure of device node data to be uploaded to the blockchain when the network status is poor, and also avoids device nodes repeatedly uploading the same data to be stored to the blockchain. Attached Figure Description

[0011] The accompanying drawings, which are included to provide a further understanding of this disclosure and form part of this application, illustrate exemplary embodiments of this disclosure and are used to explain this disclosure, but do not constitute an undue limitation of this disclosure. In the drawings:

[0012] Figure 1 This is a hardware structure block diagram of a computing device for implementing the method described in Embodiment 1 of this disclosure;

[0013] Figure 2 This is a schematic diagram of a data evidence storage system according to the first aspect of Embodiment 1 of this disclosure;

[0014] Figure 3 This is a flowchart illustrating the data evidence storage method according to the first aspect of Embodiment 1 of this disclosure;

[0015] Figure 4 This is a flowchart illustrating how a data uplink process is determined using a transition matrix, as provided in Embodiment 1 of this disclosure.

[0016] Figure 5A A schematic diagram of a data storage process corresponding to a connectivity state provided in Embodiment 1 of this disclosure;

[0017] Figure 5BA schematic diagram of a data notarization process corresponding to a weak connection state provided in Embodiment 1 of this disclosure;

[0018] Figure 5C A schematic diagram of a data storage process corresponding to a disconnected state provided in Embodiment 1 of this disclosure;

[0019] Figure 6 A schematic diagram illustrating the interaction process between a device node, a local blockchain, and a main blockchain, provided in Embodiment 1 of this disclosure;

[0020] Figure 7 This is a schematic diagram of a data storage device according to the first aspect of Embodiment 2 of this disclosure; and

[0021] Figure 8 This is a schematic diagram of a data storage device according to the first aspect of Embodiment 3 of this disclosure. Detailed Implementation

[0022] To enable those skilled in the art to better understand the technical solutions of this disclosure, the technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this disclosure, and not all embodiments. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this disclosure.

[0023] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0024] Example 1

[0025] According to this embodiment, a data storage method embodiment is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Also, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0026] The method embodiments provided in this example can be executed on mobile terminals, computer terminals, servers, or similar computing devices. Figure 1 A hardware block diagram of a computing device for implementing a data evidence storage method is shown. Figure 1 As shown, a computing device may include one or more processors (processors may include, but are not limited to, microprocessors such as MCUs or programmable logic devices such as FPGAs), memory for storing data, transmission devices for communication functions, and input / output interfaces. The memory, transmission devices, and input / output interfaces are connected to the processor via a bus. In addition, it may also include a display, keyboard, and cursor control device connected to the input / output interfaces. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, a computing device may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0027] It should be noted that the aforementioned one or more processors and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element in a computing device. As involved in the embodiments of this disclosure, the data processing circuits serve as processor control (e.g., selection of a variable resistor termination path connected to an interface).

[0028] The memory can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the data storage method in this embodiment of the present disclosure. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby realizing the above-mentioned data storage method for the application. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to the computing device via a network. Examples of the above-mentioned networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0029] The transmission device is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the computing device's communications provider. In one example, the transmission device includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0030] The display can be, for example, a touchscreen liquid crystal display (LCD), which allows users to interact with the user interface of the computing device.

[0031] It should be noted here that, in some optional embodiments, the above... Figure 1 The computing device shown may include hardware elements (including circuitry), software elements (including computer code stored on a computer-readable medium), or a combination of both hardware and software elements. It should be noted that... Figure 1 This is only one instance of a specific particular instance, and is intended to illustrate the types of components that may exist in the aforementioned computing devices.

[0032] Figure 2 This is a schematic diagram of the data storage system according to this embodiment.

[0033] Reference Figure 2 As shown, the system can include: device nodes, a target blockchain, and a main blockchain. The network state of the device nodes is unstable, sometimes connected, sometimes disconnected, and sometimes in a weak connection state. Device nodes can refer to mobile IoT devices. Multiple device nodes within the same business area can form a local blockchain. The target blockchain can be a local blockchain, and each device node can upload data requiring notarization locally to the target blockchain (the local blockchain corresponding to the business area to which the device node belongs) for notarization. Based on actual business needs, the local blockchain can cross-chain at least a portion of the data notarized within its own blockchain to the main blockchain for notarization through local blockchain nodes. The main blockchain can be used to uniformly notarize data generated by device nodes across multiple business areas.

[0034] The device node's local ledger is used to temporarily store data requiring notarization when its network conditions are poor. This local ledger is a blockchain ledger, and the data to be notarized is stored in the local ledger in the form of blockchain data. The data format of the data stored in the local ledger is consistent with the data format of the data uploaded to the target blockchain. The data is then uploaded to the target blockchain for notarization once the network conditions are restored, thus ensuring the security, integrity, and consistency of the data throughout the entire process.

[0035] In practical applications, there are various business regions, each with multiple device nodes. These business regions have different geographical locations, resulting in different underlying network environments and consequently, variations in the network environments of the device nodes within each region. In this specification, a device node could be, for example, an IoT device (such as a soldier's device) used for law enforcement at a customs port, and different business regions could refer to different ports of entry.

[0036] The specific cooperation between device nodes, local blockchain, and main blockchain in this data storage system to achieve dynamic data storage for device nodes, ensuring that device nodes can still effectively store data to be stored even when network conditions are poor, will be explained below.

[0037] It should be noted that the device nodes in the system can be adapted to the hardware structure of the computing devices described above.

[0038] Under the aforementioned operating environment, according to the first aspect of this embodiment, a data evidence storage method is provided, which can be applied to... Figure 2 The data storage system shown can be implemented by... Figure 2 The device nodes, local blockchain, and main blockchain are implemented together. Figure 3 A flowchart illustrating the method is shown below. (Refer to...) Figure 3 As shown, the method includes:

[0039] S302: The device node dynamically updates the transition matrix in the Markov chain prediction model based on its own historical network state data, and predicts the network state in future time periods based on the updated Markov chain prediction model and the current network state.

[0040] S304: If the network status of the device node is unstable in the future period, the data to be stored in the future period will be stored in the local ledger corresponding to the target blockchain; if the network status is stable in the future period, the data to be stored in the target blockchain will be uploaded to the blockchain for storage.

[0041] S306: After the actual network status stabilizes, the device node will upload the data to be stored in the local ledger to the target blockchain for storage.

[0042] In this application, a device node can refer to a device whose network status is unstable.

[0043] In this specification, the data evidence storage system and methods can be applied to various scenarios. For example, the device nodes mentioned above could be IoT devices in customs ports. Alternatively, the device node could be a device within a power grid structure; for instance, it could be a power grid device in an area with poor network signal. The following explanation will use the example of IoT devices (such as individual soldier devices) used for law enforcement in customs ports, a target blockchain being a local blockchain maintained by various IoT devices within the same port, and different business areas being different ports.

[0044] Specifically, IoT devices can dynamically update the transition matrix in the Markov chain prediction model based on their own historical network state data, and predict the network state in future periods based on the updated Markov chain prediction model and the current network state. The transition matrix is ​​used to characterize the transition probability between network states, and the Markov chain prediction model is a probabilistic model applicable to the business area to which the device node belongs for predicting network state transitions (S302). It should be noted that the initial Markov chain prediction model can be trained uniformly by training equipment (such as server equipment) within the port to which the device node belongs, using historical network-related data from various IoT devices within that port. Therefore, the Markov chain prediction model corresponds to the port to which the IoT device belongs; that is, the initial transition matrix of the Markov chain prediction model is applicable to all IoT devices within the port to which the IoT device belongs.

[0045] Furthermore, in this application, after pre-training the Markov chain prediction model, the transition matrix in the Markov chain prediction model can be adaptively updated in the IoT device, thereby adjusting the Markov chain prediction model to be more suitable for the IoT device itself to predict network states. Thus, based on this Markov chain prediction model, future network states can be predicted more accurately.

[0046] The network state of an IoT device within a given time slice can be categorized into connected, weakly connected, and disconnected states. Historical network state data can include the network state for each time slice within a historical period. Specifically, an IoT device can determine the network state for a future preset time period based on the network state of the current time slice and the transition matrix in the Markov chain prediction model, using the formula of the Markov chain prediction model.

[0047] The transition matrix is ​​in the form shown below (the numbers are for illustrative purposes only):

[0048]

[0049] The transition matrix can be understood as a state transition probability matrix. The values ​​in the first row of this matrix, from left to right, represent the probability of transitioning from a connected state to a connected state, the probability of transitioning from a connected state to a weakly connected state, and the probability of transitioning from a connected state to a disconnected state. The values ​​in the second row of this matrix, from left to right, represent the probability of transitioning from a weakly connected state to a connected state, the probability of transitioning from a weakly connected state to a weakly connected state, and the probability of transitioning from a weakly connected state to a disconnected state. The values ​​in the third row of this matrix, from left to right, represent the probability of transitioning from a disconnected state to a connected state, the probability of transitioning from a disconnected state to a weakly connected state, and the probability of transitioning from a disconnected state to a disconnected state.

[0050] The formula for the Markov chain prediction model is:

[0051] X t+i =(T updated ) i ×X t

[0052] Among them, T updated Let be the transition matrix in the updated Markov chain prediction model, where i represents the transition matrix for T. updated Matrix raised to the power of i, X t X represents the current network status of IoT devices. t+i This represents the predicted network state in the i-th time slice of the future. The above formula can be used to determine the network state in each time slice within a future preset duration.

[0053] Among them, X t+i With X t All are in the form of probability matrices. Assuming the current network state is a weakly connected state, the probability matrix X corresponding to this network state can be determined. t : That is, the first value in the probability matrix represents the probability that the network state is connected, the second value represents the probability that the network state is weakly connected, and the third value represents the probability that the network state is disconnected. Substituting this probability matrix and transition matrix into the formula of the Markov chain prediction model above, the network state X in the i-th time slice can be determined. t+i : Where a, b, and c represent the probabilities of the network state being connected, weakly connected, and disconnected, respectively. This method allows us to determine the network state for each future time slice, and thus obtain the network state for future time periods (such as several future time slices).

[0054] If an IoT device predicts that the network condition will be unstable in the future, it stores the data to be stored in the local ledger corresponding to the target blockchain. If the network condition is stable in the predicted future period, it uploads the data to the target blockchain for storage. The target blockchain is maintained by multiple device nodes within the same business area (S304). After the actual network condition stabilizes, the IoT device sends the data to be stored in the local ledger to the target blockchain for storage (S306).

[0055] from Figure 2 As can be seen, a local blockchain can contain multiple IoT devices within the same business area (port).

[0056] For an IoT device, steps S302-S304 can predict the network status within a future time period (the duration of which can be set to a relatively short duration, such as 3-5 time slices). If the predicted network status is unstable, the IoT device's data to be stored can be temporarily stored in a local ledger (i.e., local accounting). Once the IoT device's network is restored, the data previously stored in the local ledger can be uploaded to the target blockchain for storage.

[0057] Specifically, nodes in a local blockchain can include IoT devices (law enforcement equipment) and IoT network devices within a business area (port), as well as local blockchain nodes. Local blockchain nodes can refer to server devices with relatively stable network conditions within the port, or devices within the port used for interaction with staff and for staff to view management pages. Because local blockchain nodes have relatively stable network conditions, data already stored on the local blockchain can be transferred to the main blockchain via these local blockchain nodes.

[0058] The specific conditions for "stable" and "unstable" network status can be set according to actual business needs. For example, an "unstable" network status could mean that the network is predicted to be "disconnected" for the entire future period, while a "stable" network status would be the opposite. As another example, an "unstable" network status could mean that the network is predicted to be mostly "disconnected" for the majority of the future period, while a "stable" network status would be the opposite.

[0059] As described in the background section, IoT devices (especially individual soldier devices) used for law enforcement at border crossings may be in a coupled network state, which can easily lead to the failure of IoT devices to store data on the blockchain. If IoT devices continuously retransmit the failed data to the blockchain when data storage fails (data notarization failure), it will continuously consume the power of the IoT devices, making it impossible to guarantee the effective use of the IoT devices.

[0060] In view of this, refer to Figure 4 As shown, in this application, the IoT device (i.e., the device node) predicts the network state within a preset future time period using a dynamically updated transition matrix. Based on the predicted network state, it determines whether to directly send the data to be stored to the target blockchain. Furthermore, the predicted network state is based on a Markov chain prediction model adapted to the business area of ​​the IoT device, and the transition matrix in the Markov chain prediction model is dynamically updated locally on the IoT device, thus ensuring relatively accurate network state predictions. When the predicted network state indicates future network instability, the IoT device temporarily stores the data to be stored in its local ledger corresponding to the target blockchain. After the network recovers, the IoT device then sends the data to be stored to the target blockchain for storage via its local blockchain.

[0061] Therefore, this method enables IoT devices to adaptively store data to be stored based on predicted network conditions. Specifically, if a poor network condition is predicted for the IoT device (inability to communicate with the target blockchain), the data is temporarily stored in a local ledger. Once the network is restored, the data stored locally is uploaded to the target blockchain. This avoids data upload failures due to poor network conditions and prevents the IoT device from repeatedly uploading the same data to the blockchain.

[0062] Furthermore, the network status of IoT devices in this specification can be further categorized into connected, weakly connected, and disconnected states. Specifically, when the network status is predicted to be connected or weakly connected, the IoT device can directly upload the data to be stored on the target blockchain for evidence storage. (Refer to...) Figure 5A As shown, when the network state is predicted to be connected, IoT devices can directly upload the data to be stored to the target blockchain. Figure 5B As shown, when the network state is predicted to be weakly connected, IoT devices can upload the data to be stored to the target blockchain through a neighboring device network approach; that is, the data to be stored is uploaded to the target blockchain through neighboring devices with better network conditions. (Refer to...) Figure 5CAs shown, when the network is predicted to be disconnected, IoT devices can store the data to be stored in a local ledger corresponding to the target blockchain. After the network is restored, the data to be stored in the local ledger will be uploaded to the target blockchain.

[0063] It should be noted that, depending on the actual business needs, the target blockchain in this embodiment can also be the main blockchain, that is, the operation of transferring the data to be stored across the local blockchain to the main blockchain is omitted.

[0064] Optionally, the operation of dynamically updating the transition matrix in the Markov chain prediction model based on historical network state data by the device node specifically includes: the device node acquiring its own historical network-related data, which includes at least one of the following: Received Signal Strength Indicator (RSSI), network latency information, packet loss rate, and bandwidth fluctuation information; the device node determining the corresponding historical network state data based on the historical network-related data, which includes the network state for each historical time slice, wherein the network state includes any one of the following: connected state, weakly connected state, and disconnected state; the device node determining the target window size corresponding to the current network environment and extracting the network state sequence within the target window size from the historical network state data; and the device node updating the transition matrix in the Markov chain prediction model based on the network state sequence.

[0065] In other words, IoT devices can discretize the network state for each time slice based on network-related data such as Received Signal Strength Indicator (RSSI) (scanned in real-time by the IoT device's network card), network latency, packet loss rate, and bandwidth fluctuation information (classifying the network state into three states: connected, weakly connected, or disconnected), thereby determining historical network state data. Specifically, thresholds can be preset for RSSI, network latency, and packet loss rate (two thresholds for each value). The network state for each time slice is then determined by comparing the preset thresholds with the actual values ​​of the relevant network data for each time slice.

[0066] For example, thresholds are set for RSSI as -75dBm and -85dBm, for network latency as 200ms and 500ms, and for packet loss rate as 10% and 30%. If the RSSI is greater than -75dBm, the network latency is less than 200ms, and the packet loss rate is less than 10% in a given time slice, the network state for that time slice is determined to be connected. If the RSSI is between -75dBm and -85dBm, the network latency is between 200ms and 500ms, and the packet loss rate is between 10% and 30%, the network state for that time slice is set to weakly connected. If neither of the aforementioned conditions is met (i.e., neither connected nor weakly connected conditions are satisfied), the network state for that time slice is set to disconnected.

[0067] Then, the IoT device can determine the target window size corresponding to the current network environment. It then extracts a network state sequence representing the target window size from historical network state data and updates the transition matrix in the Markov chain prediction model based on this sequence. The update of the transition matrix in the Markov chain prediction model can be achieved by analyzing the transition patterns of each network state in the network state sequence. The specific method for determining the target window size will be explained later.

[0068] Optionally, the operation of updating the transition matrix in the Markov chain prediction model based on the network state sequence by the device node specifically includes: the device node counting the transition frequency between each network state in the network state sequence to generate a local transition frequency matrix; the device node normalizing the local transition frequency matrix to obtain a local transition probability matrix; and the device node updating the transition matrix in the Markov chain prediction model based on the local smoothing factor and the local transition probability matrix.

[0069] Specifically, IoT devices can update the transition matrix in the Markov chain prediction model using the following formula.

[0070] T updated =α×T raw +(1-α)×T historical

[0071] Among them, T updated This is the updated transition matrix (i.e., the transition matrix in the updated Markov chain prediction model). T raw This is the local transition probability matrix determined through the aforementioned network state sequence, that is, the local transition probability matrix determined in the current period. historicalThis is the transition matrix relative to the previous time slice, specifically the transition matrix from the Markov chain prediction model in the previous period. α is the local smoothing factor, where a larger α results in a larger update magnitude to the transition matrix, thus being more responsive to changes in the local network environment of the IoT device.

[0072] The local smoothing factor can be determined based on the network environment of the IoT devices. This local smoothing factor can be manually set according to the network environment; for example, if α = 0.1, it emphasizes historical experience; if α = 0.9, it indicates a rapid response to changes in the network environment.

[0073] Of course, the local smoothing factor can also be determined using environmental information related to the IoT device. For example, environmental information could include: the IoT device's current movement speed, base station distribution density (or AP distribution density), and time-period characteristics (e.g., whether it's currently during peak or off-peak season at a port). Specifically, the local smoothing factor for the IoT device can be determined by inputting this environmental information into a pre-trained supervised model (such as a neural network model).

[0074] In other words, in this method, IoT devices can continuously update the Markov chain prediction model, specifically, the transition matrix within the Markov chain prediction model. The duration of each period can be set, and the transition matrix in the Markov chain prediction model is updated once within each period. The network state is predicted within that period using the Markov chain prediction model. The aforementioned target window size can refer to one period, meaning the transition matrix is ​​updated once per time window.

[0075] The local transition frequency matrix represents the transition frequencies between different network states, including the frequencies of "connected state -> connected state", "connected state -> weakly connected state", "connected state -> disconnected state", "weakly connected state -> connected state", "weakly connected state -> weakly connected state", "weakly connected state -> disconnected state", "disconnected state -> connected state", "disconnected state -> weakly connected state", and "disconnected state -> disconnected state". Therefore, by normalizing this local transition frequency matrix, the local transition probability matrix can be determined. This matrix is ​​then used to update the transition matrix in the Markov chain prediction model, yielding the transition matrix for the current period. This transition matrix is ​​then updated again in the next period.

[0076] Optionally, the operation of the device node determining the target window size corresponding to the current network environment specifically includes: the device node determining the network fluctuation situation of the current network environment based on historical network state data; and the device node determining the target window size based on the network fluctuation situation, wherein the higher the frequency of network fluctuation, the smaller the target window size. That is, in this method, the more volatile the network, the smaller the target window size, and the higher the update frequency of the transition matrix in the Markov chain prediction model.

[0077] Specifically, the network fluctuation frequency can be determined by historical network state data (for example, determining the number of times the network state changes, and then determining the network fluctuation frequency based on the number of times; the more times within a certain period of time, the higher the network fluctuation frequency). Based on this network fluctuation frequency, the target window size can be determined (for example, the target window size is set to 30 time slices in high-frequency jitter scenarios, and 100 time slices in stable network conditions). Adjusting the target window size is mainly to improve continuous processing throughput.

[0078] Optionally, the training steps of the Markov chain prediction model include: the training device in the business area acquires the historical network state data sequence of all device nodes in the business area; the training device discretizes the historical network state data sequence to obtain a state sequence composed of connected states, weakly connected states, and disconnected states; the training device divides the state sequence based on a sliding window mechanism, and for the state sequence within each time window, performs the following sub-steps: counts the transition frequency between states within the current window and generates the initial transition probability matrix for that window; based on the exponential smoothing algorithm, uses a global smoothing factor to weight and fuse the initial transition probability matrix of the current window with the optimized transition probability matrix of the previous window to generate the optimized transition probability matrix for the current window; the training device collects all optimized transition probability matrices generated during the training process, calculates the average value of the optimized transition probability matrices corresponding to the last preset proportion of time windows, generates the final transition matrix, and uses the final transition matrix as the initial transition matrix of the Markov chain prediction model after training.

[0079] In this method, different business areas (different ports) can initialize their own Markov chain prediction models, that is, initialize the transition matrix in the Markov chain prediction model corresponding to their own business areas, so that the transition matrix is ​​adapted to the network environment of the business area.

[0080] First, for a business area (such as a port), training equipment (such as server equipment) within the port can collect historical network state data sequences of various IoT devices within the port, thereby acquiring a large amount of data for training. Then, the training equipment uses a sliding window approach to determine the state sequences within multiple time windows for each historical network state data sequence. For the data of the same IoT device, it sequentially determines the initial transition probability matrix and the optimized transition probability matrix for each window (time window). The initial transition probability matrix is ​​determined by statistically analyzing the transition frequencies between different network states in the state sequences within the window (refer to the method for determining the local transition probability matrix described above). The optimized transition probability matrix is ​​obtained by smoothing the initial transition probability matrix of the current window with the optimized transition probability matrix of the previous window.

[0081] The optimal transition probability matrix T for each window (the k-th window) can be determined using the following formula. k_smoothed .

[0082] T k_smoothed =β×T k +(1-β)×T k-1_smoothed

[0083] Where β is the global smoothing factor, T k Let T be the initial transition probability matrix for the k-th window. k-1_smoothed Let T be the optimized transition probability matrix for the (k-1)th window, where k ≥ 2. 1_smoothed =T1.

[0084] Furthermore, the computing device can determine the global smoothing factor corresponding to the current window based on the initial transition probability matrix of the current window and the initial transition probability matrix of the previous time window, and then update the initial transition probability matrix of the current window based on the global smoothing factor corresponding to the current window, as shown in the following formula.

[0085] T k_smoothed =β k ×T k +(1-β k )×T k-1_smoothed

[0086] Specifically, β can be determined using the following formula. k The value:

[0087]

[0088] in, The initial transition probability matrix T is located in the k-th window. k The element in the i-th row and j-th column; The initial transition probability matrix T is located in the (k-1)th window. k-1 The element in the i-th row and j-th column; D is the initial transition probability matrix T of the k-th window. k The initial transition probability matrix T of the (k-1)th window k-1 The distance between them; D max For matrix T k With matrix T k-1 The theoretical maximum value of the distance between them, for this application, can be... Among them, D and D max Both can be calculated using the L2 distance between matrices.

[0089] Therefore, in this application, the global smoothing factor β(β k This reflects the initial transition probability matrix T calculated for each time window. k The initial transition probability matrix T relative to the previous time window k-1 The difference between them. The closer the β value is to 1, the greater the difference. This difference reflects the difference in the transition frequency between different network states in each time window relative to the previous time window. Therefore, when the initial transition probability matrix T... k The initial transition probability matrix T of the previous time window k-1 When there are significant differences between them, the optimized transition probability matrix T obtained after weighted calculation k_smoothed This will reflect the difference to the greatest extent possible, and it will not be offset by the smoothing calculations above.

[0090] Furthermore, by iteratively smoothing the calculation from front to back through time windows, the resulting optimized transition probability matrix can continuously remember the differences in the transition frequency between different network states that exist in different time windows during each iteration.

[0091] Finally, the optimized transition probability matrices of each IoT device can be averaged over the last preset proportion of the time window (e.g., the last 10% window for each IoT device) to obtain the initial transition probability matrix of the corresponding IoT device.

[0092] Alternatively, the optimized transition probability matrices of each IoT device for the last preset proportion of the time window (e.g., the last 10% window for each IoT device) can be averaged together to obtain the initial transition matrix of the port.

[0093] Alternatively, the global smoothing factor can be determined in a similar way to the local smoothing factor. It can be set manually according to the port's network environment, or it can be determined using environmental information associated with the port (e.g., the port's base station distribution density (or AP distribution density)).

[0094] In practical applications, the network infrastructure conditions vary across different ports of entry; different seasons and weather conditions (temperature variations, rain, sandstorms, etc.) and different types of IoT devices (individual soldier, vehicle-mounted, and fixed devices, etc.) also lead to different network environments. Furthermore, some IoT devices are mobile (individual soldier, vehicle-mounted). Therefore, this method first trains an initial transition matrix corresponding to each port of entry, and then fine-tunes (dynamically updates) it on the IoT devices. This method combines fixed and law enforcement scene environments to update the transition matrix, thereby enabling more accurate data notarization for IoT devices.

[0095] Two examples of initial transition matrices are given, and Table 2 shows the characteristics and application strategies of transition matrices corresponding to different ports of entry. For a stable network environment, the transition matrix may be in the following form: For network environments with high-frequency jitter, the transfer matrix may take the following form:

[0096] Table 2

[0097]

[0098] Optionally, if the network status of the device node is unstable in the future period, the data to be stored in the future period will be stored in the local ledger corresponding to the target blockchain. If the network status is stable in the future period, before uploading the data to be stored to the target blockchain for notarization, the method further includes: the device node dividing the data to be stored in the future period into several slices; the device node hashing the slices and generating corresponding Merkle tree certificates based on the hashing results; the device node storing the Merkle tree certificates and the slices signed with its own private key in the local ledger; and wherein the operation of storing the data to be stored in the local ledger corresponding to the target blockchain includes: storing the Merkle tree certificates and the slices signed with its own private key in the local ledger corresponding to the target blockchain; and wherein the operation of uploading the data to be stored to the target blockchain for notarization includes: uploading the Merkle tree certificates and the slices signed with its own private key to the target blockchain for notarization.

[0099] In other words, IoT devices can segment the data to be proven, obtaining several data slices corresponding to that data. Furthermore, they can generate Merkle tree credentials corresponding to these data slices, which are used to verify the integrity of the data to be proven, composed of the data slices. If the IoT device anticipates network instability, it can store the data slices and Merkle tree credentials in its local ledger instead of the data to be proven. Alternatively, if the IoT device anticipates network stability, it can also upload the data slices and Merkle tree credentials to the target blockchain.

[0100] This Merkle tree credential can be used by the target blockchain to verify the integrity of several data slices. Both the local blockchain and the main blockchain can use the Merkle tree credential to verify the integrity of these data slices. Specifically, the Merkle tree credential can include the Merkle tree path and the root hash of the Merkle tree (referred to as the first root hash). These data slices can be encrypted and stored in the local ledger or uploaded to the target blockchain.

[0101] It should be noted that IoT devices can only segment the data to be stored when the network status is predicted to be unstable. That is, IoT devices can only segment the data to be stored when it is necessary to temporarily record the data (store it in the local ledger) to obtain several corresponding slice data and corresponding Merkle tree vouchers.

[0102] The target blockchain can verify the integrity of several data slices using smart contracts pre-deployed within it, based on the received Merkle tree credentials. It can also verify the signatures of these data slices. Only after all verifications are passed can the data slices be uploaded to the target blockchain. When the target blockchain is a local blockchain, the local blockchain can cross-chain the data to be stored to the main blockchain through local blockchain nodes. That is, several data slices and their corresponding Merkle tree credentials are sent to the main blockchain for uploading. Of course, the specific data to be stored that needs to be cross-chained to the main blockchain can be configured according to actual business needs, instead of uploading all data stored on the local blockchain.

[0103] It should also be noted that the size of the slice data can be determined based on network conditions (e.g., larger slices are used when the network is frequently connected, and smaller slices are used when the network is frequently disconnected). Furthermore, the number of slices can be determined based on the priority of the data to be stored, with the aim of sending high-priority data to the target blockchain first. For a single piece of data to be stored, the higher the priority, the more slices it can be divided into (e.g., anti-smuggling orders have high priority and can be divided into 3 slices; ordinary temperature and humidity data can be directly uploaded to the blockchain without being sliced). Additionally, the data storage location is determined based on the prediction results of the Markov chain prediction model. If the Markov chain prediction model determines that the network recovery time is short, the slice data can be stored in the memory of the IoT device; if the predicted network recovery time is long, the slice data can be stored in the flash memory of the IoT device.

[0104] Optionally, the target blockchain is a local blockchain corresponding to the business area, and the target blockchain is connected to the main blockchain; the method further includes: the target blockchain sending several slice data and Merkle tree credentials corresponding to the several slice data to the main blockchain through local blockchain nodes; after receiving the several slice data and Merkle tree credentials, the main blockchain calls the main chain smart contract pre-deployed in the main blockchain to calculate the shard hash corresponding to the several slice data, and recalculate the root hash according to the shard hash and the Merkle path in the Merkle tree credentials; the main chain smart contract compares the recalculated root hash with the root hash in the Merkle tree credentials, and verifies the signature of the several slice data using the public key of the device node; and when the root hash comparison result is consistent and the signature verification is successful, the main chain smart contract generates cross-chain verification credentials for the several slice data, and stores the several slice data and cross-chain verification credentials in the main blockchain.

[0105] In other words, the target blockchain (local blockchain) can send the data slices and Merkle tree credentials to the main blockchain. The main blockchain can then verify the data slices based on a smart contract (main chain smart contract) (verifying whether they have been tampered with and whether they can be used to form the data to be verified). Specifically, the main chain smart contract can use Merkle tree credentials to verify the integrity of the data slices and perform routine signature verification (verifying the signatures of IoT devices). If the verification is successful, a cross-chain verification credential for the data slices is generated, and the data slices and the corresponding cross-chain verification credential can be stored in the main blockchain.

[0106] Specifically, the Merkle tree path in the Merkle tree certificate represents the structure of a Merkle tree generated from several slices of data. The main chain smart contract can determine the hash value (shard hash) of each slice of data, and then, based on the hash value (shard hash) of each slice of data, use the Merkle tree path in the Merkle tree certificate to re-determine the root hash (called the second root hash) of the Merkle tree corresponding to the several slices of data. Then, it compares whether the second root hash is consistent with the first root hash, thereby verifying the integrity of the several slices of data (if the second root hash is consistent with the first hash, the integrity verification of the several slices of data passes). The target blockchain can also verify the integrity of several slices of data in the same way using the Merkle tree certificate.

[0107] Furthermore, referring to Figure 6 As shown, IoT devices can slice the data to be stored into several slices and generate corresponding Merkle tree credentials when the network condition is predicted to be unstable. The encrypted slices and Merkle tree credentials are then written into the local ledger.

[0108] Then, IoT devices can continuously send network heartbeat packets to the target blockchain to determine whether the network status has recovered.

[0109] If an IoT device receives a synchronization command from the target blockchain, it indicates that the network has been restored. The IoT device can then send the slice data stored in its local ledger to the target blockchain according to the corresponding priority. The target blockchain can verify the received data, and upon successful verification, upload it to the blockchain and return the corresponding blockchain data. Subsequently, the target blockchain can cross-chain the slice data uploaded to its own blockchain to the main blockchain.

[0110] If no synchronization instruction is received from the target blockchain, the IoT device continues to store the slices of data to be stored in the local ledger (and predict the network state through the Markov chain prediction model).

[0111] The priority of sliced ​​data can be determined based on its timeliness and value. For example, data with higher timeliness (i.e., more urgent data) has higher priority. For instance, for data awaiting certification related to cold chain food (seafood), the priority could be set as: "Enforcement Intelligence Prohibition Order" > "Risk Control Order" > "Customs Clearance Order" > "Temperature and Humidity Records" > "Food Packaging Description Content". The higher the priority, the more frequently the sliced ​​data of the corresponding data awaiting certification will be sent to the target blockchain.

[0112] It should be noted that only the data to be notified that is not stored on the main blockchain can be sent to the main blockchain (only transmitting differential block data). For example, a network heartbeat packet carrying the identifier of the data to be notified can be sent to the main blockchain. After the main blockchain returns a synchronization instruction for the data to be notified, the local blockchain verifies several slices of the data to be notified and then sends them to the main blockchain. After the main blockchain verifies the several slices of data, it can merge and notify them.

[0113] This method has the following advantages:

[0114] 1. A closed-loop innovation in prediction and execution between the Internet of Things (IoT) and blockchain. Markov chain network prediction -> dynamic routing decision -> dual-chain collaborative synchronization forms a unique technical closed loop covering the entire lifecycle of "before-during-after network outage". This invention uses Markov chains to proactively predict network outages, pre-caching to reduce latency, achieving reliable end-to-end transmission. Furthermore, the blockchain architecture of a front-end cache chain + back-end main blockchain makes front-end deployment more lightweight. Additionally, this method uses a distributed P2P relay network, enabling partial automatic fault healing.

[0115] 2. This method uses a lightweight Markov chain prediction model, which is suitable for low-computing-power devices and saves electricity, making it compatible with most border port law enforcement equipment.

[0116] 3. This method employs relative network disconnection processing and passive retransmission mechanism, Markov chain prediction + local buffer chain active caching, which not only enables law enforcement personnel to continuously monitor network conditions, but also allows for secure and automatic reconnection.

[0117] 4. Compared to repeatedly polling the connection status between the front-end IoT device and the back-end main blockchain, this method can optimize energy consumption, significantly reduce invalid transmissions, and avoid high energy consumption caused by high-frequency retransmissions.

[0118] 5. Cross-chain collaboration: Upload the data to be stored to the main blockchain through the local blockchain, reducing the reliance on centralized cross-chain bridges.

[0119] In addition, refer to Figure 1 As shown, according to a second aspect of this embodiment, a storage medium is provided. The storage medium includes a stored program, wherein, when the program is executed, a processor performs any of the methods described above.

[0120] Therefore, according to this embodiment, this method can ensure that when the network condition is poor, the IoT device can temporarily store the data to be stored in the local ledger in the form of blockchain data, and then upload the data to the blockchain after the network is restored, thereby ensuring the effectiveness of the IoT device in storing data.

[0121] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the present invention is not limited to the described order of actions, because according to the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to the present invention.

[0122] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0123] Example 2

[0124] Figure 7 A data evidence storage device according to a first aspect of this embodiment is shown, which corresponds to the method described according to the first aspect of Embodiment 1. (See reference...) Figure 7 As shown, the data storage device includes: a prediction module 710, used to dynamically update the transition matrix in the Markov chain prediction model through the device node based on its own historical network state data, and predict the network state in the future period based on the updated Markov chain prediction model and the current network state; wherein, the transition matrix is ​​used to characterize the transition probability between network states, and the initial Markov chain prediction model is a probability model applicable to the business area to which the device node belongs for predicting network state transitions; a judgment module 720, used to store the data to be stored in the future period in a local ledger corresponding to the target blockchain if the network state of the device node is unstable in the future period, wherein the data to be stored is stored in the local ledger in the data format required by the blockchain ledger; if the network state is stable in the future period, the data to be stored is uploaded to the target blockchain for storage; and a storage module 730, used to upload the data to be stored in the local ledger to the target blockchain for storage through the device node after the actual network state recovers to stability.

[0125] Optionally, the prediction module 710 is configured to: acquire its own historical network-related data through the device node, the historical network-related data including at least one of: Received Signal Strength Indication (RSSI), network latency information, packet loss rate, and bandwidth fluctuation information; determine the corresponding historical network state data based on the historical network-related data, the historical network state data including the network state of each historical time slice, wherein the network state includes any one of: connected state, weakly connected state, and disconnected state; determine the target window size corresponding to the current network environment, and extract the network state sequence within the target window size from the historical network state data; and update the transition matrix in the Markov chain prediction model based on the network state sequence.

[0126] Optionally, the prediction module 710 is used to generate a local transition frequency matrix by statistically analyzing the transition frequencies between network states in the network state sequence through device nodes; normalize the local transition frequency matrix to obtain a local transition probability matrix; and update the transition matrix in the Markov chain prediction model based on the local smoothing factor and the local transition probability matrix.

[0127] Optionally, the prediction module 710 is used to determine the network fluctuation situation of the current network environment based on historical network status data through device nodes; and to determine the target window size based on the network fluctuation situation, wherein the higher the frequency of network fluctuation, the smaller the target window size.

[0128] Optionally, the system further includes: a training module 740, used to train a Markov chain prediction model through a training device. The training steps of the Markov chain prediction model include: acquiring historical network state data sequences of all device nodes within the service area; performing state discretization processing on the historical network state data sequences to obtain a state sequence composed of connected states, weakly connected states, and disconnected states; dividing the state sequence based on a sliding window mechanism, and for the state sequence within each time window, performing the following sub-steps: counting the transition frequency between states within the current window and generating the initial transition probability matrix of the window; using an exponential smoothing algorithm, weighted fusion of the initial transition probability matrix of the window and the optimized transition probability matrix of the previous window using a global smoothing factor to generate the optimized transition probability matrix of the current window; collecting all optimized transition probability matrices generated during the training process, and calculating the average value of the optimized transition probability matrices corresponding to the last preset proportion of time windows to generate the final transition matrix, and using the final transition matrix as the initial transition matrix of the Markov chain prediction model after training.

[0129] Optionally, if the network condition is unstable in the future period, the data to be stored in the future period is stored in the local ledger corresponding to the target blockchain. If the network condition is stable in the future period, before uploading the data to be stored to the target blockchain for notarization, the judgment module 720 is further used to: divide the data to be stored in the future period into several slices of data through the device node; perform hash processing on the several slices of data, and generate corresponding Merkle tree certificates based on the hash processing results; the judgment module 720 is used to store the Merkle tree certificate and several slices of data signed with its own private key in the local ledger corresponding to the target blockchain; the notarization module 730 is used to upload the Merkle tree certificate and several slices of data signed with its own private key to the target blockchain for notarization.

[0130] Optionally, the target blockchain is a local blockchain corresponding to the business area, and the target blockchain is connected to the main blockchain; the data storage device further includes: a cross-chain module 750, used to send the plurality of slice data and the Merkle tree certificate corresponding to the plurality of slice data to the main blockchain through the local blockchain node; the data storage device further includes: a verification module 760, used to, after receiving the plurality of slice data and the Merkle tree certificate, call the main chain smart contract in the pre-deployed main blockchain, calculate the shard hash corresponding to the plurality of slice data, and recalculate the root hash according to the shard hash and the Merkle path in the Merkle tree certificate; compare the root hash recalculated by the main chain smart contract with the root hash in the Merkle tree certificate, and verify the signature of the plurality of slice data using the public key of the device node; and generate a cross-chain verification certificate for the plurality of slice data through the main chain smart contract when the root hash comparison result is consistent and the signature verification is successful, and store the plurality of slice data and the cross-chain verification certificate in the main blockchain.

[0131] Therefore, according to this embodiment, it can be ensured that when the network condition is poor, the device node temporarily stores the data to be stored in the form of blockchain data in the local ledger, and then uploads the data to be stored on the blockchain after the network is restored, thereby ensuring the effectiveness of data storage by IoT devices.

[0132] Example 3

[0133] Figure 8 A data evidence storage device according to a first aspect of this embodiment is shown, which corresponds to the method described according to the first aspect of Embodiment 1. (Reference) Figure 8As shown, the data storage device includes: a processor 810; and a memory 820 connected to the processor 810, used to provide the processor 810 with instructions to process the following steps: dynamically updating the transition matrix in the Markov chain prediction model based on its own historical network state data, and predicting the network state in the future period based on the updated Markov chain prediction model and the current network state; wherein, the transition matrix is ​​used to characterize the transition probability between network states, and the initial Markov chain prediction model is a probability model applicable to the business area to which the device node belongs for predicting network state transitions; if the network state is unstable in the future period, storing the data to be stored in the future period in a local ledger corresponding to the target blockchain, wherein the data to be stored is stored in the local ledger in the data format required by the blockchain ledger; if the network state is stable in the future period, uploading the data to be stored to the target blockchain for storage; wherein, the target blockchain is maintained by multiple device nodes in the same business area; and after the actual network state recovers and stabilizes, uploading the data to be stored in the local ledger to the target blockchain for storage.

[0134] Optionally, the operation of dynamically updating the transition matrix in the Markov chain prediction model based on historical network state data specifically includes: acquiring its own historical network-related data, which includes at least one of the following: Received Signal Strength Indication (RSSI), network latency information, packet loss rate, and bandwidth fluctuation information; determining the corresponding historical network state data based on the historical network-related data, which includes the network state of each historical time slice, wherein the network state includes any one of the following: connected state, weakly connected state, and disconnected state; determining the target window size corresponding to the current network environment, and extracting the network state sequence within the target window size from the historical network state data; and updating the transition matrix in the Markov chain prediction model based on the network state sequence.

[0135] Optionally, the operation of updating the transition matrix in the Markov chain prediction model based on the network state sequence specifically includes: counting the transition frequencies between each network state in the network state sequence to generate a local transition frequency matrix; normalizing the local transition frequency matrix to obtain a local transition probability matrix; and updating the transition matrix in the Markov chain prediction model based on the local smoothing factor and the local transition probability matrix.

[0136] Optionally, the operation of determining the target window size corresponding to the current network environment specifically includes: the device node determining the network fluctuation situation of the current network environment based on historical network status data; and the device node determining the target window size based on the network fluctuation situation, wherein the higher the frequency of network fluctuation, the smaller the target window size.

[0137] Optionally, the training steps of the Markov chain prediction model include: acquiring historical network state data sequences of all device nodes within the business area; discretizing the historical network state data sequences to obtain a state sequence composed of connected states, weakly connected states, and disconnected states; dividing the state sequence based on a sliding window mechanism, and for the state sequence within each time window, performing the following sub-steps: counting the transition frequency between states within the current window and generating the initial transition probability matrix for that window; using an exponential smoothing algorithm, weighting and fusing the initial transition probability matrix of the current window and the optimized transition probability matrix of the previous window using a global smoothing factor to generate the optimized transition probability matrix for the current window; collecting all optimized transition probability matrices generated during training, and calculating the average value of the optimized transition probability matrices corresponding to the last preset proportion of time windows to generate the final transition matrix, and using the final transition matrix as the initial transition matrix of the Markov chain prediction model after training.

[0138] Optionally, if the network state is unstable in the future period, the data to be stored in the future period is stored in a local ledger corresponding to the target blockchain. If the network state is stable in the future period, before uploading the data to be stored to the target blockchain for notarization, the memory 820 is further configured to provide the processor 810 with instructions to process the following steps: dividing the data to be stored in the future period into several slices; performing hash processing on the several slices, and generating corresponding Merkle tree certificates based on the hash processing results. The operation of storing the data to be stored in the future period in the local ledger corresponding to the target blockchain includes: storing the Merkle tree certificate and several slices signed with its own private key in the local ledger corresponding to the target blockchain. The operation of uploading the data to be stored to the target blockchain for notarization includes: uploading the Merkle tree certificate and several slices signed with its own private key to the target blockchain for notarization.

[0139] Optionally, the memory 820 is also used to provide the processor 810 with instructions to process the following steps: sending several slice data and Merkle tree credentials corresponding to the several slice data to the main blockchain through a local blockchain node.

[0140] Optionally, the memory 820 is also used to provide the processor 810 with instructions to process the following steps: after receiving several slice data and Merkle tree credentials, the main chain smart contract in the pre-deployed main blockchain is invoked to calculate the shard hash corresponding to the several slice data, and to recalculate the root hash according to the shard hash and the Merkle path in the Merkle tree credentials; the main chain smart contract compares the recalculated root hash with the root hash in the Merkle tree credentials, and verifies the signature of the several slice data using the public key of the device node; and if the comparison result of the root hash is consistent and the signature verification is successful, the main chain smart contract generates cross-chain verification credentials for the several slice data, and stores the several slice data and cross-chain verification credentials in the main blockchain.

[0141] Therefore, according to this embodiment, when the network condition is poor, the device node temporarily stores the data to be stored in the form of blockchain data in the local ledger. After the network is restored, the data to be stored is uploaded to the blockchain, thereby ensuring the effectiveness of data storage by IoT devices.

[0142] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0143] In the above embodiments of the present invention, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0144] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0145] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0146] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0147] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0148] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A data evidence storage method, characterized in that, include: The device node dynamically updates the transition matrix in the Markov chain prediction model based on its own historical network state data. Based on the updated Markov chain prediction model and the current network state, it predicts the network state in the future period. The transition matrix is ​​used to characterize the transition probability between network states. The initial Markov chain prediction model is a probability model applicable to the business area to which the device node belongs for predicting network state transitions. If the network status of the device node is unstable during the future period, it will store the data to be stored in the future period in a local ledger corresponding to the target blockchain. The data to be stored in the local ledger will be stored in the format required by the blockchain ledger. If the network status is stable during the future period, the data to be stored will be uploaded to the target blockchain for evidence storage. The target blockchain is maintained by multiple device nodes within the same business area. After the actual network state stabilizes, the device node uploads the data to be proven, stored in the local ledger, to the target blockchain for proof. The initial training steps of the Markov chain prediction model include: The training equipment in the service area acquires the historical network status data sequence of all device nodes in the service area. The training device performs state discretization processing on the historical network state data sequence to obtain a state sequence composed of connected states, weakly connected states, and disconnected states. The training device, based on a sliding window mechanism, divides the state sequence. For each time window, it performs the following sub-steps: 1) 2) 3) ... The training device collects all optimized transition probability matrices generated during the training process, calculates the average value of the optimized transition probability matrices corresponding to the last preset proportion of the time window, generates the final transition matrix, and uses the final transition matrix as the initial transition matrix of the Markov chain prediction model after training.

2. The method according to claim 1, characterized in that, The operation of a device node dynamically updating the transition matrix in the Markov chain prediction model based on its own historical network state data includes: The device node acquires its own historical network-related data, which includes at least one of the following: Received Signal Strength Indication (RSSI), network latency information, packet loss rate, and bandwidth fluctuation information. The device node determines the corresponding historical network status data based on the historical network-related data. The historical network status data includes the network status of each historical time slice, wherein the network status includes any one of the following: connected state, weak connection state, and disconnected state. The device node determines the target window size corresponding to the current network environment, and extracts the network state sequence within the target window size from the historical network state data; and The device node updates the transition matrix in the Markov chain prediction model based on the network state sequence.

3. The method according to claim 2, characterized in that, The operation of updating the transition matrix in the Markov chain prediction model based on the network state sequence by the device node specifically includes: The device node counts the transition frequency between each network state in the network state sequence and generates a local transition frequency matrix; The device node normalizes the local transfer frequency matrix to obtain a local transfer probability matrix; and The device node updates the transition matrix in the Markov chain prediction model based on the local smoothing factor and the local transition probability matrix.

4. The method according to claim 2, characterized in that, The operation of the device node determining the target window size corresponding to the current network environment specifically includes: The device node determines the network fluctuation situation of the current network environment based on the historical network status data; and The device node determines the target window size based on the network fluctuation situation, wherein the higher the network fluctuation frequency, the smaller the target window size.

5. The method according to claim 1, characterized in that, If the network state of the device node is unstable during the future period, the data to be stored in the future period will be stored in a local ledger corresponding to the target blockchain. Before uploading the data to the target blockchain for storage, if the network state is stable during the future period, the method further includes: The device node divides the data to be stored into several slices of data generated in the future time period. The device node performs hash processing on the plurality of slice data and generates corresponding Merkle tree credentials based on the hash processing results; and wherein, The operation of storing the data to be stored during the future time period in a local ledger corresponding to the target blockchain includes: The Merkle tree certificate and the several slice data signed with its own private key are stored in a local ledger corresponding to the target blockchain; and wherein... The operation of uploading the data to be notified to the target blockchain for notification includes: The Merkle tree certificate and the several slice data signed with its own private key are uploaded to the target blockchain for evidence storage.

6. The method according to claim 5, characterized in that, The target blockchain is a local blockchain corresponding to the business area, and the target blockchain is connected to the main blockchain; The method further includes: The target blockchain sends the plurality of slice data and the Merkle tree credentials corresponding to the plurality of slice data to the main blockchain through local blockchain nodes; The method further includes: After receiving the slice data and the Merkle tree certificate, the main blockchain calls the main chain smart contract pre-deployed in the main blockchain to calculate the shard hash corresponding to the slice data, and recalculates the root hash based on the shard hash and the Merkle path in the Merkle tree certificate. The main chain smart contract compares the recalculated root hash with the root hash in the Merkle tree certificate, and verifies the signature of the several slice data using the public key of the device node; and If the root hash comparison result is consistent and the signature verification is successful, the main chain smart contract generates cross-chain verification credentials for the several slice data, and stores the several slice data and the cross-chain verification credentials in the main blockchain.

7. A storage medium, characterized in that, The storage medium includes a stored program, wherein, when the program is executed, a processor performs the method according to any one of claims 1 to 6.

8. A data storage device, characterized in that, include: The prediction module is used to dynamically update the transition matrix in the Markov chain prediction model by the device node based on its own historical network state data, and to predict the network state in the future period based on the updated Markov chain prediction model and the current network state. The transition matrix is ​​used to characterize the transition probability between network states, and the initial Markov chain prediction model is a probability model applicable to the business area to which the device node belongs for predicting network state transitions. The judgment module is used to, if the network state of the device node is unstable during the future time period, store the data to be stored in the local ledger corresponding to the target blockchain, wherein the data to be stored is stored in the local ledger in the data format required by the blockchain ledger; and if the network state is stable during the future time period, upload the data to be stored in the target blockchain for evidence storage; and The evidence storage module is used to upload the data to be stored in the local ledger to the target blockchain for evidence storage via device nodes after the actual network state has stabilized. The module also includes training a Markov chain prediction model using a training device. The initial training steps for the Markov chain prediction model include: Obtain the historical network status data sequence of all device nodes within the service area; The historical network state data sequence is discretized to obtain a state sequence consisting of connected states, weakly connected states, and disconnected states. Based on the sliding window mechanism, the state sequence is divided. For each time window, the following sub-steps are performed: the transition frequency between states within the current window is counted, generating the initial transition probability matrix for that window; based on the exponential smoothing algorithm, the initial transition probability matrix of the current window and the optimized transition probability matrix of the previous window are weighted and fused using a global smoothing factor to generate the optimized transition probability matrix for the current window; and Collect all optimized transition probability matrices generated during training, calculate the average value of the optimized transition probability matrices corresponding to the last preset proportion of time window, generate the final transition matrix, and use the final transition matrix as the initial transition matrix of the Markov chain prediction model after training.

9. A data storage device, characterized in that, include: processor; as well as A memory, connected to the processor, for providing the processor with instructions to perform the following processing steps: The transition matrix in the Markov chain prediction model is dynamically updated based on its own historical network state data. Based on the updated Markov chain prediction model and the current network state, the network state in the future period is predicted. The transition matrix is ​​used to characterize the transition probability between network states. The initial Markov chain prediction model is a probability model applicable to the business area to which the device node belongs for predicting network state transitions. If the network condition is unstable during the future period, the data to be stored during the future period will be stored in a local ledger corresponding to the target blockchain, wherein the data to be stored is stored in the local ledger in the format required by the blockchain ledger; if the network condition is stable during the future period, the data to be stored will be uploaded to the target blockchain for evidence storage, wherein the target blockchain is maintained by multiple device nodes within the same business area; and After the actual network state stabilizes, the data to be notified, stored in the local ledger, is uploaded to the target blockchain for notarization. The initial training steps of the Markov chain prediction model include: The training equipment in the service area acquires the historical network status data sequence of all device nodes in the service area. The training device performs state discretization processing on the historical network state data sequence to obtain a state sequence composed of connected states, weakly connected states, and disconnected states. The training device, based on a sliding window mechanism, divides the state sequence. For each time window, it performs the following sub-steps: 1) 2) 3) ... The training device collects all optimized transition probability matrices generated during the training process, calculates the average value of the optimized transition probability matrices corresponding to the last preset proportion of the time window, generates the final transition matrix, and uses the final transition matrix as the initial transition matrix of the Markov chain prediction model after training.

Images