Fragmented block chain system performance and resource allocation optimization method based on convex optimization algorithm

Abstract

The invention provides a fragmented block chain system performance and resource allocation optimization method based on a convex optimization algorithm, and the method comprises the steps: firstly building a block chain fragmentation system based on a PBFT consensus mechanism, then analyzing how system parameters and resource allocation affect the system throughput, and finally formalizing a common optimization problem of the system parameters and resource allocation; all nodes in the block chain fragmentation system are deployed on a cloud platform; each node follows a fragmentation protocol optimization management process, and a PBFT consensus mechanism is used to ensure that transactions in each fragment achieve a rapid and safe consensus. By applying the technical scheme, the throughput and the expandability of the public chain can be obviously improved.

Description

Technical Field

[0001] The present invention relates to the technical field of blockchain, and particularly to a method for optimizing the performance and resource allocation of a sharded blockchain system based on a convex optimization algorithm. Background Art

[0002] Blockchain has become a fundamental distributed ledger technology with wide applications in the fields of finance, digital currency, and the Internet of Things (IoT). Its decentralized, anonymous, and tamper-proof characteristics make it particularly attractive to various industries. With the continuous development of blockchain technology, it has given rise to many decentralized applications, including identity management, supply chain tracking, and gaming systems. With the increasing popularity of blockchain technology, more and more blockchain platforms are being deployed in cloud environments because cloud service providers offer features such as rapid deployment, dynamic scaling, integration with other services, rich resource pools, and sandbox environments. Cloud-based blockchain systems utilize the powerful computing capabilities of cloud infrastructure while maintaining the inherent decentralization, security, and transparency of blockchain technology, supporting various application scenarios across multiple domains.

[0003] The rapid development of communication technology and the proliferation of IoT devices have led to an unprecedented surge in the number of blockchain users, transactions, and data volume. This growth poses a major challenge: maintaining high scalability in resource-constrained cloud environments where the number of transactions is growing exponentially. High scalability in a blockchain system refers to the ability to effectively process a large number of transactions or achieve a high system throughput without sacrificing performance. On the contrary, low scalability leads to bottlenecks when dealing with a high volume of transactions. When the number of transactions exceeds the processing capacity of the system, low scalability results in transaction backlogs, forcing users to wait longer for transaction confirmations. This, in turn, reduces system efficiency and the user experience.

[0004] A promising solution to this scalability challenge is sharding, a technique originally developed for database systems and now widely applied in blockchain systems. Sharding improves scalability by dividing the blockchain network into smaller and independent groups. Each shard processes a subset of the total transaction workload, thus supporting parallel transaction processing. This concept is similar to a supermarket with multiple cash registers, where each cash register handles a portion of customer transactions, enabling faster overall service. By enabling parallel processing, sharding effectively alleviates the throughput limitations of traditional blockchain systems.

[0005] In the blockchain sharding system, the PBFT (Practical Byzantine Fault Tolerance) consensus mechanism plays a crucial role in ensuring system consistency and reliability. PBFT is particularly suitable for applications with high reliability and low latency, as it can maintain system integrity even in the presence of faulty or malicious nodes. By allowing each shard to independently process transactions and reach consensus, PBFT enhances scalability and performance. Additionally, PBFT's ability to tolerate (n - 1) / 3 faulty or malicious nodes further strengthens the security and stability of the sharding architecture.

[0006] However, the implementation of sharding technology brings challenges in managing uncontrollable inter-shard transactions. In a sharded blockchain system, the number of transactions processed by different shards is usually unbalanced. Shards with high transaction volumes may encounter congestion, resulting in slower processing speeds, while shards with lower transaction volumes may underutilize resources, leading to inefficiencies. Since all shards need to reach consensus, congestion in a subset of shards can reduce the overall system throughput. Additionally, inefficient or malicious transaction allocation strategies may overload specific shards, further reducing processing speeds and throughput.

[0007] To address the challenge of unbalanced inter-shard transaction volumes and ensure reliable high throughput, a two-pronged approach is needed: First, establish appropriate system parameter configurations: Parameters such as block size and block interval directly affect transaction processing speed and efficiency. Larger block sizes allow each block to process more transactions, thus increasing overall throughput. Shorter block intervals reduce transaction confirmation times and improve processing efficiency. Carefully selecting parameters is crucial for balancing transaction throughput and network latency. Second, ensure effective inter-shard resource allocation: As transaction volumes grow, optimal resource allocation is crucial for maintaining scalability. Appropriate allocation can avoid performance bottlenecks and ensure that the system can handle increasing demands. Previous research has mainly focused on the independent optimization of system parameters or resource allocation, which is insufficient for cloud-based blockchain environments. An integrated approach that jointly optimizes both aspects is urgently needed.

[0008] Formulating such an overall optimization strategy requires solving the following specific problems: First, the coupling of system parameters and resources: System parameters and resources are tightly coupled. Changes in one aspect directly affect the other. For example, modifying the block size and block interval requires corresponding adjustments to computing and network resources to ensure timely transaction processing. Conversely, available resources impose constraints on system parameter optimization. Optimizing these two variables simultaneously is computationally challenging. Second, for the joint optimization problem of system parameters and resource allocation, an algorithm that can quickly generate near-optimal solutions is needed to ensure the system's processing speed and throughput. Summary of the Invention

[0009] In view of this, the purpose of the present invention is to provide an optimization method for the performance and resource allocation of a sharded blockchain system based on a convex optimization algorithm, and to improve the scalability of the sharded blockchain system while meeting the conditions of network resource constraints.

[0010] To achieve the above object, the present invention adopts the following technical solutions: an optimization method for the performance and resource allocation of a sharded blockchain system based on a convex optimization algorithm. First, a blockchain sharding system based on the PBFT consensus mechanism is established. Subsequently, how system parameters and resource allocation affect system throughput is analyzed. Finally, the co-optimization problem of system parameters and resource configuration is formalized.

