A blockchain-based information collection method and device, electronic equipment and medium

Abstract

Embodiments of the present application provide a kind of information collection method, device, electronic equipment and storage medium based on blockchain, the method includes: after receiving the collection template class proposal for one or more devices, the collection node cluster in blockchain can first generate target block according to collection template class proposal, collection template class proposal includes multiple collection instruction sets for different devices;Then, according to the collection template class proposal, the information of one or more devices is collected;Wherein, in the process of collecting the information of one or more devices, based on multiple collection instruction sets, interactive command is sent to one or more devices. Multiple collection instruction sets for different devices are written in the proposal of upper chain in advance, and the blockchain can automatically collect the information of devices of different manufacturers and different network layers based on multiple collection instruction sets in the proposal, without sending interactive command of different instruction sets to the device by the user one by one to collect information.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and in particular to a blockchain-based information collection method, apparatus, electronic device, and medium. Background Technology

[0002] Currently, the operation, maintenance, and interactive operation of operator data communication equipment are mostly based on establishing a session through SSH remote connection, and then using shell command-line statements developed by the manufacturer to view device information or remotely configure the device's operating protocol through remote interaction.

[0003] The interaction commands of data communication devices from different manufacturers and at different network layers can vary significantly. As technology advances, the differences and diversity of instruction sets between manufacturers and devices will increase in the future. Operators' back-end maintenance personnel can only configure and operate devices by manually entering command lines one by one into the shell, which is both time-consuming and labor-intensive.

[0004] For example, when analyzing operational data, it is often necessary to record and statistically analyze the parameter values ​​of a batch of devices in a certain scenario. If the hardware device manufacturer does not store the parameter values ​​in advance, it is necessary to manually log in to the device and periodically and repeatedly enter the corresponding instruction set commands to view the parameters, which makes it very difficult to analyze business trend data based on the time dimension on the device. Summary of the Invention

[0005] In view of the above problems, a blockchain-based information collection method, apparatus, electronic device, and storage medium are proposed to overcome or at least partially solve the above problems, including:

[0006] A blockchain-based information collection method is applied to a cluster of collection nodes in a blockchain, wherein the cluster of collection nodes is used to collect information from one or more devices, and the method includes:

[0007] Receive collection template class proposals for one or more devices, and generate target blocks based on the collection template class proposals, wherein the collection template class proposals include multiple collection instruction sets for different devices;

[0008] Based on the proposed template, information is collected from the one or more devices.

[0009] During the information collection process of the one or more devices, interactive commands are sent to the one or more devices based on the multiple collection instruction sets.

[0010] This invention also provides a blockchain-based information collection device applied to a collection node cluster in a blockchain. The collection node cluster is used to collect information from one or more devices. The device includes:

[0011] The receiving module is used to receive collection template class proposals for one or more devices, and generate target blocks according to the collection template class proposals, wherein the collection template class proposals include multiple collection instruction sets for different devices;

[0012] The data acquisition module is used to acquire information from one or more devices based on the data acquisition template class proposal; wherein, during the data acquisition process, interactive commands are sent to one or more devices based on the multiple data acquisition instruction sets.

[0013] This invention also provides an electronic device, including a processor, a memory, and a computer program stored in the memory and capable of running on the processor. When the computer program is executed by the processor, it implements the above-described blockchain-based information collection method.

[0014] This invention also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the blockchain-based information collection method described above.

[0015] The embodiments of the present invention have the following advantages:

[0016] In this embodiment of the invention, after receiving a collection template proposal for one or more devices, the collection node cluster in the blockchain can first generate a target block based on the collection template proposal, which includes multiple collection instruction sets for different devices. Then, information is collected from one or more devices according to the collection template proposal. During the information collection process, interactive commands are sent to one or more devices based on the multiple collection instruction sets. This embodiment of the invention enables the pre-writing of multiple collection instruction sets for different devices into the on-chain proposal. Therefore, the blockchain can automatically collect information from devices of different manufacturers and network layers based on these multiple collection instruction sets, eliminating the need for users to send interactive commands with different instruction sets to each device individually, thus improving information collection efficiency. Attached Figure Description

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

[0018] Figure 1 This is a flowchart illustrating the steps of a blockchain-based information collection method according to an embodiment of the present invention.

[0019] Figure 2 This is a schematic diagram of the structure of a target block according to an embodiment of the present invention;

[0020] Figure 3 This is a flowchart illustrating the steps of another blockchain-based information collection method according to an embodiment of the present invention.

[0021] Figure 4a This is a schematic diagram of a template-based proposal collection embodiment of the present invention;

[0022] Figure 4b This is a schematic diagram of a data collection task completion identifier proposal according to an embodiment of the present invention;

[0023] Figure 5 This is a schematic diagram of an instruction set template table InstructList according to an embodiment of the present invention;

[0024] Figure 6 This is a schematic diagram of a consensus process according to an embodiment of the present invention;

[0025] Figure 7 This is a flowchart of the process of collecting proposal consensus on the blockchain and collecting data according to an embodiment of the present invention;

[0026] Figure 8 This is a flowchart of a smart contract logic according to an embodiment of the present invention;

[0027] Figure 9 This is a schematic diagram illustrating the data acquisition time of different strategies under the same experimental equipment performance according to an embodiment of the present invention.

[0028] Figure 10 This is a schematic diagram illustrating the number of blocks collected using different strategies under the same experimental equipment performance according to an embodiment of the present invention.

[0029] Figure 11 This is a schematic diagram of the acquisition time of different strategies under the delay(1) parameter of experimental device A in an embodiment of the present invention;

[0030] Figure 12This is a schematic diagram of the number of blocks collected under different strategies under the delay(1) parameter of experimental device A in an embodiment of the present invention;

[0031] Figure 13 This is a schematic diagram of the acquisition time of different strategies under the delay(5) parameter of an experimental device A in an embodiment of the present invention;

[0032] Figure 14 This is a schematic diagram of the number of blocks collected under different strategies under the delay(5) parameter of an experimental device A according to an embodiment of the present invention;

[0033] Figure 15 This is a schematic diagram showing the acquisition time of different strategies under the delay(10) parameter of experimental device A in an embodiment of the present invention;

[0034] Figure 16 This is a schematic diagram of the number of blocks collected under different strategies under the delay(10) parameter of experimental device A in an embodiment of the present invention;

[0035] Figure 17 This is a structural block diagram of a blockchain-based information collection device according to an embodiment of the present invention. Detailed Implementation

[0036] To make the above-mentioned objects, features, and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0037] With the continuous development of networks, operators need to manage an ever-growing number of data communication devices. However, there is a lack of good integration functions and shared interfaces between different equipment manufacturers. The only unified login interface is a command-line shell remote login interface based on SSH (Secure Shell protocol).

[0038] However, because the configuration and command lines for viewing different equipment models and manufacturers are generally different, the operations department cannot perform batch command-line shell script operations across different equipment types when operating on data communication equipment (equipment used in a new communication method combining communication and computer technologies. The transmission channel connects data terminals to computers, enabling data terminals in different locations to share software, hardware, and information resources).

