A data consensus method and device for Internet of Things devices

Abstract

The present disclosure provides a data consensus method and device for an Internet of Things device. The method receives a consensus data block through a consensus module, stores the consensus data block in a consensus data storage linked list according to a consensus storage rule, wherein each consensus module contains at least one consensus data storage linked list; determines the value of the consensus data block, and determines the number of times the consensus data block is sent according to the value of the consensus data block; obtains the number of times the consensus data block is sent; and determines the synchronous sending processing of the consensus data block according to the number of times the consensus data block is sent. By utilizing the method disclosed in the present disclosure, it is only necessary to manage the consensus data storage linked list, and according to the present method and by utilizing the consensus communication sending port and the consensus communication interface port of each consensus module to send and receive the consensus data block, the data of all nodes can be quickly and reliably formed into a synchronous consensus.

Description

Technical Field

[0001] The present application relates to the fields of communications and Internet of Things technology, and in particular to a method and apparatus for data consensus on Internet of Things devices. Background Art

[0002] In the field of IoT communications, data often needs to be sent to various devices in the network in a communication manner to achieve data synchronization between each device. Currently, data transmission in IoT communications conventionally uses a point-to-point method to transmit data one by one (send-response-confirmation). However, in actual applications, multiple devices are usually involved in transmitting data simultaneously. In this case, conventional point-to-point transmission can only require one device to synchronize data with another device. Because conventional point-to-point data transmission methods result in long data synchronization times, low efficiency, and even disordered data in the network.

[0003] To address the aforementioned issue of data synchronization across multiple devices, a master-slave model is also commonly used for data transmission. This approach typically identifies a device as the data center master node and then polls the other slave nodes one by one to collect and transmit data. However, this approach relies entirely on the central master node, which places heavy workloads and high hardware requirements. If the central master node experiences communication congestion, or if the corresponding device malfunctions or shuts down, data synchronization will be ineffective. Summary of the Invention

[0004] In response to the problems existing in the prior art of data synchronization among multiple devices, this paper proposes a data consensus method for IoT devices, which realizes the consensus storage and recording of multi-device data in communication networks and IoT networks, and ensures that the data generated by all device nodes in the network can be synchronized to the nodes of other devices efficiently and quickly to complete the full network synchronization consensus storage.

[0005] A first aspect of the present disclosure provides a method for consensus on IoT device data, the method comprising:

[0006] Receiving a consensus data block through a consensus module, storing the consensus data block in a consensus data storage linked list of the consensus module according to a consensus storage rule, wherein each consensus module includes at least one consensus data storage linked list; determining a value of the consensus data block, and determining a number of times the consensus data block is sent according to the value of the consensus data block;

[0007] Obtaining the number of times the consensus data block is sent;

[0008] The synchronous sending processing of the consensus data block is determined according to the number of times the consensus data block is sent.

[0009] In some embodiments, the method further comprises:

[0010] The consensus data storage linked list stores at least one data storage unit in the form of a linked list, wherein the data storage unit includes a consensus data block and a transceiver control block;

[0011] Receive the consensus data block from any consensus communication receiving port of the consensus module in the form of the linked list;

[0012] The reception and transmission of the consensus data block are processed by the transceiver control block.

[0013] In some embodiments, the consensus storage rules include:

[0014] Storing the same consensus data block in the data storage unit of the same data storage linked list;

[0015] The consensus data obtained from the same data source is stored in the same data storage linked list, where one IoT device node corresponds to one data storage linked list;

[0016] The consensus data blocks are sequentially stored in the data storage linked list according to the order of data generation time to form a linked list.

[0017] In some embodiments, the method further comprises:

[0018] When confirming the consensus data block, determining a data check value of the consensus data block;

[0019] Determining whether to store or discard the consensus data block according to the data check value of the consensus data block;

[0020] When the data check value is verified to be correct, the consensus data block is stored.

[0021] In some embodiments, the method comprises:

[0022] Determine the linked list checksum of the previous consensus data block;

[0023] Determine basic information of the consensus data block, wherein the basic information of the consensus data block includes at least a consensus unique identifier, a core data block, and a consensus check block of the consensus data block;

[0024] Determining a linked list check value of the consensus data block according to the linked list check value of the previous consensus data block and basic information of the consensus data block;

[0025] When the linked list check value of the consensus data block is an optional result, the value assigned to the consensus data block is marked as credible.

[0026] In some embodiments, the method further comprises:

[0027] Set a maximum trusted delay time;

[0028] When the consensus data block assigned as untrustworthy is not updated to a trustworthy assignment state within the maximum trustworthy delay time, the consensus module initiates a trustworthy exception request through consensus.

[0029] In some embodiments, determining the number of times the consensus data block is sent according to the value assigned to the consensus data block includes:

[0030] When the value assigned to the consensus data block is untrustworthy, the number of times the consensus data block is sent is defined as a negative number, and the number of times the consensus data block is received is defined as 0; when the value assigned to the consensus data block is trustworthy, the number of times the consensus data block is sent is directly obtained.

[0031] In this embodiment, the method further comprises:

[0032] When the value assigned to the consensus data block is untrustworthy, synchronizing the consensus data block to other communication nodes in the network through the consensus module; and after synchronizing the consensus data block to other communication nodes in the network, including:

[0033] When the value assigned to the consensus data in the other communication nodes is credible, the number of times the consensus data is sent in the other communication nodes is modified to 0, so as to continue the synchronous sending process of the consensus data in the other communication nodes;

[0034] When the values ​​assigned to the consensus data in the other communication nodes are untrustworthy, the consensus data blocks in the other communication nodes are further synchronized through the consensus module.

[0035] In some embodiments, determining the synchronous sending process of the consensus data block according to the number of times the consensus data block is sent includes:

[0036] When the number of times the consensus data block is sent reaches a preset value, the sending of the consensus data block is stopped.

[0037] In this embodiment, the method further comprises:

[0038] Obtaining the number of times the consensus data block is received;

[0039] When the number of receptions of the consensus data block reaches a maximum reception threshold, the preset value of the number of transmissions of the consensus data block is adjusted downward, or the number of transmissions is increased.

[0040] In some embodiments, the method further comprises:

[0041] The consensus data block is effectively sent at least once, and the number of times the consensus data block is sent is counted.

[0042] In some embodiments, the method further includes: the consensus module may further include an insertion consensus module; the insertion consensus module receives the core data block obtained from the IoT device node through the data insertion interface.

[0043] In some embodiments, the method further comprises:

[0044] When the data insertion interface confirms the core data block, a consensus unique identifier is added to the front of the core data block, and a consensus check block is added to the back of the core data block to form a consensus data block for inserting data;

[0045] The consensus data block of the inserted data is stored in the data storage linked list according to the consensus storage rule, and the fields of the consensus data block are assigned initial values.

[0046] In this embodiment, the adding of the consensus unique identifier at the front of the core data block and the adding of the consensus check block at the back of the core data block include:

[0047] The data source and data timestamp of the core data block are combined to form the consensus data block of the inserted data, wherein the data timestamp is determined according to the same synchronization time timing unit;