[0011] In a preferred embodiment, all nodes in the blockchain sharding system are deployed on a cloud platform; each node follows the sharding protocol optimization management process and uses the PBFT consensus mechanism to ensure fast and secure consensus on transactions within each shard. The operation of the sharded blockchain system mainly includes the following steps: all transactions enter different shards for processing; then each shard independently and concurrently processes the allocated different transaction sets, and verifies the integrity of the block through consensus within the shard to achieve high throughput of system transaction processing; the blocks created in each shard are merged and re-verified through the final PBFT, thus forming new blocks on the main chain.

[0012] In a preferred embodiment, the PBFT verification process of n nodes is as follows:

[0013] Initialization: When the system is initialized, all nodes start with the same state;

[0014] Client request: The client sends a request to the primary node in the system;

[0015] Pre-prepare phase: After receiving the request, the primary node regards it as a new transaction and generates a sequence number for this transaction; then, the primary node signs the pre-prepared message containing the transaction and broadcasts this message to all other nodes;

[0016] Prepare phase: After receiving the prepare message, the replica nodes verify the validity of the message, sign the prepare message, and return the prepare message to the primary node and all other nodes;

[0017] Commit: Once the primary node receives the corresponding prepare messages sent by 2n / 3 + 1 nodes, it signs the commit message and sends it to all nodes;

[0018] Reply: After receiving 2n / 3 + 1 confirmation messages, the replica nodes regard the transaction as committed and apply it to the local state machine to complete the consensus process.

[0019] In a preferred embodiment, the system consists of K-1 shards and 1 final consensus group, denoted by . The shard number is indexed by . The number of nodes in each shard is denoted by N; Transactions randomly arrive in the sharded blockchain system. The transaction volume to be processed by each shard is denoted by λ k B, where B represents the block size, and λ k represents the coefficient of the transaction volume of the k-th shard;

[0020] Use a binary tuple Re k = <c k , r k > to represent the resource situation allocated to shard k, where c k represents the computing resources allocated to shard k, and r k represents the bandwidth resources allocated to shard k; Each type of resource has a maximum limit, denoted by C max and R max respectively; Therefore, there are the following constraints:

[0021]

[0022] Assume that the message verification process includes verifying signatures and message authentication code operations; Use θ and α CPU cycles respectively; The latency refers to the time required for a transaction to enter the blockchain system and finally be processed and become irreversible; The transaction process consists of two steps: 1) Block interval; 2) Consensus latency. The total latency T total of the system is obtained from the following formula:

[0023] T total = T I + T con (2)

[0024] where T I is the block interval, and T con is the consensus latency of shard k; T con is determined by the intra-shard consensus latency and the final consensus latency, and is obtained from the following formula:

[0025]

[0026] where and T final represent the intra-shard consensus and the final consensus latency respectively; The intra-shard consensus latency and the final consensus latency include message propagation and message verification latency, and are obtained from the following formula:

[0027]

[0028] where and Represents the propagation delay and verification delay in the consensus process within a shard in the sharded blockchain system, T dprop and T dval represent the propagation delay and verification delay in the final consensus process;

[0029] The consensus within a shard consists of three phases, namely the pre-prepare phase, the prepare phase, and the commit phase. The propagation delay of each phase is respectively represented by and Assume the timeout bound ζ of the maximum waiting time. Timeouts are set in the message propagation between nodes in the consensus process and cannot exceed the maximum waiting time. Therefore, the in-shard propagation delay is calculated as follows:

[0030]

[0031] Meanwhile, there are constraints:

[0032] Similarly, the final consensus consists of five phases, namely the request phase, the pre-prepare phase, the prepare phase, the commit, and the reply phase. The propagation delay of each phase is respectively represented by T dreq 、T dpreprepare 、T dprepare 、T dcom and T reply So the final propagation delay is calculated as follows:

[0033]

[0034] Therefore, the total consensus delay of the sharded blockchain system is expressed by the following formula:

[0035]

[0036] In a preferred embodiment, when the initial consensus of each shard starts, the primary node creates λ k blocks, performs a message authentication code verification operation for each request, and performs signature verification for each request; at the end of the commit phase, the primary node and the replica nodes send their in-shard consistency to the final consensus group to obtain the final consistency; at this time, the primary node and the replica nodes create N message authentication codes for each request; therefore, in the consensus model within a shard, it is considered that the processing time of the primary node and the replica node in the k-th shard are respectively:

[0037]

[0038] where c k refers to the amount of computing resources invested in shard k. Here, only considering the case of uniform distribution of computing resources within a shard, it is obtained that within the same shard, the processing time of the primary node is longer than that of the replica node, with the primary node's calculation as the main;

[0039] The consensus within a shard is processed in parallel, and the latency is determined by the shard with the maximum latency. The verification processes of the primary replica and replicas are executed in parallel, and it is considered that:

[0040]

[0041] The consensus process for all shards is carried out in parallel, and the propagation latency of each step in the consensus within a shard is expressed by the following formula:

[0042]

[0043] where λ k B is the transaction volume of the k-th shard, and r k represents the data transmission rate between nodes in shard k; and and are equal, that is, the internal propagation latency of the requests for each step of the consensus within a shard is calculated as follows:

[0044]

[0045] In a preferred embodiment, the final consensus latency refers to the delivery of the blocks that have reached consensus within K - 1 shards to the final consensus group to achieve the final consensus. The final consensus group verifies signatures and verifies the message authentication codes of the blocks received from each shard; the nodes in the final consensus group execute the PBFT consistency again, and then return the merged blocks to all other nodes; then, it is considered that the processing times of the primary node and replica nodes in the final consensus group are respectively expressed as:

[0046]

[0047] where C K represents the computing resources of the primary node and replica nodes in the final consensus, and is obtained from the above formula. In the final consensus group, the processing time of the primary node is longer than that of the replica node. Therefore, the verification latency in the final consensus group is obtained:

[0048] T dval = max{T dprimary ,T dreplica} (13)

[0049] The propagation latency of each step in the final consensus is expressed by the following formula:

[0050]

[0051] where r KIt represents the data transfer rate between nodes in the final consensus group; similar to the in-chip consensus propagation, the propagation delays of the first four steps in formula (14) are equal. Therefore, the propagation delay in the final consensus group is as follows:

[0052]

[0053] The total transaction delay is completed within multiple consecutive block intervals u. Therefore, the following constraints on the delay are obtained:

