Distributed terminal collaboration-oriented low-energy-consumption consensus method and device, storage medium and product

Abstract

The invention discloses a distributed terminal collaboration-oriented low-energy-consumption consensus method and device, a storage medium and a product, and the method comprises the steps: obtaining an event type of a block chain event in response to the block chain event; determining a consensus mechanism of the block chain event based on the event type; and performing consensus on the block chain event according to the consensus mechanism. According to the application, the event type is a block chain event consensus mechanism, so that different consensus mechanisms can be selected when different event types are block chain events, and therefore, security requirements and resource consumption of different event types can be considered; the problem that a traditional consensus mechanism cannot effectively work in a resource limited device or a high-security demand scene is avoided, so that the efficiency and security of distributed terminal collaboration are improved, and the energy consumption is reduced.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of Internet of Things, and in particular to a low-energy consensus method for distributed terminal collaboration, equipment, a storage medium and a product. BACKGROUND

[0002] With the development of blockchain technology, the application of blockchain technology and grouping technology in large-scale networks, such as Internet of Things systems, is gradually increasing. However, when applying blockchain technology to Internet of Things systems, due to the large number and wide distribution of terminal devices in the Internet of Things system, the resource status, network quality and security requirements of different devices differ greatly, and the existing consensus mechanism used by the blockchain system cannot take into account the resource constraints of terminal devices and industrial-level security requirements, which may cause some devices to be unable to normally participate in consensus due to insufficient resources, or fail to provide sufficient security in scenarios with high security requirements. For example, in some traditional blockchain consensus mechanisms, if the proof of work (PoW) mechanism, although it has high security, it requires a large amount of computing resources and energy consumption, which is difficult for resource-constrained Internet of Things terminal devices to bear. While the proof of stake (PoS) mechanism reduces energy consumption, it may not meet the industrial-level requirements in terms of security and consensus efficiency.

[0003] Therefore, the prior art still needs to be improved and improved. SUMMARY

[0004] The technical problem to be solved by the present application is to provide a low-energy consensus method for distributed terminal collaboration, equipment, a storage medium and a product to solve the problems of the prior art.

[0005] To solve the above technical problems, the first aspect of the present application provides a low-energy consensus method for distributed terminal collaboration, wherein the low-energy consensus method for distributed terminal collaboration specifically comprises: In response to a blockchain event, obtaining the event type of the blockchain event; Determining the consensus mechanism of the blockchain event based on the event type; According to the consensus mechanism, the blockchain event is consensus.

[0006] The low-energy consensus method for distributed terminal collaboration, wherein the obtaining the event type of the blockchain event specifically comprises: Obtaining the event security level and the occurrence frequency of the blockchain event; Determining the security score of the blockchain event based on the event security level and the occurrence frequency; Determining the event type of the blockchain event based on the security score.

[0007] The low-energy consensus method for distributed terminal collaboration further includes, before obtaining the event security level and occurrence frequency of blockchain events: Obtain the event attributes of the blockchain event, including intra-group events or cross-group events; When the event attribute is an intra-group event, the steps of obtaining the event security level and occurrence frequency of the blockchain event are executed; When the event attribute is a cross-group event, the event type of the blockchain event is set to cross-group event.

[0008] The low-energy consensus method for distributed terminal collaboration, wherein when the event attribute is an intra-group event, the process of obtaining the event security level of the blockchain event specifically includes: The security requirements for obtaining the blockchain event; The event security level of the blockchain event is determined based on the aforementioned security requirements.

[0009] The aforementioned low-energy consensus method for distributed terminal collaboration further includes: Before responding to blockchain events, the distributed terminal cluster is divided into several coordinating device groups.

[0010] The aforementioned low-energy consensus method for distributed terminal collaboration further includes: When responding to blockchain events, the distributed terminal cluster is divided into several coordinating device groups.

[0011] The low-energy consensus method for distributed terminal collaboration, wherein dividing the distributed terminal cluster into several coordination device groups specifically includes: Obtain status data of terminal devices in a distributed terminal cluster; Based on the status data, the distributed terminal cluster is collaboratively grouped to obtain several collaborative device groups.

[0012] The low-energy consensus method for distributed terminal collaboration, wherein the status data includes at least the device location and the remaining power of the device, and may also include device resources and / or device network quality.

[0013] The low-energy consensus method for distributed terminal collaboration, wherein the step of collaboratively grouping the distributed terminal cluster based on the state data to obtain several collaborative device groups specifically includes: Based on the status data, the distributed terminal cluster is collaboratively grouped using fuzzy decision tree clustering to obtain several collaborative device groups.

[0014] The low-energy consensus method for distributed terminal collaboration, wherein in the process of dividing the distributed terminal cluster into several coordination device groups, a preset number is used as a grouping constraint so that the difference between the number of devices in each coordination device group and the preset number is within a preset range.

[0015] The low-energy consensus method for distributed terminal collaboration includes event types such as low-security group events, high-security group events, and cross-group events.

[0016] The low-energy consensus method for distributed terminal collaboration, wherein the consensus mechanism for determining the blockchain event based on the event type specifically includes: When the event type is an event within a low-security group, the consensus mechanism is lightweight PoS verification; When the event type is an event within a high-security group, the consensus mechanism is a composite verification consisting of PoS verification and PoW verification. When the event type is a cross-group event, the consensus mechanism is Byzantine fault tolerance verification.

[0017] The low-energy consensus method for distributed terminal collaboration, wherein the consensus-building process for the blockchain event according to the consensus mechanism specifically includes: The blockchain event is subject to device-level consensus according to the consensus mechanism corresponding to the blockchain event. Determine whether the blockchain event requires gateway-level consensus based on the event type; When a blockchain event requires gateway-level consensus, the blockchain event is subjected to gateway-level consensus through a gateway device according to the consensus mechanism corresponding to the blockchain event.

[0018] The aforementioned low-energy consensus method for distributed terminal collaboration further includes: Obtain the equivalent distance between the current terminal device and the target terminal device; Based on the equivalent distance, the radio frequency transmission power for the current communication between the current terminal device and the target terminal device is determined, and the current terminal device is controlled to communicate according to the radio frequency transmission power.

[0019] The aforementioned low-energy consensus method for distributed terminal collaboration further includes: Monitor the rate of change of the queue length of the blockchain event queue of terminal devices in a distributed terminal cluster; The sleep time of the terminal device is adjusted based on the rate of change of the queue length.

[0020] The low-energy consensus method for distributed terminal collaboration further includes the following when the event type is a cross-group event: Obtain the hash commitments of each collaborative device group in the distributed terminal cluster; Aggregate all the obtained state commitments to obtain an aggregate signature; The aggregated signature and hash commitment are distributed to the collaborative device group so that the collaborative device group can verify based on the aggregated signature to synchronize the state within the distributed terminal cluster.

[0021] The low-energy consensus method for distributed terminal collaboration includes a verification process based on the aggregated signature, comprising: The aggregated signature is verified; When the aggregate signature verification passes, the hash commitment stored by the collaborative device group is compared with the hash commitment received by the collaborative device group. If the two hash commitments match, the verification is considered successful.

[0022] A second aspect of this application provides a computer-readable storage medium storing one or more programs that can be executed by one or more processors to implement the steps in the low-power consensus method for distributed terminal collaboration as described above.