[0048] The assignment of the consensus data block of the inserted data is marked according to the linked list check value of the consensus data block of the inserted data to form the consensus check block.

[0049] In some embodiments, the method further comprises:

[0050] The consensus module also has a consensus retrieval interface;

[0051] The insert consensus module extracts the core data blocks after synchronization consensus from the data storage linked list through the consensus retrieval interface.

[0052] A second aspect of the present disclosure provides an IoT device data consensus device, which is applied to any possible implementation method of the first aspect above, and the device includes: a receiving unit, which is used to receive a consensus data block through a consensus module, and store the consensus data block in the consensus data storage linked list according to a consensus storage rule, wherein each consensus module includes at least one consensus data storage linked list; a determining unit, which is used to determine the assignment of the consensus data block and determine the number of times the consensus data block is sent according to the assignment of the consensus data block; an acquiring unit, which is used to acquire the number of times the consensus data block is sent; and a processing unit, which is used to determine the synchronous sending processing of the consensus data block according to the number of times the consensus data block is sent.

[0053] In some embodiments, the determining unit includes: a value determining unit for

[0054] Determine the linked list checksum of the previous consensus data block;

[0055] Determine basic information of the consensus data block, wherein the basic information of the consensus data block includes at least a consensus unique identifier, a core data block, and a consensus check block of the consensus data block;

[0056] Determining a linked list check value of the consensus data block according to the linked list check value of the previous consensus data block and basic information of the consensus data block;

[0057] When the linked list check value of the consensus data block is an optional result, the value assigned to the consensus data block is marked as credible.

[0058] In some embodiments, the determining unit includes: a sending times determining unit for

[0059] When the value assigned to the consensus data block is untrustworthy, the number of times the consensus data block is sent is defined as a negative number, and the number of times the consensus data block is received is defined as 0; when the value assigned to the consensus data block is trustworthy, the number of times the consensus data block is sent is directly obtained.

[0060] In some embodiments, the processing unit is configured to stop sending the consensus data block when the number of times the consensus data block is sent reaches a preset value.

[0061] In some embodiments, the processing unit is further configured to: obtain a number of reception times of the consensus data block;

[0062] When the number of receptions of the consensus data block reaches a maximum reception threshold, the preset value of the number of transmissions of the consensus data block is adjusted downward, or the number of transmissions is increased.

[0063] In some embodiments, the apparatus further comprises:

[0064] Insertion unit, for the consensus module can also have an inserted consensus module;

[0065] The insertion consensus module receives the core data block obtained from the IoT device node through the data insertion interface.

[0066] In some embodiments, the apparatus further comprises:

[0067] The retrieval unit is used in the consensus module and also has a consensus retrieval interface;

[0068] The insert consensus module extracts the core data blocks after synchronization consensus from the data storage linked list through the consensus retrieval interface.

[0069] A third aspect of the present disclosure provides a communication device, comprising: a memory for storing processor-executable instructions; a processor connected to the memory; wherein the processor is configured to execute any possible implementation method of the first aspect.

[0070] A fourth aspect of the present disclosure provides a communication device, which, when the instructions in the storage medium are executed by a processor of a computer, enables the computer to execute any possible implementation method of the first aspect.

[0071] The technical solutions provided by the embodiments of the present disclosure may have the following beneficial effects:

[0072] The application of the method disclosed in the present invention only requires the management of the consensus data storage linked list. By following this method and utilizing the consensus communication sending port and consensus communication interface port of each consensus module to send and receive consensus data blocks, the data of all nodes can be quickly and reliably synchronized to form a consensus. BRIEF DESCRIPTION OF THE DRAWINGS

[0073] The present disclosure will be described in further detail below in conjunction with the accompanying drawings and preferred embodiments, but those skilled in the art will appreciate that these drawings are only drawn for the purpose of explaining the preferred embodiments and therefore should not be taken as limiting the scope of the present disclosure.

[0074] Figure 1 is a schematic diagram of a consensus data storage linked list according to an exemplary embodiment;

[0075] Figure 2 This is a schematic diagram showing a process of a method for consensus on data of IoT devices according to an exemplary embodiment;

[0076] Figure 3 is a schematic diagram of a consensus module according to an exemplary embodiment;

[0077] Figure 4is a schematic diagram of a data storage unit according to an exemplary embodiment;

[0078] Figure 5 is a schematic diagram of a consensus data block according to an exemplary embodiment;

[0079] Figure 6 is a schematic diagram showing a consensus unique identifier according to an exemplary embodiment;

[0080] Figure 7 is a schematic diagram of a consensus check block according to an exemplary embodiment;

[0081] Figure 8 is a schematic diagram of a transceiver control block according to an exemplary embodiment;

[0082] Figure 9 A schematic diagram of a consensus data block according to an exemplary embodiment;

[0083] Figure 10 A schematic diagram of a consensus module according to an exemplary embodiment;

[0084] Figure 11 A schematic diagram of a linked list verification method according to an exemplary embodiment;

[0085] Figure 12 A schematic diagram of a data verification method according to an exemplary embodiment;

[0086] Figure 13 This is a schematic structural diagram of a communication device provided in an embodiment of the present application;

[0087] Figure 14 It is a structural diagram of a communication device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0088] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.

[0089] The IoT device data consensus method disclosed herein can be applied to all systems, devices, and products with communication interfaces and capabilities, and can be implemented using any IoT system, device, product, software, or hardware with communication interfaces and capabilities.

[0090] The application of the method disclosed in the present invention only requires the management of the consensus data storage linked list. By following this method and utilizing the consensus communication sending port and consensus communication interface port of each consensus module to send and receive consensus data blocks, the data of all nodes can be quickly and reliably synchronized to form a consensus.

[0091] The consensus data storage linked list of the embodiment of the present disclosure can be a two-dimensional array or a two-dimensional linked list, and the consensus data storage linked list of multiple data sources is managed by a linked list header, such as Figure 1 The schematic diagram of the consensus data storage linked list shown in FIG. 4 shows a schematic diagram of the consensus data storage linked list shown in FIG. 4 , wherein the consensus data storage linked list of each data source manages multiple consensus data blocks.

[0092] The present invention discloses a data consensus method for IoT devices, which realizes the consensus storage and recording of all device data in the communication network and the IoT network, ensures that all data generated by all device nodes can be quickly synchronized to other device nodes, and completes the synchronous consensus storage of data in the entire network.

[0093] The present invention describes a data consensus method for IoT devices, such as Figure 2 The schematic diagram of the process of the IoT device data consensus method shown in the figure, in the present invention, each IoT device includes a consensus module, each consensus module includes at least one consensus data storage linked list, at least one consensus communication sending port and at least one consensus communication receiving port. Figure 3 The schematic diagram of the consensus module shown in FIG. 1 is a diagram of a consensus module shown in FIG. 1 . This embodiment discloses a method for consensus on data of IoT devices, wherein the method comprises the following steps:

[0094] S310: Receive a consensus data block through a consensus module, and store the consensus data block in a consensus data storage linked list of the consensus module according to a consensus storage rule, wherein each consensus module includes at least one consensus data storage linked list;