[0054]

[0055] In a preferred embodiment, the blockchain throughput refers to the number of transactions processed by the blockchain system per second; the block generator generates local blocks with the maximum B size for each block interval period T I If the average transaction size is b and the block header size is B H , the number of shards is K - 1, and the number of transaction blocks in each shard is λ k , then the maximum throughput of the blockchain system is calculated from the following formula:

[0056]

[0057] Under the given system parameters, it is expected to optimize the block interval T I and the block size B while allocating resources to the K shards in the sharded blockchain system to maximize the blockchain system throughput T; the above joint optimization problem is formally defined as:

[0058]

[0059] Constraint C1 represents that the maximum waiting duration of each consensus step is completed before; constraint C2 represents the relationship between the total consensus delay and the block interval; constraints C3 and C4 represent that each type of resource cannot exceed the maximum budget.

[0060] In a preferred embodiment, a two-stage alternating iteration algorithm is used to solve the P1 problem; the two-stage alternating iteration algorithm uses the block coordinate descent method to transform the original problem into two sub-problems: the system parameter optimization problem and the network resource allocation problem; sub-problem 1 is to optimize the system parameters B and T k , r k while fixing the resource allocation c I ; sub-problem 2 is to optimize the resource allocation c I while fixing the system parameters B and T k , r k ; by optimizing the two sub-problems sequentially in each iteration, the maximization of the sharded blockchain system throughput gradually converges.

[0061] In a preferred embodiment, the first sub-problem of problem P1, denoted as P2, is to solve for the optimal system parameters B and T k , r k given the resource allocations c I ; in this sub-problem P2, the coupling relationships among the optimization variables c k , r k , B, and T I no longer exist. The formalization of this sub-problem P2 is as follows:

[0062]

[0063] The system parameters B and T will be optimized by fixing them respectively; substituting equations (8), (11), (12), and (15) into (19b) gives the following:

[0064]

[0065] The second sub-problem of problem P1, denoted as P3, is to solve for the optimal resource allocations c I and r k given the system parameters B and T k obtained by solving P2; the formalization of this problem P3 is as follows:

[0066]

[0067] Theorem 2: Problem P3 is a convex optimization problem with respect to the variables c k and r k ;

[0068] Proof: For the constraint 21a in problem P3, construct the auxiliary function and find its second derivative with respect to the variable r k , and we get Therefore, this function is a convex function with respect to the variable r k , and it can be obtained that the constraint 21a is a convex constraint, and the constraint 21d is a convex constraint with respect to the variable r k ; for the constraint 21b, construct the auxiliary function

[0069]

[0070] In a preferred embodiment, in the two-stage alternating iteration algorithm, by alternately solving the sub-problems P2 and P3 of P1, the system parameters B and T I and the network resources c k , r kOptimization is as follows. The specific implementation steps of the algorithm are as follows: First, the algorithm gives an initial feasible solution according to the random policy, and then solves two sub-problems of the original problem; specifically, first, taking ck and rk obtained in the previous iteration as inputs, B and TI are obtained by solving problem P2; second, taking B and TI obtained in the previous iteration as inputs, ck and rk are obtained by solving problem P3; finally, the system throughput is calculated according to the obtained optimized solution and formula (17); the loop ends when the difference between the results of two loops is less than the precision threshold ε or the number of loops reaches the maximum value itermax; finally, the algorithm returns the obtained minimum average task response time.

[0071] Compared with the prior art, the present invention has the following beneficial effects: The present invention studies a sharded blockchain system based on PBFT. In this blockchain, the situation of transactions arriving at shards is uncontrollable, and each shard may receive unbalanced transactions. The arrival of unbalanced transactions will affect the performance of the sharded blockchain. At the same time, under the condition of meeting the network resource constraints, to improve the scalability of the sharded blockchain system, it is necessary to jointly optimize the system parameters and resource allocation; for the above joint optimization problem, based on the block coordinate descent method in convex optimization theory, the present invention proposes a two-stage alternating iteration algorithm for maximizing the throughput of the sharded blockchain system. This algorithm obtains an approximately optimal solution with convergence guarantee by iteratively solving two sub-problems decomposed from the target problem. Simulation experiments verify the effectiveness and feasibility of the proposed algorithm. The results show that the proposed joint optimization algorithm can generate an optimized solution within 5 seconds, and the performance is improved by 3.32% - 14.56% compared with other benchmark methods. Brief Description of the Drawings

[0072] Figure 1 Schematic diagram of a sharded blockchain system based on PBFT according to a preferred embodiment of the present invention;

[0073] Figure 2 Schematic diagram of the steps of PBFT according to a preferred embodiment of the present invention;

[0074] Figure 3 Schematic diagram of the system throughput under different numbers of shards according to a preferred embodiment of the present invention;

[0075] Figure 4 Schematic diagram of the algorithm execution time under different scenarios according to a preferred embodiment of the present invention;

[0076] Figure 5 Schematic diagram of the system throughput under different scenarios with unchanged resources according to a preferred embodiment of the present invention;

[0077] Figure 6 Schematic diagram of the system throughput for different transaction sizes according to a preferred embodiment of the present invention; Detailed implementation mode

[0078] The present invention will be further described below in conjunction with the accompanying drawings and embodiments.

[0079] It should be noted that the following detailed description is illustrative and is intended to provide further description of the present application. Unless otherwise specified, all technical and scientific terms used in the present invention have the same meaning as commonly understood by those of ordinary skill in the technical field to which the present application belongs.

[0080] It should be noted that the terms used herein are only for describing specific implementation modes and are not intended to limit the exemplary implementation modes according to the present application; as used herein, unless the context clearly indicates otherwise, the singular form is also intended to include the plural form. In addition, it should also be understood that when the terms "include" and / or "comprise" are used in this specification, they indicate the presence of features, steps, operations, devices, components, and / or combinations thereof.

[0081] The present invention first describes a blockchain sharding system based on the PBFT consensus mechanism. Then, it analyzes how system parameters and resource allocation affect system throughput. Finally, it formalizes the co-optimization problem of system parameters and resource configuration.

