Fragmented block chain construction method and system in multi-level Internet of Things

Abstract

The invention belongs to the technical field of Internet of Things, and particularly relates to a fragment block chain construction method and system in a multi-level Internet of Things, and the system comprises a cloud edge fragment and an edge end fragment. The cloud edge fragment comprises a cloud server and is configured as a consensus node, and the edge end fragment comprises an Internet of Things gateway and Internet of Things terminal equipment and is configured as a light node or a synchronous node; the edge server is used as the edge of the cloud edge fragment and the edge end fragment at the same time, and is configured as a synchronous node; the method has the advantages that a block chain fragmentation framework based on'cloud edge fragmentation 'and'edge end fragmentation' is provided to improve the throughput of a block chain system, the scalability of the block chain is improved by using a fragmentation technology, transaction processing workloads are divided into node groups by adopting a'divide-and-conquer 'method and fragmentation, and the throughput of the block chain system is improved. Therefore, the limitation of performance and flexibility is overcome.

Description

Technical Field

[0001] The present application belongs to the technical field of Internet of Things, and specifically relates to a sharded blockchain construction method and system in a multi-level Internet of Things. Background Art

[0002] Blockchain sharding represents a feasible technology to improve blockchain throughput and reduce latency. Currently, there are three main blockchain sharding technologies. State Sharding can significantly improve transaction processing capabilities. By dividing the blockchain state into multiple parts, transactions can be processed in parallel, reducing latency. However, its cross-shard transactions are more complex and require additional mechanisms to ensure consistency and reliability between different shards. In addition, the storage and computing burden of nodes is increased, which may lead to uneven resource allocation. Transaction Sharding can reduce competition and improve transaction processing efficiency by allocating transactions to different shards by type. It also faces the challenge of cross-shard transactions, and the order and state consistency of transactions are difficult to guarantee. In addition, some shards may be overloaded, affecting overall performance. Network Sharding can increase consensus speed and reduce network latency by dividing nodes into independent groups. However, how to effectively allocate and manage nodes to maintain load balancing is an important proposition. Summary of the invention

[0003] In order to solve the above challenges, this paper introduces a sharded blockchain construction method in a multi-level IoT. It adopts the ideas of "cloud-edge sharding" and "edge-end sharding". Its technical solution is:

[0004] A sharded blockchain construction method in a multi-level Internet of Things is provided, wherein physical devices in the Internet of Things are sharded, including cloud-edge sharding and edge-end sharding; the cloud-edge sharding includes a cloud server configured as a consensus node, and the edge-end sharding includes an Internet of Things gateway and an Internet of Things terminal device configured as a light node or a synchronization node; the edge server serves as the edge of both the cloud-edge sharding and the edge-end sharding, and is configured as a synchronization node.

[0005] Preferably, for cloud-edge sharding, the PBFT consensus mechanism is used within the shard to allow nodes in the network to reach consensus even when there are some malicious nodes;

[0006] For edge sharding, the SBFT consensus mechanism is used within the shard to tolerate Byzantine failures while reducing communication overhead.

[0007] Preferably, the transaction routing of the cloud edge sharding adopts a routing strategy based on the transaction location, that is, the closest cloud edge sharding is selected according to the location information of the uploaded transaction to reduce latency and bandwidth consumption.

[0008] The routing strategy of edge sharding is to dynamically select the target shard based on the current status of each shard within the edge sharding, and the shard with lighter load will give priority to receiving new transaction requests.

[0009] Preferably, a cross-shard communication mechanism is introduced between the cloud edge shards: when multiple shards are involved, the edge servers of all relevant shards need to participate in consensus and conduct multiple rounds of voting to ensure that all relevant shards agree on the validity of the transaction. Once a cross-shard transaction is agreed upon in all relevant shards, the status of each shard needs to be updated synchronously, and the transaction results and updated status information need to be returned to the device that initiated the transaction and updated to the storage of each shard.