[0023] A third aspect of this application provides an electronic device comprising: a processor and a memory; The memory stores a computer-readable program that can be executed by the processor; When the processor executes the computer-readable program, it implements the steps in any of the above-described low-power consensus methods for distributed terminal collaboration.

[0024] A fourth aspect of this application provides a computer program product, wherein the computer program product includes a computer program that, when executed by a processor, implements the steps of the low-power consensus method for distributed terminal collaboration as described above.

[0025] Beneficial Effects: Compared with existing technologies, this application provides a low-energy consensus method, device, storage medium, and product for distributed terminal collaboration. The method includes responding to a blockchain event and obtaining the event type of the blockchain event; determining the consensus mechanism of the blockchain event based on the event type; and achieving consensus on the blockchain event according to the consensus mechanism. This application, by using the event type as the consensus mechanism for blockchain events, allows different consensus mechanisms to be selected for different event types. This balances the security requirements and resource consumption of different event types, avoiding the problem that traditional consensus mechanisms cannot work effectively on resource-constrained devices or in scenarios with high security requirements. Therefore, it improves the efficiency and security of distributed terminal collaboration and reduces energy consumption. Attached Figure Description

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

[0027] Figure 1 A schematic block diagram of an electronic device provided in an embodiment of this application.

[0028] Figure 2 A flowchart of a low-energy consensus method for distributed terminal collaboration provided in an embodiment of this application.

[0029] Figure 3 This is a flowchart illustrating the process of dividing collaborative equipment groups.

[0030] Figure 4 This is a flowchart illustrating step H20.

[0031] Figure 5 This is a flowchart illustrating step S10.

[0032] Figure 6 This is a flowchart illustrating the detection process for determining whether an event type can be determined based on event attributes.

[0033] Figure 7 This is a flowchart illustrating the process of obtaining the security level of an event.

[0034] Figure 8 This is a flowchart illustrating step S20.

[0035] Figure 9 This is a flowchart illustrating step S30.

[0036] Figure 10 This is a flowchart illustrating the synchronization process for state synchronization.

[0037] Figure 11 This is a flowchart illustrating step S43.

[0038] Figure 12 This is a flowchart illustrating the process of determining radio frequency transmit power.

[0039] Figure 13 This is a flowchart illustrating the process of determining the hibernation time. Detailed Implementation

[0040] This application provides a low-power consensus method, device, storage medium, and product for distributed terminal collaboration. To make the objectives, technical solutions, and effects of this application clearer and more explicit, the following detailed description is provided with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only for explaining this application and are not intended to limit this application.

[0041] Those skilled in the art will understand that, unless specifically stated otherwise, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the term “comprising” as used in this application means the presence of the stated features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. It should be understood that when we say an element is “connected” or “coupled” to another element, it can be directly connected or coupled to the other element, or there may be intermediate elements. Furthermore, “connected” or “coupled” as used herein can include wireless connections or wireless coupling. The term “and / or” as used herein includes all or any units and all combinations of one or more associated listed items.

[0042] It will be understood by those skilled in the art that, 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 application pertains. It should also be understood that terms such as those defined in general dictionaries should be understood to have the same meaning as in the context of the prior art, and should not be interpreted in an idealized or overly formal sense unless specifically defined as herein.

[0043] It should be understood that the sequence number and size of each step in this embodiment do not imply the order of execution. The execution sequence of each process is determined by its function and internal logic, and should not constitute any limitation on the implementation process of this application embodiment.

[0044] Research has revealed that with the development of blockchain technology, there is a growing interest in applying blockchain and grouping technologies to large-scale networks, such as the Internet of Things (IoT) systems. However, when applying blockchain technology to IoT systems, the sheer number and wide distribution of terminal devices, along with significant differences in resource availability, network quality, and security requirements, present challenges. Existing blockchain consensus mechanisms often fail to balance resource constraints with industrial-grade security requirements. Some devices may be unable to participate in consensus due to insufficient resources, or they may not provide adequate security in scenarios with high security demands. For example, in some traditional blockchain consensus mechanisms, Proof-of-Work (PoW), while offering high security, requires substantial computational resources and energy consumption, which is unsustainable for resource-constrained IoT terminal devices. While Proof-of-Stake (PoS) mechanisms offer lower energy consumption, they may not meet industrial-grade security and consensus efficiency requirements.

[0045] To address the aforementioned issues, in this embodiment, in response to a blockchain event, the event type of the blockchain event is obtained; a consensus mechanism for the blockchain event is determined based on the event type; and consensus is reached on the blockchain event according to the consensus mechanism. This application, by using a consensus mechanism based on the event type, allows different consensus mechanisms to be selected for different event types. This balances the security requirements and resource consumption of different event types, avoiding the problem of traditional consensus mechanisms failing to work effectively on resource-constrained devices or in scenarios with high security requirements. This improves the efficiency and security of distributed terminal collaboration and reduces energy consumption.

[0046] The application content will be further explained below with reference to the accompanying drawings and through the description of the embodiments.

[0047] Please see Figure 1 , Figure 1 This is a schematic block diagram of the electronic device provided in the embodiments of this application. Figure 1 As shown, the electronic device includes a processor and a memory. The processor 1001 and the memory 1002 are connected by a bus, such as an I2C (Inter-integrated Circuit) bus or a distributed soft bus.

[0048] The memory 1002 may include a non-volatile storage medium and internal memory. The non-volatile storage medium may store an operating system and a computer program. The computer program includes program instructions that, when executed, cause the processor to execute any low-power consensus method for distributed terminal collaboration.

[0049] Processor 1001 provides computing and control capabilities to support the operation of the entire electronic device. Processor 1001 can be a Central Processing Unit (CPU), but it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0050] Specifically, the processor 1001 is used to run a computer program stored in memory, and when executing the computer program, it performs the following steps: Respond to a blockchain event and obtain the event type of the blockchain event; The consensus mechanism for the blockchain event is determined based on the event type. The blockchain event is agreed upon according to the consensus mechanism described above.

[0051] In some embodiments, when the processor 1001 obtains the event type of the blockchain event, it is specifically used to: obtain the event security level and occurrence frequency of the blockchain event; The security score of the blockchain event is determined based on the event security level and the frequency of occurrence. The event type of the blockchain event is determined based on the security score.

[0052] In some embodiments, before obtaining the event security level and occurrence frequency of the blockchain event, the processor 1001 is further configured to perform: Obtain the event attributes of the blockchain event, including intra-group events or cross-group events; When the event attribute is an intra-group event, the steps of obtaining the event security level and occurrence frequency of the blockchain event are executed; When the event attribute is a cross-group event, the event type of the blockchain event is set to cross-group event.

[0053] In some embodiments, when the event attribute is an intra-group event, the processor 1001, when obtaining the event security level of the blockchain event, specifically implements the following: The security requirements for obtaining the blockchain event; The event security level of the blockchain event is determined based on the aforementioned security requirements.

[0054] In some embodiments, the processor 1001 is further configured to implement: Before responding to blockchain events, the distributed terminal cluster is divided into several coordinating device groups.

[0055] In some embodiments, the processor 1001 is further configured to implement: When responding to blockchain events, the distributed terminal cluster is divided into several coordinating device groups.

