Block chain fragmentation method, block chain consensus method and block chain architecture

Abstract

The invention discloses a block chain fragmentation method, a block chain consensus method and a block chain architecture, relates to the technical field of block chains, and aims to solve the problem that the system throughput and efficiency are reduced due to poor reliability of a main node in the existing block chain fragmentation technology. The method comprises the following steps: in each scoring period, according to block consensus behavior data and transaction processing capability of each node in a block chain fragment, determining a score of each node in the block chain fragment; and according to the score of each node in the block chain fragment, the master nodes of the block chain fragment are adjusted, the number of the master nodes of the block chain fragment is m, the score of the master nodes of the block chain fragment is greater than the score of the common nodes of the block chain fragment, and m is an integer greater than 1. According to the embodiment of the invention, the high-quality node can be selected as the on-chip master node, and the dynamic adjustment of the fragment master node is realized, so that the response speed and the overall performance of the system are ensured to be in a better state.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to a blockchain sharding method, a blockchain consensus method, and a blockchain architecture. Background Technology

[0002] Currently, data circulation and trading platforms utilize blockchain technology to achieve verifiable and traceable transaction data. With the increase in data trading nodes, transaction volume and requests surge, leading to increased network latency and transaction confirmation times. To ensure the credibility of transaction data and improve transaction processing speed, blockchain sharding technology has been proposed, employing a reputation-based node scoring method to select shard master nodes. However, this scoring method is not fair or transparent enough, failing to fully consider the differences between nodes, resulting in some low-quality nodes becoming master nodes, thus significantly reducing system throughput and efficiency. In other words, the node scoring method used in existing blockchain sharding technologies selects master nodes with poor reliability, causing a decrease in system throughput and efficiency. Summary of the Invention

[0003] This application provides a blockchain sharding method, a blockchain consensus method, and a blockchain architecture to address the problem that the reliability of the master node selected by the node scoring method used in existing block sharding technologies is poor, resulting in a decrease in system throughput and efficiency.

[0004] In a first aspect, embodiments of this application provide a blockchain sharding method applied to a blockchain architecture, the blockchain architecture including blockchain sharding, the method comprising:

[0005] Within each scoring period, the score of each node in the blockchain shard is determined based on the block consensus behavior data and transaction processing capabilities of each node in the blockchain shard.

[0006] The master node of the blockchain shard is adjusted according to the scores of each node in the blockchain shard. The number of master nodes of the blockchain shard is m, and the score of the master node of the blockchain shard is greater than the score of the ordinary node of the blockchain shard. m is an integer greater than 1.

[0007] Secondly, this application also provides a blockchain consensus method applied to a blockchain architecture, wherein the blockchain architecture includes blockchain sharding, the blockchain sharding includes m master nodes and g ordinary nodes, the m master nodes are determined according to the method described in the first aspect, f is the number of Byzantine fault nodes that the blockchain can tolerate, g = 2f + 1, m is an integer greater than 1, and f is a positive integer; the method includes:

[0008] The master node receives the first request message sent by the client.

[0009] The master node assigns a sequence number to the first request message;

[0010] The master node sends a second request message carrying the sequence number to the ordinary node.

[0011] The ordinary node verifies the second request message, and if the verification is successful, executes the task corresponding to the second request message, obtains the execution result, and sends a first response message carrying the sequence number and the execution result to the master node;

[0012] When the first master node receives a first response message carrying the same sequence number and execution result from at least f+1 ordinary nodes, the first master node sends a second response message carrying the sequence number and execution result to the client. The first master node is any one of the m master nodes.

[0013] Specifically, if at least m / 2+1 master nodes send a second response message to the client carrying the same sequence number and execution result, the response to the first request message is confirmed to be valid.

[0014] Thirdly, embodiments of this application also provide a blockchain architecture, including a management committee and blockchain shards, wherein the management committee is used for:

[0015] Within each scoring period, the score of each node in the blockchain shard is determined based on the block consensus behavior data and transaction processing capabilities of each node in the blockchain shard.

[0016] The master node of the blockchain shard is adjusted according to the scores of each node in the blockchain shard. The number of master nodes of the blockchain shard is m, and the score of the master node of the blockchain shard is greater than the score of the ordinary node of the blockchain shard. m is an integer greater than 1.

[0017] Fourthly, this application also provides a blockchain architecture, which includes blockchain sharding. The blockchain sharding includes m master nodes and g ordinary nodes. The m master nodes are determined according to the blockchain sharding method described in the first aspect. f is the number of Byzantine fault nodes that the blockchain can tolerate, g = 2f + 1, m is an integer greater than 1, and f is a positive integer.

[0018] The master node is used to receive a first request message sent by the client and assign a sequence number to the first request message; and send a second request message carrying the sequence number to the ordinary node.

[0019] The ordinary node is used to verify the second request message, and if the verification is successful, execute the task corresponding to the second request message, obtain the execution result, and send a first response message carrying the sequence number and the execution result to the master node;

[0020] The master node is also configured to send a second response message carrying the sequence number and the execution result to the client when it receives a first response message carrying the same sequence number and the execution result from at least f+1 ordinary nodes.

[0021] Specifically, if at least m / 2+1 master nodes send a second response message to the client carrying the same sequence number and execution result, the response to the first request message is confirmed to be valid.

[0022] Fifthly, embodiments of this application also provide a blockchain architecture, including: a transceiver, a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor executes the computer program to implement the steps in the blockchain sharding method as described in the first aspect.

[0023] In a sixth aspect, embodiments of this application also provide a blockchain architecture, including: a transceiver, a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor executes the computer program to implement the steps in the blockchain consensus method as described in the second aspect.

[0024] In a seventh aspect, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in the blockchain sharding method as described in the first aspect; or implements the steps in the blockchain consensus method as described in the second aspect.

[0025] Eighthly, embodiments of this application provide a computer program product, including computer instructions, which, when executed by a processor, implement the steps in the blockchain sharding method as described in the first aspect; or implement the steps in the blockchain consensus method as described in the second aspect.

[0026] In this embodiment, within each scoring period, the score of each node in the blockchain shard is determined based on its block consensus behavior data and transaction processing capabilities. The master node of the blockchain shard is then adjusted based on its score, where the number of master nodes in the shard is m, and the score of each master node is greater than the score of any ordinary node in the shard, where m is an integer greater than 1. This approach evaluates node capabilities based on the consensus behavior data and transaction processing capabilities of each node within the shard during each scoring period, selecting high-quality nodes as master nodes within the shard. This dynamic adjustment of the shard master nodes ensures that the selected master nodes possess high reliability, thereby maintaining optimal system response speed and overall performance.

[0027] The system receives a first request message from the client through the master node; assigns a sequence number to the first request message through the master node; sends a second request message carrying the sequence number to the ordinary nodes through the master node; verifies the second request message through the ordinary nodes, and if the verification is successful, executes the task corresponding to the second request message, obtains the execution result, and sends a first response message carrying the sequence number and the execution result to the master node; if the first master node receives first response messages carrying the same sequence number and execution result from at least f+1 ordinary nodes, it sends a second response message carrying the sequence number and execution result to the client through the first master node, wherein the first master node is any one of the m master nodes; wherein, if at least m / 2+1 master nodes send second response messages carrying the same sequence number and execution result to the client, the response to the first request message is confirmed to be valid. In this way, by introducing multiple master nodes to share the proxy and verification responsibilities of transaction requests in the block consensus, the number of message transmissions between ordinary nodes can be effectively reduced, and the system communication complexity can be reduced. In addition, the multi-master node Byzantine fault-tolerant algorithm proposed in this application has an efficient node replacement mechanism, which provides robustness to the block system when some nodes have untrusted behavior, and ensures the continuity and stability of the consensus process. Attached Figure Description

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

[0029] Figure 1 This is a flowchart of the blockchain sharding method provided in the embodiments of this application;

[0030] Figure 2 This is a flowchart of the blockchain sharding scheme provided in the embodiments of this application;

[0031] Figure 3 This is a diagram of the sharded blockchain architecture provided in the embodiments of this application;

[0032] Figure 4 This is a flowchart of the blockchain consensus method provided in the embodiments of this application;

[0033] Figure 5 This is a schematic diagram of the MBFT consensus process provided in an embodiment of this application;

[0034] Figure 6 This is a structural diagram of the blockchain architecture provided in the embodiments of this application. Detailed Implementation

[0035] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0036] To make the embodiments of this application clearer, the relevant technical knowledge involved in the embodiments of this application will be introduced as follows:

[0037] In recent years, my country's data trading and circulation market has continued to expand, and the market demand for data transactions has also been increasing. To achieve controllable, measurable, usable yet invisible data, data circulation and trading platforms need to integrate blockchain technology to enable the storage and traceability of transaction data, thereby increasing data providers' trust in information security and data value security. Currently, blockchain's distributed ledger mechanism faces many challenges in handling large-scale data transactions, especially network latency and transaction processing speed. Due to the decentralized nature of blockchain, each node needs to verify and record transactions, which can effectively ensure system security and transparency when the data volume is small. However, with the surge in transaction data volume, this mechanism leads to higher network latency and longer transaction confirmation times, significantly impacting user experience.