[0010] Preferably, the cross-shard communication mechanism of edge shards: In edge shards, light nodes are responsible for generating transactions within the shards and submitting them to the gateway nodes, and the gateway nodes are responsible for identifying whether the transactions need to be processed across shards. When performing cross-shard processing, the gateway node sends a cross-shard request to the edge server, obtains the information of the target shard, and transmits the transaction to the target shard after establishing a channel; each consensus node of the target shard verifies the legitimacy of the transaction, and after confirming the transaction through the consensus algorithm, feeds the result back to the source shard and updates it to the storage of each shard.

[0011] Preferably, the edge sharding division strategy is: according to the computing power and storage resources of the nodes, the geographical location of the nodes, and the transaction characteristics of the nodes, the edge server devices, gateways, and IoT terminal devices are divided into multiple shards, and the number of nodes and node selection of the edge shards and the adaptive DRL-based sharding strategy are used to update and iterate.

[0012] Preferably, the adaptive DRL algorithm calculation steps are as follows:

[0013] S1. Initialize system parameters and perform the following operations for each iteration period episode∈[1,episode_max]:

[0014] S2. Receive initial state s t , including the computing resources, storage space, network latency and transaction load of each blockchain node;

[0015] S3. For t∈[1,epoch_max] in the current iteration epoch, through a t =μ(s t |θ μ )+N t Select and execute, where a t Indicates the best sharding solution currently considered by the system;

[0016] S4. Observe reward r t And update the status s t+1, where s t+1 It is a score calculated based on indicators such as transaction efficiency, network latency, and resource utilization after sharding. The higher the score, the better the sharding strategy.

[0017] S5. t ,a t ,r t ,s t+1 ) is stored in the replay buffer R, and a small batch of R' is randomly sampled from the replay buffer R;

[0018] S6. For each transaction of R', calculate its reward function y i , the formula is as follows:

[0019] y i =r i +γQ'(s i+1 ,μ'(s i+1 |θ μ' )|θ Q' );

[0020] Where γ is the discount factor, representing the importance of the reward;

[0021] S7. Update the value network by minimizing the loss function L and optimizing the random parameter θ Q :

[0022]

[0023] M is the sample size;

[0024] S8. Update the policy network using the sampled policy gradient to optimize the random parameter Q μ :

[0025]

[0026] Random parameter θ μ and θ Q ,strategy network μ and value network Q;

[0027] S9. Update the target network with τ:

[0028] θ Q′ ←τθ Q +(1-τ)θ Q′ ,

[0029] θ μ′ ←τθ μ +(1-τ)θ μ′

[0030] The target network Q' and μ', τ is the update speed of network parameters;

[0031] S9. The current number of iterations epoch_max reaches the number of iterations episode_max, the algorithm ends, and the optimal sharding solution a is output t , used for real-time scheduling and resource allocation in sharded blockchain systems.

[0032] Preferably, in step S1, the strategy network μ and the value network Q are initialized, using random parameters θ μ and θ Q , initialize the target network Q' and μ', set θ Q′ ←θ Q and θ μ′ ←θ μ , initialize the replay buffer R to store the experience of each step to facilitate subsequent sample extraction and network update;

[0033] In an iteration cycle episode, the random noise N used for action exploration is initialized, that is, the random noise action includes adjusting the computing resources or storage space of the device resources, changing the network topology of the device, and adjusting the transaction load size of the device.

[0034] A sharded blockchain system in a multi-level Internet of Things, including a cloud server, an edge server, an Internet of Things terminal device, and a gateway;

[0035] Cloud servers and edge servers form cloud-edge shards; edge servers, IoT terminal devices, and gateways form edge-end shards, with gateways acting as bridges between IoT terminal devices and edge servers.

[0036] The cloud server is responsible for storing global data, running deep analysis models, and executing long-term tasks. It is set as a consensus node to participate in consensus voting, transaction execution, block verification, and accounting in the blockchain network.

[0037] Edge servers are close to data sources, participate in block and transaction synchronization, block verification, transaction execution, and record complete ledger data, but do not participate in consensus voting and are configured as synchronization nodes;