[0056] In some embodiments, when the processor 1001 divides the distributed terminal cluster into several coordination device groups, it is specifically used to implement: Obtain status data of terminal devices in a distributed terminal cluster; Based on the status data, the distributed terminal cluster is collaboratively grouped to obtain several collaborative device groups.

[0057] In some embodiments, the status data includes at least the device location and remaining battery power, and may also include device resources and / or device network quality.

[0058] In some embodiments, when the processor 1001 performs collaborative grouping of the distributed terminal cluster based on the status data to obtain several collaborative device groups, it is specifically configured to: Based on the status data, the distributed terminal cluster is collaboratively grouped using fuzzy decision tree clustering to obtain several collaborative device groups.

[0059] In some embodiments, during the process of dividing the distributed terminal cluster into several coordinated device groups, a preset number is used as a grouping constraint so that the difference between the number of devices in each coordinated device group and the preset number is within a preset range.

[0060] In some embodiments, the event types include events within a low-security group, events within a high-security group, and cross-group events.

[0061] In some embodiments, when determining the consensus mechanism of the blockchain event based on the event type, the processor 1001 is specifically configured to implement: When the event type is an event within a low-security group, the consensus mechanism is lightweight PoS verification; When the event type is an event within a high-security group, the consensus mechanism is a composite verification consisting of PoS verification and PoW verification. When the event type is a cross-group event, the consensus mechanism is Byzantine fault tolerance verification.

[0062] In some embodiments, when the processor 1001 reaches consensus on the blockchain event according to the consensus mechanism, it is specifically configured to implement: The blockchain event is subject to device-level consensus according to the consensus mechanism corresponding to the blockchain event. Determine whether the blockchain event requires gateway-level consensus based on the event type; When a blockchain event requires gateway-level consensus, the blockchain event is subjected to gateway-level consensus through a gateway device according to the consensus mechanism corresponding to the blockchain event.

[0063] In some embodiments, the processor 1001 is further configured to implement: Obtain the equivalent distance between the current terminal device and the target terminal device; Based on the equivalent distance, the radio frequency transmission power for the current communication between the current terminal device and the target terminal device is determined, and the current terminal device is controlled to communicate according to the radio frequency transmission power.

[0064] In some embodiments, the processor 1001 is further configured to implement: Monitor the rate of change of the queue length of the blockchain event queue of terminal devices in a distributed terminal cluster; The sleep time of the terminal device is adjusted based on the rate of change of the queue length.

[0065] In some embodiments, when the event type is a cross-group event, the processor 1001 is further configured to implement: Obtain the hash commitments of each collaborative device group in the distributed terminal cluster; Aggregate all the obtained state commitments to obtain an aggregate signature; The aggregated signature and hash commitment are distributed to the collaborative device group so that the collaborative device group can verify based on the aggregated signature to synchronize the state within the distributed terminal cluster.

[0066] In some embodiments, when performing verification based on the aggregated signature, the processor 1001 is specifically configured to implement: The aggregated signature is verified; When the aggregate signature verification passes, the hash commitment stored by the collaborative device group is compared with the hash commitment received by the collaborative device group. If the two hash commitments match, the verification is considered successful.

[0067] Please see Figure 2 , Figure 2This is a flowchart of a low-energy consensus method for distributed terminal collaboration provided in this embodiment. The method includes responding to a blockchain event and obtaining the event type of the blockchain event; determining a consensus mechanism for the blockchain event based on the event type; and achieving consensus on the blockchain event according to the consensus mechanism. This application, by using the event type as the consensus mechanism for blockchain events, allows different consensus mechanisms to be selected for different event types. This balances the security requirements and resource consumption of different event types, avoiding the problem of traditional consensus mechanisms failing to work effectively on resource-constrained devices or in scenarios with high security requirements. Therefore, it improves the efficiency and security of distributed terminal collaboration and reduces energy consumption.

[0068] This application provides a low-energy consensus method for distributed terminal collaboration. This method is applied to a distributed terminal system, which can be a factory production line equipment collaboration system (e.g., a sensor network), a new energy vehicle group collaborative driving system, or a distributed municipal equipment system (e.g., a street light system, a meter system, or a fire hydrant system). Of course, in practical applications, this distributed terminal system can also be other IoT systems, such as smart home systems, etc., without specific limitations. The distributed terminal system includes multiple terminal devices, which can include various IoT devices such as sensors, actuators, smart meters, smart locks, and cameras. These terminal devices are widely distributed and each has different resource conditions, network quality, and security requirements. During the operation of the distributed terminal system, various blockchain events are continuously generated, such as data upload events from sensors and control command execution events received by actuators.

[0069] Specifically, such as Figure 2 As shown, the low-energy consensus method for distributed terminal collaboration provided in this application specifically includes: S10. Respond to a blockchain event and obtain the event type of the blockchain event.

[0070] Specifically, blockchain events are those that require collaborative completion through distributed terminals, such as sensor data acquisition events, device control command execution events, and data transmission events. Event types reflect the security level of a blockchain event and are categorized based on factors such as the event's security level and frequency of occurrence. Different event types correspond to different security requirements and resource consumption. For example, low-security event types have lower resource consumption requirements, while high-security event types have lower resource consumption requirements.

[0071] It is understandable that, since a distributed terminal system is composed of multiple terminal devices, consensus needs to be reached during collaboration to ensure the consistency and reliability of the distributed terminal system. However, the implementation of the consensus mechanism faces the risk of centralization, where certain key nodes or terminal devices may excessively concentrate control, causing the distributed terminal system to deviate from the distributed principle in decision-making and data processing, thereby weakening the overall decentralized advantages and security. Therefore, this application groups the terminal devices included in the distributed terminal system before responding to a blockchain event, or during the initial response to a blockchain event. In other words, the low-energy consensus method for distributed terminal collaboration further includes: The distributed terminal cluster is divided into several coordination device groups.

[0072] Specifically, a distributed terminal cluster is a cluster of terminal devices included in a distributed terminal system. Each of several coordinating device groups includes a certain number of terminal devices. The terminal devices in each coordinating device group do not overlap, and each terminal device in the distributed terminal cluster is included within one coordinating device group. In other words, this application achieves distributed organization and management of terminal devices by grouping the distributed terminal cluster into several non-overlapping coordinating device groups. Each coordinating device group can independently handle blockchain events generated by its affiliated terminal devices, reducing cross-group communication overhead while preventing a single node or group from gaining complete control, effectively mitigating the risk of centralization. The grouping of the distributed terminal cluster is a dynamic grouping process; that is, the collaborative grouping of the distributed terminal cluster dynamically changes according to the device status or preset conditions of the terminal devices during the operation of the distributed terminal cluster. For example, the preset condition is to execute a collaborative group once every time a blockchain event is responded to, or to automatically trigger a collaborative group according to a preset period. The collaborative group can be dynamically triggered during system initialization, or when a new terminal device is added / removed / replaced, or when the status changes of a preset number of terminal devices meet preset requirements (such as the remaining battery power of the device being lower than a preset battery power threshold).

[0073] Furthermore, the grouping strategy for distributing terminal clusters can be dynamically evaluated based on factors such as the terminal devices' resources, communication stability, and device location, taking into account the performance indicators and security attributes of each terminal device.

[0074] For example, such as Figure 3 As shown, dividing the distributed terminal cluster into several coordination device groups specifically includes: H10: Obtain the status data of terminal devices in the distributed terminal cluster; H20. Based on the status data, the distributed terminal cluster is collaboratively grouped to obtain several collaborative device groups.