[0039] Furthermore, the operations department often needs to monitor and analyze the trends of certain essential parameters of the equipment over a long period of time. If the hardware manufacturer does not collect and store these parameters, the only way to collect them is to manually log in to the command line of the equipment at regular intervals and manually record important parameters, which greatly increases the workload.

[0040] To address the lack of a unified self-service data collection interface and the inconsistencies in data collection instructions between devices, this invention provides a data collection method based on a cross-device instruction set template for self-designing interfaces.

[0041] The client program can provide device operators with the function of designing operation templates for the instruction set of the data collection process. Users only need to provide a set of instruction set collection scripts that they want to execute for the same type of device (the instruction set is a hardware program stored inside the CPU (Central Processing Unit) that guides and optimizes the CPU operation), and mark the parameters to be collected through the interface, provide the list of device IPs (Internet Protocol) and ports to be operated in batches, as well as the collection time and collection cycle. The client will automatically package and organize various instruction set device models, as well as the corresponding multiple collection instruction set scripts and collection task lists into a proposal and send it to the remote node to wait for consensus and on-chain processing.

[0042] Reference Figure 1 The diagram illustrates a flowchart of a blockchain-based information collection method according to an embodiment of the present invention. This method can be applied to a collection node cluster in a blockchain, and the collection node cluster can be used to collect information from one or more devices.

[0043] Specifically, it may include the following steps:

[0044] Step 101: Receive a collection template class proposal for one or more devices, and generate a target block based on the collection template class proposal. The collection template class proposal includes multiple collection instruction sets for different devices.

[0045] The target block can refer to the storage entity on the blockchain. Each collection node in the collection node cluster can redundantly store all historical blocks in order to trace the historical information of the blockchain.

[0046] like Figure 2 The target block can include two parts: a block header and other information. The block header can include: the parent block hash value, the view number, the Merkle tree root, the block timestamp, and the block initiator's public key. The other information can include: the block ID, digital signature, the number of proposals, and the proposal list.

[0047] Among them, the parent block hash value can be the hash value of the previous block; the view number can include the number of malicious collection nodes in the collection node cluster; the Merkle root can be used to quickly summarize and verify the existence and integrity of block data; the block timestamp can include time information for the target block; the block initiator public key can refer to the public key information corresponding to the initiator of the block; the block ID can refer to the ID of the target block; the digital signature can be a valid proof of the authenticity of the information sent by the sender; the number of proposals can refer to the number of proposals included in the target block; and the proposal list can refer to the collection template type proposals included in the target block.

[0048] When it is necessary to collect information (e.g., device operating parameters) from one or more devices, the operation of generating target blocks can be performed on the target client first. Specifically, since different devices may need to use different collection instruction sets, one or more corresponding collection instruction sets can be generated for one or more devices that need to collect information.

[0049] Then, the target client can package one or more collection instruction sets into a collection template class proposal and upload it to any collection node in the collection node cluster. Specifically, users can edit different collection instruction sets through the target client to obtain collection task templates; at the same time, they can also select a list of devices to execute collection tasks, attach the total execution time and interval of collection tasks, as well as the collection task description and basic information of the collection user account.

[0050] Then, the target client can package the collection task template, device list, total execution time, collection task execution interval, collection task description, and basic information of the collection user account into a collection template class proposal, and upload it to any collection node in the collection node cluster.

[0051] After receiving the collection template proposal, the collection node can package it into a target block; of course, the collection node can also package multiple collection template proposals received within a period of time into a target block, and this embodiment of the invention does not limit this.

[0052] After packaging the collection template proposal into a target block, the collection node can wait for the polling mechanism to reach the collection node and then upload the target block to the consensus cluster, so that the consensus cluster can automatically collect information from one or more devices based on one or more collection instruction sets.

[0053] Step 102: Collect information from one or more devices according to the collection template class proposal; wherein, during the information collection process of one or more devices, interactive commands are sent to one or more devices based on multiple collection instruction sets.

[0054] After the target block is uploaded to the blockchain, each collection node in the collection node cluster can store the target block; then, each collection node can collect information from one or more devices based on the collection template proposal in the target block.

[0055] During the information collection process, devices from different manufacturers and at different network layers use different interaction commands. In order to automatically collect information from different devices, the collection node cluster can send interaction commands to different devices based on multiple collection command sets. This allows the collection node cluster to collect information from devices from different manufacturers and at different network layers based on multiple collection command sets.

[0056] In this embodiment of the invention, after receiving a collection template proposal for one or more devices, the collection node cluster in the blockchain can first generate a target block based on the collection template proposal, which includes multiple collection instruction sets for different devices. Then, information is collected from one or more devices according to the collection template proposal. During the information collection process, interactive commands are sent to one or more devices based on the multiple collection instruction sets. This embodiment of the invention enables the pre-writing of multiple collection instruction sets for different devices into the on-chain proposal. Therefore, the blockchain can automatically collect information from devices of different manufacturers and network layers based on these multiple collection instruction sets, eliminating the need for users to send interactive commands with different instruction sets to each device individually, thus improving information collection efficiency.

[0057] Reference Figure 3 The diagram illustrates a flowchart of another blockchain-based information collection method according to an embodiment of the present invention, which may include the following steps:

[0058] Step 301: Receive collection template class proposals for one or more devices, and generate target blocks based on the collection template class proposals.

[0059] As an example, a cluster of data acquisition nodes can include multiple data acquisition nodes, each of which can be used to collect information from one or more devices.

[0060] When it is necessary to collect information (e.g., device operating parameters) from one or more devices, the operation of generating target blocks can be performed on the target client first. Specifically, since different devices may need to use different collection instruction sets, one or more corresponding collection instruction sets can be generated for one or more devices that need to collect information.

[0061] Then, the target client can package one or more collection instruction sets into a collection template class proposal and upload it to any collection node in the collection node cluster. After receiving the collection template class proposal, the collection node can package it into a target block; or it can package multiple collection template class proposals received within a period of time into a target block. This embodiment of the invention does not limit this.

[0062] After packaging the collection template proposal into a target block, the collection node can wait for the polling mechanism to reach the collection node and then upload the target block to the consensus cluster, so that each collection node in the consensus cluster can automatically collect information from one or more devices based on one or more collection instruction sets.

[0063] As an example, each block can store several proposals; in this embodiment of the invention, there can be two types of proposals: collection template proposals and collection task end marker proposals; collection template proposals can be used to advance collection tasks; collection task end marker proposals can be used to end a collection template proposal and advance the collection task of the next collection template proposal when all collection tasks under a collection template proposal are completed.

[0064] like Figure 4a The diagram illustrates a template-based proposal collection method according to an embodiment of the present invention.

[0065] The collection template class proposal can include collection tasks uploaded by the target client to the collection node cluster; a collection template class proposal can include a basic information class, a collection task description class, and a collection task details class.