[0095] S320: Determine the value assigned to the consensus data block, and determine the number of times the consensus data block is sent according to the value assigned to the consensus data block;

[0096] S330: Obtain the number of times the consensus data block is sent;

[0097] S340: Determine the sending process of the consensus data block according to the number of times the consensus data block is sent.

[0098] In this embodiment, the consensus module can store the consensus data blocks received from any consensus communication receiving port into the consensus data storage linked list. After receiving the consensus data block, the consensus module will determine the value of the consensus data block, and further determine the number of times the consensus data block is sent and other information based on the value assignment of the consensus data block, or directly obtain the number of times the consensus data block is sent when the number of times the consensus data block is sent is not redefined. Finally, based on the number of times the consensus data block is sent, the synchronous sending processing of the consensus data block is determined. The synchronous sending here refers to sending the consensus data block from all consensus communication interfaces. In this process, the consensus module does not perform response processing when receiving the consensus data block, and does not perform confirmation waiting when synchronously sending the consensus data block. Therefore, the synchronization of data blocks in the Internet of Things network can be completed efficiently.

[0099] In the present disclosure, the consensus module can also store and send the consensus data block, and the consensus module keeps the consensus data block intact and does not modify it during the process of receiving, storing, and sending the consensus data block.

[0100] The consensus communication sending port and consensus communication receiving port in this disclosure generally refer to any physical, logical, hardware, or software medium, circuit, or interface that can transmit information and data. This disclosure collectively refers to these media, circuits, and interfaces that can transmit information and data as consensus interfaces.

[0101] The consensus communication sending port and consensus communication receiving port disclosed in the present invention are composed of a set of at least one consensus interface, and this consensus interface set can be a combination of different media, different lines, and different interfaces.

[0102] In some embodiments, this embodiment discloses a method for consensus on IoT device data, the method further comprising:

[0103] The consensus data storage linked list stores at least one data storage unit in the form of a linked list, wherein the data storage unit includes a consensus data block and a transceiver control block;

[0104] Receive the consensus data block from any consensus communication receiving port of the consensus module in the form of the linked list;

[0105] The reception and transmission of the consensus data block are processed by the transceiver control block.

[0106] The data storage linked list stores multiple data storage units in the form of a linked list to store the consensus data blocks obtained from the consensus communication receiving port. Figure 4Each data storage unit shown contains a consensus data block and a transceiver control block. Therefore, the consensus data blocks received by the consensus module from any consensus communication receiving port can be stored in a linked list, and the transceiver control block manages the sending and receiving of the consensus data blocks.

[0107] The consensus data block disclosed in the present invention at least includes: a consensus unique identifier, a core data block and a consensus check block. Figure 5 The schematic diagram of the consensus data block shown in FIG. 1 shows that the consensus unique identifier is located in the front of the core data block, and the consensus check block is located in the back of the core data block. The consensus unique identifier, the core data block and the consensus check block can together constitute the consensus data block.

[0108] The consensus unique identifier is used to uniquely identify the core data blocks that need to be synchronized and agreed upon in the IoT network. The consensus unique identifier is different for different data generated by all device nodes in the entire network.

[0109] The core data block is the core data content that needs to be transmitted to all other consensus modules in the network through consensus using the consensus module. The core data block can be generated internally or externally by an IoT device node.

[0110] Among them, the consensus check block is used to verify the accuracy and authenticity of the consensus data block to prevent errors and modifications in the data during transmission and storage.

[0111] The consensus unique identifier of this disclosure, such as Figure 6 The schematic diagram of the consensus unique identifier shown is composed of at least two parts: the data source and the data timestamp.

[0112] Among them, the data source is used to identify the data source code of the core data block, which can be a device code that can identify the data source, such as device ID, device address code, UUID code, IP address code, etc. In the present invention, the data source can preferably adopt the ID code of the device node of the consensus module.

[0113] The data timestamp is the time point when the core data block is inserted into the consensus module through the data insertion interface. This time point is determined by a high-precision synchronization time timing unit. Depending on the accuracy requirements of the network system, the high-precision synchronization time timing unit can be millisecond, microsecond or nanosecond level accuracy.

[0114] When an IoT device node has multiple core data blocks that need to be inserted into the consensus module, they are inserted one by one from the data insertion interface in the order of the time when the core data is generated, and a consensus unique identifier is added to the front of the core data block. The consensus unique identifier can uniquely identify the uniqueness of the core data block.

[0115] The consensus check block of the present disclosure, such as Figure 7 The schematic diagram of the consensus unique identifier shown is composed of at least two parts: data verification and linked list verification.

[0116] Among them, the linked list check is used to perform rolling check on the consensus data storage linked list where the consensus data block is stored, so as to verify the authenticity of the data and prevent data errors or illegal means from tampering with the core data.

[0117] Among them, data verification is used to verify the consensus unique identifier, core data block, and linked list check value in the consensus data block to ensure the accuracy of the consensus data block; the present disclosure directly discards data with incorrect data verification.

[0118] The transceiver control block disclosed in the present invention includes two parts: data sending count and data receiving count.

[0119] The data sending count is used to record the sending count of the consensus data block in the consensus data storage linked list from the consensus communication sending port. Each time the consensus data block is sent, the sending count is increased by 1.

[0120] The data reception count is used to record the reception count of the consensus data block in the consensus data storage linked list from the consensus communication receiving port. Each time the consensus data block is received, the reception count is increased by 1.

[0121] Further, such as Figure 8 The schematic diagram of the transceiver control block shown in the figure can also include a data trustworthy flag, which is used to identify whether the linked list check value of the corresponding consensus data block in the data storage linked list is correct, that is, it is used to identify whether the data of the consensus data block is trustworthy.

[0122] In some embodiments, this embodiment discloses a method for consensus on IoT device data. The consensus storage rules involved in this disclosure include:

[0123] Store the same consensus data blocks in the data storage units of the same data storage linked list;

[0124] The consensus data obtained from the same data source is stored in the same data storage linked list, where one IoT device node corresponds to one data storage linked list;

[0125] The consensus data blocks are sequentially stored in the data storage linked list according to the order of data generation time to form a linked list.

[0126] In this embodiment, the same consensus data block is stored in the same data storage unit of the consensus data storage linked list, and the reception statistics are counted using the data reception count. Here, the same consensus data block is determined based on the information of the core data block in the consensus data block.

[0127] Consensus data blocks from different data sources are stored in different consensus data storage lists, while consensus data blocks from the same data source are stored in the same consensus data storage list. The consensus data block of the data source here is determined by the data source of the consensus unique mark in the consensus data block.

[0128] Moreover, there are as many consensus data storage linked lists as there are IoT device nodes in the network, and each IoT device node corresponds to a data storage linked list.

[0129] According to the time priority principle, the consensus data blocks are stored in the linked list in the order of the consensus data block generation time and form a linked list. The time here comes from the data source and is defined by the generation time of the data block.

[0130] In this embodiment, the consensus storage rules involved in this disclosure also include:

[0131] When confirming a consensus data block, determining the data check value of the consensus data block;

[0132] Determine whether to store or discard the consensus data block based on the data check value of the consensus data block;

[0133] When the data check value is verified to be correct, the consensus data block is stored.

[0134] When the data checksum is incorrect, the consensus data is directly discarded.

[0135] In some embodiments, this embodiment discloses a method for consensus on IoT device data, which determines the value of a consensus data block, including:

[0136] Determine the linked list checksum of the previous consensus data block;

[0137] Determine the basic information of the consensus data block, where the basic information of the consensus data block includes at least the consensus unique identifier, core data block, and consensus verification block of the consensus data block;

[0138] Determine the linked list check value of the consensus data block based on the linked list check value of the previous consensus data block and the basic information of the consensus data block;

[0139] When the linked list check value of the consensus data block is an optional result, the assignment of the consensus data block is marked as credible.

[0140] Obtain the linked list checksum value of the previous consensus data block. Or when the first consensus data block of the consensus data storage linked list is stored and the linked list checksum is processed, since there is no previous consensus data block in the linked list, the linked list checksum value of the previous consensus data block is set to 0 for linked list checksum calculation.

[0141] The linked list check value of the previous consensus data block, as well as the consensus unique identifier, core data block, and data check value of the current consensus data block are checked and calculated together to obtain a new linked list check value. This new linked list check value is the linked list check value of the consensus data block.

[0142] Furthermore, when the consensus data block is received by the consensus communication receiving port and enters the consensus module, the linked list check value will be verified. If the optional linked list check value is correct, the data trust flag of the transceiver control block will be marked as trustworthy, otherwise the data trust flag will be marked as untrustworthy.

[0143] Since the verification calculation process includes the linked list checksum of the previous consensus data block, the consensus data block in the consensus data storage linked list is verified and stored through rolling association verification. Once the consensus data block is stored in the consensus data storage linked list, it will no longer be allowed to be modified, ensuring the authenticity and validity of the data; once the linked list is modified, all subsequent checksum values ​​will be incorrect, and the linked list data of other device nodes will also be inconsistent with the linked list data of this device.

[0144] It should be noted that in the present disclosure, the consensus communication sending port of the consensus method involved in sending the consensus data block and the consensus communication receiving port in receiving the consensus data block are both processed according to the time priority principle.

[0145] When the consensus communication receiving port receives a consensus data block, it will traverse the consensus data storage linked list of the corresponding data source according to the data source, and compare to determine whether the consensus data block has been stored in the linked list. If so, the reception count will be directly increased by 1; otherwise, it indicates that the consensus data block belongs to a new consensus data block in the consensus module, and the consensus data block will be stored in the linked list according to the time priority principle and consensus storage rules.

[0146] When the consensus communication sending port sends a consensus data block, it will traverse all consensus data storage lists in the consensus module and find the oldest consensus data block whose sending count has not reached the preset value for sending processing. The preset value can be a pre-set maximum sending threshold.

[0147] In this embodiment, a method for consensus on IoT device data further includes:

[0148] Set a maximum trusted delay time;

[0149] When a consensus data block assigned an untrusted value is not updated to a trusted state within the maximum trusted delay time, the consensus module initiates a trusted exception request through consensus.

[0150] In the present disclosure, once the data trust flag of a consensus data block is identified as data trustworthy, the consensus data block cannot be modified in any way, and only after the previous consensus data block is trustworthy in the consensus data storage linked list, the subsequent consensus data blocks are trustworthy. In the present disclosure, the consensus data blocks are stored in a rolling check method using a linked list. The correctness of the linked list check value of the consensus data is affected by the linked list check value of the previous consensus data block. If a consensus data block causes an abnormal linked list check value due to abnormal loss or error of the previous consensus data block, the data trust flag of the consensus data block is in an untrustworthy state, and the consensus data storage linked list is interrupted. All subsequent consensus data blocks in the linked list will be in an untrustworthy state. The consensus module of the present disclosure will periodically check the linked list check value of the consensus data block and verify it.

[0151] The judgment of the trust status is to hope that the previous consensus data block can be restored to normal through the consensus mechanism of the network device node.

[0152] Therefore, in this disclosure, given the maximum trusted delay time, if the consensus data block in the untrusted state still does not recover to the trusted state after this given delay time, then (such as Figure 9 )The consensus module will initiate a trusted exception request instruction through consensus.

[0153] The trusted exception request instruction of the present invention is: the consensus module fills the linked list check field data in the consensus data block with 00, assigns a negative value to the data sending count, and assigns a value to the data receiving count of 0. Then, the sending port of the consensus module restarts the transmission of the consensus data according to the sending count number and the data timestamp, thereby realizing the sending of the trusted exception request instruction.

[0154] In some embodiments, determining the number of times the consensus data block is sent according to the value assigned to the consensus data block includes:

[0155] When the value assigned to the consensus data block is untrustworthy, the number of times the consensus data block is sent is defined as a negative number, and the number of times the consensus data block is received is defined as 0; when the value assigned to the consensus data block is trustworthy, the number of times the consensus data block is sent is directly obtained.

[0156] Furthermore, in this embodiment, the method further includes:

[0157] When the value assigned to the consensus data block is untrustworthy, the consensus data block is synchronized to other communication nodes in the network through the consensus module;

[0158] When the value assigned to the consensus data in the other communication nodes is credible, the number of times the consensus data is sent in the other communication nodes is modified to 0, so as to continue the synchronous sending process of the consensus data in the other communication nodes;

[0159] When the values ​​assigned to the consensus data in the other communication nodes are untrustworthy, the consensus data blocks in the other communication nodes are further synchronized through the consensus module.

[0160] In the present disclosure, when the value assigned to the consensus data block is untrustworthy, the number of times the consensus data block is sent is defined as a negative number, the number of times the consensus data block is received is defined as 0, and the consensus unique identifier and untrustworthy status of the untrustworthy consensus data block are sent out through the consensus mechanism to notify other communication nodes in the network to re-perform data consensus.

[0161] When the consensus data of other communication nodes is in a trusted state, the number of times the consensus data block is sent is modified to 0, and the consensus data sending is re-initiated. When the consensus data of other communication nodes is in an untrusted state, the untrusted processing is performed according to the above.

[0162] According to the above embodiment, after sending an abnormal request instruction to other device nodes in the network through the consensus module, it will check whether the consensus data block in the request is in a trusted state in this consensus module, or when it is determined that the value assigned to the consensus data block is untrustworthy.

[0163] If the value of the consensus data block is in a trusted state, the data sending count of the previous consensus data block is assigned a negative number and the data receiving count is assigned to 0 to restart the synchronous consensus of the previous consensus data block.

[0164] If the value of the consensus data block is in an untrusted state, the linked list check field in the consensus data block is filled with 00, the data sending count is assigned to 0, and the data receiving count is assigned to 0, so as to synchronize the request instruction to the data trusted node through consensus, and the data trusted node recovers the consensus data block of the untrusted node.

