Dynamic transaction sharding protocol method for consortium chain

Abstract

The application relates to a dynamic transaction sharding protocol method for a consortium chain, which comprises the following steps: S1, a number of shards is designed in advance, nodes in the consortium chain are divided into different shards, a leader node in each shard and a master node of the consortium chain are elected; S2, after a transaction is received, the transaction is distributed to a corresponding shard for consensus, and a microblock is formed; S3, the master node verifies the microblock and transactions in the microblock in a consensus committee, encapsulates the verified microblock into a macroblock, and adopts the macroblock to synchronize the state of all network nodes; wherein the consensus committee comprises the master node and all leader nodes; and S4, a reputation model is used to force nodes to jointly maintain the safety of the consortium chain and distinguish malicious nodes from normal nodes. The application has high processing efficiency, can reduce network congestion and shard reconfiguration cost, and has high throughput and reliability.

Description

Technical Field

[0001] This invention relates to the field of blockchain, and more specifically to a dynamic transaction sharding protocol method for consortium blockchains. Background Technology

[0002] Consortium blockchains offer decentralization and node manageability, making them suitable for industries such as finance, supply chain management, and healthcare. However, as the number of nodes increases, communication congestion and decreased throughput become significant scalability obstacles for consortium blockchains. Researchers have proposed various strategies to address performance issues and meet the practical need to enhance blockchain resources to manage ever-increasing transaction volumes. Existing solutions for blockchain scaling fall into two categories: off-chain and on-chain. Off-chain solutions employ a layered system, simplifying the blockchain architecture by aggregating resource transfers resulting from fine-grained payments managed separately in multiple asynchronous subsystems. Only the final results are stored on the blockchain, thus avoiding the high computational costs of traditional blockchain systems. On-chain solutions enhance the functionality and data processing capabilities of the blockchain by improving its protocols and mechanisms. On-chain solutions do not require coordinating or managing various subsystems and are able to record, verify, and retain all transactions, making them the mainstream approach for blockchain scaling in environments with varying network bandwidth and computational resources.

[0003] Sharding protocols are commonly used in distributed databases and cloud infrastructures. They can divide a large database into smaller data fragments and store these fragments on different servers for fast and efficient data management. Elastico first combined sharding protocols with blockchain in 2016, avoiding the forced repetitive communication and computational overhead of each participating node. Sharding protocols have been thoroughly researched and validated in academic papers, demonstrating their effectiveness in improving throughput, reducing costs, and maintaining decentralization, making them a mainstream solution for on-chain scaling. While sharding protocols improve the scalability of consortium blockchains, they still have performance limitations in transaction verification and consensus processing. As the number of members increases, the communication bandwidth and time required for broadcasting and message collection consume significant resources, thus reducing protocol efficiency. Summary of the Invention

[0004] The technical problem to be solved by the present invention is to overcome the defects of the prior art and provide a dynamic transaction sharding protocol method for consortium blockchains. It has high processing efficiency, can reduce network congestion and sharding reconfiguration costs, and has high throughput and reliability.

[0005] To solve the above-mentioned technical problems, the technical solution of the present invention is: a dynamic transaction sharding protocol method for consortium blockchains, comprising:

[0006] S1, pre-design the number of shards, divide the nodes in the consortium chain into different shards, and elect the leader node in each shard and the master node of the consortium chain;

[0007] S2, after receiving a transaction, distributes the transaction to the corresponding shard for consensus to form a micro-block;

[0008] S3, the master node verifies the micro-block and its internal transactions in the consensus committee, and encapsulates the verified micro-block into a large block. All nodes in the network adopt the large block synchronization state; wherein, the consensus committee includes the master node and all leader nodes;

[0009] S4 uses a reputation model to force nodes to jointly maintain the security of the consortium blockchain and distinguish between malicious and normal nodes.

[0010] Furthermore, S1 specifically includes:

[0011] S11, in the consortium blockchain, the number of shards k is determined based on the needs analysis of the actual application environment;

[0012] S12, all nodes calculate their identity ID, perform a modulo operation on k based on the ID, and the remainder r is the shard number to which it belongs;

[0013] S13, elect the leader node in each shard and the master node of the consortium chain; among them, the nodes are logically divided into three types of verification nodes: consensus nodes, leader nodes and master nodes;

[0014] Furthermore, in S12, the formula for calculating the identity ID of each node is:

[0015] ID=SHA256(IP+PK+epochRandomness)

[0016] Where IP represents the node's Internet Protocol address; PK represents the node's public key; epochRandomness represents the epoch randomness source; and SHA256 represents the secure hash algorithm.

[0017] Furthermore, S13 specifically includes:

[0018] S131, in each shard, the node with the smallest ID is the leader node;

[0019] S132, each leader node uses its private key as input to execute VRF and determines whether it is the master node based on the output. If it determines itself as the master node, it broadcasts verifiable election information in the result. After receiving the master node message, other nodes verify whether the legality of the random number in it meets the threshold condition. Based on the verification result, it can determine whether the message sender is the real master node. After becoming the master node, the leader node also serves as the leader node of its respective shard.

[0020] Furthermore, S2 specifically includes:

[0021] S21, Receive transaction request;

[0022] S22, Perform a modulo operation on k based on the hash value of the transaction, and the remainder r is the shard number for processing the transaction;

[0023] S23, the leader node of the corresponding shard announces the transaction confirmation threshold Tct to the consensus nodes within the shard;

[0024] S24, consensus nodes and leader nodes reach consensus on transactions and place the completed transactions into the encapsulation queue;

[0025] S25, the leader node encapsulates the transactions in the queue into a microblock and sends the microblock information to the master node.

[0026] Furthermore, S23 specifically includes:

[0027] S231, The current leader node sends the transaction confirmation threshold Tct to the consensus nodes within the shard;

[0028] S232, consensus nodes that do not receive Tct within the preset time shall publish a No-Tct message in the shard;

[0029] S233, after receiving two or more No-Tct messages, the shard changes the leader node to the node with the smallest ID among the nodes with an ID greater than the current leader node;

[0030] S234, return to step S231, until the number of No-Tct received by the fragment within the preset time does not exceed one.

[0031] Furthermore, S24 specifically includes:

[0032] S241, the consensus node verifies the transaction information and client signature, adds the correct transaction to the transaction pool, and broadcasts a confirmation message;

[0033] S242: After the number of confirmation messages received by the leader node reaches the transaction confirmation threshold Tct, the transaction will be queued into the encapsulation queue.

[0034] Furthermore, S3 specifically includes:

[0035] S31, The master node uses the PBFT algorithm to verify the correctness of the microblock content with all leader nodes;

[0036] S32, provided that consensus on all micro-blocks in the shards is achieved, the master node will encapsulate all micro-blocks into a large block and publish it to all nodes in the network;

[0037] S33: All network nodes receive large blocks sent by the master node and compare the content of the large block with the verified transactions through their local transaction pool. If the content is correct, the state is directly synchronized.

[0038] Furthermore, S31 specifically includes:

[0039] S311, the master node assigns a unique number n to each microblock and broadcasts the microblock and n together as a pre-prepare message to all other leader nodes;

[0040] S312. After receiving the pre-prepare message, all other leader nodes check whether the message originated from the master node based on the signature field. After confirming that it is correct, they combine the micro-block number and their own signature to form a prepare message and broadcast it to all leader nodes, including the master node, to indicate that they recognize the micro-block number and that preparation is complete.

[0041] S313, all leader nodes, including the master node, check the signature of any received prepare messages to ensure their correctness. If the number of prepare messages exceeds the total number of participating leader nodes, k... The consortium blockchain is considered to have reached a consensus and recognizes the microblock, and a commit message is broadcast to all leader nodes, including the master node.