[0075] In step H10, the status data reflects the terminal device's current operating status, performance parameters, and environmental information. Operating status includes whether the device is idle, busy, or malfunctioning; performance parameters include the device's computing power, storage capacity, and network bandwidth; environmental information involves the device's physical location, surrounding network signal strength, temperature, and humidity. Analyzing this status data provides a comprehensive understanding of the actual situation of each terminal device.

[0076] The status data includes device location and remaining battery power. Device location reflects the physical location of the terminal device, and remaining battery power reflects the current available power. Additionally, the status data may also include device resources and / or device network quality. For example, the status data may also include device resources, or it may include device resources and remaining battery power. Device resources may include CPU utilization, memory usage, remaining storage space, and current power consumption mode. Device network quality may include signal strength, packet loss rate, network latency, and available bandwidth.

[0077] It is understandable that terminal devices in a distributed terminal cluster collect their own status data in real time and construct device feature vectors based on the collected status data. Then, the distributed terminal cluster can be collaboratively grouped based on the device feature vectors of each terminal device. The device feature vector of a terminal device can be represented as: , in, Indicates the first Device feature vector of each terminal device Indicates the first The remaining battery power of each terminal device. Indicates the first Equipment resources for each terminal device. Indicates the first The network quality of each terminal device Indicates the first The device location of each terminal device. This indicates the number of terminal devices in the distributed terminal cluster.

[0078] In step H20, after obtaining the status data, the distributed terminal cluster can be collaboratively grouped based on the status data. For example, the status data of all terminal devices can be input into a preset collaborative grouping model and collaborative grouping can be performed through the preset collaborative grouping model. Alternatively, the terminal devices in the distributed terminal cluster can be clustered based on the status data for collaborative grouping.

[0079] In one embodiment, the step of collaboratively grouping the distributed terminal cluster based on the status data to obtain several collaborative device groups specifically involves: Based on the status data, the distributed terminal cluster is collaboratively grouped using fuzzy decision tree clustering to obtain several collaborative device groups.

[0080] Specifically, fuzzy decision tree clustering is a clustering method based on fuzzy logic and decision tree principles. It comprehensively considers multiple state factors in the state data and groups terminal devices in a distributed terminal cluster by constructing a fuzzy decision tree. First, the fuzzy decision tree partitions nodes based on the state data. For example, using state data as a partitioning node, when the state data meets a certain fuzzy partitioning criterion, the terminal device corresponding to that state data is assigned to one branch; when the state data does not meet a certain fuzzy partitioning criterion, the terminal device corresponding to that state data is assigned to another branch. By continuously partitioning nodes based on the state factors of the state data, a complete fuzzy decision tree is eventually formed. The fuzzy partitioning criterion includes the fuzzy threshold of each state factor in the state data. The fuzzy threshold of each state factor is not a precise value, but a value with a certain fuzzy range, which can better adapt to the uncertainty and diversity of the state data of terminal devices.

[0081] Terminal devices are matched against fuzzy decision trees based on their own state data, thus being grouped into different collaborative device groups. This clustering method fully considers the fuzziness and complexity of terminal device state data, making the grouping results more reasonable and consistent with reality. Moreover, fuzzy decision tree clustering also has a certain degree of flexibility and scalability. When the characteristics of the state data change or new state data factors need to be considered, the fuzzy decision tree can be easily adjusted and optimized to ensure the accuracy and effectiveness of the grouping.

[0082] This application employs fuzzy decision tree clustering for collaborative grouping, ensuring that terminal devices within each collaborative device group share similarities in state data. This facilitates collaborative work and resource sharing among terminal devices within the collaborative device group, improving the overall performance and efficiency of the distributed terminal system. Simultaneously, the differences between different collaborative device groups can meet the needs of different event types, providing a solid foundation for subsequent consensus mechanism implementation and event handling.

[0083] Furthermore, in practical applications, to avoid increased communication overhead and task scheduling complexity due to an excessive number of terminal devices within a collaborative device group, a preset number is set beforehand when dividing the distributed terminal cluster into several collaborative device groups. This preset number serves as a grouping constraint to limit the number of devices in each collaborative device group, ensuring that the difference between the number of devices in each collaborative device group and the preset number remains within a preset range. For example, the preset number is 10, and the preset range is... Therefore, the range of possible values ​​for the number of devices in each collaborative device group is: .

[0084] In one embodiment, when collaboratively grouping the distributed terminal cluster based on the status data, the terminal devices in the distributed terminal cluster can be filtered first based on the status data, and then collaboratively grouped based on the filtered terminal devices. The filtered terminal devices are identified as abnormal devices, and warning information is generated for the abnormal devices. Therefore, as follows... Figure 4 As shown, collaborative grouping of the distributed terminal cluster based on the status data may include: H21. Based on the device resources and device network quality in the status data, filter the terminal devices in the distributed terminal cluster to obtain a filtered terminal device set. H20. Based on the device location and remaining battery power, the distributed terminal cluster is collaboratively grouped to obtain several collaborative device groups.

[0085] Specifically, during the filtering process, for device resources, if CPU utilization is too high, memory usage is nearing its limit, storage space is insufficient, or the current power consumption mode is abnormal, it indicates that the device resources are strained or abnormal, and can be listed as an abnormal device. For device network quality, when the signal strength is too low, the packet loss rate is too high, the network latency is too long, or the available bandwidth is insufficient, it means that the device's network communication is poor, and can also be identified as an abnormal device. These abnormal devices are filtered out from the distributed terminal cluster to obtain a filtered terminal device set. At the same time, early warning information is generated for these abnormal devices to notify relevant personnel to perform timely maintenance or handling. This can avoid system latency caused by terminal devices with insufficient resources, and can quickly detect and deal with abnormal devices in the distributed terminal cluster, ensuring the stable operation of the entire cluster.

[0086] After obtaining the set of filtering terminal devices, the set is collaboratively grouped based on device location and remaining battery power. When collaboratively grouping the filtering terminal devices based on device distance and remaining battery power, with a preset quantity as a constraint, methods such as fuzzy decision tree clustering or K-clustering can be used.

[0087] For example, fuzzy decision tree clustering can be used for collaborative grouping. The fuzzy decision tree clustering method can be represented as follows: , in, Indicates the first A group of collaborative devices. This represents a set of filter terminal devices. Indicates the first in the set of filter terminal equipment Terminal devices. Indicates the first The device location of each terminal device. Indicates the first The remaining battery power of each terminal device. Indicates the first The location of the equipment in each cluster center Indicates the first The remaining power of the equipment in each cluster center Indicates the weighting coefficient. .

[0088] Furthermore, a grouping identifier matrix can be derived based on the fuzzy decision tree clustering method. , It can be represented as: , in, This indicates the number of devices in the filter terminal equipment set. Indicates the number of collaborative device groups. This indicates the group identifier of the terminal device.

