Blockchain shard and dag based building iot data management method

Abstract

The application discloses a building Internet of Things data management method based on a blockchain shard and a DAG, and comprises the following steps: a blockchain shard network construction step: acquiring node performance data of edge gateways and cloud servers in a building Internet of Things system, dividing the edge nodes and the cloud server nodes to different shards through a self-adaptive load balancing algorithm, generating a shard configuration information file and storing the same; a DAG blockchain network construction step: selecting an edge gateway or a cloud server node with a collection rate higher than a threshold to deploy a DAG blockchain network, generating a DAG configuration file and storing the same in a node local; a data collection and processing step: storing terminal equipment data collected to an IPFS private network after processing the same; a data encapsulation step: encapsulating and signing an IPFS storage address to form a transaction record; a data storage step: analyzing the shard configuration information file, confirming a corresponding shard, and calling a storage contract corresponding to an encapsulated data type in the transaction record to store the same on a chain.

Description

Technical Field

[0001] This invention relates to the fields of blockchain technology and building IoT, specifically to a building IoT data management method based on blockchain sharding and DAG. Background Technology

[0002] Blockchain technology is a distributed database technology that uses encryption to store and manage data, ensuring its security and integrity. It also uses smart contracts to automatically execute transactions, ensuring their security and transparency. Combining blockchain technology with the Building Internet of Things (BIoT) can achieve more secure and reliable data transmission and storage, and enable automation and intelligence in the BIoT. However, due to the deep integration of IoT with the construction industry, the number of BIoT terminal devices and the amount of data collected are growing exponentially, with diverse data types. Furthermore, the traditional single-chain structure of blockchain requires each node to process and verify every transaction, leading to storage scalability and low throughput issues when combining blockchain with the BIoT.

[0003] To address the issues of low storage scalability and throughput, blockchain sharding technology, which divides the blockchain network into multiple independent sub-networks, can effectively improve scalability and throughput. Existing technologies, such as a node location-based sharding scheme to address storage scalability in the general IoT field, do not consider the interrelationships between IoT nodes, potentially leading to frequent cross-shard transactions and wasted resources. Other sharding algorithms designed to optimize cross-shard transaction query costs to solve the frequent cross-sharding problem in blockchain sharding do not consider the performance of individual nodes and physical topology latency in the physical network scenario, potentially causing sharding overheating.

[0004] In the Building Internet of Things (BIoT), different types of IoT devices exhibit significant differences in computing and storage resources. For example, edge gateways have much higher performance than terminal devices, and their physical topology is relatively fixed, remaining unchanged regardless of the addition or removal of other nodes. Furthermore, different IoT device nodes interact with other nodes at inconsistent frequencies; for instance, access control gateways interact frequently with fire protection gateways but less frequently with energy gateways. When applying blockchain sharding technology to address storage scalability issues in BIoT, firstly, existing sharding solutions typically do not consider the actual computing and storage performance of devices in real-world BIoT scenarios, the sampling frequency and data volume of edge nodes, and data transmission latency. This leads to the aggregation of nodes with low loads, causing sharding overheating. Secondly, in a blockchain sharded network, two traversal queries are required to obtain specific transaction data. The first query retrieves the shard number of the data, and the second retrieves matching transaction data based on time, device location, and data type. These two queries reduce query efficiency.

[0005] Therefore, how to propose a data management method for the Internet of Things in buildings that can improve storage scalability and throughput by applying blockchain sharding technology, while avoiding sharding overheating and reduced query efficiency caused by existing sharding schemes, has become an urgent problem to be solved. Summary of the Invention

[0006] To address the above problems, this invention provides a building IoT data management method based on blockchain sharding and DAG, comprising:

[0007] Blockchain sharding network construction steps: Obtain the node performance data of all edge gateways and cloud servers in the building IoT system; based on the node performance data, divide the edge nodes and cloud server nodes into different shards using a preset adaptive load balancing algorithm, generate sharding configuration information files, and store them locally on the nodes;

[0008] DAG network construction steps: Select edge gateways or cloud server nodes with acquisition rates higher than the threshold in each shard to deploy the DAG blockchain network, and generate DAG configuration files to store locally on the nodes.

[0009] Data acquisition and processing steps: The edge gateway collects terminal device data from each intelligent subsystem according to the set sampling frequency. The edge gateway processes the terminal device data to form multiple data files, parses the data files, and stores them in the IPFS private network to obtain the IPFS storage address.

[0010] Data encapsulation steps: After the storage address is encapsulated by the edge gateway, the encapsulated data is signed using the node's private key to form a transaction record;

[0011] Data storage steps: The edge gateway parses the sharding configuration information file, confirms the sharding corresponding to the edge gateway, and then calls the storage contract corresponding to the encapsulated data type in the transaction record for on-chain storage.

[0012] Data query steps: Parse the user's query request to form three-dimensional query conditions of time, device location and data category, obtain a transaction set according to the three-dimensional query conditions, and obtain the terminal device data from the IPFS private network according to the IPFS storage address of the transaction data in the transaction set.

[0013] The advantages of this invention over existing technologies are as follows:

[0014] (1) To address the issues of low scalability and throughput in existing blockchain-based building IoT data management methods, this invention employs a storage approach combining blockchain sharding and the IPFS network. The original single-chain blockchain network is divided into multiple blockchain shards, each maintaining its own independent blockchain ledger, thus reducing the number of copies maintained by each full node. Furthermore, the actual data in the blockchain shards is uploaded to a private IPFS network for storage, with only IPFS address information stored within the blockchain shard network, further alleviating the storage pressure on nodes. This storage method significantly frees up node storage resources, improving the storage scalability and throughput of the blockchain network.