[0165] In this way, the trusted exception request instruction can ensure data self-recovery during the data consensus process. The present invention determines the maximum trusted delay time based on the maximum transmission delay of the network node, and the default setting of this time is 3 times the maximum transmission delay of the network node.

[0166] In other embodiments, the method disclosed herein utilizes the storage characteristics of consensus data blocks and can be applied to the distributed accounting.

[0167] In the application of blockchain-based distributed accounting methods for IoT devices, the data storage linked list of each communication node not only stores the data of the node itself, but also that of other nodes in the network. Multiple consensus data blocks of device nodes undergo rolling verification using the linked list's checksum field, ensuring the authenticity of the distributed accounting. When multiple nodes perform distributed accounting, if data inconsistencies or incorrect verification are encountered, the data can be restored to a trusted state using the data trust flag and trusted exception request instructions.

[0168] Therefore, applying the disclosed method to a distributed accounting method can ensure that the data in the network is authentic, valid, and trustworthy. In the event of errors, loss, or tampering, the data can be recovered and restored through a trusted flag and trusted exception request mechanism. Using a linked list approach, the raw data generated by each device is verified and validated in a rolling manner according to the order of timestamps, providing the most original basic data for applications requiring information tracing and timeline tracking, and this data cannot be changed. Compared to PC-based blockchains, this method uses the simplest and most lightweight linked list approach for data storage and distributed accounting, allowing cheap, low-cost single-chip microcomputers, embedded systems, and IoT devices to easily implement blockchain applications without the need for high-computing power and high-energy-consuming large processor systems. Compared to PC-based blockchains, this distributed accounting method can encrypt blockchain data from the source of data collection, reducing the chance of errors and tampering during data transmission, and maximizing the authenticity and validity of data from source to transmission to use, without the need for human intervention.

[0169] In this embodiment, determining the synchronous sending process of the consensus data block according to the number of times the consensus data block is sent includes: when the number of times the consensus data block is sent reaches a preset value, stopping the sending of the consensus data block.

[0170] In this embodiment, the method further includes: further obtaining the number of times the consensus data block is received; when the number of times the consensus data block is received reaches a maximum reception threshold, reducing or adjusting a preset value of the number of times the consensus data block is sent, or increasing the number of times the consensus data block is sent;

[0171] Before sending or stopping the consensus data block, a check is performed to determine whether the consensus data block's reception count has reached the maximum reception threshold. If the consensus data block reaches the maximum reception threshold, the preset value for reducing the number of transmissions, i.e., the maximum transmission threshold, is adjusted. A check is then performed to determine whether the transmission count has reached the maximum transmission threshold. If the transmission count has not reached the preset value, the consensus data block is sent, and after the transmission is complete, the corresponding data storage unit's transmission count is increased by 1. If the transmission count has reached the maximum transmission threshold, the consensus data block is stopped.

[0172] Alternatively, when the number of receptions reaches the maximum reception threshold, the maximum transmission threshold can be lowered according to a preset setting, or the number of transmissions can be increased, so that the number of data block transmissions can quickly reach the maximum transmission threshold. The maximum transmission threshold can be automatically set in the control module, or the number of data block transmissions can be set according to a certain rule, so that the number of receptions can be used to determine and control the early reduction of the number of transmissions, so that the number of data block transmissions can reach the maximum transmission threshold in the most efficient way.

[0173] In the embodiment of the present disclosure, the maximum sending threshold is set to 2, and the maximum receiving threshold is set to half the number of network nodes.

[0174] In some embodiments, a method for consensus on IoT device data further includes:

[0175] The consensus data block is effectively sent at least once, and the number of times the consensus data block is sent is counted.

[0176] Among them, for the consensus data block entering from the consensus communication interface, the data sending count is assigned to 0 and the data receiving count is assigned to 1. Furthermore, after the linked list verification is completed, the optional data trust flag is assigned to trustworthy or untrustworthy according to the verification result.

[0177] The effective sending process in the present disclosure means that during at least one sending operation of the communication node, the communication node can reliably send the communication data block to the communication medium without being blocked inside the communication node.

[0178] The consensus module of the present disclosure performs at least one sending operation and counts the number of sending operations for each consensus data block that needs to be sent. When the sending number count reaches a given preset value, the sending of the consensus data block is stopped.

[0179] After receiving a consensus data block from any other consensus module, the consensus module of the present disclosure stores the consensus data block in the consensus data storage linked list according to the consensus storage rules and counts the number of times it has been received. During this process, no response is given to the sending node regarding the reception of the consensus data block, and the sending process is performed according to the above steps without waiting for a response from any other consensus module.

[0180] In some embodiments, a method for consensus on IoT device data further includes:

[0181] The consensus module can also have a plug-in consensus module;

[0182] The insertion consensus module receives the core data blocks obtained from the IoT device nodes through the data insertion interface.

[0183] In this embodiment, a method for consensus on IoT device data further includes:

[0184] When the data insertion interface confirms the core data block, a consensus unique identifier is added to the front of the core data block, and a consensus check block is added to the back of the core data block to form a consensus data block for the inserted data.

[0185] The consensus data block of the inserted data is stored in the data storage linked list according to the consensus storage rule, and the fields of the consensus data block are assigned initial values.

[0186] like Figure 10 As shown, the consensus module of the present disclosure has a data insertion interface, which is used to insert core data content generated internally or externally by the IoT device node and needs to be transmitted to all other consensus modules in the network through consensus using the consensus module into the consensus module.

[0187] When inserting a core data block into the consensus module, the data insertion interface adds a consensus unique identifier to the front of the core data block and a consensus check block to the back of the core data block to form a consensus data block that can be transmitted through consensus. Once the consensus data block for the inserted data is generated, it is stored in the consensus data storage linked list according to the consensus storage rules, and initial values ​​are assigned to each field in the send control block.

[0188] Among them, when the core data block is inserted into the consensus module through the data insertion interface, before being stored in the consensus data storage linked list according to the consensus storage rules, it is necessary to add the consensus unique identifier to the front of the core data block, and then calculate the linked list check value and the data check value. The calculation result is added to the back of the core data block to form a consensus data block that can be transmitted by consensus and then stored in the linked list.

[0189] In this embodiment, a consensus unique identifier is added to the front of the core data block, and a consensus check block is added to the back of the core data block, including:

[0190] The data source and data timestamp of the core data block are combined to form the consensus data block of the inserted data, wherein the data timestamp is determined according to the same synchronization time timing unit;

[0191] The assignment of the consensus data block of the inserted data is marked according to the linked list check value of the consensus data block of the inserted data to form the consensus check block.

[0192] Further integration Figure 5-7The consensus unique identifier in the consensus data block of inserted data consists of at least two parts: a data source and a data timestamp. The data source is used to identify the data source code of the core data block. The data timestamp is the time when the core data block is inserted into the consensus module via the insertion data interface. This time is determined by a high-precision synchronized time unit. Depending on the accuracy requirements of the network system, this high-precision synchronized time unit can have millisecond, microsecond, or nanosecond accuracy.