[0089] This application embodiment uses device distance as the basis for collaborative grouping, grouping terminal devices that are close together into the same coordinating device group. This results in shorter communication distances and lower communication latency between terminal devices within the same coordinating device group, which is beneficial for improving communication efficiency and collaborative work effectiveness. Furthermore, devices that are close together may face similar environmental factors and network conditions, facilitating unified management and resource sharing. For example, in a large building, terminal devices on the same floor can be grouped into a coordinating device group. Communication between terminal devices within the same coordinating device group can be efficiently conducted through the building's local area network, and they can collectively address environmental changes and network issues on that floor. By using several coordinating device groups based on device distance, the proximity of terminal devices within the group is ensured, while interference from abnormal devices on grouping and subsequent collaborative work is eliminated, further improving the performance and reliability of the distributed terminal system.

[0090] The above completes the explanation of "dividing the distributed terminal cluster into several coordination device groups". The following section continues with the explanation of step S10.

[0091] In step S10, the event type can be determined based on factors such as the event security level and frequency of occurrence of the blockchain event. In one embodiment, such as... Figure 5 As shown, the specific event types for obtaining the blockchain event include: S11. Obtain the event security level and occurrence frequency of blockchain events; S12. Determine the security score of the blockchain event based on the event security level and the occurrence frequency; S13. Determine the event type of the blockchain event based on the security score.

[0092] In step S21, the event security level reflects the degree of impact of a blockchain event on system security. Event security levels are divided into three categories: high, medium, and low. For example, sensitive operations involving user privacy data, such as data encryption and authentication, are typically classified as high security; while general query operations, such as retrieving public information, may fall under the low security level. The frequency of occurrence reflects the number of times a blockchain event occurs within a certain period. High-frequency blockchain events may have a significant impact on system performance and resource consumption. Of course, in practical applications, event security levels can also be multiple, for example, dividing event security into five levels: Security Level 1, Security Level 2, Security Level 3, Security Level 4, and Security Level 5.

[0093] Furthermore, since the distributed terminal cluster is pre-divided into several coordination device groups, the event type can be determined based on intra-group events and inter-group events within the coordination device group. That is, the event type can include intra-group events and cross-group events. In addition, since blockchain events have both high-security and low-security requirements, intra-group events can also be divided into low-security intra-group events and high-security intra-group events. Therefore, the event types include low-security intra-group events, high-security intra-group events, and cross-group events. For example, in a factory production line equipment collaboration system, when the event to be processed is a high-frequency, low-sensitivity data (such as temperature) reporting intra-group task, the event type can be a low-security intra-group event; when the event to be processed is a high-security intra-group task, the event type can be a high-security intra-group event; and when the event to be processed is a cross-group collaborative task, the event type can be a cross-group event.

[0094] However, when a blockchain event is a cross-group event, it can be directly classified as a cross-group event. Therefore, before obtaining the event security level and occurrence frequency of the blockchain event, such as...Figure 6 As shown, the method further includes: S011. Obtain the event attributes of the blockchain event; S012. When the event attribute is an intra-group event, execute the steps of obtaining the event security level and occurrence frequency of the blockchain event; S013. When the event attribute is a cross-group event, set the event type of the blockchain event to a cross-group event.

[0095] Specifically, since event types include low-security group events, high-security group events, and cross-group events, and event attributes include group events or cross-group events, when the event attribute is a cross-group event, the event type of the blockchain event can be directly determined as a cross-group event, thus eliminating the need to perform the steps of obtaining the event security level and occurrence frequency of the blockchain event. Conversely, when the event attribute is a group event, it is necessary to determine whether the event type of the blockchain event is a secure group event or a high-security group event, thus requiring the steps of obtaining the event security level and occurrence frequency of the blockchain event to determine the event type.

[0096] In one embodiment, when the event attribute is an intra-group event, such as Figure 7 As shown, the process of obtaining the event security level of the blockchain event specifically includes: S111, Obtain the security requirements of the blockchain event; S112. Determine the event security level of the blockchain event based on the security requirements.

[0097] Specifically, security requirements reflect the specific security needs of a blockchain event for the system, with different security requirements corresponding to different event security levels. For example, if a blockchain event involves modification of core system data or operation of critical business processes, its security requirements are usually high, and the corresponding event security level may be classified as high. Conversely, for blockchain events that only involve data reading or non-critical information querying, the security requirements are relatively low, and the event security level may be low.

[0098] After determining security requirements, the event security level can be determined based on pre-defined security level classification rules. These rules can be formulated comprehensively based on factors such as the system's security policy, industry standards, and actual application scenarios. For example, an event might be classified as high security if it meets multiple high security requirements; medium security if it meets some medium security requirements; and medium security if it meets only some low security requirements.

[0099] In step S12, the security score reflects the overall security status of a blockchain event. The security score is calculated by combining the event's security level and frequency of occurrence. The process of obtaining the security score can be pre-set with scoring rules. After obtaining the event's security level and frequency of occurrence, a first security score corresponding to the event's security level and a second security score corresponding to the frequency of occurrence are determined according to the scoring rules. Then, the first and second security scores are added together to obtain the final security score. For example, a higher first security score is assigned to a blockchain event with a high security level, and a lower first security score is assigned to a blockchain event with a low security level. Similarly, a higher second security score is assigned to a blockchain event with a high frequency of occurrence, and a lower second security score is assigned to a blockchain event with a low frequency of occurrence.

[0100] Furthermore, to more accurately assess the event type of blockchain events, different weights can be assigned to the event security level and the frequency of occurrence. Assuming the weight of the event security level is 0.6 and the weight of the frequency of occurrence is 0.4, when an event has a security level score of 8 (out of 10) and a frequency of occurrence score of 6 (out of 10), the event's total security score is 8 × 0.6 + 6 × 0.4 = 7.2.

[0101] Based on this, the process of obtaining the security score can be expressed as follows: , in, Indicates blockchain events Safety rating, This represents the first security score determined based on the event's security level. This indicates a second security score determined based on the frequency of occurrence. Represents the weighting coefficients, and .

[0102] In step S13, after determining the security score of a blockchain event, the event type can be classified based on the security score. Specifically, when the event type can be classified based on the security score, a security score range corresponding to each event type can be pre-set, and the event type can be determined based on this security score range. For example, events with a security score of 8-10 are classified as cross-group events, events with a security score of 4-7 are classified as events within a high-security group, and events with a security score of 1-3 are classified as events within a low-security group.

[0103] S20. Determine the consensus mechanism of the blockchain event based on the event type.

[0104] Specifically, a consensus mechanism is an algorithm in a blockchain system that allows nodes to reach a consensus on the validity of a transaction. Different event types have different requirements for the system's security, performance, and scalability; therefore, different consensus mechanisms are needed to ensure efficient processing of blockchain events and data consistency.

[0105] For blockchain events classified as low-security intra-group events, the security requirements are relatively low and the frequency of occurrence may be high. Since these are intra-group events, the trust between nodes is relatively high, and the communication distance is short with low latency, allowing for a lightweight consensus mechanism. For blockchain events classified as high-security intra-group events, the security requirements are higher, necessitating a more secure and reliable consensus mechanism. For blockchain events classified as cross-group events, due to the interaction between different coordinating device groups, the number of nodes is large, and the trust level is low, requiring a consensus mechanism capable of adapting to large-scale networks and high security requirements.

[0106] Based on this, in one embodiment, such as Figure 8 As shown, the consensus mechanism for determining the blockchain event based on the event type specifically includes: S21. Obtain the correspondence between event types and consensus mechanisms; S22. Based on the event type, determine the consensus mechanism of the blockchain event using the corresponding relationship.