[0042] S314, all leader nodes, including the master node, check the message's correctness based on its signature upon receiving a commit message. If the number of committed messages exceeds... Then the business required by the microblock will be completed.

[0043] Furthermore, S33 specifically includes:

[0044] All nodes in the network receive large blocks sent by the master node and compare the contents of the large blocks with the verified transactions through their local transaction pools;

[0045] If the content is correct, the node will directly synchronize its status.

[0046] If a consensus node discovers that a transaction submitted by the leader node has not been verified, it will send a challenge message to the master node. This challenge message includes information about the micro-block to be reviewed and the location of the transaction to be reviewed. The master node forwards the received challenge message to all k-1 shards except the initially processed shard for in-shard verification. The master node then reaches a consensus on the verification results of the k-1 shards in the consensus committee. If more than [a certain number of] verification results are found to be valid, [further action is required]. If a shard deems a transaction incorrect, the masternode encapsulates the challenge message and review result into a block and uploads it to the consortium blockchain. If the number of shards deeming a transaction incorrect does not exceed [a certain threshold], the transaction can proceed. Questions will be invalidated, and sending incorrect questions will be considered malicious.

[0047] By adopting the above technical solution, the present invention has the following beneficial effects:

[0048] 1. The overall transaction is split based on the consensus committee and multiple sub-committees composed of shards. Verification nodes enter the shards while ensuring randomness. The master node, elected by a verifiable random function, organizes the entire system process during its tenure, enabling the shards to process their respective transactions independently and in parallel.

[0049] 2. A dynamic transaction confirmation consensus mechanism is adopted within the shards, which improves the consensus efficiency within the shards and significantly enhances the performance of the consortium blockchain system. The leader node of each shard will encapsulate the transactions of the entire shard into micro-blocks and transmit them to the consensus committee to reduce communication overhead. The protocol includes censorship mechanisms and reputation models to constrain node behavior. Overall, the protocol significantly improves the performance and scalability of the consortium blockchain.

[0050] 3. Under the aforementioned multi-shard architecture, a review mechanism ensures the validity of transactions uploaded by the leader node and reduces system centralization. In addition to the review mechanism, a point-based reward and punishment system is designed. The chain point system's increment and decrement principles are based on the probability of malicious node activity and its impact on the blockchain system, ensuring that the number of malicious nodes within each shard does not affect system operation. This improves shard security in the consortium blockchain. Overall, this protocol enhances the throughput and reliability of the consortium blockchain system. Even if the number of consortium blockchain nodes increases to its usual maximum or some nodes fail, the protocol can still maintain stable performance. Attached Figure Description

[0051] Figure 1 This is a flowchart of the dynamic transaction sharding protocol method for consortium blockchains according to the present invention;

[0052] Figure 2 This is a schematic diagram of the architecture of the dynamic transaction sharding protocol system for consortium blockchains according to the present invention;

[0053] Figure 3 This is a schematic diagram of the node network of the present invention;

[0054] Figure 4 This is a flowchart illustrating the identity change of a node after it enters a consortium blockchain, as described in this invention.

[0055] Figure 5 This is a schematic diagram of the dynamic transaction confirmation consensus process within a shard according to the present invention;

[0056] Figure 6 This is a schematic diagram illustrating the increase and decrease of reputation points according to the present invention. Detailed Implementation

[0057] To make the content of this invention easier to understand, the invention will be further described in detail below with reference to specific embodiments and accompanying drawings.

[0058] like Figure 1 As shown, a dynamic transaction sharding protocol method for consortium blockchains includes:

[0059] S1, pre-design the number of shards, divide the nodes in the consortium chain into different shards, and elect the leader node in each shard and the master node of the consortium chain;

[0060] S2, after receiving a transaction, distributes the transaction to the corresponding shard for consensus to form a micro-block;