[0038] To address this issue, sharding technology emerged, and currently, sharding technologies can be categorized into three types: network-based sharding, transaction-based sharding, and state-based sharding. Network sharding involves dividing nodes into different shards according to certain rules, with each shard forming a sub-network. Transaction sharding involves distributing transactions to different shards according to certain rules, with each shard processing only transactions within its own shard. A mainstream approach combines network and transaction sharding. First, a random grouping process divides all nodes into multiple shards to ensure the randomness of nodes within each shard. Simultaneously, each shard independently processes transactions and runs a consensus protocol, typically employing a modified Byzantine Fault Tolerance (BFT) algorithm to achieve consensus within the shard, thereby improving system performance and scalability.

[0039] State sharding divides the state data of the entire blockchain network into multiple subsets (shards), with each shard responsible for processing only a specific portion of transactions and storing the corresponding state information. Through sharding, network nodes only need to maintain the state data of their assigned shard, thereby reducing the storage and computational burden on each node.

[0040] Regarding the application of blockchain sharding technology in data circulation and trading platforms, existing technologies have the following main drawbacks:

[0041] 1. In data circulation and trading platforms, as the number of data trading nodes increases, the trading volume and requests surge. To ensure the credibility and traceability of transaction data, current reputation-based node scoring methods are not fair and transparent enough, failing to fully consider the differences between nodes, especially in terms of computing power, communication bandwidth, and historical behavior. This can lead to low-quality nodes becoming master nodes, significantly reducing system throughput and efficiency. Furthermore, this method cannot effectively deal with potential malicious nodes, further weakening system reliability.

[0042] 2. While some improved Byzantine Fault Tolerance (IBFT) algorithms can reduce communication overhead and improve consensus efficiency to some extent, they still suffer from drawbacks such as high communication complexity and unstable consensus processes. Furthermore, the IBFT algorithm has limitations on the number of faulty nodes; as the number of nodes participating in consensus increases, the number of potentially malicious nodes also increases, thus affecting the system's security and reliability.

[0043] 3. Applying state sharding technology in data trading platforms improves system scalability, but increases the complexity and coordination difficulty of cross-shard transactions, potentially leading to higher latency. Secondly, uneven load distribution between shards can cause resource strain, impacting transaction processing efficiency. Furthermore, maintaining and synchronizing state data poses performance challenges to lightweight nodes, and distributed state data may reduce data traceability and transaction reliability.

[0044] To overcome the shortcomings of existing technologies, this application proposes a blockchain sharding strategy and internal consensus mechanism for data circulation and trading platforms, aiming to improve the overall throughput and response speed of these platforms. This application introduces a node scoring evaluation mechanism, which quantitatively evaluates nodes based on their performance and participation in recent consensus rounds. Based on this evaluation scheme, dynamic and reasonable sharding allocation of nodes is achieved.

[0045] This application also designs a Multi-Node Byzantine Fault Tolerance (MBFT) algorithm to optimize the performance of the data trading platform under high transaction volumes. This algorithm aims to reduce latency caused by a large number of transactions and message propagation, ensuring high throughput and low latency in transaction processing. Simultaneously, the algorithm designs an effective intra-chip consensus mechanism to address the presence of a high proportion of Byzantine nodes, ensuring the system's efficiency and stability.

[0046] This application primarily addresses the following issues:

[0047] 1. To address the issues of unfairness and transparency in sharding methods for network transactions, a scheme is designed to evaluate nodes based on their behavior and participation in past consensus rounds. This scheme primarily selects high-scoring and high-quality nodes as master nodes within a shard to improve system response speed. Furthermore, to further optimize and dynamically adjust the system, a sharding management organization is established. Its members are responsible for regularly evaluating the status of each shard and dynamically adjusting the master node configuration based on actual operational conditions, ensuring that the system's response speed and overall performance are always at their best.

[0048] 2. A multi-master node Byzantine fault-tolerant algorithm (MBFT) is proposed for intra-shard consensus. First, MBFT introduces multiple master nodes to share the proxy and verification responsibilities of transaction requests, effectively reducing the number of message passes between ordinary nodes and lowering system communication complexity. Furthermore, the MBFT algorithm has an efficient node replacement mechanism, providing robustness to the system even when some nodes exhibit untrusted behavior, ensuring the continuity and stability of the consensus process.

[0049] The blockchain sharding method and blockchain consensus method provided in this application will be described in detail below with reference to the accompanying drawings, through specific embodiments and application scenarios.

[0050] See Figure 1 , Figure 1 This is a flowchart of a blockchain sharding method provided in an embodiment of this application, applied to a blockchain architecture, which includes blockchain sharding, such as... Figure 1 As shown, the method includes the following steps:

[0051] Step 101: Within each scoring period, determine the score of each node in the blockchain shard based on the block consensus behavior data and transaction processing capabilities of each node in the blockchain shard.

[0052] The embodiments of this application can be applied to sharded blockchain systems, and the embodiments of this application can adopt a mechanism of periodically evaluating blockchain shard nodes and dynamically adjusting the blockchain shard master nodes according to the scores. The above-mentioned scoring cycle can be set by the system. For example, if one day is a scoring cycle, then the nodes in the shard are evaluated once a day. Alternatively, several consensus rounds can be used as a scoring cycle, such as scoring once after every 10 rounds of consensus.

[0053] The aforementioned blockchain sharding can refer to the division of multiple nodes in a blockchain architecture into shards. That is, each shard includes multiple nodes, and each shard can form a sub-network. All nodes within each shard work together as a whole to process a specific task assigned to them.

[0054] Specifically, in this embodiment, each node within a blockchain shard can be scored based on its block consensus behavior data and transaction processing capabilities during each scoring period. The score reflects the accuracy, reliability, or credibility of a node's block consensus, as well as its processing performance, such as transaction processing speed. For example, each node's score can be calculated using a reasonable formula based on its block consensus behavior data and transaction processing capabilities in each consensus round within the current period. Nodes with correct consensus behavior and strong transaction processing capabilities will accumulate positive scores, while those with poor consensus behavior will receive negative scores.

[0055] The block consensus behavior data can refer to the consensus behavior data generated by the consensus (such as voting for or against) of a certain transaction on the blockchain of each node in the shard. That is, the block consensus behavior data can be data that records the consensus behavior of the nodes in the shard in each round of consensus within a scoring period. For example, if node A votes for the current transaction in a certain round of consensus, the voting result data is recorded in the block consensus behavior data of node A in the current scoring period.

[0056] The transaction processing capability can refer to a comprehensive evaluation based on data such as transaction processing speed, transaction confirmation time, and the number of transactions confirmed within the current scoring period, or these data can be used to measure and represent the node's ability to process transactions.

[0057] Step 102: Adjust the master node of the blockchain shard according to the scores of each node in the blockchain shard, wherein the number of master nodes of the blockchain shard is m, the score of the master node of the blockchain shard is greater than the average score of the blockchain shard, and m is an integer greater than 1.

[0058] In this embodiment, the blockchain system will dynamically adjust the master node configuration of the shard based on the past performance of each node in the shard, including the accuracy of consensus voting and the speed of transaction confirmation, so as to incentivize high-quality nodes and improve the overall network's computing efficiency and security.

[0059] Specifically, in this step, the master node configuration of a shard can be dynamically adjusted based on the scores of each node within the shard and the average score of the shard calculated in step 101. For example, if the score of a node within a shard is higher than the score of the current master node of that shard, then that node is selected as the new master node of that shard to replace the current master node with the lower score. Alternatively, the scores of each node within a shard can be sorted in descending order, and the top m nodes in terms of score can be adjusted to become the new master nodes of that shard.

[0060] Where m can be an integer greater than 1, that is, in this embodiment of the application, multiple master nodes (MainNode, MN) can be set for each shard to share the responsibility of proxying and verifying transaction requests, effectively reducing the number of message transmissions between ordinary nodes and reducing the complexity of system communication. The other nodes in the shard besides the master nodes are ordinary nodes (Normal Node, NN). In some embodiments, m can preferably be 3, that is, 3 master nodes can be set for each shard.

[0061] By combining node performance with regular dynamic selection and adjustment of shard master nodes, the effective management of transactions within a shard can be ensured, thereby improving the fairness and efficiency of the entire blockchain network.

[0062] Optionally, before step 101, the method further includes:

[0063] The N nodes of the blockchain are evenly distributed across k shards to obtain k blockchain shards. The number of nodes in each blockchain shard is N / k, where N is an integer greater than k.

[0064] From each of the blockchain shards, m nodes are randomly selected as the master nodes of the blockchain shards.

