Sharding blockchain construction method and system in multi-level internet of things

Abstract

The application belongs to the technical field of Internet of Things, and particularly relates to a method and system for constructing a sharded blockchain in a multi-level Internet of Things, comprising cloud-edge sharding and edge-end sharding; the cloud-edge sharding comprises a cloud server configured as a consensus node, and the edge-end sharding comprises an Internet of Things gateway and an Internet of Things terminal device configured as a light node or a synchronization node; an edge server simultaneously serves as an edge of the cloud-edge sharding and the edge-end sharding and is configured as a synchronization node; the application has the advantages that a blockchain sharding framework based on the cloud-edge sharding and the edge-end sharding is provided to improve the throughput of the blockchain system, the sharding technology is used to improve the scalability of the blockchain, and the sharding divides transaction processing workloads into node groups by using the method of divide and conquer, so that the performance and scalability limitations are overcome.

Description

TECHNICAL FIELD

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

[0002] Sharding of blockchain represents a feasible technology to improve the throughput of blockchain and reduce the delay. At present, there are mainly the following three sharding technologies of blockchain. State sharding can significantly improve the transaction processing capacity, by dividing the blockchain state into multiple parts, so that transactions can be processed in parallel, reducing the delay. However, the complexity of cross-shard transactions is high, and additional mechanisms are needed 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 distributing transactions by type to different shards. However, 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 experience overload, affecting overall performance. Network sharding can improve consensus speed and reduce network delay by dividing nodes into independent groups. However, how to effectively allocate and manage nodes to maintain load balancing is an important issue. SUMMARY

[0003] In order to solve the above challenges, a sharded blockchain construction method in a multi-level Internet of Things is introduced, which adopts the ideas of "cloud-edge sharding" and "edge-end sharding". The technical scheme is as follows:

[0004] A sharded blockchain construction method in a multi-level Internet of Things, which shards the entity devices in the Internet of Things, 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 simultaneously serves as the edge of the cloud-edge sharding and the edge-end sharding, and is configured as a synchronization node.

[0005] Preferably, for the cloud-edge sharding, the PBFT consensus mechanism is adopted within the shard to allow the nodes in the network to reach an agreement in the presence of partial malicious nodes.

[0006] For the edge-end sharding, the SBFT consensus mechanism is adopted within the shard, which tolerates Byzantine faults while reducing communication overhead.

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

[0008] The routing strategy of edge-end fragmentation is to dynamically select the target fragment according to the current state of each fragment in the edge-end fragmentation, and the fragment with lighter load is preferred to receive new transaction requests.

[0009] Preferably, a cross-fragment communication mechanism is introduced between each fragment of the cloud edge: in the case of involving multiple fragments, the edge servers of all related fragments need to participate in consensus reaching and conduct multiple rounds of voting to ensure that all related fragments reach an agreement on the validity of the transaction. Once the cross-fragment transaction obtains consensus in all related fragments, the state of each fragment needs to be updated synchronously, and the transaction result and the updated state information need to be returned to the device initiating the transaction and updated to the storage of each fragment.

[0010] Preferably, the cross-fragment communication mechanism of edge-end fragmentation: in edge-end fragmentation, the light node is responsible for generating transactions within the fragment and submitting them to the gateway node, and the gateway node is responsible for identifying whether the transaction needs to be processed across fragments. When cross-fragment processing is performed, the gateway node sends a cross-fragment request to the edge server to obtain the information of the target fragment, and after establishing a channel, the transaction is transmitted to the target fragment; each consensus node of the target fragment verifies the legality of the transaction, and after confirming the transaction through a consensus algorithm, the result is fed back to the source fragment, and updated to the storage of each fragment.

[0011] Preferably, the division strategy of edge-end fragmentation is: according to the computing power and storage resources of the node, the geographical location of the node, and the transaction characteristics of the node, the edge server device, the gateway and the Internet of Things terminal device are divided into multiple fragments, and the adaptive DRL-based fragmentation strategy is used to update and iterate the number of nodes of edge-end fragmentation and the selection of nodes of fragments.