[0066] The basic information class may include: the account information of the proposal initiator and the name of the entity collecting the proposal (instructor_name).

[0067] The data collection task description class may include: data collection task period NumGap, total data collection task duration NumHours, data collection task segmentation rule CurtorRuler, total data collection task quantity MissionMeasure, data collection task allocation probability dictionary table MissionAssigner, and data collection task list allocation dictionary table MissionDict.

[0068] The data collection task details class may include: the data collection task list table TargetList and the data collection instruction set template table InstructList.

[0069] In the basic information category of entity proposals:

[0070] The proposal initiator's account information can record the collection login account information used by the initiator, which is used by the collection nodes to map and manage the account and its operation permissions after it is uploaded to the chain;

[0071] The entity name of the collection proposal, instructor_name, records the name (string) obtained by the target client for the collection task.

[0072] In the task description class:

[0073] The NumGap data collection task period records the execution interval (in minutes) of the data collection task.

[0074] Total task duration NumHours: Records the duration of task execution (Hours);

[0075] The task splitting rules of the data collection system are recorded by CurorRuler after being uploaded to the blockchain. 1 represents the average distribution of data collection tasks according to the number of data collection nodes on the blockchain; 2 represents the distribution of data collection tasks based on the hardware and software score weights of the data collection nodes, combined with the historical data collection proposals on the blockchain and the smart contract rules.

[0076] MissionMeasure records the total number of tasks collected from the proposal entity task list.

[0077] MissionAssigner: This dictionary table represents the probability of assigning tasks to each collection node based on the task segmentation rules (CutorRuler) in the task list (TargetList). Later, the blockchain's smart contracts will use this MissionAssigner to randomly assign tasks to various collection nodes for collection work.

[0078] The task allocation dictionary table MissionDict is used to allocate tasks in the task allocation list table TargetList based on the task allocation probability dictionary table MissionAssigner and the pseudo-random number BlockSeed that is uniform across the cluster of collection nodes, thus obtaining the task allocation list table MissionDict for each collection node.

[0079] In the data collection task details class:

[0080] The TargetList table records a list of devices that need to perform data collection tasks. The list includes the device IP address and corresponding inspection parameters (such as port number, board number, PON (Passive Optical Network) port number, etc.).

[0081] The data acquisition instruction set template table `InstructionList` records the data acquisition instruction set corresponding to each device model in the data acquisition task, as well as the regular expression for the corresponding information to be extracted from the data acquisition process.

[0082] like Figure 5 The diagram illustrates a sample instruction set template table, InstrumentList, according to an embodiment of the present invention. The sample instruction set template table, InstrumentList, may include sample instruction sets for Device Type-1 and sample instruction sets for Device Type-2.

[0083] The collection instruction set for Device Type-1 can include Instruction 1 and Instruction 2; Instruction 1 and Instruction 2 can include information such as SendCode, Collection List ZZStringList, Custom SendC DIYpart, and Device Type.

[0084] The collection instruction set for Device Type-1 can include Instruction 1 and Instruction 2; Instruction 1 and Instruction 2 can include information such as SendCode, Collection List ZZStringList, Custom SendC DIYpart, and Device Type.

[0085] like Figure 4b The diagram illustrates a proposal for a data acquisition task completion identifier according to an embodiment of the present invention.

[0086] To enable on-chain smart contract functionality based on performance self-balancing data collection tasks, a data collection task completion flag class proposal with a data collection completion tag is packaged and submitted to the on-chain consensus when the data collection task is completed.

[0087] The information in a data collection task completion marker proposal can include basic information, a data collection task description, and data collection task details.

[0088] The basic information class can include the proposal account initiator information and the name of the entity collecting the proposal (instructor_name).

[0089] The task description class can include FinishFlag (the identifier for the end of the collection), BlockId (the block number where the collection task is located), MissionId (the proposal entity number corresponding to the block), and WorkLoad (the amount of collection tasks undertaken by this collection node).

[0090] The data collection task details class can include the data collection task list table TargetList and the data collection instruction set template table InstructList.

[0091] In the task description class:

[0092] FinishFlag is a single identifier that facilitates quick location of end-of-collection proposals during on-chain tracing.

[0093] BlockId indicates the block number where the data collection task that ended was located;

[0094] MissionId indicates the position of the entity proposal number within the collection task block;

[0095] WorkLoad represents the workload undertaken by this acquisition node (determined by the amount of acquisition tasks it undertakes).

[0096] In one embodiment of the present invention, the following steps may also be included:

[0097] Determine whether the collection template proposal meets the preset conditions; when the collection template proposal meets the preset conditions, execute the step of collecting information from one or more devices based on the collection template proposal; when the collection template proposal does not meet the preset conditions, discard the target block.

[0098] In practical applications, to prevent illegitimate proposals from being made on the blockchain, after receiving a target block, each collection node in the collection node cluster can first determine whether the collection template proposal meets preset conditions. These preset conditions can be used to determine whether the collection template proposal is legitimate, or whether the target client that initiated the collection template proposal has the authority to initiate the collection task corresponding to the collection template proposal.

[0099] As an example, the RBAC (Role-Based Access Control) mechanism can be used to verify the permissions of the collection account and the collection instruction set in the collection template class proposal. Specifically, the role-based access control model RBAC can be embedded in the consensus mechanism of the blockchain to review the permissions of the collection instruction set submitted by the user. If the permissions of the collection account do not match the code of the collection instruction set submitted by the user, the consensus of the consensus cluster cannot be passed, and the collection instruction set in the collection template class proposal cannot be stored and run on the chain, thereby ensuring the security of the collection instructions in the collection template. This embodiment of the invention does not limit this.

[0100] If the collection template proposal is determined to meet the preset conditions, then step 302 can be executed. If the collection template proposal is determined not to meet the preset conditions, then it means that the collection template proposal cannot be stored and run on the chain. At this time, the target block can be discarded and polling can continue to obtain the next block and perform the collection task corresponding to the next block.

[0101] Specifically, the on-chain consensus mechanism of this invention can choose a round-robin PBFT mechanism; the collection nodes participating in the collection also form a consensus cluster as consensus nodes. All operations in the consensus cluster are performed in a view state; each view state has only one master node. Replica nodes consist of three roles: client, master node (leader), and slave node (follower).

[0102] The following are the specific tasks of the three roles in the cluster:

[0103] (1) Client: The initiator of service requests and the initiator of template class proposals.

[0104] (2) Master node: responsible for processing service requests sent by clients, sequentially numbering and packaging the received request information into blocks, and then broadcasting the blocks to other slave nodes, waiting for the consensus cluster to reach a consensus on the service.

[0105] (3) Slave node: Receives the consensus request message from the master node and verifies the information; for example, it can be verified based on the digital signature.

[0106] Assuming the total number of data collection nodes is R, the system assigns each node a number: 0, 1, 2, ..., |R|-1. Based on the PBFT consensus mechanism, assuming a maximum number of malicious nodes f, the relationship between f and R is |R| = 3f + 1.