[0107] Specifically, the correspondence is pre-set and used to determine the consensus mechanism for determining blockchain events based on event types. The correspondence can be: When the event type is an event within a low-security group, the consensus mechanism is lightweight PoS verification; When the event type is an event within a high-security group, the consensus mechanism is a composite verification consisting of PoS verification and PoW verification. When the event type is a cross-group event, the consensus mechanism is Byzantine fault tolerance verification.

[0108] Lightweight PoS verification is a consensus mechanism based on proof-of-stake. It simplifies some processes of the traditional PoS mechanism, reduces computational resource consumption, and improves processing speed. In lightweight PoS verification, nodes gain the right to record transactions by holding a certain amount of stake (such as tokens); the more stake, the greater the probability of gaining the right to record transactions. This mechanism is suitable for events within low-security groups because there is a certain level of trust between nodes in the group, and high processing speed is required. Lightweight PoS verification can quickly complete the consensus process while ensuring a certain level of security.

[0109] The composite verification system, consisting of PoS and PoW verification, combines the advantages of both. PoS verification determines the right to record transactions based on the stake held by a node, while PoW verification requires nodes to compete for this right through extensive hash calculations. For events within high-security groups, where security requirements are stringent, composite verification can ensure security while avoiding the risks associated with a single mechanism. For example, PoS verification can prevent malicious attacks from nodes with less stake, while PoW verification increases the cost for attackers to tamper with data.

[0110] Byzantine Fault Tolerance (BFT) is a consensus mechanism that ensures the normal operation of a system even in the presence of malicious nodes. For cross-group events, due to the interaction between different coordinating device groups, the large number of nodes, and their low trust levels, there is a possibility of malicious nodes attempting to disrupt the system. Byzantine Fault Tolerance determines the validity of transactions through message passing and voting mechanisms between nodes, ensuring system consistency and security even with a certain number of malicious nodes, provided that a majority of nodes reach a consensus.

[0111] It should be noted that in practical applications, the correspondence between event types and consensus mechanisms can be adjusted and optimized according to the actual situation. For example, as blockchain application scenarios continue to expand and technology continues to advance, new event types and more suitable consensus mechanisms may emerge. At the same time, different industries and business needs may also impose different requirements on the correspondence between event types and consensus mechanisms. For instance, in the financial industry, blockchain events involving large-scale transactions may have extremely high security requirements. Even if the event is an intra-group event, a more stringent and secure consensus mechanism may be adopted, such as adding multi-factor authentication and auditing mechanisms to the composite verification consisting of PoS and PoW verification.

[0112] Furthermore, in dynamic blockchain systems, the characteristics of events may change over time. For example, a blockchain event that initially belongs to a low-security group may change its security requirements and frequency of occurrence as business develops and data importance increases, leading to a change in event type. In such cases, the system needs to monitor and identify these changes in a timely manner and dynamically adjust the consensus mechanism adopted to ensure the security and efficiency of the entire blockchain system.

[0113] S30. A consensus is reached on the blockchain event according to the consensus mechanism.

[0114] Specifically, the consensus process involves interaction and data verification between terminal devices. For lightweight Proof-of-Stake (PoS) verification, when the blockchain network receives an event within a low-security group, each terminal device competes for the right to record transactions based on its stake. Terminal devices with more stake have a higher probability of obtaining the right to record transactions. Once a terminal device obtains the right, it packages the event into a new block and broadcasts the block information to other terminal devices in the network. Other terminal devices, upon receiving the block information, verify it, including the legality of the event and the integrity of the data. If a predetermined number of terminal devices pass the verification, the block is added to the blockchain, completing the consensus for the event within the low-security group.

[0115] For the combined verification of PoS and PoW, when processing events within a high-security group, PoS verification first filters out eligible terminal devices that hold certain stakes to compete for the right to record transactions. Then, these eligible terminal devices compete for the final right to record transactions through extensive hash calculations using PoW verification. The terminal device that wins the right to record transactions packages the event into a block and broadcasts it. Other nodes also rigorously verify the block, checking not only the legality and integrity of the event itself but also the correctness of the PoS and PoW verification processes. Only after a predetermined number of terminal devices have passed verification is the block added to the blockchain to ensure the security and data consistency of events within the high-security group.

[0116] Byzantine fault-tolerant verification, when handling cross-group events, involves interactions between different coordinating device groups, a large number of terminal devices, and relatively low trust levels, making the consensus process more complex. When a cross-group event is received, the terminal devices broadcast the event information, and message passing and voting occur among them. Each terminal device votes based on the received information and its own judgment, indicating whether the event is valid. During the voting process, even if a certain number of malicious nodes attempt to send incorrect information or interfere with the voting results, as long as a predetermined number of honest terminal devices reach a consensus, the validity of the event can be determined. Once the event is determined to be valid, the corresponding block is added to the blockchain, ensuring the consistency and security of cross-group events in complex network environments.

[0117] Furthermore, in practical applications, to reduce consensus energy consumption, a two-layer verification mode can be adopted when reaching consensus on the blockchain event according to the aforementioned consensus mechanism. This two-layer verification mode includes device-level consensus and gateway-level consensus. That is, each collaborative device group includes several terminal devices and one gateway device. The terminal devices are used to execute device-level consensus, and the gateway device is used to execute gateway-level consensus. In other words, this application breaks down the consensus process for the blockchain event according to the aforementioned consensus mechanism into device-level consensus run by the terminal devices and gateway-level consensus run by the gateway device, achieving consensus on the blockchain event through the collaboration of device-level consensus and gateway-level consensus.

[0118] In one implementation, such as Figure 9 As shown, the consensus process for the blockchain event according to the consensus mechanism specifically includes: S31. Perform device-level consensus on the blockchain event according to the consensus mechanism corresponding to the blockchain event; S32. Determine whether the blockchain event requires gateway-level consensus based on the event type; S33. When a blockchain event requires gateway-level consensus, the blockchain event is subjected to gateway-level consensus through a gateway device according to the consensus mechanism corresponding to the blockchain event.

[0119] Specifically, the consensus process executed by device-level consensus matches the consensus mechanism corresponding to the blockchain event. For low-security intra-group events, device-level consensus is used for lightweight PoS verification. For high-security intra-group events, device-level consensus is used for PoS verification, where terminal devices select a validator based on reputation score and remaining battery power. This validator signs and confirms the blockchain event, and consensus is considered achieved when a preset threshold within the group (e.g., more than 2 / 3 of the validators agree). For cross-group events, device-level consensus is used for intra-group pre-verification, which can use PoS verification or a composite PoS+PoW verification. Specifically, during PoS verification by device-level consensus, the validator terminal device is selected based on reputation score and remaining battery power, with the selection probability of the validator terminal device being: , in, Indicates collaborative device group Terminal devices in The probability of choosing, Indicates terminal device Reputation points, Indicates terminal device Credit score, Indicates collaborative device group The set of device serial numbers, Indicates terminal device The remaining power of the device Indicates terminal device The remaining battery power of the device.

[0120] Furthermore, in practical applications, the credit score is updated, and the update process can be represented as follows: , in, This indicates the updated credit score. This indicates the credit score before the update. Indicates the update time interval. This represents the online time reward coefficient. Indicates the number of errors. This represents the penalty coefficient for incorrect behavior.