[0082] In Figure 1 a blockchain system is designed and constructed using sharding technology. All nodes in the system are deployed on a cloud platform, making full use of the flexibility and scalability of cloud services. Each node follows a sharding protocol to optimize the management process and uses the PBFT consensus mechanism to ensure fast and secure consensus on transactions within each shard. In addition, the system design gives priority to stable cloud platform operation and efficient resource utilization to meet scalability and performance requirements. The key cloud resources involved are network bandwidth and CPU cores.

[0083] As Figure 1 shown, the operation of the sharded blockchain system mainly includes the following steps: 1) All transactions enter different shards for processing; 2) Then each shard independently and parallelly processes the different transaction sets assigned to it, and verifies the integrity of the block through consensus within the shard to achieve high throughput of system transaction processing; 3) The blocks created in each shard are merged and re-verified through the final PBFT, thus forming new blocks on the main chain.

[0084] The PBFT protocol is an efficient state machine replication protocol specifically used to address malicious nodes that may exist in a distributed system, ensuring that the system can maintain normal operation and data consistency under such adverse conditions. As Figure 2 shown, the PBFT verification process for n nodes is as Figure 2 shown:

[0085] Initialization: When the system is initialized, all nodes start in the same state;

[0086] Client request: The client sends a request to the primary node in the system;

[0087] Pre-prepare phase: After receiving the request, the primary node treats it as a new transaction and generates a sequence number for this transaction. Then, the primary node signs the pre-prepared message containing the transaction and broadcasts this message to all other nodes;

[0088] Prepare phase: After receiving the prepare message, the replica nodes (not the primary node) verify the validity of the message, sign the prepare message, and return the prepare message to the primary node and all other nodes;

[0089] Commit: Once the primary node receives the corresponding prepare messages sent by 2n / 3 + 1 nodes (including itself), it signs the commit message and sends it to all nodes;

[0090] Reply: After receiving 2n / 3 + 1 confirmation messages, the replica nodes consider the transaction committed and apply it to the local state machine, completing the consensus process.

[0091] The present invention considers a blockchain system based on sharding technology. The system consists of K - 1 shards and 1 final consensus group, denoted by The shard number is indexed by and the number of nodes in each shard is denoted by N. Transactions randomly arrive in the sharded blockchain system, and the transaction volume to be processed by each shard is denoted by λ k B, where B represents the block size, and λ k represents the coefficient of the transaction quantity of the k-th shard. The main objective of the present invention is to improve the throughput of the system.

[0092] Table 1 System parameters

[0093]

[0094] Use a binary tuple Re k =<c k , r k > to represent the resource situation allocated to shard k, where c k represents the computing resources allocated to shard k, and r k represents the bandwidth resources allocated to shard k. Each type of resource has a maximum limit, denoted by C max and R max respectively. Therefore, there are the following constraints:

[0095]

[0096] The present invention also assumes that the message verification process includes two operations: verifying the signature and operating on the message authentication code (for generating and verifying the message authentication code). Respectively, θ and α CPU cycles are used. The latency refers to the time required for a transaction to enter the blockchain system and finally be processed and become irreversible. The transaction process consists of two steps: 1) block interval; 2) consensus latency, and the total latency T of the system total can be obtained from the following formula:

[0097] T total = T I + T con (2)

[0098] where T I is the block interval, and T con is the consensus latency of shard k. T con is determined by the in-shard consensus latency and the final consensus latency, and can be obtained from the following formula:

[0099]

[0100] where and T final represent the in-shard consensus and the final consensus latency respectively. The in-shard consensus latency and the final consensus latency include message propagation and message verification latency, and can be obtained from the following formula:

[0101]

[0102] where and represent the propagation latency and the verification latency in the in-shard consensus process in the sharded blockchain system, and T dprop and T dval represent the propagation latency and the verification latency in the final consensus process.

[0103] The in-shard consensus consists of three phases: the pre-prepare phase, the prepare phase, and the commit phase. The propagation latency of each phase is respectively represented by and To limit the unresponsive waiting time of message exchange, an upper bound ζ of the maximum waiting time is assumed, and timeouts are set for message propagation between nodes in the consensus process, which cannot exceed the maximum waiting time. Therefore, the in-shard propagation latency is calculated as follows:

[0104]

[0105] Meanwhile, there are constraints:

[0106] Similarly, the final consensus consists of five phases: the request phase, the pre-prepare phase, the prepare phase, the commit, and the reply phase. The propagation latency of each phase is respectively represented by Tdreq , T dpreprepare , T dprepare , T dcom and T reply represent, so the final propagation delay is calculated as follows:

[0107]

[0108] Therefore, the total consensus delay of the sharded blockchain system can be expressed by the following formula:

[0109]

[0110] When the initial consensus of each shard starts, the master node creates λ k blocks, performs a message authentication code verification operation for each request, and verifies the signature for each request. At the end of the commit phase, the master node and the replica nodes send their shard - internal consistency replies to the final consensus group to obtain the final consistency. At this time, the master node and the replica nodes create N message authentication codes for each request. Therefore, in the consensus model within a shard, it can be considered that the processing times of the master node and the replica nodes in the k - th shard are respectively:

[0111]

[0112] where c k refers to the amount of computing resources invested in shard k. Here, only considering the case where the computing resources are evenly distributed within the shard, it can be seen that within the same shard, the processing time of the master node is longer than that of the replica node. This invention focuses on the master - node calculation.

[0113] In addition, the consensus within a shard is processed in parallel, and the delay is determined by the shard with the maximum delay. The verification processes of the master - replica and the replicas are executed in parallel. It can be considered that:

[0114]

[0115] All shards in the consensus process are in parallel. The propagation delay of each step in the consensus within a shard can be expressed by the following formula:

[0116]

[0117] where λ k B is the transaction volume of the k - th shard, and r k represents the data transmission rate between nodes in shard k. Here, this invention assumes that the transmission rate is the same within the shard. Since this invention assumes that the transmission rate is evenly distributed within the same shard, so and and Equal, that is, the internal propagation delay of the requests for the consensus steps within each shard is calculated as follows:

[0118]