[0065] In some embodiments, when initializing the blockchain system, N nodes can be evenly distributed across k shards, with each shard containing N / k nodes. For each shard, m nodes can be randomly selected as the shard master nodes.

[0066] Specifically, during the initialization phase of the data trading and circulation platform, numerous nodes need to join the blockchain network. Since these nodes initially lack accumulated scores, the blockchain system employs a Verifiable Random Function (VRF) for secure random allocation, ensuring that nodes are evenly distributed across k shards and avoiding uneven load distribution due to differences in device performance. Each shard is denoted as C = {c1, c2, ..., ck}, and each shard contains n = N / k nodes. Simultaneously, m nodes are randomly selected, such as three nodes, as master nodes within each shard. The consensus group consists of nodes from the same shard. Within each shard, nodes obtain scores by participating in the consensus process, and the consensus score for each round is denoted as S(i).

[0067] This implementation method ensures the diversity of devices within a shard and prevents a single shard from being overloaded due to differences in device performance.

[0068] Optionally, after randomly selecting m nodes from each of the blockchain shards as the master nodes of the blockchain shards, and before step 101, the method further includes:

[0069] Based on the block consensus behavior data and transaction processing capabilities of each node in the blockchain shard in the first round of consensus, the score of each node in the blockchain shard in the first round of consensus is determined;

[0070] Based on the scores of each node in the blockchain shard in the first round of consensus, G nodes are selected to form a management committee, wherein the scores of the G nodes in the first round of consensus are higher than the scores of other nodes in the first round of consensus, and the other nodes are the nodes other than the G nodes among the N nodes, and G is an integer greater than 1.

[0071] The management member will be used to perform steps 101 and 102.

[0072] In some embodiments, a management committee can be selected based on the performance scores of the nodes in the first round of consensus. The management committee is responsible for supervising and auditing the scoring process of each node during subsequent consensus processes, ensuring fairness and transparency. Simultaneously, the management committee is responsible for overseeing the selection process of subsequent shard master nodes to ensure the fairness and effectiveness of the entire process.

[0073] Specifically, each node's score can be initially assessed based on its performance in the first round of consensus. Since each node's behavior and data processing capabilities differ, detailed evaluation is necessary. When scoring each node, the system iterates through all nodes in each shard and evaluates them in detail based on their consensus voting behavior. Specifically, if a node votes in favor of a correct transaction or against an incorrect transaction, it is marked as an active node and gains 1 point to its consensus score S(i) to recognize its positive contribution. Conversely, if a node votes in favor of an incorrect transaction or against a correct transaction, it is marked as a disruptive node and loses 1 point to its consensus score S(i) to reflect its negative impact on system stability. Nodes that do not post comments are marked as passive nodes and retain 0 points in the current scoring period. Additionally, the number of transactions processed, transaction confirmation time, and transaction confirmation speed in each round of consensus can also be considered for scoring. For example, the more transactions processed, the longer the transaction confirmation time, and the faster the transaction confirmation speed, the higher the score. This scoring mechanism categorizes and scores each node's specific voting behavior during the consensus process, ensuring a comprehensive evaluation and fair treatment of node performance. This helps incentivize nodes to make more active contributions in future consensus processes while simultaneously penalizing behaviors that may endanger system security.

[0074] Then, a management committee is formed based on the performance scores of each node. For example, after the first consensus round, the system selects the top 5% of performing nodes (i.e., the top 5% in node scores) to join the management committee. Specifically, the management committee can screen nodes based on their transaction confirmation speed, consensus voting accuracy, and participation. Subsequently, the management committee regularly evaluates the performance of each node and dynamically adjusts the master node configuration of the shard to ensure effective management and supervision of transactions within the shard. That is to say, steps 101 and 102 can be executed by the management committee.

[0075] Optionally, the method further includes:

[0076] Within each scoring period, the average score of the blockchain shard is determined based on the scores of each node in the blockchain shard and the transaction processing time of each node.

[0077] Step 102 includes:

[0078] The master node of the blockchain shard is adjusted based on the scores of each node in the blockchain shard and the average score of the blockchain shard.

[0079] In some embodiments, the average score of the shard can be further calculated to adjust the shard master node by combining the scores of the nodes in the shard and the average score of the shard. Specifically, the total performance score of the shard can be comprehensively evaluated based on the scores of each node in the shard and the transaction processing time of each node, and then divided by the total number of shard nodes to obtain the average score of the shard.

[0080] For example, the total score of each node in the shard can be calculated based on the scores of each node in the shard within the current period. Then, the transaction confirmation time score of each node can be calculated based on the transaction confirmation time and the maximum transaction confirmation time of each node in the shard within the current period. By combining the total score of each node in the shard and the total score of the transaction confirmation time of each node in the shard, the total performance score of the shard within the current period can be obtained.

[0081] In this embodiment, the master node of a shard can be adjusted based on the scores of each node within the shard and the average score of the shard. For example, if the score of a node is higher than the average score within the shard, then the node is adjusted to the master node within the shard. Conversely, if the score of the current master node is lower than the average score within the shard, then the node is adjusted to a regular node, and a node with a score higher than the average score within the shard is reselected as the master node.

[0082] This implementation method ensures that the sharding master node is a high-performance node, thereby guaranteeing the sharding processing performance and improving the system response speed.

[0083] Optionally, step 101 includes:

[0084] Based on the block consensus behavior data of each node in the blockchain shard at different consensus rounds within the current scoring period, determine the score of each node in the blockchain shard at different consensus rounds within the current scoring period;

[0085] The weight of each node in the blockchain shard in different consensus rounds within the current scoring period is determined based on the ratio of the number of transactions processed by each node in the blockchain shard in different consensus rounds within the current scoring period to the total number of transactions within the current scoring period.

[0086] The scores and weights of each node in the blockchain shard in different consensus rounds within the current scoring period are weighted to obtain the score of each node in the blockchain shard within the current scoring period.

[0087] Specifically, the consensus score for each node within the slice can be calculated in each round. For example, if a node votes in favor of a correct transaction or against a wrong transaction in a consensus round, its consensus score for that round increases by 1 point to recognize its positive contribution. Conversely, if a node votes in favor of a wrong transaction or against a correct transaction in a consensus round, its consensus score decreases by 1 point to reflect its negative impact on system stability. Nodes that do not comment or vote in a consensus round have their consensus score remaining at 0.

[0088] Then, the weight of each node within the shard in each consensus round can be calculated. Specifically, this can be calculated based on the number of transactions processed (or confirmed) by each node in different consensus rounds within the current scoring period and the total number of transactions in different consensus rounds within the current scoring period. For example, the calculation formula can be as follows:

[0089]

[0090] Among them, w j (i) represents the weight of the i-th node in the j-th round of consensus, T confirm,j ,ni represents the number of transactions confirmed by node i in the j-th round of consensus, T total,j Let w be the total number of transactions processed in the j-th round of consensus sharding. j The value of (i) ranges from 0 to 1. As can be seen from the formula, the more transactions a node confirms, the greater its weight and the higher its score.

[0091] In data trading and circulation platforms, the frequency and type of transactions may vary over time, and different types of nodes may exhibit different behavioral patterns at different times of the day. Therefore, it is necessary to dynamically calculate the consensus score of each node within each scoring period. For example, the formula for calculating the node consensus score can be:

[0092]

[0093] Where, n pi w represents the consensus score of node i. j (i) represents the weight of the i-th node in the j-th round of consensus, S j (i) represents the score obtained by node i in the j-th round of consensus, and l represents the number of consensus rounds included in a scoring period. If the evaluation period is set to every 10 consensus rounds, then l = 10.

[0094] This implementation method allows for the rapid and accurate assessment of a node's consensus score based on its performance in each consensus round and the number of confirmed transactions, ensuring the reliability of the assessment results.

[0095] Optionally, determining the average score of the blockchain shard within each scoring period, based on the scores of each node in the blockchain shard and the transaction processing time of each node, includes:

[0096] Based on the transaction processing time of each node in the blockchain shard in different consensus rounds within the current scoring period and the maximum transaction processing time within the current scoring period, the transaction processing time of each node in the blockchain shard within the current scoring period is determined.

[0097] The total score of the blockchain shard in the current scoring period is determined based on the scores and transaction processing times of each node in the blockchain shard within the current scoring period.

[0098] The average score of a blockchain shard is determined based on its total score within the current scoring period and the number of nodes in that blockchain shard.

[0099] Specifically, the transaction processing time of each node within a shard in the current scoring period can be calculated using the transaction processing time (which can be understood as the time to confirm transactions) of each node in different consensus rounds within the current scoring period and the maximum transaction processing time (which can be understood as the maximum time in the confirmation time of each transaction) within the current scoring period. For example, the ratio of the time a node takes to confirm all transactions in one consensus round to the maximum confirmation time can be used as a measure. The calculation formula can be as follows:

[0100]