[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 the initial state s t , including the computing resources, storage space, network delay and transaction load of each node of the blockchain;

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

[0016] S4. Observe the reward r t and update the state s t+1where s t+1 is the score calculated according to the efficiency of the transaction after sharding, network delay, resource utilization, etc. The higher the score, the better the sharding strategy.

[0017] S5. Store (s t , a t , r t , s t+1 ) in the replay buffer R, and randomly sample a small batch R' from the replay buffer R;

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

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

[0020] where γ is a discount factor representing the importance of the reward;

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

[0022]

[0023] M is the number of samples;

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

[0025]

[0026] Random parameters θ μ and θ Q , policy network μ and value network Q;

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

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

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

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

[0031] S9. If the current iteration number epoch_max reaches the iteration cycle episode_max, end the algorithm, and output the optimal sharding scheme a t , for real-time scheduling and resource allocation of a sharding blockchain system.

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

[0033] In an iteration cycle episode, a random noise N for action exploration is initialized, that is, a 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 sharding 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;

[0035] The cloud server and the edge server form a cloud-edge sharding; the edge server and the Internet of Things terminal device and the gateway form an edge-end sharding, and the gateway acts as a bridge between the Internet of Things terminal device and the edge server;

[0036] The cloud server is responsible for storing global data, running a deep analysis model, and executing long-period tasks, and is set as a consensus node for participating in consensus voting, transaction execution, block verification, and accounting in the blockchain network;

[0037] The edge server is close to the data source, participates in block and transaction synchronization, block verification, transaction execution, and records complete ledger data, but does not participate in consensus voting, and is configured as a synchronization node;

[0038] The Internet of Things terminal device and the gateway are set as light nodes or synchronization nodes according to their computing power, and the light nodes are used for participating in synchronization and checking block header information and verifying transaction existence.

[0039] Preferably, the edge server device, the gateway, and the Internet of Things terminal device 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; each shard is initially divided into n edge servers, 2n gateways, and 5n Internet of Things terminal devices to form a shard, and these nodes process related transactions internally.

[0040] When uploading transactions, the transaction request is usually sent to the consensus node for verification and processing, and then the result is returned to the light node; its transaction routing adopts load-based routing, dynamically selects transaction routing according to the current load state of the edge server, to avoid overload;

[0041] The routing strategy of the end-to-end sharding is to dynamically select the target shard according to the current state of the shard, and the shard with lighter load is preferred to receive new transaction requests.

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

[0043] Blockchain sharding framework under multi-level Internet of Things. We propose a blockchain sharding framework based on "cloud-edge sharding" and "edge-end sharding" to improve the throughput of the blockchain system. The sharding technology is used to improve the scalability of the blockchain, and by adopting the "divide and conquer" method, the sharding divides the transaction processing workload into node groups, thereby overcoming the performance and scalability limitations.

[0044] Blockchain sharding strategy based on DRL. To solve the load balancing problem caused by the heterogeneity of cloud-edge-end resources in the blockchain sharding architecture of multi-level Internet of Things, we use a deep reinforcement learning (DRL) based algorithm to formulate a joint optimization problem based on device capability, network topology, and transaction load for local optimization, ensuring that the overall network can achieve optimal performance in each state. Through training the model, the best sharding configuration under different network conditions can be learned, while improving the throughput and security of the blockchain system. BRIEF DESCRIPTION OF DRAWINGS

[0045] Figure 1 The overall architecture of the multi-level Internet of Things.

[0046] Figure 2 The sharding blockchain system diagram of the multi-level Internet of Things. DETAILED DESCRIPTION

[0047] The technical solutions of the present application will be described in detail below through specific embodiments and drawings. It should be understood that the embodiments and specific features in the embodiments are detailed descriptions of the technical solutions of the present application, and are not limitations of the technical solutions of the present application. The specific technical features can be combined with each other.

[0048] 1.1 Sharding blockchain system in multi-level Internet of Things

[0049] A multi-level IoT sharded blockchain system includes cloud servers, edge servers, IoT terminal devices, and gateways. IoT gateways, cloud servers, and edge servers can carry full-featured nodes, and capability-limited IoT terminal devices can connect to the blockchain through IoT gateways or carry lightweight blockchain nodes to participate in the system. The characteristics and functions of IoT entities directly affect the division of nodes in the blockchain, so a brief description of the characteristics of the above IoT entities is given.

[0050] Cloud server:

[0051] With strong computing and storage capabilities, it can handle 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] Close to the data source, it can achieve fast data processing and response, reducing latency. It performs preliminary processing and filtering of data before transmission to the cloud server to reduce bandwidth consumption. Compared with the cloud server, it has less 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] It serves as a bridge between IoT devices and cloud or edge servers, responsible for data collection and forwarding. Some gateways also have edge computing capabilities and can perform data processing and analysis locally, reducing the burden on backend servers. It can centrally manage multiple IoT devices, simplifying device configuration and monitoring.

[0056] IoT terminal device:

[0057] It usually has small storage and computing capabilities and relies on edge servers or cloud servers for data processing. It is responsible for data acquisition and monitoring, such as sensors, cameras, and smart home devices. It can execute simple control commands and usually does not have complex decision-making capabilities.

[0058] 1.2 Node types of sharded blockchain in multi-level IoT

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

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

[0061] Sync node: a node that participates in block and transaction synchronization, block verification, transaction execution, and records complete ledger data, but does not participate in consensus voting. Light node: a node that 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-tiered IoT

[0063] In the sharded blockchain system in the multi-tiered IoT, it is mainly divided into "cloud-edge sharding" and "edge-end sharding".

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

[0065] For edge-end sharding, the sharded blockchain with SBFT (Simplified Byzantine Fault Tolerance) consensus mechanism in the slice improves efficiency and performance, and is suitable for blockchain application scenarios with high speed requirements. It tolerates Byzantine faults while striving to reduce communication overhead, improving system throughput.

[0066] 1.4 Construction of sharded blockchain in multi-tiered IoT

[0067] In the multi-tiered IoT, the cloud-edge sharding and edge-end sharding solutions can effectively improve the scalability, real-time performance, and resource utilization efficiency of the system. Figure 2 For the sharded blockchain system in the multi-tiered IoT.

[0068] 1.4.1 Cloud-edge sharding

[0069] In the multi-tiered IoT, cloud-edge sharding is an important architectural design that disperses 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, executing smart contracts, and record keeping in the blockchain network.

[0070] Cloud-edge sharding refers to the sharding of cloud servers and edge servers. The former has strong 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 performing long-period tasks, so they are set as consensus full nodes in the system. The latter is located close to the data source and is set as a synchronization node due to its 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 location-based routing. Due to the latency problem 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] To maintain coordination and consistency between cloud-edge shards, the system introduces a cross-shard communication mechanism. In cases involving multiple shards, all related edge servers of the shards need to participate in consensus to reach a consensus on the validity of the transaction through multiple rounds of voting. Once the cross-shard transaction obtains consensus in all related shards, the state of each shard needs to be updated, and the transaction result and updated state information need to 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 safely and effectively.

[0074] 1.4.2 Edge-end sharding

[0075] In a multi-level Internet of Things, the architecture design of edge-end sharding takes advantage of the fact that edge servers are close to data sources, enabling fast data processing and response. Gateways act as a bridge between Internet of Things terminal devices and edge servers, centrally managing multiple Internet of Things devices and collecting and forwarding data. In edge-end sharding, due to the large number of nodes and weak performance, there are many transactions involved. Therefore, edge servers in edge-end sharding mainly participate in block and transaction synchronization, block verification, and transaction execution, while other light nodes participate in synchronization and verification of block header information and transaction existence.

[0076] Edge-end sharding refers to the sharding of edge servers, Internet of Things gateways, and Internet of Things terminal devices. The former is located near the network edge of terminal devices and is responsible for real-time data processing of each light node within the shard, smart contract execution, and local storage. It is set as a synchronization node. The latter is limited by resources and can only perform simple data collection, upload, and verification. It is set as a light node.

[0077] If the gateway and the Internet of Things terminal device have strong computing power, they can be used as synchronization nodes.

[0078] The system divides the edge server device, gateway and Internet of Things terminal device 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. Each shard is initially divided into 1 edge server, 2 Internet of Things gateways, and 5 Internet of Things terminal devices to form a shard, which processes related transactions internally. Subsequently, the system will update and iterate the number of nodes in the shard and the selection of nodes in the shard based on DRL after a certain amount of data is run.

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

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

[0081] 2. DRL-based blockchain sharding strategy

[0082] Sharding has become a popular technology used in blockchain, which enhances scalability by dividing blockchain nodes into multiple smaller partitions that can handle transactions in parallel, thereby increasing TPS. All sharding systems assume that all blockchain nodes are stable and homogeneous in a peer-to-peer network; therefore, they use random and static sharding strategies, i.e., randomly assigning blockchain nodes to different shards with fixed shard settings. However, such a sharding strategy is not suitable for Internet of Things blockchain systems with dynamic and diverse characteristics. Secondly, the random sharding strategy can only provide probabilistic security guarantees at the beginning of shard formation. When sharding a heterogeneous Internet of Things blockchain for a long time, it cannot balance throughput and security.

[0083] Therefore, a key issue is to partition the shards in a novel adaptive and dynamic way to achieve a long-term balanced trade-off between throughput and security in dynamic, 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, ensuring that the overall network achieves optimal performance in various states to obtain the best sharding strategy.