[0107] Within the consensus cluster, |R| nodes take turns broadcasting blocks to achieve consensus through a polling method.

[0108] The polling formula N = L mod |R| is a modulo operation, where N is the master node number of the next block producer, L is the block number of the current last block in the blockchain, and |R| is the number of nodes in the consensus cluster. Using N = L mod |R|, we know that when the current consensus node is polled, it will package the collected template proposals from this period into a block and broadcast it to all consensus nodes in the cluster for PBFT consensus. If no new template proposals are collected during this period, the consensus node will package an empty block and send it to the cluster consensus chain, thus driving the polling process.

[0109] like Figure 6 The consensus process can be divided into three stages: the pre-preparation stage, the preparation stage, and the confirmation stage. For each block to be stored on the blockchain, more than two-thirds of the consensus nodes in the consensus cluster must agree on the block's legitimacy and correctness. The Leader is the master node, and Follower1, Follower2, Follower3, and Follower4 are slave nodes.

[0110] Pre-preparation phase: The master node participates in assigning a unique number to the request, request-numbern, and broadcasts the request and n together as a pre-prepare message to all members.

[0111] Preparation phase: When all members (backup nodes) receive the pre-prepare message, they check whether the message originated from the master node based on the signature field. If it is correct, they combine the request number and their own signature to form a prepare message and broadcast it to all other members, indicating that they acknowledge the request number and are ready.

[0112] Confirmation Phase: If all nodes receive a prepare message, they check its signature for correctness. If the number of prepare messages exceeds two-thirds of the total number of nodes, the system considers that it has reached a consensus and recognizes the request and request number. The system then broadcasts a commit message to all nodes, indicating that the node can proceed with the request's business logic.

[0113] Step 302: Obtain the data collection task segmentation rules from the data collection template proposal.

[0114] The task segmentation rules can record the rules for segmenting tasks after they are uploaded to the blockchain. For example, the segmentation rules for one or more tasks corresponding to a template proposal. These rules can be set by the user corresponding to the target client, or they can be automatically set by the target client based on the performance of each collection node in the current collection node cluster. This embodiment of the invention does not impose any restrictions on this.

[0115] After receiving the data collection template proposal, the data collection task segmentation rules can be obtained from it, so as to determine which data collection strategy to use to collect information from one or more devices.

[0116] Step 303: Determine the target acquisition strategy for multiple acquisition nodes based on the acquisition task segmentation rules.

[0117] After obtaining the data collection task segmentation rules from the data collection template proposal, the target data collection strategy for each data collection node can be determined based on the information in the data collection task segmentation rules.

[0118] Step 304: According to the target acquisition strategy, information is acquired from one or more devices to generate acquisition task sub-results at each acquisition node; during the information acquisition process from one or more devices, interactive commands are sent to one or more devices based on multiple acquisition instruction sets.

[0119] After determining the target acquisition strategy, each acquisition node in the acquisition node cluster can acquire information from one or more devices according to the target acquisition strategy. When acquiring information from one or more devices, the acquisition node will generate corresponding acquisition task sub-results based on the acquisition results and store them in the acquisition node.

[0120] During the information collection process, devices from different manufacturers and at different network layers use different interaction commands. In order to automatically collect information from different devices, the collection node cluster can send interaction commands to different devices based on multiple collection command sets. This allows the collection node cluster to collect information from devices from different manufacturers and at different network layers based on multiple collection command sets.

[0121] In one embodiment of the present invention, the target acquisition strategy may include an equal distribution strategy and a self-balancing strategy; the equal distribution strategy may refer to the even distribution of all tasks in the acquisition template proposal among the acquisition nodes in the acquisition node cluster; the self-balancing strategy may refer to the distribution of all tasks in the acquisition template proposal according to the performance of each acquisition node in the acquisition node cluster.

[0122] As an example, when the target acquisition strategy is an even distribution strategy, step 304 may include the following sub-steps:

[0123] Sub-step 11: Determine the average number of collection tasks based on the number of collection nodes in the collection node cluster and the number of tasks in the collection template class proposal.

[0124] When the target collection strategy is an even distribution strategy, an average number of collection tasks can be determined based on the number of collection nodes in the collection node cluster and the number of tasks in the collection template class proposal; this average number of collection tasks can be used as the number of collection tasks for each collection node in the collection node cluster.

[0125] Specifically, the formula T = nmodi can be used to assign each collection task n in the collection task list table TargetList to obtain T, and then assign tasks Mn to DT in the collection task list allocation dictionary table MissionDict to obtain the collection task list allocation dictionary table MissionDict.

[0126] TargetList = <M1,M2,M3...,M n >, where n is the number of tasks in TargetList;

[0127] MissionDict= <D1,D2,D3...,D i >, where i is the number of data collection nodes in the data collection node cluster.

[0128] Sub-step 12: Collect information from one or more devices based on the average number of data collection tasks.

[0129] After determining the average number of data collection tasks, each data collection node can collect information from one or more devices based on the average number of data collection tasks; specifically, each data collection node can be assigned a device with an average number of data collection tasks to collect information.

[0130] As another example, when the target acquisition strategy is a self-balancing strategy, step 304 may include the following sub-steps:

[0131] Sub-step 21: Obtain the hardware and software scores for each data acquisition node.

[0132] When the target acquisition strategy is an equal-score strategy, the hardware and software scores of each acquisition node can be obtained first.

[0133] Specifically, the hardware and software score can be divided into two parts, each consisting of a real-number vector of length equal to the number of acquisition nodes. The first part can be the software performance consumption during the acquisition process, represented by the base vector SA; the second part can be the hardware performance score of the acquisition device, represented by the weight vector SD.

[0134] The overall score SF of a data collection node is the Hadamard product of two vectors (radix vector SA and weight vector SD), SA*SD. Let SF = SA*SD.

[0135] After obtaining the hardware and software scores of all acquisition nodes, the scores of all acquisition nodes can be normalized, and the task allocation probability dictionary table MissionAssigner for acquisition devices can be calculated.

[0136] For the cardinality vector SA:

[0137] The consensus initiator of the block will trace back to the _VisionPeriod block on the chain. The _VisionPeriod block can be divided into two parts: the task pool vector HisWorkMeature, which is to be completed, and the task pool vector HisDoneWorkMeature, which is to be completed.

[0138] The task quantity to be completed collection task pool vector HisWorkMeature is obtained by accumulating the final task allocation quantity of each collection node in the MissionDict field of the collection task list allocation dictionary table of all collection template class proposals in the _VisionPeriod block. The completed collection task pool vector HisDoneWorkMeature is obtained by tracing back the completed collection tasks of each collection node in the collection task completion flag class proposals of all collection task blocks in the _VisionPeriod block.