[0061] S3, the master node verifies the micro-block and its internal transactions in the consensus committee, and encapsulates the verified micro-block into a large block. All nodes in the network adopt the large block synchronization state; wherein, the consensus committee includes the master node and all leader nodes;

[0062] S4 uses a reputation model to force nodes to jointly maintain the security of the consortium blockchain and distinguish between malicious and normal nodes.

[0063] Specifically, this embodiment improves transaction processing efficiency by dividing nodes and allocating different transactions to different shards. It uses dynamic transaction confirmation consensus as an internal consensus mechanism within shards to reduce message size and packages transactions into micro-blocks, thereby modifying the communication content during transaction propagation between shards and reducing network congestion and shard reconfiguration costs. This embodiment utilizes an auditing system and reputation model to identify and punish malicious nodes. This embodiment is suitable for scenarios in industrial and commercial fields such as finance, logistics, and supply chain management where throughput and reliability requirements are high. Even if the number of nodes in the consortium blockchain increases to the commonly used maximum, or if a faulty node occurs, this method can still maintain stable performance.

[0064] Specifically, S1 includes:

[0065] S11, in the consortium blockchain, the number of shards k is determined based on the needs analysis of the actual application environment;

[0066] S12, all nodes calculate their identity ID, perform a modulo operation on k based on the ID, and the remainder r is the shard number to which it belongs;

[0067] S13, elect the leader node in each shard and the master node of the consortium chain; among them, the nodes are logically divided into three types of verification nodes: consensus nodes, leader nodes and master nodes;

[0068] In S12, the formula for calculating the identity ID of each node is:

[0069] ID=SHA256(IP+PK+epochRandomness)

[0070] Where IP represents the node's Internet Protocol address; PK represents the node's public key; epochRandomness represents the epoch randomness source; and SHA256 represents the secure hash algorithm.

[0071] Specifically, S13 includes:

[0072] S131, in each shard, the node with the smallest ID is the leader node;

[0073] S132, each leader node uses its private key as input to execute a VRF (Verifiable Random Function). Based on the output, it determines whether it is the master node. If it identifies itself as the master node, it broadcasts verifiable election information in the result. After receiving the master node message, other nodes verify whether the legality of the random number meets the threshold condition. Based on the verification result, it can determine whether the message sender is the real master node. After becoming the master node, the leader node also serves as the leader node of its respective shard.

[0074] Specifically, this embodiment incorporates a verifiable random function into the node configuration to ensure a sufficient number of honest nodes within a shard and prevent duplicate consensus processes. VRF uses node private keys as input, and the output value is fixed for the same input. Verification of the lottery result is performed using the public key corresponding to the private key; therefore, the lottery result cannot be forged. This is the advantage of VRF election results in terms of uniqueness and anti-forgery lottery results.

[0075] Specifically, S2 includes:

[0076] S21, Receive transaction request;

[0077] S22, Perform a modulo operation on k based on the hash value of the transaction, and the remainder r is the shard number for processing the transaction;

[0078] S23, the leader node of the corresponding shard announces the transaction confirmation threshold Tct to the consensus nodes within the shard;

[0079] S24, consensus nodes and leader nodes reach consensus on transactions and place the completed transactions into the encapsulation queue;

[0080] S25, the leader node encapsulates the transactions in the queue into a microblock and sends the microblock information to the master node.

[0081] Specifically, S23 includes:

[0082] S231, The current leader node sends the transaction confirmation threshold Tct to the consensus nodes within the shard;

[0083] S232, consensus nodes that do not receive Tct within the preset time shall publish a No-Tct message in the shard;

[0084] S233, after receiving two or more No-Tct messages, the shard changes the leader node to the node with the smallest ID among the nodes with an ID greater than the current leader node;

[0085] S234, return to step S231, until the number of No-Tct received by the fragment within the preset time does not exceed one.

[0086] Specifically, S24 includes:

[0087] S241, the consensus node verifies the transaction information and client signature, adds the correct transaction to the transaction pool, and broadcasts a confirmation message;