[0119] Similarly, the final consensus delay refers to the delivery of the blocks that have reached consensus within K - 1 shards to the final consensus group to achieve final consensus. The final consensus group verifies the signatures and verifies the message authentication codes of the blocks received from each shard. The nodes in the final consensus group (with N members) execute PBFT consistency again and then return the merged block to all other nodes. Then, the processing times of the primary node and the replica nodes in the final consensus group can be considered to be represented respectively as:

[0120]

[0121] where C K represents the computing resources of the primary node and the replica nodes in the final consensus. From the above formula, it can be obtained that the processing time of the primary node in the final consensus group is longer than that of the replica nodes. Therefore, the verification delay in the final consensus group can be obtained as:

[0122] T dval = max{T dprimary , T dreplica} (13)

[0123] The propagation delay of each step in the final consensus can be expressed by the following formula:

[0124]

[0125] where r K represents the data transfer rate between the nodes in the final consensus group. Similar to the in - shard consensus propagation, the propagation delays of the first four steps in formula (14) are equal. Therefore, the propagation delay in the final consensus group is as follows:

[0126]

[0127] The total transaction delay of the present invention is considered to be completed within multiple consecutive block intervals u. Therefore, the following constraints on the delay are obtained:

[0128]

[0129] The blockchain throughput refers to the number of transactions that the blockchain system can process per second. The block generator generates local blocks with a maximum size of B for each block interval period T I If the average transaction size is b, the block header size is B H , the number of shards is K - 1, and the number of transaction blocks in each shard is λ k, the maximum throughput of the blockchain system can be calculated from the following formula:

[0130]

[0131] In the present invention, under the condition of given system parameters, the present invention expects to optimize the block interval T I and the block size B while allocating resources to K shards in the sharded blockchain system, and maximize the throughput T of the blockchain system. The above joint optimization problem can be formally defined as:

[0132]

[0133] Constraint C1 represents that it is completed before the maximum waiting duration of each consensus step; Constraint C2 represents the relationship between the total consensus delay and the block interval; Constraints C3 and C4 represent that each type of resource cannot exceed the maximum budget.

[0134] Due to the existence of coupled variables in Constraints C1 and C2, Problem P1 is difficult to solve. Therefore, the present invention proposes a two-stage alternating iterative algorithm based on convex optimization to solve the throughput maximization problem. This algorithm uses the block coordinate descent method to transform the original problem into two sub-problems: the system parameter optimization problem and the network resource allocation problem. Sub-problem 1 is to optimize the system parameters B and T k c k r I while fixing the resource allocation c I r k ; Sub-problem 2 is to optimize the resource allocation c k r <00*********]]

[0135] The first sub-problem of Problem P1, denoted as P2, is to solve the optimal system parameter B and T k c k r I configuration under the given resource allocation c k r k B and T I . In this sub-problem, the coupling relationship between the optimization variables c

[0136] <000*********]]

[0137] Since both the numerator and denominator in the objective function contain optimization variables, this problem is a fractional non-convex optimization problem and is difficult to solve directly. Therefore, the system parameters B and T will be fixed and optimized separately. Substituting Formulas 8, 11, 12, and 15 into 19b, the following formula can be obtained:

[0138]

[0139] Theorem 1: After fixing TI, problem P2 is a convex optimization problem with respect to variable B.

[0140] Proof: Given the known variables TI and c k 、r k In this case, it is clear that constraint 4-19a is a convex constraint on variable B, and 4-19c and 4-19d are convex constraints on known variables c. k 、r k Convex constraint. For constraint 4-19b, convert it to the form of formula 2-20. Since all variables except variable B are known in the inequality, constants m and n are introduced for ease of understanding. The coefficient of B is equivalent to constant m. The sum of the first and third parts on the right side of the formula is equivalent to n. The original formula can be rewritten as T I ≥n+mB, it can be concluded that conditions 4-19b are convex constraints on variable B. For the objective function, the partial derivative with respect to B is obtained. It can be deduced that the objective function is an affine function with respect to the variable B; therefore, after fixing TI, problem P2 is a convex optimization problem with respect to the variable B, and Theorem 1 is proved.

[0141] Theorem 2: After fixing B, problem P2 is a convex optimization problem with respect to variables TI.

[0142] Proof: Given the known variables B and c k 、r k In the case of , for constraint 20, since all variables except TI are known in the inequality, constraint 20 is a convex constraint of TI. For the objective function, the second-order partial derivative with respect to TI is obtained. It can be deduced that the objective function is a convex function with respect to the variable TI; therefore, after fixing B, problem P2 is a convex optimization problem with respect to the variable TI, and Theorem 2 is proved.

[0143] For the convex optimization problem P2, it is difficult to directly give the optimization variables B and T I The solution can be achieved by using CVX

[24] Toolkit for solving.

[0144] The second sub-problem of problem P1, denoted as P3, is to solve the system parameters B and T obtained by solving P2. I Solve the optimal resource allocation c k 、r k In this case, the system parameters are known, so the optimization variable c in the original problem is k 、r k , B and T IThe coupling relationship between them no longer exists, and this problem can be formalized as follows:

[0145]

[0146] Theorem 2: Problem P3 is a convex optimization problem with respect to variables c k and r k .

[0147] Proof: For constraint 21a in Problem P3, construct the auxiliary function and find its second derivative with respect to variable r k , and we can get Therefore, this function is a convex function with respect to variable r k , and it can be obtained that constraint 21a is a convex constraint, and constraint 21d is a convex constraint with respect to variable r k . For constraint 21b, construct the auxiliary function

[0148]

[0149] For function L, find its second partial derivative with respect to r k , and we can get Obviously, this function is a convex function with respect to r k , and similarly, it can be obtained that this function is also a convex function with respect to c k . Therefore, constraint 21b is a convex constraint with respect to variables c k and r k respectively. Substitute T in the objective function T I and convert it into a function with respect to variables c k and r k . It has been proved before that the auxiliary function L is a convex function with respect to variables c k and r k respectively. According to the property of convex functions: if function f is a convex function defined on convex set C, then for any real number β ≥ 0, function βf is also a convex function defined on C. It can be obtained that the objective function is a convex function with respect to variables c k and r k , and constraint 21c is a convex constraint with respect to variable c k . Therefore, Problem P3 is a convex optimization problem with respect to variables c k and r k , and Theorem 2 is proved.