[0101] Among them, T pi t represents the transaction confirmation time of node i within the current scoring period. Txn,j tmax represents the transaction confirmation time of node i in the j-th round of consensus. Txn,j This represents the maximum transaction confirmation time in the j-th round of consensus.

[0102] Then, based on the node score n pi and transaction confirmation time T pi The total performance score P of the computing node across several consensus rounds within the current scoring period. sum For example, the calculation formula is as follows:

[0103]

[0104] Where n represents the number of nodes within a shard.

[0105] Finally, it can be based on P sum Calculate the average score of nodes within a fragment based on the total number of nodes within the fragment.

[0106] This implementation method allows for the rapid and accurate assessment of the average score of shard nodes based on the ratings and transaction processing times of each node within the shard, ensuring the reliability of the assessment results.

[0107] Optionally, adjusting the master node of the blockchain shard based on the scores of each node in the blockchain shard and the average score of the blockchain shard includes:

[0108] Compare the scores of each node in the blockchain shard with the average score of the blockchain shard;

[0109] Nodes in the blockchain shard whose scores are higher than the average score of the blockchain shard will be adjusted to become the master nodes of the blockchain shard, and nodes in the blockchain shard whose scores are lower than or equal to the average score of the blockchain shard will be removed from the list of master nodes of the blockchain shard.

[0110] Alternatively, nodes in the blockchain shard with scores higher than the average score of the blockchain shard can be added to the master node shard, and nodes in the blockchain shard with scores lower than or equal to the average score of the blockchain shard can be added to the ordinary node shard; m nodes are allocated from the master node shard to the blockchain shard as master nodes of the blockchain shard, and g nodes are allocated from the ordinary node shard to the blockchain shard as ordinary nodes of the blockchain shard, where g = nm, and n is the number of nodes included in the blockchain shard.

[0111] In some implementations, the scores of each node within a shard can be compared with the average score of that shard. Nodes with scores higher than the average score within the shard can be adjusted to become the master nodes of that shard, while the master nodes with scores lower than or equal to the average score within the shard can be disqualified, thus ensuring that the master nodes within a shard are high-performance nodes.

[0112] In other embodiments, blockchain master node shards and ordinary node shards can be set up to allocate master nodes from master node shards to various shards, and ordinary nodes from ordinary node shards to various shards, enabling dynamic adjustment of each shard. Specifically, nodes with scores higher than the average score within each shard can be added to the team master node shard, and nodes with scores lower than or equal to the average score within each shard can be added to the ordinary node shard. Then, for each shard, m nodes are allocated from the master node shard as master nodes for that shard, and g nodes are allocated from the ordinary node shard as ordinary nodes for that allocation. This also ensures that the master nodes within a shard are high-performance nodes, improving the overall processing capacity and response speed of the shard.

[0113] In data circulation and trading platforms, there are various types of nodes, including data provider nodes, data demander nodes, and platform operator nodes. These nodes are numerous and widely distributed, requiring an efficient and secure network to support large-scale transactions and data transmission. This application proposes a dynamic network sharding scheme based on a node scoring mechanism, aiming to optimize the performance of the distributed ledger through a multi-stage node allocation strategy to meet the low-latency requirements of data circulation platforms. An example flow of this scheme is as follows: Figure 2 As shown, in each consensus round, authentication and consensus are achieved based on the node's public / private key pair and digital signature. In the initial consensus round, since nodes have not yet accumulated scores, the system uses a verifiable random function (VRF) for secure random allocation, ensuring that nodes are evenly distributed across k shards. As time progresses into subsequent consensus rounds, the system dynamically adjusts the shard allocation of nodes based on their past performance, including transaction confirmation speed and consensus voting accuracy. This incentivizes high-quality nodes and improves the overall network's computational efficiency and security. Assuming the system contains N nodes, the specific sharding steps can be as follows: Figure 2 As shown.

[0114] In the process of selecting shard master nodes, the shard master node is responsible for coordinating and managing transactions within the shard. During the evaluation of node i within a shard, if its total score is higher than the average score within the shard, the node will be added to the team master node shard; otherwise, it will be assigned to a regular node shard. For each shard, three nodes are allocated from the team master node shard as the master nodes for that shard to improve the overall processing capacity and response speed of the shard.

[0115] In the dynamic adjustment of master nodes, the data transaction and circulation platform is dynamic, and the status and performance of each node may change over time and with usage. Therefore, management members need to periodically evaluate the performance of all nodes and make dynamic adjustments based on the latest scoring results. At the end of each consensus round, management members evaluate all nodes and calculate their total score. Based on the scoring results, management members calculate the average score for each shard and dynamically adjust the master node configuration of the shard accordingly. If a node's score is higher than that of the current shard master node, that node will be elected as the new shard master node to replace the current master node with the lower score. Through this mechanism, management members ensure the effective management and supervision of transactions within shards, thereby improving the fairness and efficiency of the entire network.

[0116] Furthermore, the management team implements a periodic evaluation mechanism to maintain the fairness and efficiency of network governance. For example, the evaluation cycle can be set every 10 consensus rounds, during which the management team comprehensively reviews member participation, decision-making accuracy, and management efficiency. The evaluation results determine member retention: nodes with substandard performance or low rankings within a shard are replaced by nodes with higher scores. This dynamic member renewal strategy not only promotes technical updates and management capabilities for the management team but also enhances the network's adaptability to environmental changes through continuous optimization of node configuration, thereby ensuring the network's long-term stability and healthy development. In addition, the management team's regular notifications and adjustments to shard master nodes further optimize the management of transactions within shards, providing a strong guarantee for the network's efficient operation.

[0117] The blockchain sharding method of this application embodiment determines the score of each node in the blockchain shard and the average score of the blockchain shard based on the block consensus behavior data and transaction processing capabilities of each node in the blockchain shard within each scoring period. The master node of the blockchain shard is adjusted based on the scores of each node and the average score of the blockchain shard. The number of master nodes in the blockchain shard is m, and the score of each master node is greater than the average score of the blockchain shard, where m is an integer greater than 1. In this way, by evaluating node capabilities based on the consensus behavior data and transaction processing capabilities of each node in the shard during each scoring period, high-scoring and high-performance nodes are selected as master nodes within the shard, thereby achieving dynamic adjustment of the shard master nodes. This scoring scheme fully considers the actual processing capabilities of each node within the shard, ensuring that the selected master node has high reliability, thus ensuring that the system response speed and overall performance are at their best.

[0118] In sharding, implementing an efficient internal consensus mechanism is crucial for ensuring platform performance. While existing improved Byzantine Fault Tolerance (IBFT) algorithms offer improvements in fault tolerance and efficiency, they still face several key challenges. First, these algorithms scalable poorly in large-scale networks; communication complexity and overhead increase significantly with the number of nodes. Second, improved algorithms typically require higher network traffic, leading to increased communication costs and susceptibility to network latency. Furthermore, increased algorithm complexity makes implementation and maintenance more difficult, posing a challenge to balancing fault tolerance and efficiency. To address these issues, this application proposes a Multi-Master Byzantine Fault Tolerance (MBFT) algorithm, aiming to achieve a fast and economical consensus process by reducing network load and computational costs.

[0119] To better understand, the following will be combined with Figure 3 The data circulation and trading platform shown illustrates the embodiments of this application, meaning that the embodiments of this application can be applied to... Figure 3 The data circulation and trading platform shown employs a sharded blockchain architecture. Various nodes, such as data provider nodes, data demander nodes, computing nodes, data standardization nodes, data lightweighting nodes, and data integration nodes, interact through a central node, forming a complete data circulation and privacy computing ecosystem. Data provider nodes are responsible for providing raw data resources and initiating resource listing requests to the central node. After resources are listed, data demander nodes can filter suitable resources through the resource hall and initiate order requests to the central node. These transaction requests are formatted using a specific data structure. Subsequently, the system uses sharding technology to randomly allocate nodes to various shards, achieving a uniform distribution of nodes.

[0120] The master node within each shard is responsible for receiving and processing transaction requests, assigning sequence numbers using a hash function to ensure transaction consistency. Regular nodes receive forwarded requests, verify their signatures, message digests, and sequence numbers, add verified requests to their local ordered reports, execute their corresponding tasks, and then send the results back to the master node. Once the master node receives a sufficient number of responses, it confirms the validity of the results and notifies the client that verified transactions will be packaged into blocks and added to the blockchain.

[0121] During transactions, nodes execute consensus algorithms within their respective shards, participating in transaction verification and block generation. Within each consensus round, the system scores nodes based on their past performance and dynamically adjusts their shard assignments to incentivize high-quality nodes and improve network computational efficiency and security. A management council is selected from high-performing nodes, whose members periodically evaluate node performance and dynamically adjust shard master node configurations to ensure effective management and oversight of transactions within each shard.

[0122] In this process, sharding and the consensus mechanism proceed simultaneously. Sharding ensures the parallelism of transaction processing and the scalability of the network, while the consensus mechanism ensures the consistency and security of transactions within each shard. Through the combination of dynamic sharding and efficient consensus algorithms, the system can handle transaction requests from a large number of nodes while ensuring the security and efficiency of the overall network.