[0015] (2) In view of the problem of sharding overheating caused by the application of existing blockchain sharding technology in the Internet of Things in buildings, this invention designs a sharding partitioning algorithm that conforms to the performance characteristics and interaction characteristics of Internet of Things nodes. The algorithm divides the blockchain sharding network according to the actual deployment performance data of Internet of Things cluster nodes and the interaction frequency between nodes, avoiding the clustering of nodes with low performance and low interaction frequency, thereby avoiding the problem of sharding overheating.

[0016] (3) To address the low data query efficiency caused by the application of existing blockchain sharding technology in the building IoT, this invention proposes a method combining DAG blockchain with a blockchain sharding network. Furthermore, a 3D-Merkle tree block structure is designed within the sharding network to support three-dimensional conditional queries based on time, device location, and data type. Confirmed transactions are constructed into a 3D-Merkle tree structure, and a root hash value is generated and encapsulated in the block header. Subsequently, the block header and a list of full node IP addresses are uploaded to the DAG blockchain to achieve rapid block location. Attached Figure Description

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

[0018] Figure 1 This is a flowchart of the building Internet of Things (IoT) data management method of the present invention;

[0019] Figure 2 for Figure 1 The step-by-step flowchart of step S1;

[0020] Figure 3 for Figure 1 The step-by-step flowchart of step S12;

[0021] Figure 4 for Figure 1 The step-by-step flowchart of step S3;

[0022] Figure 5 for Figure 1 The step-by-step flowchart of step S5;

[0023] Figure 6 for Figure 1 Flowchart of step S6;

[0024] Figure 7 This is an application flowchart of the building Internet of Things data management method of the present invention;

[0025] Figure 8 This is the application flowchart for step S12;

[0026] Figure 9 This is a flowchart illustrating the 3D-Merkle tree construction method.

[0027] Figure 10 A schematic diagram of the 3D-Merkle tree root hash generation method;

[0028] Figure 11 This is a flowchart illustrating the two-level indexing method.

[0029] Figure 12 This is a flowchart illustrating the 3D-Merkle tree three-dimensional conditional query method.

[0030] Figure 13 A schematic diagram of a data management method for building security equipment based on blockchain sharding and DAG;

[0031] Figure 14This is a schematic diagram of a building security data management method based on blockchain sharding and DAG. Detailed Implementation

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

[0033] The illustrative embodiments and descriptions of the present invention are used to explain the invention, but are not intended to limit the invention. Furthermore, elements / components using the same or similar reference numerals in the drawings and embodiments are used to represent the same or similar parts.

[0034] The terms "first," "second," "S1," "S2," etc., used in this document do not specifically refer to any order or sequence, nor are they intended to limit the invention. They are merely used to distinguish elements or operations described using the same technical terms.

[0035] The terms “include,” “including,” “have,” “contain,” etc., used in this article are all open-ended terms, meaning that they include but are not limited to.

[0036] Please refer to Figure 1 , Figure 1 This is a flowchart of the building IoT data management method of the present invention. Figure 1 As shown, the present invention provides a building IoT data management method based on blockchain sharding and DAG, comprising:

[0037] Blockchain sharding network construction step S1: Obtain the node performance data of all edge gateways and cloud servers in the building IoT system, and divide the edge nodes and cloud server nodes into different shards according to the node performance data through a preset adaptive load balancing algorithm, generate sharding configuration information files and store them locally on the nodes;

[0038] DAG network construction step S2: Select edge gateways or cloud server nodes with acquisition rates higher than the threshold in each shard to deploy the DAG blockchain network, and also generate DAG configuration files and store them locally on the nodes.

[0039] Data acquisition and processing step S3: The edge gateway collects terminal device data from each intelligent subsystem according to the set sampling frequency. The edge gateway processes the terminal device data to form multiple data files, parses the data files, and stores them in the IPFS private network to obtain the IPFS storage address.

[0040] Data encapsulation step S4: After encapsulating the storage address through the edge gateway, the encapsulated data is signed using the node's private key to form a transaction record;

[0041] Data storage step S5: The edge gateway parses the sharding configuration information file, confirms the sharding corresponding to the edge gateway, and then calls the storage contract corresponding to the encapsulated data type in the transaction record for on-chain storage.

[0042] Data query step S6: Parse the user's query request to form three-dimensional query conditions of time, device location and data type, obtain a transaction set according to the three-dimensional query conditions, and obtain the terminal device data from the IPFS private network according to the IPFS storage address of the transaction data in the transaction set.

[0043] The building IoT data management method of the present invention can balance the data load of each blockchain shard, improve data throughput and storage scalability, and improve data query efficiency with the support of DAG blockchain.

[0044] In this invention, the acquisition rate reflects storage resources and computing resources (CPU processing efficiency).

[0045] Please refer to Figures 2-3 , Figure 2 for Figure 1 The step-by-step flowchart of step S1; Figure 3 for Figure 2 The step-by-step flowchart for step S12. (See attached flowchart.) Figures 2-3 As shown, the fragmentation step S1 includes:

[0046] Step S11: Obtain the node performance data of all edge nodes and cloud servers in the building IoT system, determine the number of edge gateway and cloud server nodes, the spatial location number and data type number of each node, and then write the performance data, the number of nodes, the node spatial location and data type number into the node local configuration file.

[0047] Step S12: Deploy the blockchain sharding network environment, DAG blockchain network environment, and InterPlanetary File System environment. Use an adaptive load balancing algorithm to divide edge gateways and cloud server nodes into different shards based on node performance data, and write the correspondence between nodes and shards into the local configuration file of the node. In addition, select edge gateways or cloud server nodes with high performance in each shard to deploy the DAG blockchain network, and generate DAG configuration files and store them locally on the node.

[0048] Step S12 includes:

[0049] Step S121: Obtain the performance data set and number of shards for each node;

[0050] Step S122: Calculate the sampling frequency of each node based on the relationship between the node's sampled data volume, computing resources, and network latency; calculate the load value of each node based on the relationship between the storage resources, sampling frequency, and computing resources.

[0051] Step S123: Traverse all nodes. If the load value of a node is lower than the low load standard value, add the node to the low load node set; if the load value of a node is higher than the high load standard value, add the node to the high load node set; add the remaining nodes to the appropriate load set.

[0052] Step S124: Sort the high-load node set and the low-load node set according to the rule that the low-load set is from smallest to largest and the high-load set is from largest to smallest. Then, take the remainder of the number of shards in the two sets in order and allocate them to the corresponding shards. After sharding, update each node to the sharded state.

[0053] Step S125: Calculate the total interaction integral of the nodes in the suitable load set with each shard according to the interaction integral table between nodes, and assign the nodes to the shard with the largest total interaction integral.

[0054] Step S126: Output the final sharding result and generate a sharding configuration file, which is stored locally on each node and in the DAG blockchain.

[0055] Step S127: After sharding is completed, the edge gateway or server in the sharding network that also has the identity of a DAG blockchain node is responsible for updating the node interaction points table in real time, updating the latest storage and computing resources of each node at a set time interval, calculating the sharding load to determine the sharding status, and if the overheated sharding exceeds a threshold, then it is re-sharded.

[0056] Please refer to Figure 4 , Figure 4 for Figure 1 The step-by-step flowchart for step S3. (See attached flowchart.) Figure 4As shown, the data acquisition and processing step S4 includes:

[0057] Step S41: After generating the public and private keys of the blockchain shard nodes using the elliptic curve algorithm, broadcast the public key to the blockchain shard network.

[0058] Step S42: The data acquisition interface is invoked through the edge gateway to collect data from terminal devices in each intelligent subsystem connected to the edge gateway node in batches according to the sampling frequency;

[0059] Step S43: The edge gateway converts the collected terminal device data into JSON or XML format and classifies it into multiple data files. The gateway parses the timestamp, device location number, and data type number of the data files according to the local configuration file and stores the data files in the InterPlanetary File System to obtain the storage address.

[0060] Furthermore, the data encapsulation step S3 includes: encapsulating the IPFS storage address with three dimensions—timestamp, device location number, and data type number—through the edge gateway to obtain encapsulated data, and then using the edge gateway's private key to sign the encapsulated data to form the transaction record.

[0061] Please refer to Figure 5 , Figure 5 for Figure 1 The flowchart for step S5 is shown below. Figure 5 As shown, the data storage step S5 includes:

[0062] Step S51: After parsing the local sharding configuration information file through the edge gateway and determining the shard to which the edge gateway belongs, the transaction record is broadcast to the designated blockchain sharding network for consensus. The valid transaction records are verified and arranged in order. The 3D-Merkle tree construction method is called to process the transactions confirmed to be stored in the block. After the construction is completed, the M-HASH method is called to generate the 3D-Merkle root hash and encapsulate it into the block header.

[0063] Step S52: Upload the block header to the DAG blockchain network through an edge gateway or cloud server node that also has the identity of a DAG blockchain node in the blockchain sharding network, and add the list of full node IP addresses to the block. Then, perform consensus verification on the block and distribute its storage.

[0064] Step S51 includes:

[0065] a) First, construct the transaction set as a 3D-Merkle tree node set;

[0066] b) Obtain the current 3D-Merkle tree construction level Depth and node set Node. Calculate the current layer's splitDim by taking the modulo operation of Depth with the node dimension length 3.

[0067] c) Sort the node set in ascending order according to the split dimension splitDim, take the middle node as the root node, the nodes smaller than the middle node as the left subtree nodes of the root, and the nodes larger than the middle node as the right subtree nodes of the root.

[0068] d) Recursively execute steps b) and c) above for the left and right subtree node sets until all nodes are partitioned.

[0069] Step S51 further includes:

[0070] e) Obtain the Root_node of the 3D-Merkle tree;

[0071] f) Determine whether the 3D-Merkle tree node Root_node is a leaf node. If it is a leaf node, calculate the hash value of Root_node itself and assign it as the root hash value of the current tree to the M-Hash field of Root_node. If not, assign the left and right child nodes to Root_node respectively, and recursively execute the aforementioned steps e) and f) to calculate the root hash values ​​of the left and right subtrees. Then, concatenate the root hash values ​​of the left and right subtrees with the hash value of Root_node itself to finally obtain the 3D-Merkle root hash. Specifically, if it is a leaf node, then: Root_node.M-Hash = hash(Root_node); otherwise: Root_node.M-hash = Root_node.hash ∪ M-HASH(left) ∪ M-HASH(right); otherwise, assign the left and right child nodes to Root_node respectively, and recursively execute the aforementioned steps e) and f) to finally obtain the 3D-Merkle root hash.

[0072] Please refer to Figure 6 , Figure 6 for Figure 1 The flowchart for step S6 is shown below. Figure 6 As shown, the data query step S6 further includes:

[0073] Step S61: The user initiates a query request to the backend server through the terminal device. The server verifies the user's identity and parses the query request to form three-dimensional query conditions with time, device location and data type. The server calls the two-level index interface to quickly obtain the transaction set that meets the query conditions.

[0074] Step S62: After receiving the transaction set, the server uses the public key of the corresponding edge gateway node to verify the transaction signature, then retrieves the real data stored in the IPFS private network according to the storage address in the transaction data, and returns it to the user.

[0075] Please refer to the following: Figures 7-12 The building IoT data management method of the present invention is described in detail below, and the flowchart of the method is as follows. Figure 7 As shown, the specific steps include:

[0076] Step 1: Determine the network topology of the building IoT system, i.e., obtain the performance data Node_Performance of all edge nodes and cloud servers in the building IoT system, determine the number of edge gateways and cloud server nodes, and the spatial location number P and data type number D of each node. Then write Node_Performance to the node's local configuration file.

[0077] Specifically, the network topology of the building Internet of Things system refers to connecting various devices, sensors, controllers, gateways, etc. within a building to form a complete end-edge-cloud network system, so as to realize the interaction and data transmission between devices within the building.

[0078] It should be further noted that once sensors, gateways, and other devices are added to the building IoT, they will not be arbitrarily added or removed, and their locations will not frequently change with the addition of new nodes. In addition, the computing and storage capabilities of terminal devices are limited and cannot meet the requirements of blockchain nodes, so they cannot be used as blockchain nodes. Therefore, in the building IoT, blockchain can only be deployed at the edge and cloud nodes.

[0079] Specifically, the node performance data Node_Performance includes the node ID, the node's computing resources C, the node's storage resources M, the node's sampled data volume D, the interaction integral table with other nodes T, the node's sampling frequency F, the average physical latency of the node connecting to the terminal device Tr, the node's load value Load, and the node's load state State.

[0080] It should be further explained that, in order to better quantify the computing resources C of the edge nodes, let C be the amount of data processed by the node per second; the interactive integral table T = {t1,...,t} i ,...,t n} represents the interaction frequency between the current node and other nodes; the sampling frequency F of a node is actually determined by the amount of sampled data D, computing resources C, and average physical latency Tr, and the relationship is expressed as: F = D / C + Tr; the load value Load of a node is determined by the storage resources M, computing resources C, and interaction frequency F, and the relationship is expressed as: Load = M / CF; when the node is a node with too low load, State = 0; when the node is a node with a suitable load, State = 1; when the node is a node with too high load, State = 2.

[0081] Specifically, the local configuration file of the edge node includes, but is not limited to: the node's performance data Node_Performance, the physical location number P and data type number D of the node's connected terminal device and itself, the correspondence between the node and the blockchain shard, and the node information belonging to the same blockchain shard.

[0082] It should be noted that node information includes, but is not limited to, node number, blockchain to which it belongs, node IP address, and node communication port number.

[0083] Step 2: Deploy the blockchain sharding network environment, the DAG blockchain network environment, and the InterPlanetary File System (IPFS) environment. Using the Adaptive Load Balancing Algorithm (ALBA), edge gateways and cloud server nodes are divided into different shards based on node performance data (Node_Performance). The mapping between nodes and shards is written to a configuration file and stored locally on the nodes and in the DAG blockchain. Since cloud servers have significant computing and storage resources, the DAG blockchain and IPFS private network can be deployed on all cloud server nodes, or the DAG blockchain network and IPFS network can be deployed on the edge gateways or cloud service nodes with higher performance in each shard. In this embodiment, using the InterPlanetary File System (IPFS) private network is the preferred implementation method.

[0084] Specifically, the blockchain sharding network environment divides the edge gateways and cloud server nodes in the building IoT into multiple node clusters, with each cluster node running an independent Hyperledger Fabric blockchain network.

[0085] It should be noted that a gateway / server acting as a blockchain node can be added to one or more shards of the sharding network, depending on the scenario requirements and the computing and storage resources of the gateway / server.

[0086] It should be further explained that data storage requests initiated by the gateway or server are directly uploaded to the blockchain shard network corresponding to the gateway or server node. Only the nodes within that shard perform consensus confirmation on the stored data, while other nodes do not need to consume computing resources. Therefore, the data management method provided in this application can have good concurrent processing performance in high-concurrency scenarios.

[0087] Specifically, the DAG blockchain network environment supports higher transaction throughput and faster transaction times, corresponding to the high throughput characteristics of blockchain sharding networks. Here, it is used to receive and store the block headers of each shard. The DAG blockchain is deployed on gateway or server nodes selected from each shard, which have higher computing and storage resources.

[0088] It should be noted that data query requests initiated by building IoT users are first uploaded to the DAG blockchain to query block headers that meet the criteria. The data block is quickly located by using the shard number, block height, and node IP address stored in the block header, and then the set of transactions that meet the criteria is queried.

[0089] Specifically, IPFS is a distributed file storage system that stores data in the form of files and identifies files by generating unique hash values ​​through file content. IPFS is used to store IoT data generated in building IoT scenarios, thereby reducing the storage and bandwidth pressure on blockchain networks.

[0090] Specifically, the building Internet of Things includes, but is not limited to, various intelligent subsystems consisting of equipment such as building interior lighting, monitoring, access control, and environmental monitoring.

[0091] The intelligent subsystems include, but are not limited to, video surveillance systems, fire protection systems, building control systems, environmental monitoring systems, and / or access control systems.

[0092] Specifically, the building IoT cluster refers to a cluster consisting of one or more buildings or parks.

[0093] Specifically, the intelligent subsystems belong to categories including but not limited to security, access, communication and / or energy consumption systems.

[0094] Specifically, the ALBA algorithm is as follows: Figure 8 As shown, the specific steps are as follows:

[0095] Step 1: Obtain the performance data set for each node: Node = {node1, ... node ... i ,...node n} and the number of shards m. Where nodei = {ID, C, M, D, T, Tr, State}.

[0096] Step 2: Calculate the sampling frequency F of each node based on the relationship between node performance F = D / C + Tr; calculate the load value Load of each node based on the relationship L = M / FC.

[0097] Step 3: Traverse all blockchain nodes. If the load value of a node is lower than the low load standard value X1, add the node to the low load node set LowLoad; if the load is higher than the high load standard value X2, add the node to the high load node set HighLoad; add the remaining nodes to the appropriate load set AvgLoad.