[0038] IoT terminal devices and gateways are set as light nodes or synchronization nodes according to their computing capabilities. Light nodes are used to participate in synchronization and verify block header information and verify the existence of transactions.

[0039] Preferably, the edge server devices, gateways and IoT terminal devices are divided into multiple shards according to the computing power and storage resources of the nodes, the geographical location of the nodes, and the transaction characteristics of the nodes; the initial division strategy for each shard is that n edge servers, 2n IoT gateways, and 5n IoT terminal devices form a shard, and these nodes process related transactions internally;

[0040] When uploading a transaction, the transaction request is usually sent to the consensus node, which verifies and processes it, and then returns the result to the light node. Its transaction routing adopts load-based routing, dynamically selecting the transaction route according to the current load status of the edge server to avoid overload.

[0041] The routing strategy of edge sharding is to dynamically select the target shard based on the current state of the shard, and the shard with lighter load will receive new transaction requests first.

[0042] Compared with the prior art, the present invention has the following beneficial effects:

[0043] Blockchain Sharding Framework for Multi-level Internet of Things. We proposed a blockchain sharding framework based on "cloud-edge sharding" and "edge-end sharding" to improve the throughput of blockchain systems. Sharding technology is used to improve blockchain scalability. Sharding divides transaction processing workloads into node groups by adopting a "divide and conquer" approach, thereby overcoming performance and scalability limitations.

[0044] Blockchain sharding strategy based on DRL. In order to solve the load balancing problem caused by the heterogeneity of cloud-edge resources in the blockchain sharding architecture of multi-level IoT, we use an algorithm based on deep reinforcement learning (DRL) to formulate a joint optimization problem based on device capabilities, network topology, and transaction load for local optimization to ensure that the overall network can achieve optimal performance in all states. By training the model, we can learn the optimal sharding configuration under different network conditions, while improving the throughput and security of the blockchain system. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] Figure 1 This is the overall architecture diagram of the multi-level Internet of Things.

[0046] Figure 2 A diagram of a sharded blockchain system for multi-level IoT. DETAILED DESCRIPTION

[0047] The technical solution of the present application is described in detail below through specific embodiments and drawings. It should be understood that the embodiments of the present application and the specific features in the embodiments are detailed descriptions of the technical solution of the present application, rather than limitations on the technical solution of the present application, and the specific technical features may be combined with each other.

[0048] 1.1 Sharded blockchain system in multi-level IoT

[0049] A sharded blockchain system in a multi-level Internet of Things includes a cloud server, an edge server, an Internet of Things terminal device, and a gateway. The Internet of Things gateway, the cloud server, and the edge server can carry full-function nodes, and the Internet of Things terminal devices with limited capabilities can be connected to the blockchain through the Internet of Things gateway, or carry lightweight blockchain nodes to participate in the system. Since the characteristics and functions of the Internet of Things entity are directly related to its node division in the blockchain, a brief description of the characteristics of the above-mentioned Internet of Things entities is given.

[0050] Cloud Server:

[0051] With powerful computing and storage capabilities, it can process large amounts of data and run complex algorithms. It provides high bandwidth, high storage capacity, and high computing resources, suitable for large-scale data processing and analysis. Centralized data management and control, suitable for complex data analysis, machine learning, and deep learning tasks.

[0052] Edge Server:

[0053] Being close to the data source enables fast data processing and response, reducing latency. Before data is transmitted to the cloud server, it performs preliminary processing and screening on the data to reduce bandwidth consumption. Compared with the cloud server, it has fewer computing and storage resources, but still has the ability to handle some local tasks. It supports real-time data processing and can run simple smart contracts.

[0054] Gateway:

[0055] Acting as a bridge between IoT devices and the cloud or edge server, it is responsible for data collection and forwarding. Some gateways also have edge computing capabilities, which can process and analyze data locally, reducing the burden on backend servers. It can centrally manage multiple IoT devices and simplify device configuration and monitoring.

[0056] IoT terminal devices:

[0057] Usually has small storage and computing capabilities, relying on edge servers or cloud servers for data processing. Responsible for data collection and monitoring, such as sensors, cameras, smart home devices, etc. Can execute simple control commands, usually without complex decision-making capabilities.