[0123] The following is combined Figure 4 The blockchain consensus method provided in the embodiments of this application will be described in detail.

[0124] See Figure 4 , Figure 4This is a flowchart of a blockchain consensus method provided in an embodiment of this application, applied to a blockchain architecture. The blockchain architecture includes blockchain sharding, and each blockchain shard includes m master nodes and g ordinary nodes. The m master nodes are determined according to the blockchain sharding method described in the foregoing embodiment. f is the number of Byzantine fault nodes that the blockchain can tolerate, g = 2f + 1, m is an integer greater than 1, and f is a positive integer. Figure 4 As shown, it includes the following steps:

[0125] Step 401: Receive the first request message sent by the client through the master node.

[0126] Specifically, when a client has a business processing requirement, it sends a first request message to the m master nodes within the shard. The m master nodes within the shard then receive the first request message. The format of the first request message can be...<Req,0,t,c> Where Req represents the request operation, 0 represents the operation number, c is the client identifier, and the timestamp t is generated by the client c and represents the request time. It should be noted that in practical applications, it is necessary to ensure that the timestamp of each subsequent request is greater than the timestamp of the previous request to prevent duplicate execution of requests and ensure the uniqueness of requests.

[0127] Step 402: Assign a sequence number to the first request message through the master node.

[0128] After receiving the first request message, the master node assigns a sequence s to the request. In this embodiment, m master nodes can use the same sequence number for the same received request to ensure that a request is used only once. In some embodiments, the master node can use its own identity to perform a hash operation on the request message to generate a sequence number for that request message.

[0129] Optionally, step 402 includes:

[0130] The m master nodes each use their respective identity identifiers to perform hash operations on the first request message to obtain m hash values;

[0131] The maximum value among the m hash values ​​is determined as the sequence number of the first request message.

[0132] In some embodiments, the master node can use its own identity to perform a hash operation on the received request message to obtain a hash value, and then use the hash value as the sequence number of the request message. Furthermore, to ensure that multiple master nodes within a shard use only one sequence number for the same request, the maximum value among the hash values ​​calculated by multiple master nodes can be taken as the sequence number of the request message, and the sequence numbers of other master nodes can be updated to ensure that the sequence numbers assigned to the request message by multiple master nodes within the shard are consistent.

[0133] Specifically, each master node hashes the request ri using its own identity. Assuming the three master nodes in the shard are P1, P2, and P3, the hash results are A, B, and C. If the value of B is greater than the other two values ​​A and C, then master node P2 assigns a sequence number s to the request r. Master nodes P1 and P3 update their sequence numbers accordingly, making them the same as the sequence number s assigned to the request r by P2, thus ensuring the consistency of the request.

[0134] Step 403: Send a second request message carrying the sequence number to the ordinary node through the master node.

[0135] After assigning a sequence number 's' to the first request message, the master node then sends a second request message to the 2f+1 ordinary nodes within the slice. The format of the second request message can be...<Reqt,s,Le,D(m),m,p> Where Reqt indicates that this is a task request message, m represents the message, D(m) is the summary of message m, Le represents the acknowledgment information of the previous execution request, used to ensure the consistency of request order and status update, p is the identity identifier of the team leader (i.e., as the shard master node), and f refers to the number of Byzantine fault nodes that the system can tolerate.

[0136] Step 404: Verify the second request message through the ordinary node, and if the verification is successful, execute the task corresponding to the second request message, obtain the execution result, and send a first response message carrying the sequence number and the execution result to the master node.

[0137] After receiving the task corresponding to the second request message sent by the master node, the ordinary nodes within the shard first verify the second request message to check its legality and whether it is a duplicate request. For example, the ordinary node can first confirm the validity of the signature in the request message to ensure the source and integrity of the request; secondly, it checks whether D(m) is a digest related to message m to verify the integrity and consistency of the message content; subsequently, it confirms whether the sequence number s is the maximum sequence number of previously accepted requests plus 1 to ensure the sequential execution of requests; in addition, it can check whether a Req message with the same sequence number but a different request has been previously accepted. If such a message exists, the current request is not accepted. After completing the above verification steps, the ordinary nodes accept the request and add the ordered requests to their report queue. Upon receiving Le, the ordinary nodes update their status. The ordinary nodes execute the task corresponding to the second request message and send the execution result R and the corresponding sequence number to the corresponding team leader, i.e., the master node within the shard, via a first response message.

[0138] The message format of the first response message can be:<R,s,m,p,r> R represents the execution result of the task, s represents the sequence number of the request corresponding to the task, and r represents the request message corresponding to the execution result.

[0139] Step 405: If the first master node receives a first response message carrying the same sequence number and execution result from at least f+1 ordinary nodes, the first master node sends a second response message carrying the sequence number and execution result to the client. The first master node is any one of the m master nodes.

[0140] Specifically, if at least m / 2+1 master nodes send a second response message to the client carrying the same sequence number and execution result, the response to the first request message is confirmed to be valid.

[0141] Specifically, each master node within the chip waits for responses from different ordinary nodes. In this embodiment, since the system can tolerate f Byzantine fault nodes, the master node must wait for matching responses from at least f+1 ordinary nodes before confirming the execution result as valid. These responses must have valid signatures and the same sequence number s and execution result R. After confirming the execution result as valid, the master node sends a second response message to the client and can update up to f ordinary nodes that have not sent responses to ensure that the state of all ordinary nodes remains consistent.

[0142] The format of the second response message can be...<R,s,c> This includes the execution result R, the sequence number s, and the client identifier c.

[0143] After completing the above steps, the client waits for responses from at least m / 2+1 master nodes, meaning it needs responses from more than half of the master nodes in the shard. These responses must have the same execution result R and sequence number s for the client to accept the result. If there are no errors, the client receives responses from at least m / 2+1 matching master nodes, indicating that the request operation is complete. The client sends the execution result R to its program, confirms the validity of the result, and continues with subsequent operations. If the client does not receive matching responses from more than half of the master nodes, it may mean that some master nodes in the shard may be faulty. In this case, the client will continue to wait for responses from the master nodes until the predetermined waiting time has elapsed.

[0144] Optionally, the blockchain architecture further includes a management committee, which consists of the top G nodes in the blockchain architecture in terms of score ranking, where G is an integer greater than 1; the method further includes:

[0145] If the management member detects that the second master node has failed to respond to the first request message multiple times, the second master node will be removed as the master node of the blockchain shard, and a new master node will be selected for the blockchain shard based on the scores of each node in the blockchain shard, wherein the second master node is any one of the m master nodes.

[0146] In some embodiments, the management members in the blockchain architecture can monitor the potential malicious behavior of master nodes. For example, if a master node is found to be unresponsive to client requests or fails to return a matching response to the client multiple times, it may be suspected that the master node is malicious. In this case, the node may be disqualified as a shard master node, and a high-scoring, high-quality node within the shard may be re-selected as the master node.

[0147] For example, the client sets a timestamp when sending the first request. When the waiting period (epoch) expires and no response is received from all master nodes, the client resends the request to the master nodes. If the execution result has already been sent, the master node will resend the execution result; if the master node intentionally does not send a response, the client will suspect that it is a malicious master node. If a master node exhibits malicious behavior, the management members will send information including the master node's ID, i.e., the master node's identity information, to all nodes within the shard. After the nodes receive the message, the management members will delete the node from the master node shard, cancel its status as a shard master node, and re-evaluate the shard's node scores, selecting a new master node based on the scores. This method of replacing master nodes ensures the system's efficiency and stability.

[0148] Taking three master nodes per shard as an example, the blockchain consensus process based on the MBFT algorithm provided in this application embodiment can be as follows: Figure 5 As shown.

[0149] The blockchain consensus method of this application embodiment includes: receiving a first request message sent by a client through the master node; assigning a sequence number to the first request message through the master node; sending a second request message carrying the sequence number to the ordinary nodes through the master node; verifying the second request message through the ordinary nodes, and if the verification is successful, executing the task corresponding to the second request message, obtaining the execution result, and sending a first response message carrying the sequence number and the execution result to the master node; and when the first master node receives first response messages carrying the same sequence number and execution result from at least f+1 ordinary nodes, sending a second response message carrying the sequence number and the execution result to the client through the first master node, wherein the first master node is any one of the m master nodes; wherein, when at least m / 2+1 master nodes send second response messages carrying the same sequence number and execution result to the client, the response to the first request message is confirmed to be valid. In this way, by introducing multiple master nodes to share the proxy and verification responsibilities of transaction requests in the block consensus, the number of message transmissions between ordinary nodes can be effectively reduced, and the system communication complexity can be reduced. In addition, the multi-master node Byzantine fault-tolerant algorithm proposed in this application has an efficient node replacement mechanism, which provides robustness to the block system when some nodes have untrusted behavior, and ensures the continuity and stability of the consensus process.