[0098] Specifically, the low-load standard value X1 refers to the criterion for classifying low-load nodes. If a node's load value (Load) is less than X1, the node is considered a low-load node. Furthermore, X1 is calculated as follows: Similarly, X2 is the criterion for dividing high-load nodes, and X2 is calculated as follows: Nodes whose load values ​​are within the range [X1, X2] are called suitable load nodes.

[0099] Step 4: Sort the LowLoad collection nodes in ascending order of load value and the HighLoad collection nodes in descending order of load value. Assign the two collection nodes to the i%m shards in sequence. After sharding, update the State of each node.

[0100] Step 5: Divide the AvgLoad collection nodes into fragments according to the interaction integral table T between nodes, that is, maximize the sum of the interaction integrals between the node to be fragmented and the nodes within the fragment.

[0101] Step 6: Output the final sharding result: Chain = {chain1, ... chain i ...chain n}

[0102] Step 7: After sharding is completed, the edge gateway or cloud server, which also has the identity of a DAG network node in the blockchain sharding network, updates the node interaction points table in real time. Every time T, the latest storage resources M and computing resources C of each node are updated, the sharding load is calculated to determine the sharding status, and if the overheated shard exceeds 1 / 3m, the sharding algorithm is called to re-shard.

[0103] Specifically, the reason for updating the computation C and storage resources M of each node every time period T is that C and M are constantly changing during the operation of the sharded network, and the node load value Load = M / CF. It is possible that a node that was originally high-loaded becomes a low-loaded node after time T.

[0104] Specifically, hot sharding refers to the number of low-load nodes exceeding 51% of the total number of nodes in a shard. The more low-load nodes in a shard, the worse the shard consensus capability, leading to severe data accumulation and causing shard overheating. Similarly, cold sharding refers to the number of high-load nodes exceeding 51% of the total number of nodes in a shard.

[0105] Step 3: Generate the public and private keys for the blockchain shard nodes. First, the node's private key Key_pri is generated using the Elliptic Curve Cryptography (ECC) algorithm. Then, the node's public key Key_pub = Key_pri * G is generated using the private key, where G represents the generation point on the elliptic curve. Finally, the node's public key is broadcast to the blockchain shard network.

[0106] Specifically, the public and private keys of the blockchain nodes utilize a cryptographic technique, where the public key can be shared within the blockchain network, while the private key remains confidential. When the edge gateway collects device data, it first signs the data using its private key, then uploads the data to the blockchain network. Other nodes verify the data using the initiating node's public key to ensure the data has not been tampered with.

[0107] St4, in the building IoT, the edge gateway calls the data acquisition interface to collect data from terminal devices in various intelligent subsystems connected to the node in batches according to the sampling frequency.

[0108] Specifically, the data acquisition interface refers to a dedicated interface that IoT device manufacturers pre-set for IoT devices, allowing other entities to obtain their data.

[0109] Specifically, the IoT data includes, but is not limited to, device operation data, device status information, and / or surrounding environment information collected by the device.

[0110] St5, the edge gateway converts the collected data into JSON or XML format and classifies it into multiple data files fi. It parses the timestamp, device location number and data type number of fi according to the local configuration file of the gateway, and stores fi in the IPFS private network to obtain the storage address fi_ipfs_addr.

[0111] Specifically, the timestamp of file fi refers to the time when the gateway collects data from devices in batches;

[0112] Specifically, the device location number first measures the device location using latitude and longitude, and then uses the GeoHash algorithm to convert the latitude and longitude into a comparable string number, which is recorded in the edge gateway's local configuration file.

[0113] Specifically, the storage address fi_ipfs_addr refers to the unique hash value returned after storing the data file in the IPFS private network, which identifies the file storage address.

[0114] St6, the edge gateway encapsulates fi_ipfs_addr with timestamp T, device location number P, and data type number D, and then uses the private key Key_pri to sign the encapsulated data to form transaction record Txi.

[0115] Specifically, the data structure of the transaction record Txi is shown in Table 1, including but not limited to gateway ID, timestamp, device location number, datatype, IPFS storage address fi_ipfs_addr, original data file fi_hash value, and signature.

[0116] Table 1

[0117] gateway_ID timestamp porsition datatype fi_ipfs_addr fi_hash sign

[0118] Specifically, the data gateway ID is used to uniquely identify the data gateway, and an ID has been assigned to the data gateway during initialization;

[0119] Specifically, the original data file hash value is the result of a hash operation performed on the converted original JSON or XML file.

[0120] St7: The edge gateway parses the local shard configuration information file, determines the shard to which the gateway belongs, broadcasts the transaction record Txi to the specified blockchain shard network for consensus, verifies the valid Txi order, calls the 3D-Merkle tree constructor method Create3DMerkle() to process the transactions confirmed to be stored in the block, and after construction, calls the M-HASH() method to generate the 3D-Merkle root hash and encapsulates it into the block header.

[0121] Specifically, the Txi sequential arrangement refers to arranging the transaction records Tx that have been verified by the consensus nodes in the order of their timestamps, and packaging them into blocks in that order. In the existing blockchain, the size of each block is approximately 1-2 MB.

[0122] Specifically, the 3D-Merkle tree construction method Create3DMerkle() is as follows: Figure 9 As shown, the specific steps are as follows:

[0123] Step 1: First, set the transaction set Tx = {tx1, ... tx} i ,...tx nConstruct a 3D-Merkle tree node set Node = {node1, ... node2} i ,...node n}

[0124] Specifically, the 3D-Merkle tree node is shown in Table 2, including but not limited to the three-dimensional coordinates Point, Left child node, Right child node, transaction record hash value Tx_hash, node hash value Node_hash, and node 3D-Merkle hash value M_hash.