[0121] Furthermore, after device-level consensus, the need for gateway-level consensus is determined based on the event type. Since events within low-security groups use lightweight PoS verification, which is already executed at the device-level consensus stage, gateway-level consensus is unnecessary. For events within high-security groups and cross-group events, gateway-level consensus is required. For high-security group events, gateway-level consensus is used for PoW anchoring; for cross-group events, it is used for Byzantine Fault Tolerance (BFT) verification.

[0122] This application executes device-level consensus authentication through device terminals and gateway-level consensus through gateway devices. In this way, device terminals achieve dynamic energy consumption allocation through weighted random election (low-power devices are demoted); the gateway device audits key events. The global energy consumption of this two-layer authentication mode is only 3% of that of traditional PoW, while inheriting its resistance to 51% attacks, which greatly reduces the energy consumption of the distributed terminal system.

[0123] In one embodiment, when a cross-group event occurs, state synchronization across collaborative device groups is required. Therefore, when the event type is a cross-group event, such as... Figure 10 As shown, the low-energy consensus method for distributed terminal collaboration further includes: S41. Obtain the hash commitments of each collaborative device group in the distributed terminal cluster; S42. Aggregate all the obtained state commitments to obtain an aggregate signature; S43. Distribute the aggregated signature and hash commitment to the collaborative device group so that the collaborative device group can verify based on the aggregated signature to synchronize the state within the distributed terminal cluster.

[0124] Specifically, the coordinating device group reaches a consensus based on state information, and then generates a hash commitment based on this consensus. This hash commitment includes the state information of the coordinating device group and a random number to ensure the integrity and immutability of the group's state information, thus ensuring the reliability of subsequent verification and synchronization operations based on these hash commitments. The hash commitment can be represented as: , in, Indicates hash commitment, Indicates status information, Represents a random number. This represents a hash function.

[0125] After obtaining all hash commitments, they are aggregated to obtain an aggregate signature. This aggregate signature is used to verify the consistency and correctness of the state information of all cooperating device groups. The generation of the aggregate signature can employ advanced cryptographic algorithms, such as elliptic curve cryptography-based aggregate signature algorithms, which can improve the efficiency of signature aggregation while ensuring security.

[0126] For example, an aggregate signature can be represented as: , in, Indicates aggregate signature, This indicates the aggregated signature private key. This means concatenating all hash commitments. Indicates the number of collaborative device groups.

[0127] Furthermore, when distributing the aggregated signature and hash commitment to the collaborating device groups, the aggregated signature and the hash commitments of all groups are packaged into a lightweight synchronization proof and broadcast to all other shards in the blockchain network to achieve shard broadcasting, reducing traffic to 1 / K (where K is the number of groups) of traditional blockchains. The synchronization proof can be represented as: , in, This indicates simultaneous proof.

[0128] Then, after receiving the synchronization proof, each coordinating device group will verify it based on the aggregate signature and hash commitment contained in the synchronization proof. For example, Figure 11 As shown, the verification process for the same device group based on the aggregated signature may include: S431. Verify the aggregated signature; S432. When the aggregated signature verification passes, the hash commitment stored by the collaborative device group is compared with the hash commitment received by the collaborative device group. S433. If the two hash commitments are consistent, the verification is considered successful.

[0129] Specifically, verifying the aggregated signature refers to verifying the validity of the aggregated signature using the public key of the aggregation gateway. After the validity of the aggregated signature is verified, the hash commitment of itself (i.e., the hash commitment of itself received by the collaborative device group) is found in the synchronization proof. Then, the found hash commitment of itself is compared with the hash commitment of itself stored in the collaborative device group to verify the consistency of the two hash commitments. When the two hash commitments are consistent, the verification is deemed to be successful.

[0130] In one embodiment, to further reduce energy consumption, device power can be dynamically managed during communication between terminal devices. Based on this, such as... Figure 12 As shown, the low-energy consensus method for distributed terminal collaboration further includes: N11. Obtain the equivalent distance between the current terminal device and the target terminal device; N12. Determine the radio frequency transmission power for the current communication between the current terminal device and the target terminal device based on the equivalent distance, and control the current terminal device to communicate according to the radio frequency transmission power.

[0131] Specifically, the equivalent distance is used to reflect the communication distance between the current terminal device and the target terminal device. Since the terminal device maintains its own device location, the equivalent distance between the current terminal device and the target terminal device can be determined based on their respective device locations. For example, the equivalent distance can be the Euclidean distance between the current terminal device and the target terminal device.

[0132] After obtaining the equivalent distance, the radio frequency (RF) transmit power for the current communication between the current terminal device and the target terminal device is determined based on this equivalent distance. The process of determining the RF transmit power can be expressed as follows: , in, Indicates radio frequency transmit power. Indicates the lowest frequency transmission power. Indicates the adjustment factor. Indicates the current device location of the terminal device. Indicates the device location of the target terminal device. Indicates the minimum distance. Indicates the maximum distance.

[0133] In one embodiment, to further improve the reduction of system energy consumption, such as Figure 13 As shown, the low-energy consensus method for distributed terminal collaboration further includes: N21. Monitor the rate of change of the queue length of the blockchain event queue of terminal devices in the distributed terminal cluster; N22. Adjust the sleep time of the terminal device based on the rate of change of the queue length.

[0134] Specifically, the queue length change rate refers to the change in the length of the blockchain event queue per unit of time. By monitoring the queue length change rate of the blockchain event queues of each terminal device in the distributed terminal cluster, the workload of each terminal device can be understood. When the queue length change rate is low, it means that the terminal device is currently experiencing low workload and is in a relatively idle state. In this case, the sleep time of the terminal device can be appropriately extended to reduce unnecessary energy consumption. For example, if the queue length of a certain terminal device hardly changes or grows very slowly over a period of time, its sleep time can be extended from the original 10 minutes to 20 minutes.

[0135] Conversely, a high rate of change in queue length indicates that the terminal device is experiencing heavy workload and is in a busy operating state. In this case, it is necessary to shorten the sleep time of the terminal device to ensure that it can handle the increasing number of blockchain events in a timely manner and guarantee the efficient operation of the system. For example, when the queue length of a terminal device increases sharply in a short period of time, and the rate of change in queue length far exceeds the preset normal range, its sleep time should be shortened from the original 20 minutes to 5 minutes.

[0136] To more precisely adjust the sleep time of terminal devices, different queue length change rate ranges can be preset, and appropriate sleep time adjustment strategies can be set for each range. For example, when the queue length change rate is between 0-5%, the sleep time can be extended by 30%; when the queue length change rate is between 5%-20%, the current sleep time can be kept unchanged; and when the queue length change rate exceeds 20%, the sleep time can be shortened by 50%.

[0137] In one embodiment, the formula for calculating the hibernation time can be: , in, Indicates the hibernation time. Indicates the maximum sleep time. Indicates the rate of change of queue length. Indicates the length of the blockchain event queue. and This indicates the device type parameter.

[0138] This application embodiment, by adjusting the sleep time of the terminal device based on the queue length change rate, can dynamically adjust the energy consumption of the terminal device according to the actual business situation, avoid the terminal device consuming too much energy when idle, and at the same time ensure that the system performance is not affected when business is busy, thereby further improving the energy utilization efficiency of the distributed terminal collaborative system and reducing the overall energy consumption.