[0088] S242: After the number of confirmation messages received by the leader node reaches the transaction confirmation threshold Tct, the transaction will be queued into the encapsulation queue.

[0089] Specifically, S3 includes:

[0090] S31, the master node uses the PBFT (Practical Byzantine Fault Tolerance) algorithm to verify the correctness of the microblock content with all leader nodes;

[0091] S32, provided that consensus on all micro-blocks in the shards is achieved, the master node will encapsulate all micro-blocks into a large block and publish it to all nodes in the network;

[0092] S33: All network nodes receive large blocks sent by the master node and compare the content of the large block with the verified transactions through their local transaction pool. If the content is correct, the state is directly synchronized.

[0093] Specifically, S31 includes:

[0094] S311, the master node assigns a unique number n to each microblock and broadcasts the microblock and n together as a pre-prepare message to all other leader nodes;

[0095] S312. After receiving the pre-prepare message, all other leader nodes check whether the message originated from the master node based on the signature field. After confirming that it is correct, they combine the micro-block number and their own signature to form a prepare message and broadcast it to all leader nodes, including the master node, to indicate that they recognize the micro-block number and that preparation is complete.

[0096] S313, all leader nodes, including the master node, check the signature of any received prepare messages to ensure their correctness. If the number of prepare messages exceeds the total number of participating leader nodes, k... The consortium blockchain is considered to have reached a consensus and recognizes the microblock, and a commit message is broadcast to all leader nodes, including the master node.

[0097] S314, all leader nodes, including the master node, check the message's correctness based on its signature upon receiving a commit message. If the number of committed messages exceeds... Then the business required by the microblock will be completed.

[0098] Specifically, S33 includes:

[0099] All nodes in the network receive large blocks sent by the master node and compare the contents of the large blocks with the verified transactions through their local transaction pools;

[0100] If the content is correct, the node will directly synchronize its status.

[0101] If a consensus node discovers that a transaction submitted by the leader node has not been verified, it will send a challenge message to the master node. This challenge message includes information about the micro-block to be reviewed and the location of the transaction to be reviewed. The master node forwards the received challenge message to all k-1 shards except the initially processed shard for in-shard verification. The master node then reaches a consensus on the verification results of the k-1 shards in the consensus committee. If more than [a certain number of] verification results are found to be valid, [further action is required]. If a shard deems a transaction incorrect, the masternode encapsulates the challenge message and review result into a block and uploads it to the consortium blockchain. If the number of shards deeming a transaction incorrect does not exceed [a certain threshold], the transaction can proceed. Questions will be invalidated, and sending incorrect questions will be considered malicious.

[0102] Specifically, S4 includes:

[0103] S41, there is a one-to-one mapping between nodes and enterprise entities;

[0104] S42, nodes pay a deposit upon entry and receive an initial reputation score;

[0105] S43: Nodes gain or lose points based on their specific actions. When the points drop to a preset value, the node will be forcibly removed from the network and its deposit will be forfeited.

[0106] The technical solutions involved in the above embodiments will be described in detail below with reference to specific examples.

[0107] Figure 2 This is the system architecture proposed in this embodiment. The system consists of three parts. The first part is the basic framework layer, which includes blocks, blockchain, transactions, transaction pools, messages, and the network, forming the basic framework of the blockchain system, the node network, and the transaction cache pool. The second part is the functional layer, which includes encapsulation functions, nodes, consensus mechanisms, and views, implementing transaction verification and encapsulation, message transmission, and view transformation functions. The third part is the implementation layer, which only contains the sharding protocol.

[0108] In the basic framework, a block contains a Merkle root, version information, block number, and timestamp. Nodes have an information table and a micro-block table. The information table stores view transformation information and transaction verification and review information received from the network, while the micro-block table stores micro-blocks sent by the leader node of its subcommittee, comparing them with the large block information on the consortium blockchain. The network class is responsible for managing node addresses.