[0125] Table 2

[0126] Left Point Tx_hash Node_hash M_hash Right

[0127] Specifically, the three-dimensional coordinate Point includes the timestamp T of the transaction corresponding to the node, the device location number P, and the data type number D.

[0128] Specifically, the left child node (Left) connects the root node and the left child node by assigning the hash value (Node_hash) of the left child node to the left of the root node, and the same applies to the right child node.

[0129] Specifically, the node hash value Node_hash refers to a hash value of a specified length obtained by concatenating the various fields of a node and performing a hash operation.

[0130] Specifically, the 3D-Merkle hash value M_hash is obtained by concatenating the M_hash values ​​of the left and right children.

[0131] It should be noted that if the current node is a leaf node, the M_hash value is equal to the Node_hash. In addition, if the node has only one child node, the child node is copied to generate the M_hash.

[0132] Step 2: Obtain the current 3D-Merkle tree level Depth and the node set Node. Take the modulo operation of Depth on the node dimension length, i.e., Depth%len(nodei.Point), to obtain the split dimension splitDim of the current layer.

[0133] It should be noted that the 3D-Merkle tree is constructed layer by layer from top to bottom.

[0134] Specifically, the splitDim dimension of the current layer refers to the construction of root nodes for each subtree of the current layer according to the splitDim dimension.

[0135] It should be noted that the splitDim dimension of the previous layer is obtained by taking the modulo of the node dimension length with the current layer depth Depth. In the building IoT, the data is characterized by time T, location P, and data type D, that is, the node dimension length is 3.

[0136] Step 3: Sort the node set in ascending order according to the dimension splitDim, and take the middle node as the 3D-Merkle Root. Nodes smaller than the middle node are the left subtree nodes of the Root, and nodes larger than the middle node are the right subtree nodes of the Root.

[0137] Step 4: Recursively execute Step 2 and Step 3 on the left and right subtree node sets until all nodes are partitioned.

[0138] Specifically, the 3D-Merkle root hash generation steps in the M-HASH() method are as follows: Figure 10 As shown, the specific steps are as follows:

[0139] Step 1: Obtain the 3D-Merkle node Root_node.

[0140] Step 2: Determine if Root_node is a leaf node. If it is a leaf node, then: Root_node.M-Hash = hash(Root_node); otherwise: Root_node.M-hash = Root_node.hash ∪ M-HASH(left) ∪ M-HASH(right).

[0141] Step 3: Assign the left and right child nodes to the Root_node respectively, and recursively execute Step 1 and Step 2 to finally obtain the 3D-Merkle root hash.

[0142] In St8, cloud server nodes in the sharded network upload the block header to the DAG blockchain network and add the full node IP address list (IP_list) to the block. Then, the block undergoes consensus verification and is stored in a distributed manner.

[0143] Specifically, the fields included in the block header are shown in Table 3, including but not limited to version number, fragment number, block height, hash value of the previous block, and timestamp range of all transaction records [T]. min ,T max ], All transaction record location number range [P min ,P max ], All transaction record data type number range [D min D max ] , 3D-Merkle tree roots.

[0144] Table 3

[0145]

[0146] Specifically, the version number refers to the software version number of the blockchain, which is used to identify different blockchain software versions so that nodes in the network can correctly identify and process blocks from different versions.

[0147] Specifically, the block height refers to which block the current block is in the blockchain. It is an integer, and the height increases by one for each new block added.

[0148] St9. The user sends a query request Req = {<...> to the backend server via their terminal device. <t> , , <d>The server verifies the user's identity and parses the query request to form three-dimensional query conditions [T / P / D]. The server calls the Two_level_index() interface to quickly retrieve the transaction set Data that meets the query conditions.

[0149] Specifically, the terminal devices include, but are not limited to, mobile phones, tablets, and laptops.

[0150] Specifically, the backend server also exists as a blockchain node, and blockchain applications are deployed on the backend server.

[0151] Specifically, the Two_level_index() interface is as follows: Figure 11 As shown, the specific steps are as follows:

[0152] Step 1: Obtain the three-dimensional query conditions [T] min ,T max ],[P min ,P max ],[D min D max ].

[0153] Step 2: Query the block header in the DAG blockchain using the breadth-first traversal algorithm.

[0154] Specifically, the breadth-first traversal algorithm rules for the DAG blockchain are as follows:

[0155] (1) First, define the queue of unvisited nodes, Seq.

[0156] (2) Starting from the root node DAG_root of the DAG, mark DAG_root as visited.

[0157] (3) Add the adjacent nodes of DAG_root to Seq. If Seq is empty, the traversal ends.

[0158] (4) Otherwise, take out the first node DAG_node in Seq, mark it as visited, and then add the unvisited adjacent nodes of DAG_node to Seq.

[0159] (5) Repeat step (4) until Seq is empty.