[0150] In summary, on the one hand, this application's embodiments introduce a more fair and transparent node scoring evaluation mechanism during the sharding process. This mechanism considers the node's performance and participation in recent consensus rounds. Based on this evaluation scheme, reasonable dynamic allocation of nodes is achieved, effectively improving the performance of the data circulation system. On the other hand, this application's embodiments introduce a management member meeting during the sharding process to ensure the fairness of node sharding and master node selection. Through the supervision and dynamic adjustment mechanism of the management member meeting, the system's security and stability are guaranteed.

[0151] On the other hand, the multi-node Byzantine Fault-Tolerant (MBFT) on-chip consensus algorithm proposed in this application introduces multiple on-chip master nodes in its design, which are responsible for proxying and verifying transaction requests. This mechanism significantly reduces the communication requirements between ordinary nodes, thereby effectively reducing the communication complexity of the algorithm to O(n). Furthermore, the MBFT algorithm has an efficient node replacement mechanism, providing robustness to the system even when some nodes exhibit untrustworthy behavior, ensuring the continuity and stability of the consensus process.

[0152] Compared with the prior art, the embodiments of this application have the following technical advantages:

[0153] 1. In this embodiment, nodes are divided based on their historical behavior, transaction confirmation speed, and voting accuracy during the consensus process. This effectively distinguishes the differences between nodes, and the selected high-quality nodes serve as master nodes, which effectively improves the system's throughput and processing efficiency.

[0154] 2. Compared with the IBFT algorithm, the MBFT algorithm in this application embodiment not only has lower communication complexity, but also has higher fault tolerance and a more efficient fault master node replacement mechanism, effectively solving the single point of failure risk in the current IBFT algorithm. At the same time, the MBFT algorithm has lower computational cost and network overhead.

[0155] 3. This application proposes an efficient sharding method and intra-shard consensus mechanism, which can better distribute network load compared to state sharding. By flexibly adjusting the master node based on node scores, the system's flexibility and adaptability are enhanced, thereby optimizing resource utilization and improving network processing capacity and response speed. This dynamic adjustment mechanism enables the network to quickly adapt to changing load demands and node behavior, enhancing the system's scalability.

[0156] This application's embodiments significantly improve the performance of the data circulation and trading platform in high-transaction-volume scenarios by introducing a sharding strategy and a multi-master node Byzantine fault-tolerant algorithm, substantially reducing latency and increasing system throughput. This performance improvement enables the data circulation and trading platform to process large numbers of transaction requests more quickly, meeting market demands for efficient data trading and privacy-preserving computation, and enhancing the platform's competitiveness. Higher transaction processing efficiency and security also create conditions for the data circulation and trading platform to explore more application scenarios, such as data circulation and privacy-preserving computation in finance, healthcare, and supply chain management, further expanding the platform's application prospects.

[0157] This application also provides a blockchain architecture. See [link to relevant documentation]. Figure 3 , Figure 3 This is a structural diagram of the blockchain architecture provided in the embodiments of this application. Since the principle of the blockchain architecture in solving the problem is similar to the blockchain sharding method in the embodiments of this application, the implementation of this blockchain architecture can refer to the implementation of the method, and the repeated parts will not be described again.

[0158] like Figure 3 As shown, the blockchain architecture includes a management committee 301 and blockchain shards 302, wherein the management committee 301 is used for:

[0159] Within each scoring period, the score of each node in the blockchain shard is determined based on the block consensus behavior data and transaction processing capabilities of each node in the blockchain shard.

[0160] The master node of the blockchain shard is adjusted according to the scores of each node in the blockchain shard. The number of master nodes of the blockchain shard is m, and the score of the master node of the blockchain shard is greater than the score of the ordinary node of the blockchain shard. m is an integer greater than 1.

[0161] Optionally, the blockchain architecture further includes processing nodes for:

[0162] The N nodes of the blockchain are evenly distributed across k shards to obtain k blockchain shards. The number of nodes in each blockchain shard is N / k, where N is an integer greater than k.

[0163] From each of the blockchain shards, m nodes are randomly selected as the master nodes of the blockchain shards.

[0164] Optionally, the processing node is further configured to:

[0165] Based on the block consensus behavior data and transaction processing capabilities of each node in the blockchain shard in the first round of consensus, the score of each node in the blockchain shard in the first round of consensus is determined;

[0166] Based on the scores of each node in the blockchain shard in the first round of consensus, G nodes are selected to form a management committee, wherein the scores of the G nodes in the first round of consensus are higher than the scores of other nodes in the first round of consensus, and the other nodes are the nodes other than the G nodes among the N nodes, where G is an integer greater than 1.

[0167] Optionally, the management of members' meeting 301 is also used for:

[0168] Within each scoring period, the average score of the blockchain shard is determined based on the scores of each node in the blockchain shard and the transaction processing time of each node.

[0169] The master node of the blockchain shard is adjusted based on the scores of each node in the blockchain shard and the average score of the blockchain shard.

[0170] Optionally, the management of members' meeting 301 is also used for:

[0171] Based on the block consensus behavior data of each node in the blockchain shard at different consensus rounds within the current scoring period, determine the score of each node in the blockchain shard at different consensus rounds within the current scoring period;

[0172] The weight of each node in the blockchain shard in different consensus rounds within the current scoring period is determined based on the ratio of the number of transactions processed by each node in the blockchain shard in different consensus rounds within the current scoring period to the total number of transactions in different consensus rounds within the current scoring period.

[0173] The scores and weights of each node in the blockchain shard in different consensus rounds within the current scoring period are weighted to obtain the score of each node in the blockchain shard within the current scoring period.

[0174] Optionally, the management of members' meeting 301 is also used for:

[0175] Based on the transaction processing time of each node in the blockchain shard in different consensus rounds within the current scoring period and the maximum transaction processing time within the current scoring period, the transaction processing time of each node in the blockchain shard within the current scoring period is determined.

[0176] The total score of the blockchain shard in the current scoring period is determined based on the scores and transaction processing times of each node in the blockchain shard within the current scoring period.

[0177] The average score of a blockchain shard is determined based on its total score within the current scoring period and the number of nodes in that blockchain shard.

[0178] Optionally, the management of members' meeting 301 is also used for:

[0179] Compare the scores of each node in the blockchain shard with the average score of the blockchain shard;

[0180] Nodes in the blockchain shard whose scores are higher than the average score of the blockchain shard will be adjusted to become the master nodes of the blockchain shard, and nodes in the blockchain shard whose scores are lower than or equal to the average score of the blockchain shard will be removed from the list of master nodes of the blockchain shard.

[0181] Alternatively, nodes in the blockchain shard with scores higher than the average score of the blockchain shard can be added to the master node shard, and nodes in the blockchain shard with scores lower than or equal to the average score of the blockchain shard can be added to the ordinary node shard; m nodes are allocated from the master node shard to the blockchain shard as master nodes of the blockchain shard, and g nodes are allocated from the ordinary node shard to the blockchain shard as ordinary nodes of the blockchain shard, where g = nm, and n is the number of nodes included in the blockchain shard.

[0182] The blockchain architecture provided in this application embodiment can execute... Figure 1 The method embodiments shown are similar in principle and technical effect, and will not be described again here.

[0183] The blockchain architecture of this application embodiment determines the score of each node in the blockchain shard based on the block consensus behavior data and transaction processing capabilities of each node in the blockchain shard during each scoring period. Based on the scores of each node in the blockchain shard, the master node of the blockchain shard is adjusted. The number of master nodes in the blockchain shard is m, and the score of the master node of the blockchain shard is greater than the score of the ordinary nodes in the blockchain shard, where m is an integer greater than 1. In this way, by evaluating the node capabilities based on the consensus behavior data and transaction processing capabilities of each node in the shard during each scoring period, high-quality nodes are selected as master nodes within the shard, thereby achieving dynamic adjustment of the shard master nodes. This scoring scheme fully considers the actual processing capabilities of each node within the shard, ensuring that the selected master node has high reliability, thus ensuring that the system response speed and overall performance are at their best.

[0184] This application also provides a blockchain architecture. Since the principle behind the blockchain architecture's solution is similar to the blockchain sharding method in this application, the implementation of this blockchain architecture can be found in the method implementation section, and repeated details will not be elaborated further. Figure 3 As shown, the blockchain architecture includes a blockchain shard 302, which includes m master nodes 31 and g ordinary nodes 32. The m master nodes 31 are determined according to the aforementioned block sharding method, f is the number of Byzantine fault nodes that the blockchain can tolerate, g = 2f + 1, m is an integer greater than 1, and f is a positive integer.

[0185] The master node 31 is used to receive a first request message sent by the client and assign a sequence number to the first request message; and send a second request message carrying the sequence number to the ordinary node 32.