[0109] Figure 3 This is the node network proposed in this embodiment. The diagram illustrates the interaction between nodes and shards. The network model design adopts a weakly centralized network architecture based on a consortium blockchain. Nodes need system approval to enter or leave the network and broadcast their node address to the consortium blockchain network, joining at the start of the next sharding period.

[0110] And in Figure 3 In this protocol, three types of validator nodes are included: consensus nodes, leader nodes, and master nodes. Each sub-committee consists of all consensus nodes and leader nodes within a single shard, while the sole consensus committee consists of all leader nodes and master nodes. Consensus nodes verify transactions and submit the final consensus result to the leader node within their respective sub-committee. Leader nodes encapsulate the consensus-completed transactions into microblocks and submit these microblocks to the sole master node at each shard period. The master node organizes the verification of microblocks within its consensus committee and encapsulates and uploads the verified microblocks to the consortium blockchain. After all validator nodes synchronize their states, each leader node randomly generates a string. The master node merges these strings, adds the latest block hash, and finally uses a secure hash algorithm (SHA256) to calculate the era random source. The master node broadcasts the obtained era random source to the entire network, and then the system executes the view replacement protocol to transition to the next shard period.

[0111] Figure 4 This describes the process of node identity changes during sharding. In each sharding period, a node possesses its own identity ID. Each node uses its ID as input for a modulo operation, with the remainder *r* representing its position in a subcommittee. The node with the smallest ID becomes the leader node. Each leader node executes a Verifiable Random Function (VRF) with its private key as input. The algorithm's input and output are (r, proof, result) = VRF_result(s, SK), where *s* is the seed for the leader node's extraction algorithm (which can be the hash of the current node's public key), *proof* is a zero-knowledge proof using a provided random value, and *SK* is the node's private key. To ensure the VRF result is unpredictable, an unpredictable and tamper-proof value needs to be embedded in *s*, such as the hash of the most recent block or the block height. A node determines whether it is a leader node based on the *result*. The determination is based on calculating the extraction result using *r* and comparing it with a threshold, where the hash function is the SHA256 cryptographic hash algorithm. If it determines it is a leader node, it broadcasts the extraction result and the message content (r, proof, bool, ID). After receiving the message, other nodes verify the validity of the random number and whether it meets the threshold condition. The verification function is result = Verify(s,r,PK).

[0112] Figure 5 This embodiment describes the dynamic transaction confirmation consensus process within a shard. The leader node broadcasts the Tct value to the consensus nodes. If a consensus node does not receive the Tct value within a specified time, it broadcasts a no-Tct message to other consensus nodes within the sub-committee. If two no-Tct messages are received, the next leader node is selected from the sub-committee node with the largest and closest ID to the current leader node. The client broadcasts the transaction information and signs it to the node network set. Nodes within the shard verify the signature; if correct, the transaction is stored in the transaction pool. If the verifying node verifies the transaction, it adds the transaction to the verified transaction set and broadcasts confirmation information. When the number of confirmation messages received by the leader node reaches a threshold, it considers the transaction correct, adds it to the transaction encapsulation queue, and encapsulates the transactions in the queue into microblocks after time t, sending the microblock information to the master node. The microblock information includes transaction information, version information, Tct, verification information, etc. After receiving the large block information sent by the master node, the verification node iterates and compares its own transaction pool with the set of verified transactions. If the transaction information in the block is in the set of verified transactions, it skips it; if the transaction is in the transaction pool but has not been verified by itself, it retrieves it for verification; if the transaction information is incorrect, it raises a question to the master node and applies to enter the review stage; if the transaction is correct, it updates its own consortium chain.

[0113] If a transaction fails to reach consensus within a group, but the leader node encapsulates it and submits it to the master node, or if a consensus node discovers information about an unverified transaction in a micro-block during the master node's announcement phase, it can send a challenge message (including the message challenge type) to the master node. After receiving at least one challenge message, the master node forwards the challenged message to the remaining sub-committees for group consensus. The other group leader nodes then send their group verification information to the master node. Similarly, if a consensus committee performs PBFT consensus and obtains the same approval opinion from a certain number of sub-committees... Subsequently, the review results and the reviewed micro-blocks are packaged into a block and uploaded to the blockchain. Furthermore, based on the type of complaint, the responsible node's reputation score is deducted.

[0114] If the master node commits malicious acts, all nodes on the network can challenge the transactions in the previous block before the next block is published. If the challenge is successful, the malicious master node will be punished, and its points will be deducted and given to the challenging node. If the master node does not respond to the challenge message within the specified time, it will be replaced by the leader node with the smallest ID.

[0115] Figure 6 This embodiment describes an example of reputation score increases and decreases. Outside of the consensus mechanism, a reward and punishment system is used to compel all nodes in the network to jointly maintain system security. A points pool is used to distinguish between normal and malicious nodes. Due to the enterprise's sound regulatory system, nodes in the consortium blockchain can have a one-to-one mapping relationship with the enterprise entity. Therefore, by linking points to personal economic rewards or penalties, economic game theory can be used to incentivize all nodes to jointly maintain system security, limit malicious behavior, and increase the cost of malicious behavior. Reputation is obtained by recording and calculating behavioral information and is used to assess the reliability of nodes and verify their voice. To prevent nodes from becoming normal nodes again after malicious behavior through a series of point-adding actions, thus creating a low-cost problem for malicious behavior, a node malicious behavior counter concept is introduced into the punishment mechanism. The malicious behavior counter is stored in the node's account. The relationship between points S, the points P corresponding to point-increasing actions, the points Q corresponding to point-deducting actions, and the number of malicious behaviors T is S = S + P - QT. Therefore, the point loss caused by repeated malicious behavior will become increasingly larger until a single malicious behavior causes points S to fall below a preset value, thereby removing the node from the consensus node set.

[0116] Based on the above-described preferred embodiments of the present invention, and through the foregoing description, those skilled in the art can make various changes and modifications without departing from the inventive concept. The technical scope of this invention is not limited to the contents of the specification, but must be determined according to the scope of the claims.

Claims

1. A dynamic transaction sharding protocol method for a consortium chain, characterized in that, comprising: S1, a number of shards is designed in advance, nodes in the consortium chain are divided into different shards, and leader nodes in each shard and a master node of the consortium chain are elected, and a one-to-one mapping exists between the nodes and enterprise entities; the sharding strategy is: the number of shards k is determined according to the demand analysis of the actual application environment in the consortium chain; all nodes calculate their identities ID, and perform a modulo operation on k according to the ID, and the remainder r is the shard serial number to which the node belongs; the formula for calculating the identity ID of each node is: ID = SHA256 (IP + PK + epochRandomness) wherein IP represents the Internet protocol address of the node; PK represents the public key of the node; epochRandomness represents an epoch randomness source, and SHA256 represents a secure hash algorithm; the nodes are divided into three types of verification nodes in terms of logical roles: consensus nodes, leader nodes and master nodes; the strategy for electing leader nodes in each shard and the master node of the consortium chain is: in each shard, the node with the smallest ID is the leader node; each leader node uses a private key as input to execute VRF, and judges whether it is a master node according to the output result; if it judges itself as a master node, it broadcasts election information for verification in the result; after other nodes receive the master node message, they verify whether the legality of the random number meets the threshold condition, and judge whether the message sender is the real master node according to the verification result; after the leader node serves as the master node, it also serves as the leader node of the corresponding shard; S2, after receiving a transaction, the transaction is allocated to the corresponding shard for consensus to form a microblock; S2 specifically comprises: S21, receiving a transaction request; S22, performing a modulo operation on k according to the hash value of the transaction, and taking the remainder r as the shard serial number for processing the transaction; S23, the leader node of the corresponding shard publishes a transaction confirmation threshold Tct to the consensus nodes in the shard; S24, the consensus nodes and the leader node perform consensus on the transaction, and put the consensus completed transaction into an encapsulation queue; S25, the leader node encapsulates the transaction in the queue into a microblock, and sends the microblock information to the master node; S3, the master node verifies the microblock and the transactions therein in the consensus committee, encapsulates the verified microblock into a large block, and synchronizes the state of the large block to all network nodes; wherein the consensus committee comprises the master node and all leader nodes; S3 specifically comprises: S31, the master node uses the PBFT algorithm to verify whether the microblock content is correct with all the leader nodes; S32, on the premise that the microblock consensus of all shards is completed, the master node encapsulates all the microblocks into a large block and publishes it to all network nodes; S33, all network nodes receive the large block sent by the master node, and compare the content of the large block with the verified transactions in the local transaction pool; if the content is correct, the state is directly synchronized; S4, a reputation model is used to force all nodes in the consortium chain to jointly maintain the security of the consortium chain, and to distinguish between malicious nodes and normal nodes.

2. The dynamic transaction sharding protocol method for alliance chain according to claim 1, characterized in that, S23 specifically comprises: S231, the current leader node sends a transaction confirmation threshold Tct to the consensus nodes within the shard; S232, the consensus nodes that do not accept Tct within a preset time publish No-Tct messages in the shard; S233, the shard replaces the leader node with the node with the smallest ID number among the nodes with IDs greater than the current leader node after receiving more than two No-Tct messages; S234, return to step S231 until the shard receives no more than one No-Tct within a preset time.

3. The dynamic transaction sharding protocol method for alliance chain according to claim 1, characterized in that, S24 specifically comprises: S241, the consensus node verifies the transaction information and the client signature, adds the correct transaction to the transaction pool, and broadcasts a confirmation message; S242: the leader node queues the transaction to the encapsulation queue after receiving a confirmation message quantity reaching the transaction confirmation threshold Tct.

4. The dynamic transaction sharding protocol method for alliance chain according to claim 1, characterized in that, S31 specifically comprises: S311, the main node assigns a unique number n to each microblock and broadcasts the microblock together with n to all other leader nodes as a pre-prepare message; S312, after receiving the pre-prepare message, all other leader nodes check whether the message is from the main node by relying on the signature field, and after confirming that there is no error, they compose a prepare message with the microblock number and their own signature, and broadcast it to all leader nodes including the main node, indicating that they approve the microblock number and prepare completion; S313, all leader nodes including the main node, if the received prepare message, rely on the signature to check whether it is correct, if the number of prepare messages exceeds the number of all participating leader nodes k It is considered that the alliance chain agrees to recognize the microblock, and the commit message is broadcast to all leader nodes including the main node; S314, if the commit message is received by all the leader nodes including the master node, the message is checked by signature to determine if it is correct, and if the number of commit messages exceeds the microblock requirement is completed.

5. The dynamic transaction sharding protocol method for alliance chain according to claim 1, characterized in that, S33 specifically comprises: All network nodes receive the large block sent by the main node, and compare the content of the large block with the verified transactions through their local transaction pools; If the content is correct, the network nodes will directly synchronize the state; If the consensus node finds that the transaction submitted by the leader node is not verified, a challenge message will be sent to the master node, which includes the microblock information to be audited and the location of the transaction to be audited; the master node forwards the received challenge message to the other k-1 shards except the initially processed shard for intra-shard verification; the master node reaches a consensus on the verification results of the k-1 shards by the consensus committee, if more than of the shards in the verification results think that the transaction is incorrect, the master node encapsulates the challenge message and the audit result into a block and uploads it to the consortium chain, if the number of shards that think the transaction is incorrect does not exceed , the challenge is invalid, and the behavior of sending false challenge is regarded as malicious.

Images