[0139] Finally, HisWorkMeature-HisDoneWorkMeature is used to calculate the vector SMA. The elements in SMA represent the number of acquisition tasks that each acquisition node has not completed in the near future. In order to facilitate later calculations, we want to obtain a cardinality vector of acquisition process performance consumption. The larger the element, the fewer the acquisition tasks to be completed. Therefore, we perform an inverse proportional normalization operation on SMA.

[0140] HisWorkMeature=<HW(1),HW(2),HW(3),....,HW(n)>

[0141] n is the number of collection nodes in the consensus cluster, and HW(n) is the task pool vector HisWorkMeature of the nth collection node.

[0142] HisDoneWorkMeature=<HD(1),HD(2),HD(3),....,HD(n)>

[0143] n is the number of collection nodes in the consensus cluster, and HD(n) is the completed collection task pool vector HisDoneWorkMeature of the nth collection node.

[0144] The formula for calculating SA is as follows:

[0145]

[0146] Where, SMA =<HW(1)-HD(1),HW(2)-HD(2),HW(3)-HD(3),...,HW(n)-HD(n)> .

[0147] Regarding the weight vector SD:

[0148] The main function of the node scoring module is to collect information about the nodes in the network and calculate the hardware performance score of the nodes based on the node's performance parameters (running memory, storage capacity, CPU) using a formula, so as to provide a basis for the allocation of data collection tasks.

[0149] Assuming there are n data collection nodes, and the total score of various performance parameters M across the entire network is 100, the score G(i) of any node i in parameter M is calculated using the following formula:

[0150]

[0151] By calculating the memory score G(i) for each data acquisition node according to the above formula, we can obtain the corresponding memory score G(i). B Storage capacity score G(i) S And the CPU score G(i) C The total score A(i) of the data collection node can be calculated using the following formula:

[0152] A(i)=G(i) B +G(i) S +G(i) C

[0153] Based on the obtained A(i) of all acquisition nodes, the hardware performance score weight vector SD of the acquisition node cluster can be obtained.<A(1),A(2),A(3),...,A(n)> .

[0154] Sub-step 22: Based on the software and hardware scores, determine the task allocation probability dictionary for each acquisition node.

[0155] After obtaining the hardware and software scores of each acquisition node, a probability dictionary for task allocation can be determined for each acquisition node based on the hardware and software scores.

[0156] Specifically, the comprehensive score vector SF of the data acquisition node cluster can be calculated using the following formula:

[0157] SF =<SA(1)*SD(1),SA(2)*SD(2),...,SA(n)*SD(n)>

[0158] Then, the comprehensive score vector SF is normalized using softmax to obtain the task assignment probability dictionary MissionAssigner for each acquisition node:

[0159]

[0160] Sub-step 23: Collect information from one or more devices according to the task allocation probability dictionary.

[0161] After obtaining the task allocation probability dictionary, each consensus node can collect information from one or more devices based on the task allocation probability dictionary.

[0162] In one embodiment of the present invention, sub-step 23 can be implemented in the following manner:

[0163] A random value is determined; based on the random value and the task allocation probability dictionary, tasks are assigned to each acquisition node; multiple acquisition nodes collect information from one or more devices according to their assigned acquisition tasks.

[0164] Specifically, after a template-type proposal passes the consensus mechanism, it can be assigned to the collection tasks in the TargetList collection task list table one by one according to the MissionAssigner collection task allocation probability dictionary table obtained above.

[0165] Each collection node uses the current block's BlockId as a pseudo-random number seed randseed(BlockId), and randomly selects a number between [0,1] for each collection task. The collection node to which the collection task belongs is calculated using the following formula:

[0166] i final ={r>RMA(i)∩r≤RMA(i+1)|1≤i≤n}

[0167] Where r = randseed(BlockSeed); r ∈ (0, 1);

[0168]

[0169] MA represents the MissionAssigner obtained above.

[0170] It should be noted that as long as the pseudo-random number seed of each collection node is the same, the output random number sequence will remain consistent.

[0171] After obtaining the data collection node to which each data collection task belongs, each data collection node can collect information from the corresponding device according to the assigned data collection task.

[0172] After each acquisition node completes its corresponding acquisition task, it can generate a sub-result of the acquisition task and store it in the acquisition node.

[0173] It should be noted that the even distribution strategy, without considering node performance, distributes the data collection task list evenly across the collection nodes for distributed data collection. Compared to traditional data collection methods using data devices, this results in faster task completion. The even distribution strategy is recommended when the performance of the collection nodes is relatively balanced.

[0174] The self-balancing strategy comprehensively considers the hardware and software performance of the data collection nodes, allocating data collection tasks based on the overall hardware and software score of the cluster. Nodes with higher performance scores receive more tasks. Because the performance of nodes in a blockchain data collection cluster can vary significantly, the worst-performing node can negatively impact the overall task execution efficiency when the number of tasks is large. Therefore, the self-balancing strategy is recommended when there are significant performance differences among the data collection nodes. This method can accelerate data collection efficiency when there are large performance variations among the nodes.

[0175] In practical applications, the target client can either actively obtain the sub-results of the collection task from each consensus node in the collection node cluster, or obtain the sub-results of the collection task from each consensus node in the collection node cluster and send them to the target client through the following steps:

[0176] The collection template proposal also includes the total collection task duration, determining the collection task start time; determining the collection task end time based on the collection task start time and the total collection task duration; when the collection task end time is reached, obtaining the collection task sub-results from multiple collection nodes; generating the collection task result based on the collection task sub-results, and returning it to the target client that sent the collection template proposal.

[0177] First, since the template-type proposal includes the total duration of the collection task, the duration of the collection task can be counted at the beginning of the collection task. Once the duration exceeds the preset total duration of the collection task, the sub-results of the collection task can be obtained from each collection node.

[0178] Specifically, you can first determine the start time of the data collection task.

[0179] Then, based on the start time and total duration of the data collection task, determine the end time of the data collection task; for example, if the start time of the data collection task is 12:00:00 on July 1, 2022, and the total duration of the data collection task is 5 hours, then 17:00:00 on July 1, 2022 can be used as the end time of the data collection task.

[0180] When the system time reaches the end time of the data collection task, the sub-results of the data collection task can be obtained from each data collection node.

[0181] As an example, the sub-results of the collection task can be obtained from each collection node after the system time has exceeded the preset time for the collection task to end. This embodiment of the invention does not limit this.

[0182] After obtaining the sub-results of the collection tasks stored in all collection nodes in the collection node cluster, they can be concatenated into a single collection task result and returned to the target client that sent the collection template class proposal.

[0183] like Figure 7 The following is a flowchart illustrating an embodiment of the present invention for collecting proposal consensus on-chain and the collection process:

[0184] First, users edit the data acquisition task templates for different instruction set models through the client, select the list of devices to be acquired, attach the total execution time and interval of the acquisition task, as well as the description of the acquisition task and the basic information of the account used for acquisition.

[0185] Then, the client can package the data collection task template into a data collection template class proposal and upload it to any data collection node. The data collection node processes the packaged data collection template class proposals within a certain period, fills in the block header information to form a block, and waits for the polling mechanism to produce a block. When the data collection node produces a block, it uploads the block containing the data collection template class proposal to the consensus cluster for consensus.