[0186] Ordinary node 32 is used to verify the second request message, and if the verification is successful, execute the task corresponding to the second request message, obtain the execution result, and send a first response message carrying the sequence number and the execution result to master node 31;

[0187] The master node 31 is also configured to send a second response message carrying the sequence number and the execution result to the client when it receives a first response message carrying the same sequence number and the execution result from at least f+1 ordinary nodes 32.

[0188] Specifically, if at least m / 2+1 master nodes 31 send a second response message to the client carrying the same sequence number and execution result, the response to the first request message is confirmed to be valid.

[0189] Optionally, the blockchain architecture also includes a management member council 301, which consists of the top G nodes in the blockchain architecture in terms of score ranking, where G is an integer greater than 1.

[0190] Management member 301 is used to cancel the second master node as the master node of the blockchain shard if it is detected that the second master node has failed to respond to the first request message multiple times, and to reselect the master node of the blockchain shard according to the scores of each node in the blockchain shard, wherein the second master node is any one of the m master nodes.

[0191] Optionally, the m master nodes 31 each use their respective identity identifiers to perform hash operations on the first request message to obtain m hash values; the master node that calculates the largest hash value among the m master nodes 31 assigns the largest hash value as the sequence number of the first request message.

[0192] This application also provides a blockchain architecture. Since the principle behind the blockchain architecture's problem-solving is similar to the blockchain sharding method or blockchain consensus method in this application, the implementation of this blockchain architecture can be found in the implementation of the method; repeated details will not be elaborated further. Figure 6 As shown, the blockchain architecture of this application embodiment includes:

[0193] Processor 600 is used to read the program from memory 620 and execute the following procedures:

[0194] Within each scoring period, the score of each node in the blockchain shard is determined based on the block consensus behavior data and transaction processing capabilities of each node in the blockchain shard.

[0195] The master node of the blockchain shard is adjusted according to the scores of each node in the blockchain shard. The number of master nodes of the blockchain shard is m, and the score of the master node of the blockchain shard is greater than the score of the ordinary node of the blockchain shard. m is an integer greater than 1.

[0196] Transceiver 610 is used to receive and send data under the control of processor 600.

[0197] Among them, Figure 6In this context, the bus architecture may include any number of interconnected buses and bridges, specifically linking various circuits together, represented by one or more processors (processor 600) and memory (memory 620). The bus architecture may also link together various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. A bus interface provides an interface. Transceiver 610 may be multiple elements, including transmitters and transceivers, providing a unit for communicating with various other devices over a transmission medium. Processor 600 is responsible for managing the bus architecture and general processing, and memory 620 may store data used by processor 600 during operation.

[0198] Optionally, the processor 600 is also used to read the program from the memory 620 and perform the following steps:

[0199] The N nodes of the blockchain are evenly distributed across k shards to obtain k blockchain shards. The number of nodes in each blockchain shard is N / k, where N is an integer greater than k.

[0200] From each of the blockchain shards, m nodes are randomly selected as the master nodes of the blockchain shards.

[0201] Optionally, the processor 600 is also used to read the program from the memory 620 and perform the following steps:

[0202] Based on the block consensus behavior data and transaction processing capabilities of each node in the blockchain shard in the first round of consensus, the score of each node in the blockchain shard in the first round of consensus is determined;

[0203] Based on the scores of each node in the blockchain shard in the first round of consensus, G nodes are selected to form a management committee, wherein the scores of the G nodes in the first round of consensus are higher than the scores of other nodes in the first round of consensus, and the other nodes are the nodes other than the G nodes among the N nodes, and G is an integer greater than 1.

[0204] The management members will be used to perform the following steps: determining the score of each node in the blockchain shard based on the block consensus behavior data and transaction processing capabilities of each node in the blockchain shard within each scoring period, and adjusting the master node of the blockchain shard based on the score of each node in the blockchain shard.

[0205] Optionally, the processor 600 is also used to read the program from the memory 620 and perform the following steps:

[0206] Within each scoring period, the average score of the blockchain shard is determined based on the scores of each node in the blockchain shard and the transaction processing time of each node.

[0207] The master node of the blockchain shard is adjusted based on the scores of each node in the blockchain shard and the average score of the blockchain shard.

[0208] Optionally, the processor 600 is also used to read the program from the memory 620 and perform the following steps:

[0209] Based on the block consensus behavior data of each node in the blockchain shard at different consensus rounds within the current scoring period, determine the score of each node in the blockchain shard at different consensus rounds within the current scoring period;

[0210] The weight of each node in the blockchain shard in different consensus rounds within the current scoring period is determined based on the ratio of the number of transactions processed by each node in the blockchain shard in different consensus rounds within the current scoring period to the total number of transactions in different consensus rounds within the current scoring period.

[0211] The scores and weights of each node in the blockchain shard in different consensus rounds within the current scoring period are weighted to obtain the score of each node in the blockchain shard within the current scoring period.

[0212] Optionally, the processor 600 is also used to read the program from the memory 620 and perform the following steps:

[0213] Based on the transaction processing time of each node in the blockchain shard in different consensus rounds within the current scoring period and the maximum transaction processing time within the current scoring period, the transaction processing time of each node in the blockchain shard within the current scoring period is determined.

[0214] The total score of the blockchain shard in the current scoring period is determined based on the scores and transaction processing times of each node in the blockchain shard within the current scoring period.

[0215] The average score of a blockchain shard is determined based on its total score within the current scoring period and the number of nodes in that blockchain shard.

[0216] Optionally, the processor 600 is also used to read the program from the memory 620 and perform the following steps:

[0217] Compare the scores of each node in the blockchain shard with the average score of the blockchain shard;

[0218] Nodes in the blockchain shard whose scores are higher than the average score of the blockchain shard will be adjusted to become the master nodes of the blockchain shard, and nodes in the blockchain shard whose scores are lower than or equal to the average score of the blockchain shard will be removed from the list of master nodes of the blockchain shard.

[0219] Alternatively, nodes in the blockchain shard with scores higher than the average score of the blockchain shard can be added to the master node shard, and nodes in the blockchain shard with scores lower than or equal to the average score of the blockchain shard can be added to the ordinary node shard; m nodes are allocated from the master node shard to the blockchain shard as master nodes of the blockchain shard, and g nodes are allocated from the ordinary node shard to the blockchain shard as ordinary nodes of the blockchain shard, where g = nm, and n is the number of nodes included in the blockchain shard.

[0220] The blockchain architecture includes blockchain sharding, which includes m master nodes and g ordinary nodes, where f is the number of Byzantine fault nodes that the blockchain can tolerate, g = 2f + 1, m is an integer greater than 1, and f is a positive integer.

[0221] In some embodiments, the processor 600 is also configured to read a program from the memory 620 and perform the following steps:

[0222] The master node receives the first request message sent by the client.

[0223] The master node assigns a sequence number to the first request message;

[0224] The master node sends a second request message carrying the sequence number to the ordinary node.

[0225] The ordinary node verifies the second request message, and if the verification is successful, executes the task corresponding to the second request message, obtains the execution result, and sends a first response message carrying the sequence number and the execution result to the master node;

[0226] When the first master node receives a first response message carrying the same sequence number and execution result from at least f+1 ordinary nodes, the first master node sends a second response message carrying the sequence number and execution result to the client. The first master node is any one of the m master nodes.

[0227] Specifically, if at least m / 2+1 master nodes send a second response message to the client carrying the same sequence number and execution result, the response to the first request message is confirmed to be valid.

[0228] Optionally, the blockchain architecture further includes a management committee, which consists of the top G nodes ranked in the blockchain architecture by score, where G is an integer greater than 1; the processor 600 is also used to read the program in the memory 620 and execute the following steps:

[0229] If the second master node fails to respond to the first request message multiple times, the second master node is removed as the master node of the blockchain shard, and the master node of the blockchain shard is reselected based on the scores of each node in the blockchain shard, wherein the second master node is any one of the m master nodes.

[0230] Optionally, the processor 600 is also used to read the program from the memory 620 and perform the following steps:

[0231] The first request message is hashed using the identity identifiers of the m master nodes respectively, resulting in m hash values;

[0232] The maximum value among the m hash values ​​is determined as the sequence number of the first request message.

[0233] The blockchain architecture provided in this application embodiment can execute the aforementioned method embodiment, and its implementation principle and technical effect are similar, so it will not be described again here.

[0234] Furthermore, the computer-readable storage medium of this application embodiment is used to store a computer program that can be executed by a processor to implement the various steps in the foregoing method embodiments.

[0235] This application provides a computer program product, including computer instructions. When the computer instructions are executed by a processor, they implement the various processes of the aforementioned method embodiments and achieve the same technical effects. To avoid repetition, they will not be described again here.

[0236] In the several embodiments provided in this application, it should be understood that the disclosed methods and apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0237] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can be physically included separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