[0058] 1.2 Node Types of Sharded Blockchain in Multi-Level IoT

[0059] In the Internet of Things (IoT) scenario, blockchain networks contain multiple types of nodes that differ in functionality and resources to suit specific application requirements and network architecture.

[0060] Consensus node: A full node that participates in consensus voting, transaction execution, block verification, and bookkeeping in a blockchain network.

[0061] Sync node: Participates in block and transaction synchronization, block verification, transaction execution, and records complete ledger data, but does not participate in consensus voting. Light node: Participates in synchronization and verification of block header information, and verifies the existence of transactions.

[0062] 1.3 Consensus Protocol for Sharded Blockchain in Multi-Level IoT

[0063] The sharded blockchain system in the multi-level Internet of Things is mainly divided into "cloud-edge sharding" and "edge sharding".

[0064] For cloud-edge sharding, the sharded blockchain that uses the PBFT (Practical Byzantine Fault Tolerance) consensus mechanism can effectively improve the security and performance of the system, aiming to allow nodes in the network to reach consensus even when there are some malicious nodes. Its core idea is to ensure the consistency and security of transactions by all honest nodes through multiple communication rounds.

[0065] For edge sharding, the sharded blockchain that uses the SBFT (Simplified Byzantine Fault Tolerance) consensus mechanism improves efficiency and performance, and is suitable for blockchain application scenarios with high speed requirements. While tolerating Byzantine faults, it strives to reduce communication overhead and improve system throughput.

[0066] 1.4 Construction of Sharded Blockchain in Multi-Level IoT

[0067] In the multi-level Internet of Things, the adoption of cloud-edge sharding and edge-end sharding solutions can effectively improve the scalability, real-time performance and resource utilization efficiency of the system as a whole. Figure 2 It is a sharded blockchain system in a multi-level Internet of Things.

[0068] 1.4.1 Cloud-edge Sharding

[0069] In the multi-level Internet of Things, cloud-edge sharding is an important architectural design that distributes data processing and storage between cloud servers and edge servers to improve system efficiency, reduce latency, and optimize resource utilization. In cloud-edge sharding, due to the limited number of nodes and strong performance, fewer transactions are involved, so cloud-edge sharding is responsible for participating in consensus voting, transaction execution, block verification, execution of smart contracts, and bookkeeping in the blockchain network.

[0070] Cloud-edge sharding is to shard cloud servers and edge servers. The former has powerful computing and storage capabilities and is suitable for processing complex tasks and large-scale data. Cloud servers are usually responsible for storing global data, running deep analysis models, and executing long-term tasks, so they are set as consensus full nodes in this system. The latter is close to the data source and is set as a synchronization node due to limited performance.

[0071] The system will divide cloud server devices and edge servers into one shard based on the computing power and storage resources of the nodes, the geographical location of the nodes, and the transaction characteristics of the nodes.

[0072] Secondly, the transaction routing of cloud-edge sharding adopts routing based on transaction location. Since there are often latency issues between cloud server nodes and edge server nodes, the routing strategy of cloud-edge sharding is to select the closest server based on the location information of the uploaded transaction to reduce latency and bandwidth consumption.

[0073] In order to maintain coordination and consistency between cloud-edge shards, the system introduces a cross-shard communication mechanism. When multiple shards are involved, the edge servers of all relevant shards must participate in consensus and conduct multiple rounds of voting to ensure that all relevant shards agree on the validity of the transaction. Once a cross-shard transaction is agreed upon in all relevant shards, the status of each shard must be updated synchronously, and the transaction results and updated status information must be returned to the device that initiated the transaction and updated to the storage of each shard. This mechanism ensures that transactions within a shard can interact with other shards securely and effectively.

[0074] 1.4.2 Edge Sharding