[0193] The consensus check block in the consensus data block of the inserted data is composed of at least two parts: data check and linked list check. Among them, the linked list check is used to perform rolling check on the consensus data storage linked list stored in the consensus data block to verify the authenticity of the data and prevent data errors or illegal means from tampering with the core data. Therefore, once the data of the IoT device node of the present invention enters the consensus module through the data insertion interface, the linked list check value is calculated and processed and stored, the data will be immediately synchronized to the consensus modules of all device nodes in the network through the consensus method and stored, so as to achieve the purpose of rapid synchronization consensus of network data and prevent data tampering.

[0194] In this embodiment, a method for consensus on IoT device data further includes:

[0195] The consensus module also has a consensus retrieval interface;

[0196] The consensus module disclosed herein also has a consensus retrieval interface, which is used by IoT device nodes to extract core data after synchronized consensus from the consensus data storage list.

[0197] In other embodiments, the method disclosed herein utilizes a consensus mechanism and can be applied to a method for data port mirroring of IoT devices.

[0198] In this method, the consensus data storage linked list of the IoT device stores all the data of all device nodes in the network. On one of the devices, a data mirroring port is opened, and the consensus retrieval interface is used to retrieve the specified or all data of the specified or all nodes from the consensus data storage linked list to realize the port mirroring function of the corresponding IoT device data.

[0199] The method utilizes the port mirroring function to achieve the bit error rate of IoT devices, data transmission reliability, sensor equipment acquisition stability, and supervision of IoT device data. Current IoT devices are limited by the heterogeneity of the network and the privacy of data, which makes it impossible to effectively supervise the data of IoT devices.

[0200] In some embodiments, when a new consensus data block is stored in the consensus data storage linked list, the sending and receiving control block is initialized.

[0201] For the consensus data block composed of core data entering from the data insertion interface, the data sending count is assigned a negative number and the data receiving count is assigned to 0. The optional data trust flag is further assigned to trust after the linked list verification calculation is completed.

[0202] For the consensus data blocks entering from the consensus communication interface, the data sending count is assigned to 0 and the data receiving count is assigned to 1. After the linked list verification is completed, the optional data trust flag is assigned to trustworthy or untrustworthy according to the verification results.

[0203] It should be noted that the consensus data storage list of the IoT device node will become larger and larger. In order to avoid the data storage space being full, the present invention is set to regularly clean up or back up the old consensus data block data at a certain time period. The cleaning or backup period can be days, weeks, months or years.

[0204] It should be noted that the sending, storage and reception of consensus data in the consensus method disclosed herein are all processed accordingly using the time priority principle.

[0205] The consensus communication is sent and received using the time priority principle. The consensus data blocks sent from a device node must be sent in chronological order, and are also transmitted in sequence in the transmission medium. The receiving nodes also receive and forward them in chronological order, and the consensus data storage list is also stored in chronological order. Therefore, the consensus transmission of all consensus data blocks disclosed in the present invention is processed in chronological order. Even if due to network transmission delays, new consensus data blocks with closer nodes will arrive earlier than old consensus data blocks with farther nodes, but because the consensus data storage list is divided into multiple lists according to the data source to store consensus data blocks, the consensus data blocks of the consensus data storage list of all device nodes in the network disclosed in the present invention are in the same order as the data source device nodes and have the same checksum values.

[0206] According to the time priority principle, all consensus data blocks in the network will send old data before new data. Even if a small amount of new data arrives first due to short transmission delay and is marked as untrusted data, once the old data arrives later, the consensus data storage list will be filled and the data will be synchronized and complete.

[0207] In some embodiments of the present disclosure, Figure 1 As shown, the consensus data storage linked list can be a two-dimensional array or a two-dimensional linked list. The consensus data storage linked lists of multiple data sources are managed through a linked list header, and the consensus data storage linked list of each data source is followed by multiple consensus data blocks.

[0208] The linked list check field of the consensus data block in the linked list check method is used to verify the integrity of the linked list and the credibility of the data. Consensus data blocks that fail the check are not discarded, but marked as untrusted with a data credibility flag, and wait for the credibility exception request instruction to restore and correct the linked list and data.

[0209] like Figure 11 As shown, the value of linked list check 1 of consensus data block 1 of data source A is obtained by performing a checksum calculation based on the initial value 00, data source A, data timestamp 1, and core data block 1. The value of linked list check 2 of consensus data block 2 of data source A is obtained by performing a checksum calculation based on linked list check 1, data source A, data timestamp 2, and core data block 2.

[0210] By analogy, the calculation of the linked list checksum value of each consensus data block is based on the linked list checksum value of the previous consensus data block, forming a mutually rolling checksum method. Once any data in the linked list has an error or is invaded and modified, the linked list checksum value will be wrong, causing the linked list to be interrupted. At the same time, each device node in the network will store the consensus data storage linked list of all device nodes in the network, and the linked list stored by each device maintains consistency. Therefore, it is impossible to invade and modify the data of one or several device nodes. In addition, each node will also restore and correct data through the data trust mark, ensuring the robustness of the network and the reliability, recoverability, and traceability of the data.

[0211] In some embodiments of the present disclosure, the data check field of the consensus data block only checks the correctness of the consensus data block. When the data check is wrong, the consensus data block is deemed as erroneous data and is directly discarded.

[0212] like Figure 12 In the verification method shown, for example, the value of data check 2 is obtained by performing verification calculation on data source A, data timestamp 2, core data block 2, and linked list check 2.

[0213] In some embodiments of the present disclosure, the data insertion interface inserts the consensus module process into the core data block:

[0214] 1. Check the validity of the core data block and exit directly if the data block is invalid;

[0215] 2. Get the data source information and record the current time value of the inserted time unit as the data timestamp;

[0216] 3. Search the linked list of the data source in the consensus data storage linked list, and create a data storage unit space at the end of the linked list of the data source;

[0217] 4. Store the data source, data timestamp, and core data block into the consensus data block in the data storage unit space;

[0218] 5. Calculate the linked list checksum and data checksum of the consensus data block and store them;

[0219] 6. Assign the data sending count of the transceiver control block to -1, the data receiving count to 0, and the data trust flag to the trustworthy state;

[0220] 7. End and exit.

[0221] In some embodiments of the present disclosure, the process of a consensus communication receiving port receiving a consensus data block is as follows:

[0222] 1. Use the data check field of the consensus data block to verify the correctness of the consensus data block. If the verification fails, the consensus data block will be discarded directly and the process will end and exit.

[0223] 2. Extract the data source and data timestamp in the consensus data block;

[0224] 3. Search the linked list of data sources in the consensus data storage linked list according to the data source;

[0225] 4. Check whether the consensus data block exists in the data source linked list based on the data timestamp;

[0226] 5. If the consensus data block exists, increase the number of data reception times by 1 and then exit;

[0227] 6. If the consensus data block does not exist, insert the consensus data block into the linked list in chronological order, assign the number of data sent to 0 and the number of data received to 1;

[0228] 7. Use the linked list check field of the consensus data block to verify the credibility of the linked list. If the verification is correct, the data credibility flag is set to the trusted state; if the verification fails, the data credibility flag is set to the untrusted state;

[0229] 8. End and exit.