[0150] For the convex optimization problem P3, it can be directly solved by the convex optimization solver CVX. The CVX solver is a toolbox specifically used to solve convex optimization problems, and it uses methods such as the interior point method to solve these optimization problems at the underlying level.

[0151] To solve the above joint optimization problem, an optimization algorithm with two-stage alternating iteration is proposed based on convex optimization theory to obtain its approximate optimal solution. In this algorithm, by alternately solving sub-problems P2 and P3 of P1, the system parameters B, T I and network resources c k , r k are optimized. The specific implementation steps of the algorithm are shown in Algorithm 1.

[0152]

[0153] The algorithm first gives an initial feasible solution according to the random strategy (line 2), and then solves the two sub-problems of the original problem. Specifically, it includes: first, taking ck and rk obtained in the previous iteration as inputs, B and TI are obtained by solving problem P2 (line 7); second, taking B and TI obtained in the previous iteration as inputs, ck and rk are obtained by solving problem P3; finally, the system throughput is calculated according to the obtained optimal solution and formula (17). The condition for the end of the loop is that the difference between the results obtained in two loops is less than the precision threshold ε or the number of loops reaches the maximum value itermax (line 10). The algorithm finally returns the obtained minimum average task response time (line 11).

[0154] Experimental settings

[0155] In the present invention, in order to verify the effectiveness and superiority of the method of the present invention in solving the target joint optimization problem, a simulation experiment evaluation is carried out in a simulation environment. In particular, the following research questions (RQ) are verified through simulation experiments:

[0156] ·RQ1: How much is the performance improvement of the proposed method compared with other methods?

[0157] ●RQ2: How does the throughput of the sharded blockchain change with the increase in the number of shards under the condition of limited resources?

[0158] ●RQ3: What impact will different average transaction sizes have on the scalability of the sharded blockchain?

[0159] Simulation settings

[0160] The simulation experiment of the present invention is carried out under the 64-bit Windows 10 system with a configuration of 16GB of memory and a 3.00GHz i5 Intel processor. Other system parameters are set as shown in Table 1.

[0161] Table 2 Simulation parameter settings

[0162]

[0163] Benchmark

[0164] The present invention considers the following benchmarks for comparison with the proposed algorithm.

[0165] ● PSO-GARes.Allocation: Particle Swarm Genetic Algorithm, population size of 60, maximum number of iterations of 1000.

[0167] ● Top-S Res.Allocation: This algorithm evenly allocates each type of resource to the shards with the top 50% of queue lengths. · Average Res.Allocation: This method evenly distributes the available resources of each type to all network shards. · Random Res.Allocation: Resources are randomly allocated, and the optimal value of the results of 100,000 random repeated experiments is used

[0168] as the final result.

[0169] Analysis of Experimental Results

[0170] Performance Advantages of the Method of the Present Invention

[0171] To verify the convergence of the convex optimization method in different scenarios, five scenarios are set up, as shown in Table 1. Each scenario has different resource configurations and the number of shards. This series of configurations is designed to simulate different system loads to evaluate the specific impact of resource allocation on performance.

[0172] To fully verify the optimization effect of the convex optimization algorithm on system throughput, two methods of fixed block size and fixed block interval are compared. The fixed block size method fixes the block size B to 4, while the block interval, computing resources, and bandwidth resources continue to be alternately optimized relying on the convex optimization algorithm. The fixed block interval method sets the block interval T to 8 seconds, and the block size, computing resources, and bandwidth resources also rely on the convex optimization algorithm for alternate optimization. As Figure 4 shown, based on the parameters of Scenario 4, the target algorithm is compared with the above two methods. These methods have the same optimization goal, that is, system throughput. It can be seen that the target method achieves optimization effects of 50.2% and 84.4% respectively compared with the fixed block size and fixed block interval methods. This is because the target algorithm jointly optimizes the block size, block interval, computing resources, and bandwidth resources, which also shows that jointly optimizing the block size and block interval can significantly improve system throughput. From the experimental results, it can be concluded that the convex optimization algorithm has a very obvious optimization effect on system throughput.

[0173] For RQ1, through Figure 3, the proposed algorithm was compared with other benchmark methods. The budgets for computing resources and network resources were set to increase from 100 CPUs to 500 CPUs and from 10 Mb / s to 50 Mb / s respectively. The number of network shards varied from 5 to 25. Under different sharding scenarios, the performance of the method proposed in the present invention was superior to that of PSO-GA, Average, Greedy, and Random. Its throughput was respectively about 3.3%, 10.76%, 6.33%, and 14.56% better than that of PSO-GA, Average, Top-S, and Random on average. This is because the larger the solution space, the more difficult it is for PSO-GA to solve, and it is easy to fall into local optima, thus unable to obtain the optimal solution. Average only considers the average allocation of resources and is difficult to handle unbalanced transaction arrivals and cannot make full use of resources, so its performance is poor. For the Top-S algorithm, since only the shards with the first 50% length are allocated each time, the calculated solutions are generally local optimal solutions, so the optimization effect on system throughput is limited. The Random method only randomly allocates resources and completely ignores the transaction arrival situation and the impact of system parameters on throughput, so its performance is poor.

[0174] In addition, the execution time required for all benchmark methods to obtain better solutions in different scenarios was evaluated, and the experimental results were the average of the execution times for 3 times in each scenario. It can be seen from the simulation results shown in Table 2 that the execution time of the method proposed in the present invention is much less than that of PSO-GA Res.Allocation and Random Res.Allocation, and as the scale becomes larger, the difference in algorithm execution time becomes greater. The execution times of Top-s and Average are close to that of the present invention. This is because the resources are allocated based on rules, which greatly reduces the number of allocation solutions, so the algorithm complexity is relatively low.

[0175] Combined with Figure 3 and Figure 4 the simulation results, it can be obtained that although the optimization effect of PSO-GA on the throughput of the sharded blockchain system is close to that of the method of the present invention, the algorithm execution time is too long and it is not applicable in the actual environment. The execution times of Top-S and Average in each scenario are close to that of the method of the present invention, but their optimization effects on system throughput are poor. In summary, the proposed method has obvious performance advantages compared with the benchmark algorithms and can converge to an approximate optimal solution in a shorter time.