[0075] In the multi-level Internet of Things, the architecture design of edge sharding takes advantage of the fact that edge servers are close to data sources and can achieve fast data processing and response. Gateways are used as bridges between IoT terminal devices and edge servers to centrally manage multiple IoT devices and collect and forward data. When performing edge sharding, due to the large number of nodes and weak performance, and the large number of transactions involved, the edge servers in the edge sharding are mainly involved in block and transaction synchronization, block verification, and transaction execution, while other light nodes are involved in synchronizing and verifying block header information and verifying the existence of transactions.

[0076] Edge sharding is to shard each node of edge servers, IoT gateways, and IoT terminal devices. The former is located at the edge of the network close to the terminal device, responsible for real-time data processing, smart contract execution, and local storage of each light node in the chip, and is set as a synchronization node. The latter is limited by resources and can only do some simple data collection, upload, verification, etc., and is set as a light node.

[0077] If the computing power of the gateway and IoT terminal devices is strong, they can be used as synchronization nodes.

[0078] The system will divide edge server devices, gateways, and IoT terminal devices into multiple shards based on the computing power and storage resources of the nodes, the geographical location of the nodes, and the transaction characteristics of the nodes. The initial division strategy for each shard is that 1 edge server, 2 IoT gateways, and 5 IoT terminal devices form a shard, and these nodes process related transactions internally. After the system runs based on a certain amount of data, it will use the DRL-based sharding strategy to update and iterate the number of nodes in the shard and the node selection of the shard.

[0079] Secondly, unlike the transaction method of cloud-edge sharding, due to the existence of light nodes in edge sharding, it mainly relies on full nodes for data verification and transaction processing. When uploading transactions, transaction requests are usually sent to full nodes for verification and processing, and then the results are returned to light nodes. Its transaction routing adopts load-based routing, dynamically selecting transaction routes according to the current load status of the edge server to avoid overload. Therefore, the routing strategy of edge sharding is to dynamically select the target shard based on the current status of the shard, and the shard with lighter load will receive new transaction requests first.

[0080] Next is the dynamic adjustment of shards. Changes in IoT devices (such as the addition or departure of devices, performance changes, etc.) also need to be monitored in real time. The system can continuously optimize shard configurations based on real-time feedback and historical data through intelligent algorithms to ensure efficient use of resources. When the load on a shard is too high, the system can automatically adjust and distribute some transactions to other shards with lighter loads.

[0081] 2. Blockchain sharding strategy based on DRL

[0082] Sharding has become a popular technology used in blockchain, which enhances scalability by dividing blockchain nodes into multiple smaller partitions that can process transactions in parallel, thereby enhancing TPS. All sharding systems assume that all blockchain nodes are stable and homogeneous in a peer-to-peer network; therefore, they adopt random and static sharding strategies, which randomly assign blockchain nodes to different shards with fixed sharding settings. However, such sharding strategies are not suitable for IoT blockchain systems with dynamic and diverse features. The second is the random sharding strategy, which can only obtain probabilistic security guarantees at the beginning of shard formation. It cannot balance throughput and security when sharding heterogeneous IoT blockchains for a long time.

[0083] Therefore, a key issue is to partition the shards in a novel adaptive and dynamic way so as to achieve a long-term balanced trade-off between throughput and security in dynamic and heterogeneous IoT blockchain scenarios. Using a deep reinforcement learning (DRL)-based algorithm, a joint optimization problem is formulated according to device capabilities, network topology, and transaction load for local optimization to ensure that the overall network can achieve optimal performance in all states to obtain the best sharding strategy.

[0084] Sharding decision optimization for deep reinforcement learning on specific networks

[0085] Introducing deep reinforcement learning (DRL) to perform joint optimization based on device capabilities, network topology, and transaction load can significantly improve the efficiency and reliability of the system.

[0086] First, the core of the joint optimization problem is to define the state space, action space, and reward function, which play a crucial role in deep reinforcement learning.

[0087] State Space

[0088] In the state space S, we define the state as a vector that includes device capabilities, network topology, and transaction load. Device capabilities can be quantified by the computing power, storage capacity, and bandwidth of each IoT device, network topology can be represented by the connection relationship and latency between nodes, and transaction load can be represented as the number and type of transactions in each shard in the current network. This multi-dimensional state space design enables the deep reinforcement learning model to fully capture the dynamic changes of the system and the complex relationship between various indicators, thereby providing strong support for the formulation of efficient blockchain sharding strategies.