[0084] Deep reinforcement learning sharding decision optimization for specific networks

[0085] The introduction of deep reinforcement learning (DRL) for 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 containing device capabilities, network topology, and transaction load. Device capabilities can be quantified by the computational power, storage capacity, and bandwidth of each IoT device, network topology can be represented by the connection relationship and delay between nodes, and transaction load can be represented by the number and type of transactions in each shard. This multi-dimensional state space design allows the deep reinforcement learning model to fully capture the dynamic changes of the system and the complex relationships between various indicators, providing strong support for formulating an efficient blockchain sharding strategy.

[0089] Action space

[0090] In the action space A, we need to define the specific actions that the model can take, adjusting device capabilities (by allocating computational resources or storage space to affect the processing power of the device), optimizing network topology (according to network delay and connection quality to dynamically adjust the connection between nodes), and managing transaction load (according to the transaction volume of each shard to dynamically allocate or reorganize). This flexible action space allows the model to adapt to different environmental conditions and targets, achieving optimal performance.

[0091] Reward function

[0092] Defining the reward function is a key step in implementing deep reinforcement learning, which takes into account factors such as device capabilities, network topology, and transaction load. The reward can be constructed by evaluating the overall performance of the system, which effectively utilizes the computing and storage resources of devices, optimizes network connections, and processes high-load transactions within a reasonable time. Positive rewards are given when the system effectively utilizes device resources, optimizes network connections, and processes high-load transactions within a reasonable time. Negative rewards are given when the system experiences device overload, increased network latency, or delayed transaction processing. This design ensures that the reward function fully reflects the actual situation of system operation, guiding the model towards optimization goals.

[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, whose algorithm flow is as follows, where the input includes the computing resources of node devices, the storage space of node devices, the network latency of node devices, and the transaction load of nodes:

[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 experiences at each step for subsequent sample extraction and network updates;

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

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

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

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

[0102] 8) Through at = μ(s t | θ μ ) + N t Select and execute, where a t represents the best sharding scheme according to the current system;

[0103] 9) Observe the reward r t and update the state s t+1 , where s t+1 is the score calculated according to the efficiency of the sharded transaction, network delay, resource utilization, etc. The higher the score, the better the sharding strategy.

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

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

[0106] 12) For each transaction in 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 is the reward function;

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

[0110]

[0111] 15) Update the policy network using the sampled policy gradient to optimize the random parameter θ μ :

[0112]

[0113] M is the number of samples;

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

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

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

[0117] τ is the update speed of network parameters, called step size, 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, output the optimal fragmentation scheme a t for real-time scheduling and resource allocation of the fragmented blockchain system.

[0121] The policy is updated by constantly interacting with the environment. In each training step, the model will choose an action from the current state and interact with the environment to get a new state and the corresponding reward. Through this feedback mechanism, the model can update its policy and gradually improve its decision-making ability in different states. As the training progresses, the deep reinforcement learning model will gradually learn how to best adjust device capabilities and optimize network topology under different conditions, 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 as to appropriately increase computing resources when device load is high, and vice versa, to ensure the stable operation of the network. At the same time, in terms of optimization of network topology, the model can learn how to flexibly adjust the connection between nodes under different network conditions and transaction load, so as to minimize delay and improve the response speed of the system, especially when the network is congested or potential failure occurs, the strategy can be adjusted in time to optimize the use efficiency of resources.

[0122] The above is only the preferred embodiment of the present application, it should be pointed out that, for those skilled in the technical field, without departing from the technical principles of the present application, can make a number of improvements and modifications, these improvements and modifications should be considered as the protection scope of the present application.

Claims