[0186] During the consensus process, the next proposal in the proposal list of the block can be extracted first; then the type of the proposal can be determined.

[0187] If the proposal entity is a data collection task completion marker proposal, the consensus cluster can run a consensus mechanism to determine the legality of the block content (i.e., the data collection task completion marker proposal) (e.g., RBAC mechanism can be used to verify the permissions of the data collection account and the instruction set in the proposal). If it fails, consensus fails, and the block can be discarded. If it succeeds, it can then be determined whether the data collection task completion marker proposal is the last proposal in the block. If so, the block consensus is successful, and it can be stored on the blockchain. If not, the next proposal entity in the block can be retrieved.

[0188] If the proposal entity is a template-type proposal, the consensus cluster can use a formula mechanism to determine the legality of the block content (i.e., the template-type proposal). If it fails, consensus fails, and the block can be discarded. If it passes, the consensus cluster will generate a proposal based on the smart contract: first, determine the strategy corresponding to the collection task partitioning rule CurorRuler; then, allocate collection tasks to each collection node according to the strategy, obtaining the task allocation dictionary table MissionDict (for example, if it is a self-balancing strategy, the random value obtained by using the collection task allocation probability dictionary table MissionAssigner and the current last block number as a pseudo-random seed can be used to randomly calculate the tasks in the collection list table TargetList one by one, and then allocate them to the corresponding collection nodes with reference to the collection task allocation probability dictionary table MissionAssigner to obtain the task allocation dictionary table MissionDict).

[0189] Simultaneously, it can be determined whether the collected template proposal is the last proposal in the block. If so, the block consensus is successful, and it can be stored on the chain. If not, the next proposal entity in the block can be retrieved.

[0190] The data acquisition node cluster can allocate the task list dictionary table MissionDict to the part of its own data acquisition based on the task list, and create a data acquisition process to execute the data acquisition task (for example, the data acquisition node cluster can allocate the task list dictionary in the task list dictionary table MissionDict to the part of its own data acquisition, and create a new process to execute the instruction set asynchronous data acquisition).

[0191] After the data collection is completed, a data collection task completion flag proposal can be generated and sent to its own node. After polling, consensus will be reached and the data will be stored on the blockchain.

[0192] After all data collection nodes have completed their data collection tasks, the proposal initiating client sends a data collection result feedback request. According to the task list, the MissionDict dictionary table is allocated to obtain partial data collection task results from each data collection node and then splices them together to form a complete data collection result.

[0193] like Figure 8 The following is a flowchart illustrating a smart contract logic according to an embodiment of the present invention:

[0194] Once the smart contract starts, the collection task partitioning rule CurtorRuler in the proposal can be extracted first; then the strategy type corresponding to the collection task partitioning rule CurtorRuler can be determined.

[0195] If the strategy is to distribute tasks equally, then the modulo remainder formula is used to allocate the target and obtain the task list allocation dictionary table MissionDict.

[0196] If it is a self-balancing strategy, then the hardware performance score of the collection node cluster is used as the weight vector B; and it is determined whether the block corresponding to the proposal is the first block on the chain.

[0197] If so, initialize A as a vector of all ones with dimension equal to the number of nodes in the data collection node cluster.

[0198] If not, then traverse all proposals in the previous block to find the dictionary of tasks in execution and the dictionary of tasks completed, and update the task quantity to be completed collection task pool vector HisWorkMeature and the task quantity to be completed collection task pool vector HisDoneWorkMeature respectively.

[0199] Then, determine whether the previous block is the first block or whether it has exceeded the _VisionPeriod range.

[0200] If the previous block is not the first block and / or does not exceed the _VisionPeriod range, then re-execute the steps of "traversing all proposals in the previous block to find the dictionary of tasks in progress and the dictionary of completed tasks, and updating the task quantity unfinished collection task pool vector HisWorkMeature and the completed collection task pool vector HisDoneWorkMeature respectively".

[0201] If the previous block is the first block or has exceeded the _VisionPeriod range, then the acquisition task performance consumption cardinality A vector of the acquisition node is obtained according to HisWorkMeature-HisDoneWorkMeature, and the comprehensive score vector is the Hadamard product A*B of vectors A and B.

[0202] After softmax normalization of the A*B vector, the task assignment probability dictionary MissionAssigner is obtained.

[0203] Then, using the current block number BlockId as the pseudo-random number seed, the task allocation dictionary MissionDict is obtained by allocating tasks to the collection list table TargetList according to the task allocation probability dictionary MissionAssigner.

[0204] In this embodiment of the invention, after receiving a collection template proposal for one or more devices, the collection node cluster in the blockchain can first generate a target block based on the collection template proposal; then, it can obtain the collection task segmentation rules from the collection template proposal; next, it can determine the target collection strategy for multiple collection nodes based on the collection task segmentation rules; then, it can collect information from one or more devices according to the target collection strategy, so as to generate collection task sub-results at each collection node; during the information collection process of one or more devices, interactive commands are sent to one or more devices based on multiple collection instruction sets. Through this embodiment of the invention, information collection from devices based on different collection strategies is realized.

[0205] Furthermore, by using the unfinished historical collection tasks of the collection nodes as the base and the hardware and software performance indicators of the node devices as the weights, the weighted average is calculated and normalized to obtain the score of the collection node cluster. Collection tasks are then allocated based on the score, which allows high-performance collection nodes to execute more collection tasks, while low-performance collection nodes execute fewer collection tasks. This results in a more reasonable allocation of collection tasks, thereby achieving the goal of completing collection tasks faster.

[0206] Furthermore, by setting preset conditions, the security of the collection instructions in the collection template is ensured.

[0207] To further illustrate the technical effects achievable by the embodiments of the present invention, a specific embodiment is described below:

[0208] Four experimental devices were used as a consensus cluster, simultaneously participating as data collection nodes in on-chain data collection tasks. To demonstrate the superiority of smart contracts over traditional data collection methods, two experimental components were designed: a blockchain smart contract data collection time experiment and a data collection task block production experiment. The data collection time experiment recorded the total time elapsed from the start of the data collection task to the end of all distributed / centralized data collection tasks. The blockchain block production experiment recorded the total number of blocks produced from the start of the data collection task to the end of all distributed / centralized data collection tasks. The PBFT polling interval for blockchain block production was 30 seconds.

[0209] The performance of the four data acquisition devices is as follows:

[0210] The equipment performance scores are shown in Table 1.

[0211] Table 1:

[0212]

[0213] The hardware scores for each experimental device are shown in Table 2.

[0214] Table 2:

[0215]

[0216] The weight vector SD for the hardware performance scores of these four experimental devices is: <44.01,52.04,64.47,139.37>.