[0089] Action Space

[0090] In action space A, we need to define specific actions that the model can take, adjust device capabilities (affect the processing power of the device by allocating computing resources or storage space), optimize network topology (dynamically adjust the connection between nodes according to network latency and connection quality), and manage transaction load (dynamically allocate or reorganize according to the transaction volume of each shard). This flexible action space enables the model to adaptively adjust to different environmental conditions and goals to achieve optimal performance.

[0091] Reward Function

[0092] Defining the reward function is a key step in implementing deep reinforcement learning. This function will comprehensively consider factors such as device capabilities, network topology, and transaction load. Rewards can be constructed by evaluating the overall performance of the system. If the system can effectively utilize the computing and storage resources of the device, optimize network connections, and process high-load transactions within a reasonable time, positive rewards will be given; negative rewards will be given when the system is overloaded, network latency increases, or transactions are not processed in a timely manner. This design ensures that the reward function can fully reflect the actual situation of the system operation, thereby guiding the model towards the optimization goal.

[0093] This design enables the deep reinforcement learning model to balance the trade-offs between different indicators in the multi-objective optimization process to find the best strategy. To achieve this goal, we use the deep deterministic policy gradient (DDPG) deep reinforcement learning algorithm, the algorithm flow is as follows, where the input includes the computing resources of the node device, the storage space of the node device, the network delay of the node device, and the transaction load of the node:

[0094] The adaptive DRL algorithm calculation steps are as follows:

[0095] 1) Initialize the policy network μ and the value network Q, using random parameters θ μ and θ Q ;

[0096] 2) Initialize the target network Q' and μ', set θ Q′ ←θ Q and θ μ′ ←θ μ ;

[0097] 3) Initialize the replay buffer R to store the experience of each step to facilitate subsequent sample extraction and network update;

[0098] 4) For each iteration episode∈[1,episode_max], perform the following operations:

[0099] 5) In this iteration cycle episode, initialize the random noise N used for action exploration, that is, the random noise action includes adjusting the computing resources or storage space of the device resources, changing the network topology of the device, and adjusting the transaction load size of the device;

[0100] 6) In this episode, the initial observation state s1 is received, which includes the computing resources, storage space, network latency, and transaction load of each blockchain node;

[0101] 7) For each epoch t∈[1,epoch_max], perform the following operations:

[0102] 8) Through at =μ(s t |θ μ )+N t Select and execute, where a t Indicates the best sharding solution currently considered by the system;

[0103] 9) Observe the reward r t And update the status s t+1 , where s t+1 It is a score calculated based on indicators such as transaction efficiency, network latency, and resource utilization after sharding. The higher the score, the better the sharding strategy.

[0104] 10) will (s t ,a t ,r t ,s t+1 ) is stored in the replay buffer R;

[0105] 11) Randomly sample a small batch R' from the replay buffer R;

[0106] 12) For each transaction of R', perform the following operations:

[0107] 13)y i =r i +γQ'(s i+1 ,μ'(s i+1 |θ μ' )|θ Q' ),

[0108] Where γ is the discount factor, representing the importance of the reward; y i Reward function;

[0109] 14) Update the value network by minimizing the loss function and optimizing the random parameter θ Q :

[0110]

[0111] 15) Use the sampled policy gradient to update the policy network and optimize the random parameter θ μ :

[0112]

[0113] M is the sample size;

[0114] 16) Update the target network with τ:

[0115] θ Q′ ←τθ Q +(1-τ)θ Q′ ,

[0116] θμ′ ←τθ μ +(1-τ)θ μ′

[0117] τ is the update speed of the network parameters, called the step size, which is a value between 0 and 1.

[0118] 17) End the inner loop (episode);

[0119] 18) End the outer loop (episode);