[0139] Based on the above-described low-energy consensus method for distributed terminal collaboration, this embodiment provides a computer-readable storage medium having computer-readable program instructions (i.e., computer programs) stored thereon. The computer-readable program instructions are used to execute the low-energy consensus method for distributed terminal collaboration in the above embodiment.

[0140] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system or device, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, and portable compact disk read-only memory (CD-ROM). ROM: CD Read-only memory, optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in connection with an instruction execution system or device. The program code contained on the computer-readable storage medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (Radio Frequency), etc., or any suitable combination thereof.

[0141] The aforementioned computer-readable storage medium may be included in an electronic device or may exist independently without being assembled into an electronic device.

[0142] The aforementioned computer-readable storage medium carries one or more programs. When the aforementioned one or more programs are executed by an electronic device, they respond to a pending transaction, obtain the transaction type of the pending transaction, determine the consensus mechanism of the blockchain event based on the transaction type, and reach a consensus on the pending transaction according to the consensus mechanism.

[0143] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0144] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0145] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0146] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the aforementioned low-power consensus method for distributed terminal collaboration, thereby solving the technical problem of poor application performance. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the low-power consensus method for distributed terminal collaboration provided in the above embodiments, and will not be repeated here.

[0147] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the low-power consensus method for distributed terminal collaboration as described above.

[0148] The computer program product provided in this application can solve the technical problem of poor application performance. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the low-energy consensus method for distributed terminal collaboration provided in the above embodiments, and will not be repeated here.

[0149] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A low-energy consensus method for distributed terminal collaboration, characterized in that, The low-energy consensus method for distributed terminal collaboration specifically includes: Respond to a blockchain event and obtain the event type of the blockchain event; The consensus mechanism for the blockchain event is determined based on the event type. The blockchain event is agreed upon according to the consensus mechanism described above.

2. The low-energy consensus method for distributed terminal collaboration according to claim 1, characterized in that, The specific event types for obtaining the blockchain event include: Obtain the security level and frequency of blockchain events; The security score of the blockchain event is determined based on the event security level and the frequency of occurrence. The event type of the blockchain event is determined based on the security score.

3. The low-energy consensus method for distributed terminal collaboration according to claim 2, characterized in that, Before obtaining the event security level and occurrence frequency of the blockchain event, the method further includes: Obtain the event attributes of the blockchain event, including intra-group events or cross-group events; When the event attribute is an intra-group event, the steps of obtaining the event security level and occurrence frequency of the blockchain event are executed; When the event attribute is a cross-group event, the event type of the blockchain event is set to cross-group event.

4. The low-energy consensus method for distributed terminal collaboration according to claim 3, characterized in that, When the event attribute is an intra-group event, the process of obtaining the event security level of the blockchain event specifically includes: The security requirements for obtaining the blockchain event; The event security level of the blockchain event is determined based on the aforementioned security requirements.

5. The low-energy consensus method for distributed terminal collaboration according to claim 1, characterized in that, The method further includes: Before responding to blockchain events, the distributed terminal cluster is divided into several coordinating device groups.

6. The low-energy consensus method for distributed terminal collaboration as described in claim 1, characterized in that, The method further includes: When responding to blockchain events, the distributed terminal cluster is divided into several coordinating device groups.

7. The low-energy consensus method for distributed terminal collaboration according to claim 5 or 6, characterized in that, The specific steps of dividing the distributed terminal cluster into several coordination device groups include: Obtain status data of terminal devices in a distributed terminal cluster; Based on the status data, the distributed terminal cluster is collaboratively grouped to obtain several collaborative device groups.

8. The low-energy consensus method for distributed terminal collaboration according to claim 7, characterized in that, The status data includes at least the device location and remaining battery power, and may also include device resources and / or device network quality.

9. The low-energy consensus method for distributed terminal collaboration according to claim 8, characterized in that, The specific steps of collaboratively grouping the distributed terminal cluster based on the status data to obtain several collaborative device groups are as follows: Based on the status data, the distributed terminal cluster is collaboratively grouped using fuzzy decision tree clustering to obtain several collaborative device groups.

10. The low-energy consensus method for distributed terminal collaboration according to claim 5 or 6, characterized in that, In the process of dividing the distributed terminal cluster into several coordinating device groups, a preset number is used as a grouping constraint so that the difference between the number of devices in each coordinating device group and the preset number is within a preset range.

11. The low-energy consensus method for distributed terminal collaboration according to claim 1, characterized in that, The event types include events within low-security groups, events within high-security groups, and cross-group events.

12. The low-energy consensus method for distributed terminal collaboration according to claim 11, characterized in that, The consensus mechanism for determining the blockchain event based on the event type specifically includes: When the event type is an event within a low-security group, the consensus mechanism is lightweight PoS verification; When the event type is an event within a high-security group, the consensus mechanism is a composite verification consisting of PoS verification and PoW verification. When the event type is a cross-group event, the consensus mechanism is Byzantine fault tolerance verification.

13. The low-energy consensus method for distributed terminal collaboration according to claim 1, characterized in that, The specific steps of reaching consensus on the blockchain event according to the consensus mechanism include: The blockchain event is subject to device-level consensus according to the consensus mechanism corresponding to the blockchain event. Determine whether the blockchain event requires gateway-level consensus based on the event type; When a blockchain event requires gateway-level consensus, the blockchain event is subjected to gateway-level consensus through a gateway device according to the consensus mechanism corresponding to the blockchain event.

14. The low-energy consensus method for distributed terminal collaboration according to claim 1, characterized in that, The method further includes: Obtain the equivalent distance between the current terminal device and the target terminal device; Based on the equivalent distance, the radio frequency transmission power for the current communication between the current terminal device and the target terminal device is determined, and the current terminal device is controlled to communicate according to the radio frequency transmission power.

15. The low-energy consensus method for distributed terminal collaboration according to claim 1, characterized in that, The method further includes: Monitor the rate of change of the queue length of the blockchain event queue of terminal devices in a distributed terminal cluster; The sleep time of the terminal device is adjusted based on the rate of change of the queue length.

16. The low-energy consensus method for distributed terminal collaboration according to claim 1, characterized in that, When the event type is a cross-group event, the method further includes: Obtain the hash commitments of each collaborative device group in the distributed terminal cluster; Aggregate all the obtained state commitments to obtain an aggregate signature; The aggregated signature and hash commitment are distributed to the collaborative device group so that the collaborative device group can verify based on the aggregated signature to synchronize the state within the distributed terminal cluster.

17. The low-energy consensus method for distributed terminal collaboration according to claim 16, characterized in that, The verification process based on the aggregated signature includes: The aggregated signature is verified; When the aggregate signature verification passes, the hash commitment stored by the collaborative device group is compared with the hash commitment received by the collaborative device group. If the two hash commitments match, the verification is considered successful.

18. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores one or more programs, which can be executed by one or more processors to implement the steps in the low-power consensus method for distributed terminal collaboration as described in any one of claims 1 to 17.

19. An electronic device, characterized in that, include: Processor and memory; The memory stores a computer-readable program that can be executed by the processor; When the processor executes the computer-readable program, it implements the steps in the low-power consensus method for distributed terminal collaboration as described in any one of claims 1 to 17.

20. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the low-power consensus method for distributed terminal collaboration as described in any one of claims 1 to 17.

Images