1. A method for constructing a sharded blockchain in a multi-tiered Internet of Things, the method comprising: The entity device in the Internet of Things is 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 simultaneously serves as an edge of the cloud-edge sharding and the edge-end sharding and is configured as a synchronization node; The division strategy of the edge-end sharding is that the edge server device, the gateway and the Internet of Things terminal device are divided into multiple shards according to the computing power and storage resources of the nodes, the geographical position of the nodes and the transaction characteristics of the nodes, and the number of nodes of the edge-end sharding and the selection of the nodes of the shards are updated and iterated using a self-adaptive DRL-based sharding strategy; The self-adaptive DRL algorithm calculation steps are as follows: S1. Initialize system parameters, The following operations are performed: S2. receiving an initial state comprising computing resources, storage space, network latency and transaction load of each node of the blockchain; S3. For the current iteration number epoch, select and execute , where is the best shard plan according to the current system; and represents the best shard plan according to the current system. S4. Observe rewards And update state Wherein is a score calculated according to the efficiency of the transaction after the fragmentation, network delay, resource utilization, etc. The higher the score, the better the fragmentation strategy. S5. The replay buffer R, and from the replay buffer randomly sample small batches of ; S6. For each transaction, compute its reward function Each transaction, calculate its reward function , as follows: ； wherein is a discount factor representing the importance of the reward; S7. updating the value network by minimizing the loss function L with respect to the random parameters : ； M N is the number of samples; S8. Update the policy network using the sampled policy gradient, optimizing the stochastic parameters : = ; Stochastic parameters And Policy network And value network ; S9. with update target network: ； ； Target network Q' and , The update speed of network parameters; S10. Current iteration number reached number, end algorithm, output optimal sharding scheme for real-time scheduling and resource allocation of a sharded blockchain system. 2.The method of claim 1, wherein, For the cloud-edge sharding, the PBFT consensus mechanism is used in the shard to allow the nodes in the network to reach an agreement in the presence of partial malicious nodes; For the edge-end sharding, the SBFT consensus mechanism is used in the shard to tolerate Byzantine faults while reducing communication overhead. 3.The method of claim 1, wherein, The transaction routing of the cloud-edge sharding adopts a routing strategy based on the location of the transaction, that is, the closest cloud-edge shard is selected according to the location information of the uploaded transaction to reduce delay and bandwidth consumption; The routing strategy of the edge-end sharding is to dynamically select the target shard according to the current state of each shard in the edge-end sharding, and the shard with lighter load is given priority to receive new transaction requests. 4.The method of claim 1, wherein, A cross-shard communication mechanism is introduced between the shards of the cloud edge: in the case of involving multiple shards, the edge servers of all related shards need to participate in consensus to reach an agreement, and multiple rounds of voting are required to ensure that all related shards reach an agreement on the validity of the transaction. Once the cross-shard transaction obtains consensus in all related shards, the state of each shard needs to be updated, and the transaction result and the updated state information need to be returned to the device initiating the transaction and updated to the storage of each shard. 5.The method of claim 1, wherein, The cross-shard communication mechanism of the edge-end sharding: in the edge-end sharding, the light node is responsible for generating transactions within the shard and submitting them to the gateway node, and the gateway node is responsible for identifying whether the transaction needs to be processed across shards; when cross-shard processing is performed, the gateway node sends a cross-shard request to the edge server to obtain the information of the target shard, and after the channel is established, the transaction is transmitted to the target shard; each consensus node of the target shard verifies the legality of the transaction, and after confirming the transaction through the consensus algorithm, the result is fed back to the source shard, and the result is updated to the storage of each shard. 6.The sharded blockchain construction method in multi-tiered internet of things according to claim 1, wherein, In step S1, initialize the policy network and value network , using random parameters and , initialize the target network Q' and ,set up and , initialize the replay buffer R to store the experience of each step to facilitate subsequent sample extraction and network update; In one iteration cycle , initialize random noise N for action exploration, i.e., random noise action includes adjusting the computing resource or storage space of the device resource, changing the network topology of the device, adjusting the transaction load size of the device.

7. A sharded blockchain system in a multi-tiered Internet of Things, the system comprising: The multi-level Internet of Things sharding blockchain construction method of any one of claims 1-6 includes a cloud server, an edge server, an Internet of Things terminal device and a gateway; The cloud server and the edge server constitute cloud-edge sharding; The edge server, the Internet of Things terminal device and the gateway constitute edge-end sharding, and the gateway serves as a bridge between the Internet of Things terminal device and the edge server; The cloud server is responsible for storing global data, running a deep analysis model and executing long-period tasks, and is configured as a consensus node for participating 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 power, and the light nodes are used to participate in synchronization and check block header information and verify transaction existence. 8.The sharded blockchain system in a multi-tiered internet of things according to claim 7, wherein, 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; each shard is initially divided into n edge servers, 2n IoT gateways and 5n IoT terminal devices to form a shard, and these nodes internally process related transactions. When uploading transactions, the transaction request is usually sent to the consensus node for verification and processing, and then the result is returned to the light node; the transaction routing adopts load-based routing, and the transaction routing is dynamically selected according to the current load state of the edge server to avoid overload. The routing strategy of the end-edge shard is to dynamically select the target shard according to the current state of the shard, and the shard with lighter load is given priority to receive new transaction requests.

Images