[0230] In some embodiments of the present disclosure, the process of a consensus communication sending port sending a consensus data block is as follows:

[0231] 1. Record the current time value of the device node time timing unit as a temporary data timestamp;

[0232] 2. Traverse the consensus data storage linked list to find the consensus data block with the oldest data timestamp and the number of times it has been sent does not reach the maximum sending threshold SendCount_Max;

[0233] 3. Determine whether the data reception count reaches the maximum reception threshold RecvCount_Max;

[0234] 4. If the number of data receptions reaches the maximum reception threshold, adjust the new maximum sending threshold SendCount_Max to half of the current value;

[0235] 5. Determine whether the data sending count reaches the new maximum sending threshold SendCount_Max. If it does, set the data sending count to the original maximum sending threshold SendCount_Max and exit.

[0236] 6. If the consensus is not reached, the consensus data is sent through the consensus communication sending port;

[0237] 7. After sending, add 1 to the data sending count;

[0238] 8. End and exit.

[0239] The second aspect of the present disclosure provides an IoT device data consensus device, such as Figure 13 The device schematic diagram shown is applied to any possible implementation method of the first aspect above, and the device includes: a receiving unit, which is used to receive a consensus data block through a consensus module, and store the consensus data block in the consensus data storage list according to a consensus storage rule, wherein each consensus module contains at least one consensus data storage list; a determining unit, which is used to determine the assignment of the consensus data block; an acquiring unit, which is used to acquire the number of times the consensus data block is sent; and a processing unit, which is used to determine the synchronous sending processing of the consensus data block according to the assignment of the consensus data block and the number of times the consensus data block is sent.

[0240] A third aspect of the present disclosure provides a communications device comprising: a memory for storing processor-executable instructions; and a processor connected to the memory; wherein the processor is configured to execute any possible implementation of the method of the first aspect. Furthermore, the application of this method is not limited to the processor referred to in this disclosure and may also be executed in a corresponding logic chip.

[0241] A fourth aspect of the present disclosure provides a communication device, which, when the instructions in the storage medium are executed by a processor of a computer, enables the computer to execute any possible implementation method of the first aspect.

[0242] Figure 14 6 is a block diagram of a communication device 600 according to an exemplary embodiment. The method or apparatus according to the embodiment of the present disclosure may also be implemented with the aid of a computing device architecture. Figure 14A schematic diagram of the architecture of an exemplary computing device according to an embodiment of the present disclosure is shown. As shown in Figure 14, the computing device 600 may include a bus 601, one or more CPUs 602, a read-only memory (ROM) 603, a random access memory (RAM) 604, a communication port 605 connected to a network, an input / output component 606, a hard disk 607, etc. The storage device in the computing device 600, such as the ROM 603 or the hard disk 607, can store various data or files used for processing and / or communication of the data processing method based on inter-node data sharing provided by the present disclosure, as well as program instructions executed by the CPU. The computing device 600 may also include a user interface 608. Of course, Figure 14 The architecture shown is only exemplary and can be omitted according to actual needs when implementing different devices. Figure 14 One or more components of a computing device are shown.

[0243] According to yet another aspect of the present disclosure, a computer-readable storage medium is provided.

[0244] The computer storage medium stores computer-readable instructions. When the computer-readable instructions are executed by the processor, the data processing method based on inter-node data sharing according to the embodiment of the present disclosure described with reference to the above figures can be executed. The computer-readable storage medium includes, but is not limited to, volatile memory and / or non-volatile memory. The volatile memory may include, for example, random access memory (RAM) and / or cache memory (cache), etc. The non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, etc.

[0245] Those skilled in the art will appreciate that the contents disclosed in this disclosure may be subject to various modifications and improvements. For example, the various devices or components described above may be implemented through hardware, software, firmware, or a combination of some or all of the three.

[0246] In addition, although the present disclosure makes various references to certain units in the system according to embodiments of the present disclosure, any number of different units can be used and run on the client and / or server. The units are only illustrative, and different aspects of the systems and methods can use different units.

[0247] Those skilled in the art will appreciate that all or part of the steps in the above method can be performed by instructing the relevant hardware through a program, and the program can be stored in a computer-readable storage medium, such as a read-only memory, a magnetic disk, or an optical disk. Alternatively, all or part of the steps in the above embodiment can also be implemented using one or more integrated circuits. Accordingly, each module / unit in the above embodiment can be implemented in the form of hardware or in the form of software functional modules. The present disclosure is not limited to any particular combination of hardware and software.

[0248] Unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs. It should also be understood that terms such as those defined in common dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and should not be interpreted in an idealized or highly formal sense, unless explicitly defined as such herein.

[0249] The above is an illustration of the present disclosure and should not be considered as a limitation thereof. Although several exemplary embodiments of the present disclosure have been described, it will be readily understood by those skilled in the art that many modifications may be made to the exemplary embodiments without departing from the novel teachings and advantages of the present disclosure. Therefore, all such modifications are intended to be included within the scope of the present disclosure as defined by the claims. It should be understood that the above is an illustration of the present disclosure and should not be considered as limited to the specific embodiments disclosed, and modifications to the disclosed embodiments and other embodiments are intended to be included within the scope of the appended claims. The present disclosure is defined by the claims and their equivalents.

Claims

1. A data consensus method for IoT devices, characterized in that: Receive the consensus data block through the consensus module, and store the consensus data block in the consensus data storage linked list of the consensus module according to the consensus storage rule, wherein each consensus module includes at least one consensus data storage linked list; Determining the value assigned to the consensus data block, and determining the number of times the consensus data block is sent according to the value assigned to the consensus data block; including: when the value assigned to the consensus data block is untrustworthy, synchronizing the consensus data block to other communication nodes in the network through the consensus module; when the value assigned to the consensus data block in the other communication node is trustworthy, modifying the number of times the consensus data block is sent in the other communication node to 0, so as to continue the synchronous sending process of the consensus data block in the other communication node; when the value assigned to the consensus data block in the other communication node is untrustworthy, continuing to synchronize the consensus data block in the other communication node to the communication node with trustworthy data through the consensus module, and the communication node with trustworthy data recovers the other communication node with untrustworthy data; Obtaining the number of times the consensus data block is sent; The synchronous sending processing of the consensus data block is determined according to the number of times the consensus data block is sent.

2. The method for data consensus of an Internet of Things device according to claim 1, characterized in that: The method further comprises: The consensus data storage linked list stores at least one data storage unit in the form of a linked list, wherein the data storage unit includes a consensus data block and a transceiver control block; Receive the consensus data block from any consensus communication receiving port of the consensus module in the form of a linked list; The reception and transmission of the consensus data block are processed by the transceiver control block.

3. The method for data consensus of an Internet of Things device according to claim 1, characterized in that: The consensus storage rules include: Storing the same consensus data block in the data storage unit of the same consensus data storage linked list; The consensus data blocks obtained from the same data source are stored in the same consensus data storage linked list, where one IoT device node corresponds to one consensus data storage linked list; The consensus data blocks are sequentially stored in the consensus data storage linked list according to the order of data generation time to form a linked list.