[0217] Two types of experiments were designed to test the data acquisition time. The first type used virtual machines to configure four Ubuntu 5.4.0 systems with the same performance configuration to test the overall time of batch data acquisition under three task allocation strategies. The second type used the four physical machines in Table 4 above to test the overall time of data acquisition under the three task allocation strategies.

[0218] 1) When the performance of experimental equipment is the same

[0219] 1.1 Table 3 shows the data acquisition time for different strategies under the same experimental equipment performance; Figure 9 The results show the acquisition time for different strategies when the experimental equipment performance is the same.

[0220] Table 3:

[0221]

[0222] 1.2 The number of blocks acquired using different strategies under the same experimental equipment performance is shown in Table 4; Figure 10 This shows the block output of different strategies under the same experimental equipment performance.

[0223] Table 4:

[0224]

[0225] Experiments show that, under the same hardware performance, both the equal distribution strategy and the self-balancing strategy take 69.2% less time and produce 63.3% fewer blocks than the single-machine collection strategy. This proves that the smart contract collection strategy can complete the consensus collection on the blockchain faster. Under the same performance conditions, the equal distribution strategy is slightly faster than the self-balancing strategy.

[0226] 2) Situations where experimental equipment performance differs

[0227] Due to the limited types of hardware devices, the experiment uses a built-in delay(x) function in the code to simulate the slowdown effect when the device is running out of memory or when the CPU reaches its peak processing power. The parameter x of the delay function represents the program sleeping for x seconds, and the parameter x is reflected in the device hardware score. The experiment uses the formula SD(i) = SD(i) - 5x to simulate the deduction of the device hardware performance SD due to the built-in delay function in the program. To highlight the difference in hardware performance between different devices in the experiment, different degrees of delay operation will be performed on experimental device A.

[0228] 2.1 The acquisition time for different strategies under the delay(1) parameter of experimental equipment A is shown in Table 5; Figure 11 The figure shows the acquisition time of different strategies under the delay(1) parameter of experimental device A.

[0229] Table 5:

[0230]

[0231] 2.2 The number of data points collected under different strategies with the delay(1) parameter of experimental equipment A is shown in Table 6; Figure 12 The figure shows the number of blocks acquired under different strategies when the delay(1) parameter is set for experimental device A.

[0232] Table 6:

[0233]

[0234] In an experiment simulating the slowdown effect of insufficient memory or peak CPU computing power when the delay(1) function is embedded in experimental device A, both the equal distribution strategy and the self-balancing strategy have a 68% shorter collection time and a 58.5% smaller block output compared to the single-machine collection strategy. The self-balancing strategy has a 18.2% longer collection time and a 10.8% larger block output compared to the equal distribution strategy. This proves that under relatively balanced hardware conditions, smart contracts perform better than single-machine collection, and the self-balancing strategy of smart contracts is slightly worse than the equal distribution strategy.

[0235] 3.1 The acquisition time for different strategies under the delay(5) parameter of experimental equipment A is shown in Table 7; Figure 13 The data acquisition time for different strategies is shown under the delay(5) parameter of experimental device A.

[0236] Table 7:

[0237]

[0238] 3.2 The number of blocks acquired under different strategies with delay(5) parameter of experimental equipment A is shown in Table 8; Figure 14 The figure shows the number of blocks acquired under different strategies when the delay(5) parameter is set for experimental device A.

[0239] Table 8:

[0240]

[0241] In the experiment simulating the slowdown effect of insufficient device memory or CPU computing power reaching its peak when the delay(5) delay function is embedded in experimental device A, the average distribution strategy and the self-balancing strategy are 74.1% shorter in collection time and 67.4% less in block output than the single-machine collection strategy. The self-balancing strategy is 26.8% shorter in collection time and 26.6% less in block output than the average distribution strategy. This proves that under the condition of relatively balanced device hardware level, smart contract is better than single-machine collection, and the self-balancing strategy of smart contract is better than the average distribution strategy.

[0242] 4.1 The acquisition time for different strategies under the delay(10) parameter of experimental equipment A is shown in Table 9; Figure 15 The data acquisition time for different strategies is shown under the delay(10) parameter of experimental device A.

[0243] Table 9:

[0244]

[0245] 4.2 The number of blocks acquired under different strategies with delay(10) parameter of experimental equipment A is shown in Table 10; Figure 16 The figure shows the number of blocks acquired under different strategies when the delay(10) parameter is set for experimental device A.

[0246] Table 10:

[0247]

[0248] In an experiment simulating the slowdown effect of insufficient memory or peak CPU computing power when the delay(10) function is embedded in experimental device A, both the equal distribution strategy and the self-balancing strategy have a collection time 73.6% shorter and a block output 68% less than the single-machine collection strategy. The self-balancing strategy has a collection time 44.8% shorter and a block output 47.6% less than the equal distribution strategy. This proves that under relatively balanced hardware conditions, smart contracts are more efficient than single-machine collection, and the self-balancing strategy of smart contracts is more efficient than the equal distribution strategy.

[0249] Experiments show that in all cases, smart contracts based on the collection strategy are more efficient than those based on single-node collection. The even distribution strategy is more efficient than the self-balancing strategy when the device performance is relatively balanced. The greater the difference in device performance among the collection node clusters, the more efficient the smart contracts based on the self-balancing strategy are.

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

[0251] Reference Figure 17 The diagram illustrates a schematic of a blockchain-based information collection device according to an embodiment of the present invention. This device is applied to a collection node cluster within a blockchain. The collection node cluster is used to collect information from one or more devices and may include the following modules:

[0252] The receiving module 1701 is used to receive collection template class proposals for one or more devices, and generate target blocks according to the collection template class proposals. The collection template class proposals include multiple collection instruction sets for different devices.

[0253] The data acquisition module 1702 is used to acquire information from one or more devices based on the data acquisition template class proposal; wherein, during the data acquisition process from one or more devices, interactive commands are sent to one or more devices based on multiple data acquisition instruction sets.

[0254] In an optional embodiment of the present invention, the data acquisition node cluster includes multiple data acquisition nodes, and the data acquisition module 1702 includes:

[0255] The segmentation rule acquisition submodule is used to obtain the task segmentation rules from the collection template class proposal;

[0256] The data acquisition strategy determination submodule is used to determine the target data acquisition strategy for multiple data acquisition nodes based on the data acquisition task segmentation rules.

[0257] The information acquisition submodule is used to acquire information from one or more devices according to the target acquisition strategy, so as to generate acquisition task sub-results at each acquisition node.

[0258] In an optional embodiment of the present invention, the target acquisition strategy includes an equal distribution strategy and an information acquisition submodule, which is used to determine the average number of acquisition tasks based on the number of acquisition nodes in the acquisition node cluster and the number of acquisition tasks in the acquisition template class proposal; and to acquire information from one or more devices based on the average number of acquisition tasks.

[0259] In an optional embodiment of the present invention, the target acquisition strategy includes a self-balancing strategy and an information acquisition submodule, which is used to obtain the software and hardware scores of each acquisition node; determine the task allocation probability dictionary for each acquisition node based on the software and hardware scores; and perform information acquisition on one or more devices based on the task allocation probability dictionary.