[0160] Step 3: If the query conditions in the three dimensions of T / P / D all intersect with the query conditions in the block header, [T' min ,T' max ],[P' min ,P' max ],[D' min ,D' max Then, the block location can be quickly located by using the fragment number in the block header, the block height, and the full node IP_list in the block body.

[0161] It should be noted that a transaction record matching the conditions will only exist in the block body when the [T / P / D] 3D coordinate range in the block header intersects with the 3D query conditions. For example, in the Building Physics Network, if a monitoring device DEV_00001 with latitude and longitude [W,E] uploads 180MB of monitoring video data with data category number DataType_00001 at 12:00, T must contain 12:00, P must contain [W,E], and D must contain DataType_00001.

[0162] Step 4: Call the 3D-Merkle_index() interface to quickly query and return the set of transactions within the block that meet the three-dimensional query conditions.

[0163] Step 5: If the query conditions in the three dimensions of T / P / D do not overlap with the query conditions in the block header, then continue querying the next block.

[0164] Specifically, the 3D-Merkle_index() interface in Step 4 is as follows: Figure 12 As shown, the specific steps are as follows:

[0165] Step 1: Obtain the root node of the 3D-Merkle tree, query the current level (Depth) of the tree, and use the query condition [T'] min ,T' max ],[P' min ,P' max ],[D' min ,D' max ].

[0166] Step 2: First, determine which dimension W is used for the query in the current layer based on Depth%3. If Depth%3 = 0, W = T; if Depth%3 = 1, W = P; if Depth%3 = 2, W = D.

[0167] Step 3: If W = 0:

[0168] Step 3-1: If Determine if Root.P and Root.D are both contained in [P' min ,P' max ] and [D' min ,D' max If the root node is included in the data, then the root node is added to the returned set Data; otherwise, the left and right child nodes are queried in turn.

[0169] Step 3-2: If Root.T <T’ min Then, query the left child node of Root, namely 3D-Merkle_index(Root.Left,Data,Depth+1).

[0170] Step 3-3: If Root.T>T' max Then, query the right child node Right of Root, i.e., 3D-Merkle_index(Root.Right,Data,Depth+1).

[0171] Step 4: When W = 1,2, the process is the same as in Step 3. Finally, the set of transactions Data that meets the query conditions is returned.

[0172] St10. After receiving the transaction set Data, the server first uses the public key Key_pub of the corresponding edge gateway node to verify the correctness of the transaction signature, ensuring that the transaction data has not been tampered with. Then, it retrieves the real data stored in the IPFS private network based on fi_IPFS_addr in the transaction data and returns it to the user.

[0173] Specifically, the public key verification of the transaction signature means using the public key of the edge gateway that initiated the transaction to verify the signature of the transaction on the private key of the edge gateway that initiated the transaction.

[0174] Please refer to the following: Figures 13-14 , Figure 13 A schematic diagram of a data management method for building security equipment based on blockchain sharding and DAG; Figure 14 This is a schematic diagram illustrating a building security data management method based on blockchain sharding and DAG. (Example:) Figures 13-14 The following is combined Figure 13-14 Taking the collection of security data as an example, this invention will be described in detail. The embodiments of this application include the following steps:

[0175] Step 1: The security edge gateway calls the data acquisition interface to collect security data from the 10th floor of a building at a sampling frequency of 2 seconds.

[0176] Step 2: The edge gateway converts the collected security data into JSON and divides it into three data files F = {f1, f2, f3} according to different sampling devices. Based on the gateway's local configuration file, it parses the timestamp, device location number, and data type number of F, resulting in F' = {[12:00 / [50,60] / datatype_00001], [12:02 / [50,70] / datatype_00001], [12:04 / [50,90] / datatype_00001]}. F is then stored in IPFS, and the storage address F_addr = {f1_ipfs_addr, f2_ipfs_addr, f3_ipfs_addr} is obtained.

[0177] Step 3: The edge gateway encapsulates F_addr with timestamp T, device location number P, and data type D, resulting in Tx = {tx1, tx2, tx3}. Then, it signs the three encapsulated transaction data using the gateway's private key Key_pri.

[0178] Step 4: The edge gateway parses the local shard configuration information file, confirms that the security data is stored in shard n, broadcasts the transaction Tx to the shard network for consensus, and calls the storage contract Shard_S_contract in the shard network (including the Create3DMerkle() method and the M-HASH() method) to perform the on-chain operation.

[0179] Step 5: The cloud server nodes in the sharded network upload the block header and full node IP_list to the DAG blockchain data storage contract DAG_S_contract to perform the on-chain operation.

[0180] Step 6: Enterprise user User1 sends a query request to the backend server via mobile phone: Req = {<...>, <12:00>, <[50, 60]>,<datatype_00001> The server verifies User1's identity and simultaneously parses the three-dimensional query conditions [12:00 / [50,60] / datatype_00001]. The server then calls the two-level index interface to retrieve tx1.

[0181] Step 7: After receiving tx1, the server uses the edge gateway public key Key_pub to verify the correctness of the transaction signature, ensuring that the transaction data has not been tampered with; it then retrieves the real data stored in the IPFS private network based on f1_ipfs_addr in the transaction data and returns it to User1.

[0182] In summary, this invention enables data load balancing for each blockchain shard, improving data throughput and storage scalability, and enhances data query efficiency with the support of DAG blockchain and KD tree data structures.

[0183] Although the present invention 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; and these 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 the present invention.< / d> < / t>

Claims

1. A building IoT data management method based on blockchain sharding and DAG, characterized in that, include: Blockchain sharding network construction steps: Obtain the node performance data of all edge gateways and cloud servers in the building IoT system; based on the node performance data, divide the edge nodes and cloud server nodes into different shards using a preset adaptive load balancing algorithm, generate sharding configuration information files, and save them locally on the nodes; DAG network construction steps: Select edge gateways or cloud servers in each shard with a collection rate higher than a threshold to deploy the DAG blockchain network, and generate a DAG configuration file to be stored locally on the node. Data acquisition and processing steps: The edge gateway collects terminal device data from each intelligent subsystem according to the set sampling frequency. The edge gateway processes the terminal device data to form multiple data files, parses the data files, and stores them in the IPFS private network to obtain the IPFS storage address. Data encapsulation steps: The storage address is encapsulated through the edge gateway, and then the encapsulated data is signed using the node's private key to form a transaction record; Data storage steps: The edge gateway parses the shard configuration information file, confirms the shard corresponding to the edge gateway, and then calls the storage contract corresponding to the encapsulated data type in the transaction record to store it on the blockchain. The blockchain sharding network construction steps include: Step S11: Obtain the node performance data of all edge nodes and cloud servers in the building IoT system, as well as the spatial location and data type number of each node. The node performance data includes the node's computing resources, storage resources, sampled data volume, interaction integration table with other nodes, and network latency. Then, write the node performance data into the node's local configuration file. Step S12: Deploy the blockchain sharding network environment, DAG blockchain network environment, and InterPlanetary File System environment. Use an adaptive load balancing algorithm to divide the nodes of the edge gateway and cloud server into different shards based on node performance data, and write the correspondence between nodes and shards into the local configuration file of the node. Step S12 includes: Step S121: Obtain the performance data set and number of shards for each node; Step S122: Calculate the sampling frequency of each node based on the relationship between the sampling data volume, computing resources and network latency of the node; calculate the load value of each node based on the relationship between the storage resources of the node, the sampling frequency and the computing resources of the node. Step S123: Traverse all nodes. If the load value of a node is lower than the low load standard value, add the node to the low load node set; if the load value of a node is higher than the high load standard value, add the node to the high load node set; add the remaining nodes to the appropriate load set. Step S124: After sorting the high-load node set and the low-load node set according to the set rules, the nodes of the two sets are sequentially assigned to the corresponding shards by taking the remainder of the number of shards, and then each node is updated to the sharded state. Step S125: Calculate the total interaction integral of the nodes in the suitable load set with each shard according to the interaction integral table between nodes, and assign the nodes to the shard with the largest total interaction integral. Step S126: Output the final sharding result and generate a sharding configuration file, which is stored locally on each node and in the DAG blockchain; Step S127: After sharding is completed, the DAG blockchain nodes and the edge gateways or cloud servers for the sharding nodes are responsible for updating the node interaction points table in real time. Every set time interval, the latest storage and computing resources of each node are updated, the sharding load is calculated to determine the sharding status, and if the overheated sharding exceeds a threshold, it is re-sharded.

2. The building IoT data management method as described in claim 1, characterized in that, Also includes: Data query steps: Parse the user's query request to form three-dimensional query conditions of time, device location and data category, obtain a transaction set according to the three-dimensional query conditions, and obtain the terminal device data from the private network according to the storage address of the transaction data in the transaction set.

3. The building IoT data management method as described in claim 1, characterized in that, The data acquisition and processing steps include: Step S31: After generating the public and private keys of the blockchain shard nodes using the elliptic curve algorithm, broadcast the public key to the blockchain shard network; Step S32: By calling the data acquisition interface through the edge gateway, data from terminal devices in each intelligent subsystem connected to the edge gateway are collected in batches according to the sampling frequency; Step S33: The edge gateway converts the collected terminal device data into JSON or XML format and classifies it into multiple data files. The gateway parses the timestamp, device location number, and data type number of the data files according to the local configuration file and stores the data files in the InterPlanetary File System to obtain the storage address.

4. The building IoT data management method as described in claim 3, characterized in that, The data encapsulation step includes: encapsulating the storage address with three dimensions—time stamp, device location number, and data type number—through an edge gateway to obtain encapsulated data, and then using the edge gateway's private key to sign the encapsulated data to form the transaction record.

5. The building IoT data management method as described in claim 4, characterized in that, The data storage steps include: Step S51: After parsing the local sharding configuration information file through the edge gateway and determining the shard to which the edge gateway belongs, the transaction record is broadcast to the designated blockchain sharding network for consensus. The valid transaction records are verified and arranged in order. The 3D-Merkle tree construction method is called to process the transactions confirmed to be stored in the block. After the construction is completed, the M-HASH method is called to generate the 3D-Merkle root hash and encapsulate it into the block header. Step S52: The block header is uploaded to the DAG blockchain network by an edge gateway or cloud server node that also has the identity of a DAG blockchain node in the blockchain sharding network. At the same time, the list of full node IP addresses is added to the block. Then, consensus verification of the block is performed and distributed storage is performed.

6. The building IoT data management method as described in claim 5, characterized in that, Step S51 includes: a) First, construct the transaction set as a 3D-Merkle tree node set; b) Obtain the current 3D-Merkle tree level Depth and node set Node. Calculate the current layer's splitDim by taking the modulo of Depth with the node dimension length. c) Sort the node set in ascending order according to the split dimension splitDim, take the middle node as the root node, the nodes smaller than the middle node as the left subtree nodes of the root, and the nodes larger than the middle node as the right subtree nodes of the root. d) Recursively execute steps b) and c) above for the left and right subtree node sets until all nodes are partitioned.

7. The building IoT data management method as described in claim 6, characterized in that, Step S51 further includes: e) Obtain the Root_node of the 3D-Merkle tree; f) Determine whether the 3D-Merkle tree node Root_node is a leaf node. If it is a leaf node, calculate the hash value of Root_node itself and assign it as the root hash value of the current tree to the M-Hash field of Root_node. If not, assign the left and right subtree nodes to Root_node respectively, recursively execute the aforementioned steps e) and f) to calculate the root hash values ​​of the left and right subtrees, and then concatenate the root hash values ​​of the left and right subtrees with the hash value of Root_node itself to finally obtain the 3D-Merkle root hash.

8. The building IoT data management method as described in claim 2, characterized in that, The data query step also includes: Step S61: The user initiates a query request to the backend server through the terminal device. The server verifies the user's identity, parses the query request to form three-dimensional query conditions with time, spatial location and data category, and the server calls the two-level index interface to quickly obtain the transaction set that meets the query conditions. Step S62: After receiving the transaction set, the server uses the public key of the corresponding edge gateway node to verify the transaction signature, then retrieves the real data stored in the IPFS private network according to the storage address in the transaction data, and returns it to the user.

Images