[0176] 1. How does the throughput of the sharded blockchain change with the increase in the number of shards under limited resources

[0177] To verify the effectiveness of the method of the present invention under fixed resources, the method of the present invention is compared with other benchmark methods. Except for the resource settings, other experimental settings are the same as those in RQ1. The total computing resources and transmission resources are fixed at 400 CPUs and 40 Mb / s respectively. The number of shards is increased from 5 to 30 in steps of 5.

[0178] Figure 5 It shows the throughput changes of the method proposed in the present invention and other benchmark methods in different shard scenarios. As the number of shards increases, the system throughput of all benchmark methods first increases and then decreases. The reason for this phenomenon is that as the number of shards increases, the system throughput increases accordingly. However, after reaching a certain number of shards, the limited resources are difficult to meet the needs of more shards, so the system performance will decline.

[0179] 2. How does different average transaction size affect the scalability of sharded blockchains?

[0180] Next, the impact of different average transaction sizes on the scalability of sharded blockchains is further evaluated. When the number of shards is 20, the total computing resource capacity limit and the total network bandwidth limit are 400 CPUs and 40 Mbps respectively. The maximum block size B is 8 MB. The average transaction size is set to increase from 100 Bytes to 550 Bytes in steps of 50.

[0181] From Figure 6 it can be seen that as the average transaction size increases, the system throughput decreases. The reason is that as the average transaction scale increases, the number of transactions contained in a block will decrease. On the other hand, compared with other baselines, this method maintains the highest throughput at different average transaction sizes. The reason lies in that this method can adjust reasonable blockchain parameters and resource allocation to improve system throughput.

Claims

1. A method for optimizing the performance and resource allocation of a sharded blockchain system based on a convex optimization algorithm, characterized in that, First, a blockchain sharding system based on the PBFT consensus mechanism is established. Subsequently, how system parameters and resource allocation affect system throughput is analyzed. Finally, the co-optimization problem of system parameters and resource configuration is formalized.

2. The method for optimizing the performance and resource allocation of the sharded blockchain system based on the convex optimization algorithm according to claim 1, wherein All nodes in the blockchain sharding system are deployed on a cloud platform; each node follows a sharding protocol to optimize the management process and uses the PBFT consensus mechanism to ensure fast and secure consensus on transactions within each shard. The operation of the sharding blockchain system mainly includes the following steps: all transactions enter different shards for processing; then each shard independently and concurrently processes the allocated different transaction sets, and verifies the integrity of the blocks through consensus within the shard to achieve high throughput in system transaction processing; the blocks created in each shard are merged and re-verified through the final PBFT, thus forming new blocks on the main chain.

3. The method for optimizing the performance and resource allocation of the sharded blockchain system based on the convex optimization algorithm according to claim 2, wherein The PBFT verification process for n nodes is as follows: Initialization: When the system is initialized, all nodes start with the same state. Client request: The client sends a request to the primary node in the system. Pre-prepare phase: After receiving the request, the primary node treats it as a new transaction and generates a sequence number for this transaction. Then, the primary node signs the pre-prepared message containing the transaction and broadcasts this message to all other nodes. Prepare phase: After receiving the prepare message, the replica nodes verify the validity of the message, sign the prepare message, and return the prepare message to the primary node and all other nodes. Commit: Once the primary node receives the corresponding prepare messages sent by 2n / 3 + 1 nodes, it signs the commit message and sends it to all nodes. Reply: After receiving 2n / 3 + 1 confirmation messages, the replica nodes consider the transaction committed and apply it to the local state machine to complete the consensus process.

4. The method for optimizing the performance and resource allocation of the sharded blockchain system based on the convex optimization algorithm according to claim 3, characterized in that, The system consists of K - 1 shards and 1 final consensus group, denoted by . The shard number is indexed by . The number of nodes in each shard is denoted by N. Transactions randomly arrive at the sharded blockchain system. The transaction volume that each shard needs to process is denoted by λ k B, where B represents the block size, and λ k represents the coefficient of the transaction quantity of the k-th shard; Use a binary tuple Re k = <c k , r k > to represent the resource situation allocated to shard k, where c k represents the computing resources allocated to shard k, and r k represents the bandwidth resources allocated to shard k; each type of resource has a maximum limit, which are represented by C max and R max respectively; Therefore, there are the following constraints: Assume that the message verification process includes verifying signatures and message authentication code operations, which use θ and α CPU cycles respectively; latency refers to the time required for a transaction to enter the blockchain system and finally be processed and become irreversible. The trading process consists of two steps: 1) block interval; 2) consensus delay, and the total delay T of the system total is obtained by the following formula: T total = T I + T con (2) Among which T I is the block interval, and T con is the consensus delay of shard k; T con is determined by the in-shard consensus delay and the final consensus delay, and is obtained by the following formula: Among them and T final respectively represent the in-shard consensus and the final consensus latency; the in-shard consensus latency and the final consensus latency include message propagation and message verification latency, which are obtained by the following formula: Among them and represent the propagation delay and verification delay in the in - shard consensus process in the sharded blockchain system, T dprop and T dval represent the propagation delay and verification delay in the final consensus process; The in - slice consensus consists of three stages, namely the pre - prepare stage, the prepare stage, and the commit stage. The propagation delays of each stage are represented by and respectively; assuming the timeout bound ζ of the maximum waiting time, timeouts are set for message propagation between nodes in the consensus process and cannot exceed the maximum waiting time. Therefore, the in - slice propagation delay is calculated as follows: Meanwhile, there are constraints: Similarly, the final consensus consists of five stages, namely the request stage, the pre-preparation stage, the preparation stage, the submission, and the reply stage. The propagation delays of each stage are represented by T dreq , T dpreprepqare , T dprepare , T dcom , and T reply respectively. Therefore, the final propagation delay is calculated as follows: Therefore, the total consensus latency of the sharding blockchain system is expressed by the following formula:

5. The method for optimizing the performance and resource allocation of a sharded blockchain system based on a convex optimization algorithm according to claim 4, characterized in that At the beginning of the initial consensus for each shard, the primary node creates λ k blocks, performs a message authentication code verification operation for each request, and verifies the signature for each request; at the end of the commit phase, the primary node and the replica nodes send their in-shard consistency to the final consensus group to obtain final consistency; at this time, the primary node and the replica nodes create N message authentication codes for each request; therefore, in the consensus model within a shard, it is considered that the processing time of the primary node and the replica nodes in the k-th shard are respectively: where c k refers to the amount of computing resources invested in shard k. Here, only considering the case where the computing resources within the shard are evenly distributed, it is obtained that within the same shard, the processing time of the master node is longer than that of the replica node, and the master node's calculation is the main consideration; The consensus within the shard is processed in parallel, and the latency is determined by the shard with the maximum latency. The verification processes of the primary replica and replicas are executed in parallel, and it is considered that: The consensus process of all shards is carried out in parallel, and the propagation latency of each step in the in-shard consensus is expressed by the following formula: where λ k B is the trading volume of the k-th shard, and r k represents the data transfer rate between nodes in shard k; and are equal to That is, the internal propagation delay of requests for consensus steps within each shard is calculated as follows:

6. The method for optimizing the performance and resource allocation of the sharded blockchain system based on the convex optimization algorithm according to claim 5, wherein The final consensus delay refers to the delivery of the blocks that reach consensus within K-1 shards to the final consensus group to reach the final consensus. The final consensus group verifies signatures and verifies the message authentication codes of the blocks received from each shard; the nodes in the final consensus group execute PBFT consensus again and then return the merged blocks to all other nodes; then, the processing times of the primary node and the replica nodes in the final consensus group are respectively represented as: Among which C K represents the computing resources of the primary node and replica nodes in the final consensus, which is obtained from the above formula. In the final consensus group, the processing time of the primary node is longer than that of the replica nodes. Therefore, the verification delay in the final consensus group is obtained as follows: T dval = max{T dprimary , T dreplica} (13) The propagation latency of each step in the final consensus is expressed by the following formula: where r K represents the data transmission rate between nodes in the final consensus group; similar to the in-chip consensus propagation, the propagation delays of the first four steps in formula (14) are equal. Therefore, the propagation delay in the final consensus group is as follows: The total transaction latency is completed within multiple consecutive block intervals u, so there are the following constraints on latency:

7. The method for optimizing the performance and resource allocation of the sharded blockchain system based on the convex optimization algorithm according to claim 6, characterized in that, The blockchain throughput refers to the number of transactions processed per second by the blockchain system; the block generator has a block interval period T I Generate a local block with the maximum B size; if the average transaction size is b and the block header size is B H , the number of shards is K - 1, and the number of transaction blocks per shard is λ k , then the maximum throughput of the blockchain system is calculated from the following formula: Given the system parameters, it is desired to allocate resources to K shards in the sharded blockchain system while optimizing the block interval T I and the block size B, and maximize the throughput T of the blockchain system. The formal definition of the above joint optimization problem is as follows: Constraint C1 represents that it is completed before the maximum waiting duration of each consensus step; Constraint C2 represents the relationship between the total consensus latency and the block interval; Constraints C3 and C4 represent that each type of resource cannot exceed the maximum budget.

8. The method for optimizing the performance and resource allocation of the sharded blockchain system based on the convex optimization algorithm according to claim 7, wherein Solve the P1 problem using a two-stage alternating iteration algorithm; the two-stage alternating iteration algorithm uses the block coordinate descent method to transform the original problem into two sub-problems: the system parameter optimization problem and the network resource allocation problem; sub-problem 1 is to optimize the system parameters B and T under the condition of fixed resource allocation c k , r k ; sub-problem 2 is to optimize the resource allocation c under the condition of fixed system parameters B and T I ; sub-problem 2 is to optimize the resource allocation c I under the condition of fixed system parameters B and T k , r k ; by optimizing the two sub-problems sequentially in each iteration, the maximization of the throughput of the sharded blockchain system gradually converges.

9. The method for optimizing the performance and resource allocation of the sharded blockchain system based on the convex optimization algorithm according to claim 8, wherein The first sub - problem of problem P1, denoted as P2, is to solve for the optimal system parameters B, T k and r k under the given resource allocations c I ; in this sub - problem P2, the coupling relationships among the optimization variables c k and r k , B, and T I in the original problem no longer exist, and the formalization of this sub - problem P2 is as follows: The system parameters B and TI will be fixed and optimized respectively; substituting formulas (8), (11), (12), and (15) into (19b) gives the following formula: The second sub-problem of problem P1, denoted as P3, is to solve for the optimal resource allocation c I and r k under the system parameters B and T obtained by solving P2 k ; this problem P3 can be formalized as follows: Theorem 2: Problem P3 is a convex optimization problem with respect to variables c k , r k ; Proof: For the constraint condition 21a in problem P3, construct the auxiliary function and find its second derivative with respect to the variable r k . It can be obtained that Therefore, this function is a convex function with respect to the variable r k . It can be obtained that the constraint condition 21a is a convex constraint, and the constraint condition 21d is a convex constraint with respect to the variable r k . For the constraint condition 21b, construct the auxiliary function 10. The method for optimizing the performance and resource allocation of the sharded blockchain system based on the convex optimization algorithm according to claim 9, wherein In the two-stage alternating iteration algorithm, by alternately solving the sub-problems P2 and P3 of P1, the optimization of the system parameters B, T I and the network resources c k , r k is achieved. The specific implementation steps of the algorithm are as follows: The algorithm first gives an initial feasible solution according to the random strategy, and then solves the two sub-problems of the original problem; specifically, first, taking ck and rk obtained in the previous iteration as inputs, B and TI are obtained by solving problem P2; second, taking B and TI obtained in the previous iteration as inputs, ck and rk are obtained by solving problem P3; finally, the system throughput is calculated according to the obtained optimal solution and formula (17); the condition for the end of the loop is that the difference between the results obtained in two loops is less than the precision threshold ε or the number of loops reaches the maximum value itermax; the algorithm finally returns the obtained minimum average task response time.

Images