[0260] In an optional embodiment of the present invention, the information acquisition submodule is used to determine a random value; allocate acquisition tasks to each acquisition node according to the random value and the task allocation probability dictionary; and the multiple acquisition nodes collect information from one or more devices according to the allocated acquisition tasks.

[0261] In an optional embodiment of the present invention, the collection template type proposal further includes the total collection task duration, and the device further includes:

[0262] The return module is used to determine the start time of the data collection task; based on the start time and total duration of the data collection task, the end time of the data collection task is determined; when the end time of the data collection task is reached, the sub-results of the data collection task are obtained from multiple data collection nodes.

[0263] Based on the sub-results of the data collection task, generate the data collection task results and return them to the target client that sent the data collection template class proposal.

[0264] In an optional embodiment of the present invention, the apparatus further includes:

[0265] The authentication module is used to determine whether the collected template-type proposals meet the preset conditions; when the collected template-type proposals do not meet the preset conditions, the target block is discarded.

[0266] The data acquisition module 1702 is also used to perform data acquisition on one or more devices based on the data acquisition template proposal when the data acquisition template proposal meets the preset conditions.

[0267] In this embodiment of the invention, after receiving a collection template proposal for one or more devices, the collection node cluster in the blockchain can first generate a target block based on the collection template proposal, which includes multiple collection instruction sets for different devices. Then, information is collected from one or more devices according to the collection template proposal. During the information collection process, interactive commands are sent to one or more devices based on multiple collection instruction sets. Through this embodiment of the invention, automatic information collection from devices of different manufacturers and network layers is achieved, eliminating the need for users to send interactive commands with different instruction sets to each device individually, thus improving information collection efficiency.

[0268] This invention also provides an electronic device, including a processor, a memory, and a computer program stored in the memory and capable of running on the processor. When the computer program is executed by the processor, it implements the above-described blockchain-based information collection method.

[0269] This invention also provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, it implements the above-described blockchain-based information collection method.

[0270] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0271] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0272] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, apparatus, or computer program products. Therefore, embodiments of the present invention can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of the present invention can take the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0273] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0274] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing terminal device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1The function specified in one or more boxes.

[0275] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal equipment, causing a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0276] Although preferred embodiments of the present invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present invention.

[0277] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.

[0278] The above provides a detailed description of a blockchain-based information collection method, device, electronic device, and storage medium. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A blockchain-based information collection method, characterized in that, A data collection node cluster applied in a blockchain, the data collection node cluster being used to collect information from one or more devices, the method comprising: Receive collection template class proposals for one or more devices, and generate target blocks based on the collection template class proposals, wherein the collection template class proposals include multiple collection instruction sets for different devices; Based on the proposed template, information is collected from the one or more devices. During the information collection process of the one or more devices, interactive commands are sent to the one or more devices based on the multiple collection instruction sets; The data collection node cluster includes multiple data collection nodes, and the step of collecting information from one or more devices according to the data collection template class proposal includes: Obtain the task segmentation rules from the collection template class proposal; wherein, the task segmentation rules record the rules for segmenting tasks after being uploaded to the blockchain; Based on the task segmentation rules, a target acquisition strategy is determined for the multiple acquisition nodes. The target acquisition strategy includes an equal distribution strategy and a self-balancing strategy. The equal distribution strategy means that all tasks in the acquisition template proposal are evenly distributed among the acquisition nodes in the acquisition node cluster. The self-balancing strategy means that all tasks in the acquisition template proposal are distributed according to the performance of each acquisition node in the acquisition node cluster. According to the target acquisition strategy, information is collected from one or more devices to generate acquisition task sub-results at each acquisition node.

2. The method according to claim 1, characterized in that, The step of collecting information from the one or more devices according to the target acquisition strategy includes: The average number of collection tasks is determined based on the number of collection nodes in the collection node cluster and the number of collection tasks in the collection template class proposal. Information is collected from the one or more devices based on the average number of collection tasks.

3. The method according to claim 1, characterized in that, The step of collecting information from the one or more devices according to the target acquisition strategy includes: Obtain the hardware and software scores for each data collection node; Based on the software and hardware scores, a task allocation probability dictionary is determined for each acquisition node; Information is collected from the one or more devices based on the task allocation probability dictionary.

4. The method according to claim 3, characterized in that, The step of collecting information from the one or more devices according to the task allocation probability dictionary includes: Determine a random value; Based on the random value and the task allocation probability dictionary, the acquisition tasks are allocated to each acquisition node; The multiple acquisition nodes collect information from one or more devices according to their assigned acquisition tasks.

5. The method according to any one of claims 1-4, characterized in that, The data collection template proposal also includes the total data collection task duration, and the method further includes: Determine the start time of the data collection task; The end time of the data collection task is determined based on the start time of the data collection task and the total duration of the data collection task. When the end time of the data collection task is reached, the sub-results of the data collection task are obtained from the multiple data collection nodes; Based on the sub-results of the collection task, the collection task result is generated and returned to the target client that sent the collection template class proposal.

6. The method according to claim 1, characterized in that, The method further includes: Determine whether the collected template proposals meet the preset conditions; When the collection template proposal meets the preset conditions, the step of collecting information from the one or more devices according to the collection template proposal is executed; When the proposed template does not meet the preset conditions, the target block is discarded.

7. A blockchain-based information collection device, characterized in that, A data collection node cluster used in blockchain, the data collection node cluster being used to collect information from one or more devices, the device comprising: The receiving module is used to receive collection template class proposals for one or more devices, and generate target blocks according to the collection template class proposals, wherein the collection template class proposals include multiple collection instruction sets for different devices; The data acquisition module is used to acquire information from one or more devices according to the data acquisition template class proposal; wherein, during the data acquisition process, interactive commands are sent to one or more devices based on the multiple data acquisition instruction sets; The data collection node cluster includes multiple data collection nodes. The data collection module is used to obtain data collection task segmentation rules from the data collection template class proposals. These rules record the rules for task segmentation after being uploaded to the blockchain. Based on the data collection task segmentation rules, a target data collection strategy is determined for the multiple data collection nodes. The target data collection strategy includes an equal distribution strategy and a self-balancing strategy. The equal distribution strategy means that all tasks in the data collection template class proposals are evenly distributed among the data collection nodes in the data collection node cluster. The self-balancing strategy means that all tasks in the data collection template class proposals are distributed according to the performance of each data collection node in the data collection node cluster. Based on the target data collection strategy, information is collected from one or more devices to generate data collection task sub-results at each data collection node.

8. An electronic device, characterized in that, It includes a processor, a memory, and a computer program stored in the memory and capable of running on the processor, wherein the computer program, when executed by the processor, implements the blockchain-based information collection method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, A computer program is stored on the computer-readable storage medium, and when executed by a processor, the computer program implements the blockchain-based information collection method as described in any one of claims 1 to 6.

Images