4. The method for data consensus of an Internet of Things device according to claim 3, characterized in that: The method further comprises: When confirming the consensus data block, determining a data check value of the consensus data block; Determining whether to store or discard the consensus data block according to the data check value of the consensus data block; When the data check value is verified to be correct, the consensus data block is stored.

5. The method for data consensus of an Internet of Things device according to claim 1, characterized in that: Determining the value of the consensus data block includes: Determine the linked list checksum of the previous consensus data block; Determine basic information of the consensus data block, wherein the basic information of the consensus data block includes at least a consensus unique identifier, a core data block, and a consensus check block of the consensus data block; Determining a linked list check value of the consensus data block according to the linked list check value of the previous consensus data block and basic information of the consensus data block; When the linked list check value of the consensus data block is an optional result, the value assigned to the consensus data block is marked as credible.

6. The method for data consensus of an Internet of Things device according to claim 5, characterized in that: The method further includes: setting a maximum credible delay time; When the consensus data block assigned as untrustworthy is not updated to a trustworthy assignment state within the maximum trustworthy delay time, the consensus module initiates a trustworthy exception request through consensus.

7. The method for data consensus of an Internet of Things device according to claim 1, characterized in that: The determining the number of times the consensus data block is sent according to the value assigned to the consensus data block includes: When the value assigned to the consensus data block is untrustworthy, the number of times the consensus data block is sent is defined as a negative number, and the number of times the consensus data block is received is defined as 0; when the value assigned to the consensus data block is trustworthy, the number of times the consensus data block is sent is directly obtained.

8. The method for data consensus of an Internet of Things device according to claim 1, characterized in that: The step of determining the synchronous sending process of the consensus data block according to the number of times the consensus data block is sent includes: When the number of times the consensus data block is sent reaches a preset value, the sending of the consensus data block is stopped.

9. The method for data consensus of an Internet of Things device according to claim 8, characterized in that: The method further comprises: Obtaining the number of times the consensus data block is received; When the number of times the consensus data block is received reaches a maximum reception threshold, the preset value of the number of times the consensus data block is sent is adjusted downward, or the number of times the consensus data block is sent is increased.

10. The method for data consensus of an Internet of Things device according to claim 1, characterized in that: The method further includes: performing effective sending processing on the consensus data block at least once, and counting the number of times the consensus data block is sent.

11. The method for data consensus of an Internet of Things device according to claim 1, characterized in that: The method further comprises: The consensus module also has an inserted consensus module; The insertion consensus module receives the core data block obtained from the IoT device node through the data insertion interface.

12. The method for data consensus of an Internet of Things device according to claim 11, characterized in that: The method further comprises: When the data insertion interface confirms the core data block, a consensus unique identifier is added to the front of the core data block, and a consensus check block is added to the back of the core data block to form a consensus data block for inserting data; The consensus data block of the inserted data is stored in the consensus data storage linked list according to the consensus storage rule, and initial values ​​are assigned to the fields of the consensus data block.

13. The method for data consensus of an Internet of Things device according to claim 12, characterized in that: The adding of a consensus unique identifier at the front of the core data block and the adding of a consensus check block at the rear of the core data block include: The data source and data timestamp of the core data block are combined to form the consensus data block of the inserted data, wherein the data timestamp is determined according to the same synchronization time timing unit; The assignment of the consensus data block of the inserted data is marked according to the linked list check value of the consensus data block of the inserted data to form the consensus check block.

14. The method for data consensus of an Internet of Things device according to claim 11, characterized in that: The method further comprises: The consensus module also has a consensus retrieval interface; The insert consensus module extracts the core data blocks after synchronization consensus from the consensus data storage linked list through the consensus retrieval interface.

15. An IoT device data consensus device, applied to an IoT device data consensus method according to any one of claims 1 to 14, characterized in that: The device comprises: A receiving unit, configured to receive a consensus data block through a consensus module, and store the consensus data block in the consensus data storage linked list according to a consensus storage rule, wherein each consensus module includes at least one consensus data storage linked list; a determination unit, configured to determine the value assigned to the consensus data block, and determine the number of times the consensus data block is sent according to the value assigned to the consensus data block; including: when the value assigned to the consensus data block is untrustworthy, synchronizing the consensus data block to other communication nodes in the network through the consensus module; when the value assigned to the consensus data block in the other communication node is trustworthy, modifying the number of times the consensus data block is sent in the other communication node to 0, so as to continue the synchronous sending process of the consensus data block in the other communication node; when the value assigned to the consensus data block in the other communication node is untrustworthy, continuing to synchronize the consensus data block in the other communication node to a data-trustworthy communication node through the consensus module, and having the data-trustworthy communication node restore the data of the other communication node that is untrustworthy; An acquiring unit, configured to acquire the number of times the consensus data block is sent; A processing unit is used to determine the synchronous sending processing of the consensus data block according to the number of times the consensus data block is sent.

16. The IoT device data consensus device according to claim 15, characterized in that: The determining unit includes: an assignment determining unit, configured to: Determine the linked list checksum of the previous consensus data block; Determine basic information of the consensus data block, wherein the basic information of the consensus data block includes at least a consensus unique identifier, a core data block, and a consensus check block of the consensus data block; Determining a linked list check value of the consensus data block according to the linked list check value of the previous consensus data block and basic information of the consensus data block; When the linked list check value of the consensus data block is an optional result, the value assigned to the consensus data block is marked as credible.

17. The IoT device data consensus device according to claim 15, characterized in that: The determination unit includes: a sending number determination unit, which is used to: when the value assigned to the consensus data block is untrustworthy, define the sending number of the consensus data block as a negative number and define the receiving number of the consensus data block as 0; when the value assigned to the consensus data block is credible, directly obtain the sending number of the consensus data block.

18. The IoT device data consensus device according to claim 15, characterized in that: The processing unit is configured to stop sending the consensus data block when the number of times the consensus data block is sent reaches a preset value.

19. The IoT device data consensus device according to claim 18, characterized in that: The processing unit is further configured to: obtain the number of times the consensus data block is received; When the number of times the consensus data block is received reaches a maximum reception threshold, the preset value of the number of times the consensus data block is sent is adjusted downward, or the number of times the consensus data block is sent is increased.

20. The IoT device data consensus device according to claim 15, characterized in that: The apparatus further comprises: an insertion unit, wherein the consensus module further comprises an insertion consensus module; The insertion consensus module receives the core data block obtained from the IoT device node through the data insertion interface.

21. The IoT device data consensus device according to claim 20, characterized in that: The device further comprises: The retrieval unit is used in the consensus module and also has a consensus retrieval interface; The insert consensus module extracts the core data blocks after synchronization consensus from the consensus data storage linked list through the consensus retrieval interface.

22. A communication device, characterized in that: include: a memory for storing processor-executable instructions; A processor connected to the memory; wherein the processor is configured to execute the method according to any one of claims 1 to 14.

23. A non-transitory computer-readable storage medium, which, when instructions in the storage medium are executed by a processor of a computer, enables the computer to perform the method according to any one of claims 1 to 14.

Images