[0120] 19) End the algorithm and output the optimal sharding solution a t , used for real-time scheduling and resource allocation in sharded blockchain systems.

[0121] The strategy is updated by continuously interacting with the environment. In each training step, the model will select an action from the current state and interact with the environment to obtain a new state and corresponding reward. Through this feedback mechanism, the model can update its strategy and gradually improve its decision-making ability in different states. As training progresses, the deep reinforcement learning model will gradually learn how to best adjust device capabilities and optimize network topology in different situations, thereby improving the overall efficiency and reliability of the blockchain system. In particular, for the adjustment of device capabilities, the model can predict the optimal allocation of resources through historical data and real-time feedback, so that computing resources can be appropriately increased when the device load is high, and vice versa, to ensure the stable operation of the network. At the same time, in terms of optimizing the network topology, the model can learn how to flexibly adjust the connection between nodes under different network conditions and transaction loads to minimize latency and improve the system's response speed, especially when the network is congested or potential failures occur, and can adjust the strategy in time to optimize the efficiency of resource use.

[0122] The above is only a preferred implementation of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the technical principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A method for constructing a sharded blockchain in a multi-level Internet of Things, characterized in that: Sharding of physical devices in the IoT, including cloud-edge sharding and edge-end sharding; The cloud-edge shards include cloud servers, which are configured as consensus nodes, and the edge shards include IoT gateways and IoT terminal devices, which are configured as light nodes or synchronization nodes; The edge server serves as the edge of both cloud-edge sharding and edge-end sharding and is configured as a synchronization node.

2. The method for constructing a sharded blockchain in a multi-level Internet of Things according to claim 1, characterized in that: For cloud-edge sharding, the PBFT consensus mechanism is used within the shard to allow nodes in the network to reach consensus even when there are some malicious nodes; For edge sharding, the SBFT consensus mechanism is used within the shard to tolerate Byzantine failures while reducing communication overhead.

3. The method for constructing a sharded blockchain in a multi-level Internet of Things according to claim 1, characterized in that: The transaction routing of cloud edge shards adopts a routing strategy based on transaction location, that is, the closest cloud edge shard is selected according to the location information of the uploaded transaction to reduce latency and bandwidth consumption; The routing strategy of edge sharding is to dynamically select the target shard based on the current status of each shard within the edge sharding, and the shard with lighter load will give priority to receiving new transaction requests.

4. The method for constructing a sharded blockchain in a multi-level Internet of Things according to claim 1, characterized in that: A cross-shard communication mechanism is introduced between the cloud-edge shards: When multiple shards are involved, the edge servers of all relevant shards need to participate in reaching consensus and conduct multiple rounds of voting to ensure that all relevant shards reach an agreement on the validity of the transaction. Once a cross-shard transaction is agreed upon in all relevant shards, the status of each shard needs to be updated synchronously, and the transaction results and updated status information need to be returned to the device that initiated the transaction and updated to the storage of each shard.

5. The method for constructing a sharded blockchain in a multi-level Internet of Things according to claim 1, characterized in that: Cross-shard communication mechanism of edge shards: In edge shards, light nodes are responsible for generating transactions within the shards and submitting them to gateway nodes. Gateway nodes are responsible for identifying whether transactions need to be processed across shards. When performing cross-shard processing, the gateway node sends a cross-shard request to the edge server, obtains the target shard’s information, and transmits the transaction to the target shard after establishing a channel; Each consensus node of the target shard verifies the legitimacy of the transaction, and after confirming the transaction through the consensus algorithm, feeds the result back to the source shard and updates it to the storage of each shard.

6. The method for constructing a sharded blockchain in a multi-level Internet of Things according to claim 1, characterized in that: The edge sharding division strategy is: according to the computing power and storage resources of the nodes, the geographical location of the nodes, and the transaction characteristics of the nodes, the edge server devices, gateways, and IoT terminal devices are divided into multiple shards, and the number of nodes and node selection of the edge shards are updated and iterated using the adaptive DRL-based sharding strategy.