[0238] The integrated units implemented as software functional units described above can be stored in a computer-readable storage medium. These software functional units, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute some steps of the transmission and reception methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0239] The above description is the preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principles described in this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A blockchain sharding method, characterized in that, Applied to a blockchain architecture, wherein the blockchain architecture includes blockchain sharding, the method includes: Within each scoring period, the score of each node in the blockchain shard is determined based on the block consensus behavior data and transaction processing capabilities of each node in the blockchain shard. The master node of the blockchain shard is adjusted according to the scores of each node in the blockchain shard. The number of master nodes of the blockchain shard is m, and the score of the master node of the blockchain shard is greater than the score of the ordinary node of the blockchain shard. m is an integer greater than 1.

2. The method according to claim 1, characterized in that, Before determining the score of each node in the blockchain shard based on the block consensus behavior data and transaction processing capabilities of each node in each scoring period, the method further includes: The N nodes of the blockchain are evenly distributed across k shards to obtain k blockchain shards. The number of nodes in each blockchain shard is N / k, where N is an integer greater than k. From each of the blockchain shards, m nodes are randomly selected as the master nodes of the blockchain shards.

3. The method according to claim 2, characterized in that, After randomly selecting m nodes from each of the blockchain shards as the master nodes of the blockchain shards, and before determining the score of each node in the blockchain shards based on the block consensus behavior data and transaction processing capabilities of each node in each scoring period, the method further includes: Based on the block consensus behavior data and transaction processing capabilities of each node in the blockchain shard in the first round of consensus, the score of each node in the blockchain shard in the first round of consensus is determined; Based on the scores of each node in the blockchain shard in the first round of consensus, G nodes are selected to form a management committee, wherein the scores of the G nodes in the first round of consensus are higher than the scores of other nodes in the first round of consensus, and the other nodes are the nodes other than the G nodes among the N nodes, and G is an integer greater than 1. The management members will be used to perform the following steps: determining the score of each node in the blockchain shard based on the block consensus behavior data and transaction processing capabilities of each node in the blockchain shard within each scoring period, and adjusting the master node of the blockchain shard based on the score of each node in the blockchain shard.

4. The method according to claim 1, characterized in that, The method further includes: Within each scoring period, the average score of the blockchain shard is determined based on the scores of each node in the blockchain shard and the transaction processing time of each node. The step of adjusting the master node of the blockchain shard based on the scores of each node in the blockchain shard includes: The master node of the blockchain shard is adjusted based on the scores of each node in the blockchain shard and the average score of the blockchain shard.

5. The method according to any one of claims 1 to 4, characterized in that, Within each scoring period, the score of each node in the blockchain shard is determined based on the block consensus behavior data and transaction processing capabilities of each node in the blockchain shard, including: Based on the block consensus behavior data of each node in the blockchain shard at different consensus rounds within the current scoring period, determine the score of each node in the blockchain shard at different consensus rounds within the current scoring period; The weight of each node in the blockchain shard in different consensus rounds within the current scoring period is determined based on the ratio of the number of transactions processed by each node in the blockchain shard in different consensus rounds within the current scoring period to the total number of transactions in different consensus rounds within the current scoring period. The scores and weights of each node in the blockchain shard in different consensus rounds within the current scoring period are weighted to obtain the score of each node in the blockchain shard within the current scoring period.

6. The method according to claim 4, characterized in that, Within each scoring period, the average score of the blockchain shard is determined based on the scores of each node in the blockchain shard and the transaction processing time of each node, including: Based on the transaction processing time of each node in the blockchain shard in different consensus rounds within the current scoring period and the maximum transaction processing time within the current scoring period, the transaction processing time of each node in the blockchain shard within the current scoring period is determined. The total score of the blockchain shard in the current scoring period is determined based on the scores and transaction processing times of each node in the blockchain shard within the current scoring period. The average score of a blockchain shard is determined based on its total score within the current scoring period and the number of nodes in that blockchain shard.

7. The method according to claim 4, characterized in that, The step of adjusting the master node of the blockchain shard based on the scores of each node in the blockchain shard and the average score of the blockchain shard includes: Compare the scores of each node in the blockchain shard with the average score of the blockchain shard; Nodes in the blockchain shard whose scores are higher than the average score of the blockchain shard will be adjusted to become the master nodes of the blockchain shard, and nodes in the blockchain shard whose scores are lower than or equal to the average score of the blockchain shard will be removed from the list of master nodes of the blockchain shard. Alternatively, nodes in the blockchain shard with scores higher than the average score of the blockchain shard can be added to the master node shard, and nodes in the blockchain shard with scores lower than or equal to the average score of the blockchain shard can be added to the ordinary node shard; m nodes are allocated from the master node shard to the blockchain shard as master nodes of the blockchain shard, and g nodes are allocated from the ordinary node shard to the blockchain shard as ordinary nodes of the blockchain shard, where g = nm, and n is the number of nodes included in the blockchain shard.

8. A blockchain consensus method, characterized in that, The method is applied to a blockchain architecture, which includes blockchain sharding, wherein each blockchain shard includes m master nodes and g ordinary nodes, the m master nodes are determined by the method according to any one of claims 1 to 7, f is the number of Byzantine fault nodes that the blockchain can tolerate, g = 2f + 1, m is an integer greater than 1, and f is a positive integer; the method includes: The master node receives the first request message sent by the client. The master node assigns a sequence number to the first request message; The master node sends a second request message carrying the sequence number to the ordinary node. The ordinary node verifies the second request message, and if the verification is successful, executes the task corresponding to the second request message, obtains the execution result, and sends a first response message carrying the sequence number and the execution result to the master node; When the first master node receives a first response message carrying the same sequence number and execution result from at least f+1 ordinary nodes, the first master node sends a second response message carrying the sequence number and execution result to the client. The first master node is any one of the m master nodes. Specifically, if at least m / 2+1 master nodes send a second response message to the client carrying the same sequence number and execution result, the response to the first request message is confirmed to be valid.

9. The method according to claim 8, characterized in that, The blockchain architecture also includes a management committee, which consists of the top G nodes ranked in the blockchain architecture by score, where G is an integer greater than 1; the method also includes: If the management member detects that the second master node has failed to respond to the first request message multiple times, the second master node will be removed as the master node of the blockchain shard, and a new master node will be selected for the blockchain shard based on the scores of each node in the blockchain shard, wherein the second master node is any one of the m master nodes.

10. The method according to claim 8 or 9, characterized in that, The master node assigns a sequence number to the first request message, including: The m master nodes each use their respective identity identifiers to perform hash operations on the first request message to obtain m hash values; The maximum value among the m hash values ​​is determined as the sequence number of the first request message.

11. A blockchain architecture, characterized in that, This includes a management membership council and blockchain sharding, the management membership council being used for: Within each scoring period, the score of each node in the blockchain shard is determined based on the block consensus behavior data and transaction processing capabilities of each node in the blockchain shard. The master node of the blockchain shard is adjusted according to the scores of each node in the blockchain shard. The number of master nodes of the blockchain shard is m, and the score of the master node of the blockchain shard is greater than the score of the ordinary node of the blockchain shard. m is an integer greater than 1.

12. A blockchain architecture, characterized in that, The method includes blockchain sharding, wherein the blockchain sharding includes m master nodes and g ordinary nodes, the m master nodes are determined by the method according to any one of claims 1 to 7, f is the number of Byzantine fault nodes that the blockchain can tolerate, g = 2f + 1, m is an integer greater than 1, and f is a positive integer; The master node is used to receive a first request message sent by the client and assign a sequence number to the first request message; and send a second request message carrying the sequence number to the ordinary node. The ordinary node is used to verify the second request message, and if the verification is successful, execute the task corresponding to the second request message, obtain the execution result, and send a first response message carrying the sequence number and the execution result to the master node; The master node is also configured to send a second response message carrying the sequence number and the execution result to the client when it receives a first response message carrying the same sequence number and the execution result from at least f+1 ordinary nodes. Specifically, if at least m / 2+1 master nodes send a second response message to the client carrying the same sequence number and execution result, the response to the first request message is confirmed to be valid.

13. A blockchain architecture, comprising: A transceiver, a memory, a processor, and a computer program stored in the memory and executable on the processor; characterized in that the processor is configured to read the program in the memory to implement the steps in the blockchain sharding method as described in any one of claims 1 to 7.

14. A blockchain sharding method, comprising: A transceiver, a memory, a processor, and a computer program stored in the memory and executable on the processor; characterized in that the processor is configured to read the program in the memory to implement the steps in the blockchain consensus method as described in any one of claims 8 to 10.

15. A computer-readable storage medium for storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps in the blockchain sharding method as described in any one of claims 1 to 7; or implements the steps in the blockchain consensus method as described in any one of claims 8 to 10.

16. A computer program product, characterized in that, It includes computer instructions that, when executed by a processor, implement the steps in the blockchain sharding method as described in any one of claims 1 to 7; or implement the steps in the blockchain consensus method as described in any one of claims 8 to 10.

Images