7. The method for constructing a sharded blockchain in a multi-level Internet of Things according to claim 6, characterized in that: The adaptive DRL algorithm calculation steps are as follows: S1. Initialize system parameters and perform the following operations for each iteration period episode∈[1,episode_max]: S2. Receive initial state s t , including the computing resources, storage space, network latency and transaction load of each blockchain node; S3. For t∈[1,epoch_max] in the current iteration epoch, through a t =μ(S t |θ μ )+N t Select and execute, where a t Indicates the best sharding solution currently considered by the system; S4. Observe reward r t And update the status s t+1 , where s t+1 It is a score calculated based on indicators such as transaction efficiency, network latency, and resource utilization after sharding. The higher the score, the better the sharding strategy. S5. t ,a t ,r t ,s t+1 ) is stored in the replay buffer R, and a small batch of R′ is randomly sampled from the replay buffer R; S6. For each transaction of R', calculate its reward function y i , the formula is as follows: y i =r i +γQ'(s i+1 ,m'(s i+1 |θ μ' )|θ Q' ); Where γ is the discount factor, representing the importance of the reward; S7. Update the value network by minimizing the loss function L and optimizing the random parameter θ Q : M is the sample size; S8. Update the policy network using the sampled policy gradient to optimize the random parameter θ μ : Random parameter θ μ and θ Q ,strategy network μ and value network Q; S9. Update the target network with τ: i Q′ ←tth Q +(1-τ)θ Q′ , i μ′ ←tth μ +(1-τ)θ μ′ The target network Q' and μ', τ is the update speed of network parameters; S9. The current number of iterations epoch_max reaches the number of iterations episode_max, the algorithm ends, and the optimal sharding solution a is output t , used for real-time scheduling and resource allocation in sharded blockchain systems.

8. The method for constructing a sharded blockchain in a multi-level Internet of Things according to claim 6, characterized in that: In step S1, the policy network μ and the value network Q are initialized using random parameters θ μ and θ Q , initialize the target network Q' and μ', set θ Q′ ←θ Q and θ μ′ ←θ μ , initialize the replay buffer R to store the experience of each step to facilitate subsequent sample extraction and network update; In an iteration cycle episode, the random noise N used for action exploration is initialized, that is, the random noise action includes adjusting the computing resources or storage space of the device resources, changing the network topology of the device, and adjusting the transaction load size of the device.

9. A sharded blockchain system in a multi-level Internet of Things, characterized in that: A sharded blockchain construction method in a multi-level Internet of Things according to any one of claims 1 to 8, comprising a cloud server, an edge server, an Internet of Things terminal device, and a gateway; Cloud servers and edge servers form cloud-edge shards; The edge server, IoT terminal devices, and gateways constitute edge sharding. The gateway acts as a bridge between IoT terminal devices and edge servers. The cloud server is responsible for storing global data, running deep analysis models, and executing long-term tasks. It is set as a consensus node to participate in consensus voting, transaction execution, block verification, and accounting in the blockchain network. Edge servers are close to data sources, participate in block and transaction synchronization, block verification, transaction execution, and record complete ledger data, but do not participate in consensus voting and are configured as synchronization nodes; IoT terminal devices and gateways are set as light nodes or synchronization nodes according to their computing capabilities. Light nodes are used to participate in synchronization and verify block header information and verify the existence of transactions.

10. The sharded blockchain system in the multi-level Internet of Things according to claim 9, characterized in that: According to the computing power and storage resources of the nodes, the geographical location of the nodes, and the transaction characteristics of the nodes, the edge server devices, gateways, and IoT terminal devices are divided into multiple shards; the initial division strategy for each shard is that n edge servers, 2n IoT gateways, and 5n IoT terminal devices form a shard, and these nodes process related transactions internally; When uploading a transaction, the transaction request is usually sent to the consensus node, which verifies and processes it and then returns the result to the light node; Its transaction routing adopts load-based routing, dynamically selecting transaction routes according to the current load status of the edge server to avoid overload; The routing strategy of edge sharding is to dynamically select the target shard based on the current state of the shard, and the shard with lighter load will receive new transaction requests first.

Images