Data processing method based on alliance chain

Abstract

The invention relates to the technical field of block chains, and particularly discloses a data processing method based on an alliance chain, and the method comprises the steps: a management node elects at least four committee nodes and at least two signature collection nodes from a plurality of computing nodes based on the reputation score values of the plurality of computing nodes; the at least four committee nodes vote for the out-of-block nodes according to the reputation score value of each committee node, voting data is sent to the at least two signature collection nodes, the out-of-block nodes are selected from the committee nodes, and the other committee nodes serve as consensus nodes; the block output node generates a block and submits the generated block to the consensus node, and the consensus node votes the block and sends voting data to the signature collection node so as to verify the block; and writing the block into the alliance chain under the condition that the block verification is passed. According to the scheme, the consensus efficiency of the alliance chain can be improved.

Description

Technical Field

[0001] This specification relates to the field of blockchain technology, and in particular to a data processing method based on alliance chain. Background Art

[0002] Blockchain is a decentralized distributed ledger technology that uses cryptography, consensus mechanisms and network protocols to ensure the security, transparency and immutability of data. In recent years, blockchain technology has been applied in many fields, and medical data sharing is one of the key areas. Consortium chain is a type of blockchain with appropriate access control and regulatory permission, which is more suitable for medical data sharing scenarios with high performance, security and privacy requirements.

[0003] Medical data sharing blockchain, also known as medical blockchain, is a blockchain used to store and share medical data. It generally uses alliance chain technology and has been piloted in cross-hospital diagnosis and treatment, commercial insurance claims, judicial verification and other business scenarios, and has achieved good results. However, when the current medical blockchain is promoted and used in a wider area and among more institutions, there are still deficiencies in performance, which are manifested in low throughput and high latency, making it difficult to meet the requirements of some medical data sharing scenarios.

[0004] To address the above problems, no effective solution has been proposed yet. Summary of the invention

[0005] The embodiments of this specification provide a data processing method based on a consortium chain to solve the problem of low consensus efficiency of the consensus mechanism in the prior art in the medical data sharing blockchain scenario.

[0006] The embodiment of this specification provides a data processing method based on a consortium chain, wherein the consortium chain includes a management node and multiple computing nodes, wherein the management node and the multiple computing nodes both store reputation score data, wherein the reputation score data includes a reputation score value of each computing node in the multiple computing nodes; the reputation score value of each computing node is determined based on hardware performance data, security data, and network delay data of the corresponding computing node; the method includes:

[0007] The management node selects at least four committee nodes and at least two signature collection nodes from the multiple computing nodes based on the reputation score value of each computing node in the multiple computing nodes;

[0008] The at least four committee nodes vote for the block-producing node according to the reputation score value of each committee node among the at least four committee nodes, and send the voting data to the at least two signature collection nodes to elect a committee node from the at least four committee nodes as the block-producing node, and use the other committee nodes among the at least four committee nodes except the block-producing node as consensus nodes;

[0009] The block-producing node generates a block and submits the generated block to the consensus node. The consensus node votes on the block and sends the voting data to the signature collection node to verify the block. If the block verification passes, the block is written into the alliance chain.

[0010] In one embodiment, the management node sorts the multiple computing nodes from large to small according to the reputation score value; randomly selects at least two computing nodes from a preset number of computing nodes in the front as the signature collection nodes; and uses the other computing nodes in the preset number of computing nodes in the front except the signature collection nodes as committee nodes; the preset number is greater than or equal to six.

[0011] In one embodiment, the at least four committee nodes vote on the block-producing node according to the reputation score value of each committee node among the at least four committee nodes, and send the voting data to the signature collection node; the signature collection node reaches a consensus on the final block-producing node according to the collected voting data, and sends the consensus data to the committee node; the committee node verifies the consensus data of the signature collection node, and if no computing node challenges the result, a consensus is reached and the block-producing node is selected; if a computing node initiates a challenge, the evidence of the challenging party's computing node is reviewed.

[0012] In one embodiment, the block producing node is one of the following:

[0013] The committee node with the highest reputation score among the at least four committee nodes;

[0014] a committee node with the highest performance index among the at least four committee nodes; the performance index is determined based on performance data of the corresponding committee node;

[0015] The committee node having the highest sum of performance index and network status index among the at least four committee nodes; the performance index is determined based on performance data of the corresponding committee node, and the network status index is determined based on network delay data of the corresponding committee node.

[0016] In one embodiment, the consensus node votes on the block and sends the voting data to the signature collection node; the signature collection node reaches a consensus on the block based on the collected voting data and sends the consensus data to the committee node; the committee node verifies the consensus data of the signature collection node to verify the block, and if the verification passes, the block is written into the consortium chain.

[0017] In one embodiment, the method further comprises:

[0018] The signature collection node generates network delay data of the committee node or the consensus node when receiving the voting data of the committee node or the consensus node;

[0019] When broadcasting the voting result, the signature collection node broadcasts the network delay data of the committee node or the consensus node, so that the committee node or the consensus node updates the local reputation score data according to the received network delay data.

[0020] In one embodiment, the method further comprises:

[0021] The signature collection node performs a network delay test on the other computing nodes among the multiple computing nodes except the committee node and the signature collection node every a certain number of blocks, and broadcasts the obtained network delay data to the multiple computing nodes, so that the multiple computing nodes update local reputation score data according to the received network delay data.

[0022] In one embodiment, the selection of the block producing node and the generation of the block by the block producing node are performed in parallel; and / or,

[0023] The block generation of the block producing node and the block broadcasting of the block producing node are executed in parallel by multiple threads.

[0024] In one embodiment, the block-producing node generates a preset number of blocks during a round of consensus, and the preset number is greater than 1.

[0025] An embodiment of this specification also provides a computer device, including a processor and a memory for storing processor executable instructions, and when the processor executes the instructions, the steps of the alliance chain-based data processing method described in any of the above embodiments are implemented.

[0026] An embodiment of this specification also provides a computer-readable storage medium on which computer instructions are stored. When the instructions are executed, the steps of the data processing method based on the alliance chain described in any of the above embodiments are implemented.

[0027] In the embodiment of this specification, a data processing method based on a consortium chain is provided. The consortium chain includes a management node and multiple computing nodes. The management node and the multiple computing nodes store reputation scoring data. The reputation scoring data includes the reputation scoring value of each computing node in the multiple computing nodes. The reputation scoring value of each computing node is determined based on the hardware performance data, security data and network delay data of the corresponding computing node. The management node can elect at least four committee nodes and at least two signature collection nodes from the multiple computing nodes based on the reputation scoring values ​​of the multiple computing nodes. Considering that the consortium chain has a node access mechanism, the security of the computing nodes is relatively high, and the Byzantine fault tolerance is relatively strong. Therefore, when calculating the reputation score value of each computing node, not only the security data of each node is considered, but also the hardware performance data and network delay data of each node are combined. In this way, the comprehensive situation of all computing nodes can be considered more comprehensively, and a batch of computing nodes with the best comprehensive performance can be selected. Under the premise of ensuring security, the consensus efficiency and data processing efficiency can be improved. At the same time, by setting at least two signature collection nodes with good performance to collect and forward voting data, single point failures can be effectively prevented. At least four committee nodes vote for the block-producing nodes according to the reputation score of each committee node, and send the voting data to at least two signature collection nodes to elect the block-producing nodes from the committee nodes, and use the other committee nodes as consensus nodes. The block-producing nodes generate blocks and submit the generated blocks to the consensus nodes. The consensus nodes vote on the blocks and send the voting data to the signature collection nodes to verify the blocks; if the block verification passes, the blocks are written into the alliance chain. The signature collection nodes are used to collect the voting data of the committee nodes or consensus nodes to avoid direct interaction between all nodes. Instead, most of the voting information is collected through a small number of signature collection nodes first, which can reduce complex network-wide communications and improve consensus efficiency.

[0028] With reference to the following description and drawings, specific embodiments of the present invention are disclosed in detail, indicating the manner in which the principles of the present invention can be adopted. It should be understood that the embodiments of the present invention are not limited in scope. Features described and / or shown for one embodiment can be used in one or more other embodiments in the same or similar manner, combined with features in other embodiments, or replace features in other embodiments.

[0029] It should be emphasized that the term “include / comprises” when used herein refers to the presence of features, parts, steps or components, but does not exclude the presence or addition of one or more other features, parts, steps or components. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] The drawings described herein are only for explanation purposes and are not intended to limit the scope of the present invention in any way. In addition, the shapes and proportional dimensions of the components in the drawings are only for illustration purposes and are used to help understand the present invention. They do not specifically limit the shapes and proportional dimensions of the components of the present invention. Under the guidance of the present invention, those skilled in the art can select various possible shapes and proportional dimensions to implement the present invention according to specific circumstances. In the drawings:

[0031] Figure 1 A flowchart of a data processing method based on a consortium chain in an embodiment of this specification is shown;

[0032] Figure 2 A flowchart of the BMDS-BFT consensus mechanism in an embodiment of this specification is shown;

[0033] Figure 3 A timing diagram of a data processing method based on a consortium chain in an embodiment of this specification is shown;

[0034] Figure 4 A schematic diagram of the process of pipeline block output in an embodiment of this specification is shown;

[0035] Figure 5 It shows the system architecture diagram of the public medical chain in one embodiment of this specification;

[0036] Figure 6 A schematic diagram of the structure of a computer device in one embodiment of the present specification is shown. DETAILED DESCRIPTION

[0037] The principles and spirit of this specification will be described below with reference to several exemplary embodiments. It should be understood that these embodiments are provided only to enable those skilled in the art to better understand and implement this specification, and are not intended to limit the scope of this specification in any way. On the contrary, these embodiments are provided to make this specification more thorough and complete, and to fully convey the scope of this disclosure to those skilled in the art.

[0038] Those skilled in the art know that the embodiments of this specification can be implemented as a system, device, method or computer program product. Therefore, this specification can be implemented in the following forms, namely: complete hardware, complete software (including firmware, resident software, microcode, etc.), or a combination of hardware and software.

[0039] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which this specification belongs. The terms used herein in this specification are only for the purpose of describing specific embodiments and are not intended to limit this specification. The term "and / or" used herein includes any and all combinations of one or more of the related listed items.

[0040] The embodiments of this specification provide a data processing method based on a consortium chain. Figure 1 A flowchart of a data processing method based on a consortium chain in an embodiment of this specification is shown. Although this specification provides method operation steps or device structures as shown in the following embodiments or drawings, more or fewer operation steps or module units may be included in the method or device based on routine or no creative labor. In the steps or structures where there is no necessary causal relationship logically, the execution order of these steps or the module structure of the device is not limited to the execution order or module structure described in the embodiments of this specification and shown in the drawings. When the method or module structure described is applied to an actual device or terminal product, it can be connected according to the method or module structure shown in the embodiment or drawings for sequential execution or parallel execution (for example, a parallel processor or a multi-threaded processing environment, or even a distributed processing environment).

[0041] Specifically, Figure 1 As shown, a data processing method based on a consortium chain provided in one embodiment of this specification may include the following steps.

[0042] The method in the embodiments of this specification is applied to nodes in the alliance chain. The alliance chain has appropriate access control and regulatory permissions, and is more suitable for scenarios with high requirements for performance, security and privacy, such as medical data sharing scenarios.

[0043] The alliance chain may include a management node and multiple computing nodes. The management node and the multiple computing nodes both store reputation score data. The reputation score data includes the reputation score value of each computing node in the multiple computing nodes. The reputation score value of each computing node is determined based on the hardware performance data, security data and network delay data of the corresponding computing node.

[0044] Hardware performance data is used to characterize the hardware performance of computing nodes. For example, it can include CPU, memory, and disk I / O utilization. Security data is used to characterize the security of computing nodes. The hardware performance data of nodes can be automatically obtained through server management tool monitoring.

[0045] The security data of computing nodes can be evaluated based on the security events of computing nodes in historical time periods (such as breach records, timeliness of patch updates, strength of security policies, etc.), and a security level (such as a numerical representation from 0 to 1) can be given. The more secure the node, the higher the score. The security data of computing nodes can be given an initial score by the management node of the alliance chain, and then it can be automatically acquired and adjusted through monitoring by network security management tools.

[0046] Network latency data is used to characterize the network status of computing nodes. For example, network latency data may include network latency data. Scoring can be based on the network latency of communication between nodes. The lower the latency, the higher the score, because nodes with good network status can communicate with other nodes faster in a distributed system. The network latency of computing nodes can be automatically obtained through inter-node communication and network management tools.

[0047] In one embodiment, a reputation scoring formula can be defined that combines factors such as hardware performance, security, network latency, etc. Different weights are assigned to each factor, and these weights are adjusted according to the specific needs of the system.

[0048] In one embodiment, a hardware performance index of a computing node may be determined based on the hardware performance data of the computing node. The larger the value of the hardware performance index, the better the hardware performance. The value of the hardware performance index may be 0 to 1. A security index of a computing node may be determined based on the security data of the computing node. The larger the value of the security index, the higher the security. The value of the security index may be 0 to 1. A network status index of a computing node may be calculated based on the network delay data of the computing node. The larger the value of the network status index, the better the network status. The value of the network status index may be 0 to 1.

[0049] In one embodiment, the reputation score value of the computing node can be calculated based on multiple preset weights and hardware performance indicators, security indicators, network status indicators, etc. Among them, the multiple preset weights are three preset weights, which correspond to the hardware performance indicators, security indicators and network status indicators one by one. For example, the reputation score value is equal to the sum of the product of the hardware performance indicator and the first preset weight, the product of the security indicator and the second preset weight, and the product of the network status indicator and the third preset weight. The first preset weight, the second preset weight and the third preset weight can be set by the user of the management node according to actual needs. When initializing the alliance chain network, the management node can send the first preset weight, the second preset weight and the third preset weight to each computing node. The sum of the first preset weight, the second preset weight and the third preset weight is 1. Considering that the medical data sharing blockchain is a strict access management alliance chain, in order to improve the performance of the alliance chain, the weight coefficient can be generally biased towards performance indicators, especially dynamic performance indicators. In the genesis block, the first preset weight, the second preset weight and the third preset weight are 0.25, 0.15 and 0.6 respectively.

[0050] Step S101: The management node selects at least four committee nodes and at least two signature collection nodes from the multiple computing nodes based on the reputation score value of each computing node in the multiple computing nodes.

[0051] Step S102, the at least four committee nodes vote for the block-producing node according to the reputation score value of each committee node among the at least four committee nodes, and send the voting data to the at least two signature collection nodes to elect a committee node from the at least four committee nodes as the block-producing node, and use the other committee nodes among the at least four committee nodes except the block-producing node as consensus nodes.

[0052] The management node can select at least four committee nodes and at least two signature collection nodes from the multiple computing nodes based on the reputation score value of each computing node in the multiple computing nodes. In one embodiment, at least four computing nodes randomly selected from the multiple computing nodes whose reputation score values ​​rank in the front preset number of digits can be used as committee nodes and at least two computing nodes randomly selected therefrom can be used as signature collection nodes. The committee node can include multiple consensus nodes and a block node. By setting at least two signature collection nodes with good performance to collect and forward voting data, single point failure can be effectively prevented.

[0053] In some embodiments of the present specification, the management node sorts the multiple computing nodes from large to small according to the reputation score value; randomly selects at least two computing nodes from the preset number of computing nodes in the front as the signature collection nodes; and uses the other computing nodes in the preset number of computing nodes in the front except the signature collection nodes as committee nodes; the preset number is greater than or equal to six. In the above manner, the committee nodes and the signature collection nodes can be determined.

[0054] After at least four committee nodes are elected, the at least four committee nodes may vote for the block-producing node according to the reputation score value of each committee node among the at least four committee nodes, and send the voting data to the at least two signature collection nodes to elect a committee node from the at least four committee nodes as the block-producing node. The other committee nodes among the at least four committee nodes except the block-producing node may serve as consensus nodes.

[0055] In some embodiments of the present specification, the block-producing node is one of the following: the committee node with the highest reputation score among the at least four committee nodes; the committee node with the highest performance index among the at least four committee nodes; the performance index is determined based on the performance data of the corresponding committee node; the committee node with the highest sum of the performance index and the network status index among the at least four committee nodes; the performance index is determined based on the performance data of the corresponding committee node, and the network status index is determined based on the network delay data of the corresponding committee node. Specific election rules can be pre-set according to actual needs. In the above manner, selection rules can be set according to actual needs to elect a block-producing node that meets actual needs.

[0056] In some embodiments of the present specification, the at least four committee nodes vote on the block-producing nodes according to the reputation score value of each committee node in the at least four committee nodes, and send the voting data to the signature collection node; the signature collection node reaches a consensus on the final block-producing node according to the collected voting data, and sends the consensus data to the committee node; the committee node verifies the consensus data of the signature collection node, and if there is no computing node challenge result, a consensus is reached and the block-producing node is selected. If a computing node initiates a challenge, the evidence of the computing node of the challenger is reviewed. Collecting and forwarding votes through signature collection nodes can reduce complex network-wide communications, improve consensus efficiency, and thus improve the efficiency of election of block-producing nodes.

[0057] Step S103, the block-producing node generates a block and submits the generated block to the consensus node, the consensus node votes on the block and sends the voting data to the signature collection node to verify the block; if the block verification passes, the block is written into the alliance chain.

[0058] After the block producing nodes and consensus nodes are elected, the block producing nodes can generate blocks and submit the generated blocks to the consensus nodes. The consensus nodes can vote on the blocks and send the voting data to the signature collection nodes to verify the blocks. If the block verification passes, the block can be written into the alliance chain.

[0059] In some embodiments of this specification, the consensus node votes on the block and sends the voting data to the signature collection node; the signature collection node reaches a consensus on the block based on the collected voting data and sends the consensus data to the committee node; the committee node verifies the consensus data of the signature collection node to verify the block, and if the verification passes, the block is written into the alliance chain. Collecting votes and forwarding them through the signature collection node can reduce complex network-wide communications, improve consensus efficiency, and thus improve the efficiency of block production nodes.

[0060] In some embodiments of the present specification, the method may further include: when the signature collection node receives the voting data of the committee node or the consensus node, the signature collection node generates network delay data of the committee node or the consensus node; when broadcasting the voting results, the signature collection node broadcasts the network delay data of the committee node or the consensus node, so that the committee node or the consensus node updates the local reputation score data according to the received network delay data.

[0061] In this embodiment, the reputation score first requires that when the committee nodes participate in the voting, the signature collection node not only collects the voting data of each committee node, but also dynamically evaluates the network status of the node. After completing the collection of voting data, the network delay of each committee node will be included when broadcasting the voting results. After receiving the network delay parameters, the node will update the local reputation list. After calculating the scores of each committee node, each committee node scores and ranks the overall reputation of the hardware performance, security and network delay of each committee node locally, so that each node updates the local reputation score data.

[0062] In some embodiments of the present specification, the method may further include: the signature collection node performs a network delay test on the other computing nodes among the multiple computing nodes except the committee node and the signature collection node every a certain number of blocks, and broadcasts the obtained network delay data to the multiple computing nodes, so that the multiple computing nodes update local reputation score data according to the received network delay data.

[0063] In this embodiment, when scoring ordinary nodes (other computing nodes among multiple computing nodes except committee nodes and signature collection nodes), their hardware performance and security scores are obtained in the same way as the consensus committee nodes, but they do not participate in the consensus process, and network delay data cannot be obtained. In order to implement the reputation scoring of ordinary nodes, the signature collection node performs a network delay test on ordinary nodes every certain number of blocks and broadcasts the corresponding value to all nodes. Therefore, each node can calculate the reputation value of ordinary nodes locally and rank them, so that the reputation score value of ordinary nodes in the reputation score data can be updated.

[0064] After obtaining the scores of all nodes, each node locally calculates the reputation of each node and votes for the node with the highest reputation. Then, a consensus mechanism is needed to select the final optimal node, i.e., the block-producing node. If a clear leader cannot be selected in one vote, multiple rounds of voting can be used. After each round of voting, some nodes with poor performance are eliminated according to the scores until the remaining candidate nodes can reach a consensus and select the block-producing node.

[0065] By using signature collection nodes, the communication complexity of the voting process can be reduced, and a consensus can be reached across the entire network within three rounds of voting. This solution achieves this final consensus through hierarchical voting. First, the nodes in the entire network are divided into two levels: committee nodes and signature collection nodes. The committee nodes are responsible for packaging system transactions and electing block nodes. The committee nodes will send the voting data to the signature collection nodes, and then the signature collection nodes will vote on the final block nodes based on the collected voting data, and elect the block nodes to produce blocks.

[0066] The specific voting process includes the following steps: Step 1: Each node locally calculates the weight of each node and votes for the node with the largest weight; Step 2: All committee nodes submit the ballots to the signature collection node. The goal of this round is to reduce complex network-wide communications and avoid direct interaction among all nodes, but to first collect most of the voting information through a small number of signature collection nodes; Step 3: The committee node verifies the consensus of the signature collection node. If no node challenges the result, the system can reach a consensus across the entire network and select a block node. If a node initiates a challenge, it will be reviewed based on the evidence of the challenger.

[0067] As for the election of consensus committee nodes from ordinary nodes, since the number of ordinary nodes that need to be supplemented in one replacement is 10% of the total number of committee nodes, the election objects are just ordinary nodes with higher reputation values ​​(10% of the total number of committee nodes), and the election process is the same as the block-producing node election process.

[0068] In some embodiments of the present specification, the election of the block producing node and the generation of the block by the block producing node are performed in parallel; and / or, the block generation of the block producing node and the block broadcasting of the block producing node are performed in parallel by multiple threads.

[0069] In this embodiment, when the election of the block-producing node is carried out, the election phase is parallel to the block-producing phase. After one round of the election phase ends, the next round of elections can be carried out immediately, without waiting for the elected block-producing node to produce blocks, which can make better use of the system's parallel computing resources and significantly improve the system's response speed. After each round of elections is completed, the selected block-producing node identifier and its corresponding block-producing term are cached for use in subsequent stages. The block-producing node packages transactions from the transaction pool and generates and broadcasts blocks in sequence at predetermined time intervals (such as one block every 0.5 seconds). Block generation and block broadcasting are pipelined. After the block-producing thread generates a block, an asynchronous block broadcasting thread is started to broadcast the block, and the block-producing thread can continue to generate new blocks. This can achieve continuous block generation without waiting for the block broadcast result. The block-producing node generates multiple blocks within a block-producing term, which can reduce the overhead caused by frequent switching of block-producing nodes.

[0070] After receiving the block broadcasted by the block-producing node, all non-block-producing nodes will immediately verify the validity of the block, including checking the block header, transaction legitimacy, Merkle tree correctness, etc. To prevent malicious nodes from arbitrarily producing blocks, the node will also check whether the node is indeed a block-producing node for the term based on the election result cache. If it is not a block-producing node, these blocks will be discarded and the election weight of the node will be reduced. If the node is found to have produced blocks at random multiple times, the iptables firewall will be called to discard the message from the node. After the node receives multiple blocks broadcasted by the previous block-producing node and verifies them, it checks the election result cache. If the node itself is the next block-producing node, it will immediately enter the block-producing stage and start pipeline block production without waiting for the results of a new round of elections, which can greatly reduce the waiting time for block generation.

[0071] In some embodiments of this specification, the block-producing node generates a preset number of blocks in a round of consensus, and the preset number is greater than 1. For example, the block-producing node generates 3 blocks in a round of consensus. The block-producing node can produce blocks serially (single-threaded) without multi-threading. The height of each block is 1 plus the height of the previous block.

[0072] In the above embodiment, the block node election, block packaging and broadcast process pipeline are executed in parallel, which effectively reduces the time consumption and improves the parallel efficiency and consensus efficiency of block production. At the same time, multiple blocks are allowed to be produced in one view, and multiple blocks are produced and broadcasted in batches to avoid the impact of verification failure on the overall block efficiency due to too many transactions packaged in a single block.

[0073] Each embodiment in this specification is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. For details, please refer to the description of the above-mentioned related processing related embodiments, and no further description is given here.

[0074] The above is a description of a specific embodiment of the specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0075] The above method is described below in conjunction with a specific embodiment. However, it should be noted that the specific embodiment is only for better illustrating the present specification and does not constitute an improper limitation on the present specification.

[0076] Considering that the existing consensus mechanism PBFT (Practical Byzantine Fault Tolerance) uses full-node consensus, the master node replacement process is complicated, resulting in high communication costs, and the consensus process does not use pipeline parallel technology, the performance still cannot meet the needs of most scenarios. In particular, as the number of nodes increases, its consensus efficiency drops sharply.

[0077] In order to solve the above problems, a data processing method based on a consortium chain is provided in this specific embodiment. In this specific embodiment, the PBFT algorithm is used as a basis, and the PBFT algorithm is improved to improve the consensus efficiency of the consensus mechanism. The consensus mechanism in this embodiment can be called the BMDS-BFT consensus mechanism. The BMDS-BFT consensus mechanism is a medical data sharing scenario, based on the PBFT consensus algorithm, focusing on scenario-based transformation and technical optimization in terms of reputation mechanism and pipeline parallel technology, with the goal of designing a high-performance consortium chain consensus mechanism that adapts to the high-frequency transaction needs of medical data sharing scenarios. Please refer to Figure 2 , which shows a flow chart of the BMDS-BFT consensus mechanism in the embodiments of this specification. Figure 2As shown in the figure, the BMDS-BFT consensus mechanism will perform actions such as block node election, transaction packaging, block broadcasting, signature collection, and block verification in each view.

[0078] The following is an explanation of the various node roles of the BMDS-BFT consensus mechanism.

[0079] Ordinary nodes. Ordinary nodes can join or leave the network after being reviewed by management nodes and meeting certain conditions. It is a general term for the remaining nodes after selecting specific functional nodes (such as committee nodes, block nodes, signature collection nodes, etc.) from all nodes in the network according to the reputation mechanism. Ordinary nodes are responsible for receiving, storing and verifying transactions, and do not participate in the consensus process of the system. New consensus committee nodes can be elected from ordinary nodes according to a specific reputation mechanism.

[0080] Committee nodes. Committee nodes are elected from all nodes on the network or ordinary nodes according to a specific reputation mechanism. One node can be further elected from the committee nodes as a block node, and the others as consensus nodes. Consensus nodes are used to vote and verify the block results to ensure that the work of block nodes is effective and correct. Consensus nodes can veto non-compliant blocks or refuse to recognize blocks generated by illegal block nodes during the voting process.

[0081] Block producing nodes. Block producing nodes are nodes elected by the committee and are responsible for generating new blocks. Block producing nodes are used to collect transactions, package valid transactions into blocks, calculate the validity of blocks and submit them to the committee. Block producing nodes are also used to submit blocks for committee verification and write them to the chain after they are passed. Block producing nodes usually need to have more powerful hardware performance and network speed to ensure fast block generation and data transmission.

[0082] Signature collection node. The signature collection node is responsible for receiving votes from committee members on consensus data to confirm whether consensus needs to be reached on the results. After collecting enough signatures, the signature collection node broadcasts the voting results to other nodes in the entire network. When collecting voting information, the signature collection node will dynamically count the network delay status of each committee node, and when broadcasting the voting results, it will also include the network delay parameters of each node. Every certain number of blocks, the signature collection node can perform network delay tests on all ordinary nodes and broadcast the results to all nodes as the value of the ordinary node network delay reputation indicator.

[0083] The node reputation mechanism in this specific embodiment is described below.

[0084] In a distributed system, the hardware performance, security and network latency of each node can be used as reputation indicators, and a weighted reputation value calculation formula can be designed to select signature collection nodes and consensus committee nodes, and the consensus committee will vote to select block nodes in each round. At the same time, abnormal nodes can also be found based on the reputation value, and those nodes that affect system security and efficiency can be removed in time.

[0085] Set reputation scoring indicators.

[0086] Hardware performance: Evaluate the hardware performance of each node based on the utilization of CPU, memory, and disk I / O. The hardware performance of the node can be automatically obtained through monitoring with server management tools.

[0087] Security: The security of the node is evaluated based on historical node security events (such as breach records, timeliness of patch updates, strength of security policies, etc.), and a security level (such as a numerical value from 0 to 1) is given. The more secure the node, the higher the score. The security of the node is initially scored by the alliance chain management node, and can then be automatically obtained and adjusted through network security management tool monitoring.

[0088] Network Latency: Scored based on the network latency of communication between nodes. The lower the latency, the higher the score, because nodes with good network status can communicate with other nodes faster in a distributed system. The network latency of a node can be automatically obtained through inter-node communication and network management tools.

[0089] Set reputation scoring rules.

[0090] Define a reputation scoring formula that combines factors such as hardware performance, security, network latency, etc. Assign different weights to each factor and adjust these weights according to the specific needs of the system:

[0091] Node Score = α·Performance Score + β·Security Score + γ·NetworkScore

[0092] Among them, α, β, and γ are the weight coefficients of hardware performance indicators, security indicators, and network status indicators, respectively, and the sum is 1. Performance Score is a hardware performance indicator, Security Score is a security indicator, and Network Score is a network status indicator. These weight coefficients are specified when the alliance chain system is configured (determined by the genesis block during initialization) to dynamically manage the block node election process.

[0093] In this specific embodiment, each node locally maintains a score list that records the reputation indicators of each node in the system, and the list is updated every round of view. When a node enters the network, it will obtain a reputation score and be broadcasted to other committee nodes.

[0094] According to the above indicator settings, when considering the specific scoring rules, it is found that the three types of indicators have their own characteristics, and it is difficult to simply use the weighted sum method to calculate. For example: the hardware performance indicator includes three percentages of CPU, memory, and disk I / O utilization, and the lower the percentage, the better; the network delay indicator has only one time value, and the lower the time value, the better. Different evaluation indicators often have different dimensions and dimensional units. Simply setting scores for different indicators will affect the results of data analysis and it is difficult to reflect their corresponding value in the overall reputation value calculation.

[0095] In order to eliminate the dimensionality impact between indicators and ensure the comparability of the scores of hardware performance, security and network status indicators, it is necessary to standardize the data of different indicators so that each indicator is at the same order of magnitude. Therefore, the min-max standardization method can be used for score calculation. The min-max standardization method is also called deviation standardization, which is a linear transformation of the original data so that the result value is mapped between 0 and 1. The conversion function is shown in the following formula, where max is the maximum value of the sample data and min is the minimum value of the sample data.

[0096]

[0097] Among them, x * is the index after transformation, and x is the index before transformation.

[0098] Performance Score = Transform(1 / Perfomance)

[0099] Its value is between 0 and 1, the higher the better. Perfomance is the performance data.

[0100] Network Score = Transform(1 / Network)

[0101] Its value is between 0 and 1, the higher the better. Network is the network delay data.

[0102] Security Score = Transform(Security),

[0103] Its value is between 0 and 1, the higher the better. Security is the security data.

[0104] Among them, Transform() is a min-max normalization function, which is a linear transformation of the original data so that the result value is mapped to between 0 and 1.

[0105] Score the consensus committee nodes (including block-producing nodes). The reputation score first requires that when the committee nodes participate in the voting, the signature collection node not only collects the voting data of each committee node, but also dynamically evaluates the network status of the node. After completing the collection of voting data, the network delay of each committee node will be included when broadcasting the voting results. After receiving the network delay parameters, the node will update the local reputation list. After calculating the scores of each committee node, each committee node will score and rank the overall reputation of the hardware performance, security and network delay of each committee node locally.

[0106] Scoring of ordinary nodes. When scoring ordinary nodes, the acquisition of their hardware performance and security scores is the same as that of consensus committee nodes, but they do not participate in the consensus process, and network latency indicators cannot be obtained. In order to implement reputation scoring of ordinary nodes, we also specify signature collection nodes to perform network latency tests on ordinary nodes every certain number of blocks, and broadcast the corresponding values ​​to all nodes. Therefore, each node can calculate the reputation value of ordinary nodes locally and rank them.

[0107] Please refer to Figure 3 , shows a timing diagram of the data processing method based on the alliance chain in the embodiment of this specification. Figure 3 As shown, part of the consensus mechanism in this embodiment follows the relevant steps of PBFT: the step in which the block-producing node broadcasts the block to all committee nodes. The other steps are improvements on the relevant steps of PBFT. The ballot broadcasting and signature collection of the committee nodes are different from PBFT. The ballots and corresponding signatures of the committee nodes only need to be sent to a few signature collection nodes, which collect the ballots and corresponding signatures, and then all committee nodes verify the consensus of the signature collection nodes. Figure 3 In the example, assume that node 1 is elected as the block producing node.

[0108] Both steps of PBFT require communication between nodes in the entire network, and the complexity is O(n 2 ), in the two steps corresponding to this scheme, only the committee node and a small number of signature collection nodes are required to communicate, which reduces the communication overhead.

[0109] The method in this specific embodiment may include the following process.

[0110] Voting and election mechanism.

[0111] After obtaining the scores of all nodes, each node locally calculates the reputation of each node and votes for the node with the highest reputation. Then, a consensus mechanism needs to be designed to select the final optimal node, that is, the block-producing node. If a clear leader cannot be selected in one vote, multiple rounds of voting can be used. After each round of voting, some nodes with poor performance are eliminated according to the scores until the remaining candidate nodes can reach a consensus and select the block-producing node.

[0112] By using signature collection nodes, the communication complexity of the voting process can be reduced, and a consensus can be reached across the entire network within three rounds of voting. This solution achieves this final consensus through hierarchical voting. First, the nodes in the entire network are divided into two levels: committee nodes and signature collection nodes. The committee nodes are responsible for packaging system transactions and electing block nodes. The committee nodes will send the voting data to the signature collection nodes, and then the signature collection nodes will vote on the final block nodes based on the collected voting data, and elect the block nodes to produce blocks.

[0113] The specific voting process is as follows: Step 1: Each node locally calculates the weight of each node and votes for the node with the largest weight. Step 2: All committee nodes submit their votes to the signature collection node. The goal of this round is to reduce complex network-wide communications and avoid direct interaction among all nodes. Instead, most of the voting information is collected through a small number of signature collection nodes. Step 3: The committee node verifies the consensus of the signature collection node. If no node challenges the result, the system can reach a consensus across the entire network and select a block node. If a node initiates a challenge, it will be reviewed based on the evidence of the challenger.

[0114] As for the election of committee nodes from ordinary nodes, since the number of ordinary nodes that need to be supplemented in one replacement is 10% of the total number of committee nodes, the election objects are just ordinary nodes with higher reputation values ​​(10% of the total number of committee nodes), and the election process is the same as the block-producing node election process.

[0115] Pipeline block generation solution.

[0116] Please refer to Figure 4 , shows a schematic diagram of the pipeline block flow. Figure 4 As shown in the figure, the pipeline block generation scheme of BMDS-BFT is divided into three stages: election stage, block generation stage, verification and block generation node switching stage. The specific working mechanisms of each stage are as follows.

[0117] Election stage.

[0118] The reputation-based scheme is used to elect block-producing nodes. The election phase is parallel to the block-producing phase. After one round of election phase, the next round of election can be carried out immediately. There is no need to wait for the elected block-producing nodes to produce blocks. This can make better use of the system's parallel computing resources and significantly improve the system's response speed. After each round of election is completed, the selected block-producing node ID and its corresponding block-producing term are cached for use in subsequent stages.

[0119] Block generation phase.

[0120] The block-producing node packages transactions from the transaction pool, generates and broadcasts blocks in sequence at predetermined time intervals (such as one block every 0.5 seconds). Block generation and block broadcasting are pipelined. After the block-producing thread generates a block, an asynchronous block broadcasting thread is started to broadcast the block, and the block-producing thread can continue to generate new blocks. This can achieve continuous block generation without waiting for block broadcast results. The block-producing node generates multiple blocks within a block-producing term, which can reduce the overhead caused by frequent switching of block-producing nodes.

[0121] Verification and block production node switching phase.

[0122] After receiving the block broadcasted by the block-producing node, all non-block-producing nodes will immediately verify the validity of the block, including checking the block header, transaction legitimacy, Merkle tree correctness, etc. To prevent malicious nodes from arbitrarily producing blocks, the node will also check whether the node is indeed a block-producing node for the term based on the election result cache. If it is not a block-producing node, these blocks will be discarded and the election weight of the node will be reduced. If the node is found to have produced blocks at random multiple times, the iptables firewall will be called to discard the message from the node. After the node receives multiple blocks broadcasted by the previous block-producing node and verifies them, it checks the election result cache. If the node itself is the next block-producing node, it will immediately enter the block-producing stage and start pipeline block production without waiting for the results of a new round of elections, which can greatly reduce the waiting time for block generation.

[0123] The system starts.

[0124] When the alliance chain management node is started, the block interval (how long it takes to produce a block) and block capacity (how many transactions are included in a block) parameters are set. The alliance chain management node reviews the node registration, automatically obtains node hardware (CPU, memory, disk I / O), network performance (latency) and other information through the server and network management tools, and assigns the node security level according to the alliance chain security scoring rules (number of breaches, patch update timeliness, security policy strength), and comprehensively calculates the node reputation score. Those who do not meet the conditions will not be registered.

[0125] According to the security level, hardware and network performance reputation scores of the registered nodes, the top m+k nodes with the highest scores are automatically screened, and k (usually 2) nodes are randomly selected from them for signature collection. They generally remain unchanged unless a failure occurs, and then ordinary nodes with high reputation scores are automatically and randomly selected for replacement; the remaining m (usually 4-30) nodes form the initial committee, among which the node with the highest reputation score is determined as the initial block node, and the other committee nodes are consensus nodes, implementing the consensus mechanism.

[0126] In the comprehensive reputation scoring formula, some weights need to be set for indicators such as hardware performance, security, and network latency. Among them, α, β, and γ represent the weight coefficients of hardware performance, security, and network status, respectively, and the sum is 1. Considering that the medical data sharing blockchain is a consortium chain with strict access management, the main purpose of this article is to improve the performance of the consortium chain, so the weight coefficient is generally biased towards performance indicators, especially dynamic performance indicators. In the genesis block, α, β, and γ are set to: 0.25, 0.15, and 0.6, respectively.

[0127] A specific embodiment is given to illustrate the technical solution.

[0128] At present, it is possible to build a public medical chain that can cover a wider area and more institutions, and provide medical data sharing services for other industries (such as commercial insurance, justice, health management, scientific research institutions, etc.) and individuals outside the medical system. The nodes of the medical data sharing blockchain are generally medical institution nodes. After strict registration and review, the node scale of a provincial region may reach hundreds or thousands; communication between nodes is mainly through health and medical special networks, financial special networks, judicial special networks or other Internet dedicated line access methods; transactions are mainly high-frequency data sharing services, and the main data on the chain are medical data and related data hashes, data sharing behavior records, etc., which belong to the type of evidence storage; in terms of security, on the basis of the national secret algorithm, further targeted authorization review, anonymous query, attribute encryption and other measures will be taken. Its system architecture is generally like this Figure 5 shown.

[0129] In the medical data sharing blockchain, the so-called transaction refers to the process in which the medical data demander submits a data sharing application and the medical data provider provides medical data after relevant verification. The main scenarios of such transactions include: medical research, cross-hospital diagnosis and treatment, commercial insurance two-core risk control, digital claims, judicial verification, disease prediction and health guidance, etc. Taking the commercial insurance online underwriting scenario as an example, its business process is as follows: Step 1, the customer submits an underwriting application on the commercial insurance agency's Internet APP and signs an authorization agreement; Step 2, the commercial insurance agency uploads the two-factor hash of the customer's name and ID number, the authorization document or its hash to the chain; Step 3, the commercial insurance agency inquires which medical institutions the customer has visited within the specified period, and issues a specific data sharing application to these medical institutions; Step 4, after receiving the application, the medical institution automatically verifies the authorization document and makes a decision on whether to share the data; Step 5, the medical institution directly uploads the medical data summary to the chain (suitable for simple underwriting scenarios), and the medical data details are sent to the commercial insurance agency after encryption; Step 6, the commercial insurance agency analyzes the medical data through its own underwriting model and makes an underwriting decision. It can be seen that online underwriting scenarios involve multiple links of interaction, which have high performance requirements. Depending on the amount and complexity of the medical data required, under relatively simple underwriting conditions, the data sharing response time should be controlled within 500 milliseconds, so that online customers will have a relatively good insurance experience, which also puts high demands on the performance of the medical data sharing blockchain.

[0130] Therefore, it is necessary to apply the alliance chain consensus mechanism based on reputation and pipeline parallelism to the medical data sharing blockchain scenario. The main implementation process is as follows.

[0131] Network initialization.

[0132] The medical data sharing blockchain management node is started, and the block interval (for example, one block every 0.5 seconds) and block capacity (for example, each block contains 100 transactions) are set.

[0133] The computer nodes of medical institutions apply to join the medical data sharing blockchain network and submit node information (including hardware performance and network performance).

[0134] The medical data sharing blockchain management node reviews the application for joining of each medical institution's computer node and automatically obtains information such as the node's hardware performance and network performance.

[0135] The medical data sharing blockchain management node assigns security weights to the computer nodes of each medical institution according to the security scoring rules of the medical data sharing blockchain.

[0136] The computer nodes of all medical institutions in the medical data sharing blockchain use the weighted values ​​of the three indicators of security, hardware performance, and network performance to comprehensively calculate the reputation score of each medical institution's computer node.

[0137] Filter out the computer nodes of m+k medical institutions with the highest reputation scores (for example, m=20, k=2), and randomly select k medical institutions' computer nodes as the initial signature collection nodes, and the remaining m medical institutions' computer nodes form the initial committee nodes.

[0138] Among the initial committee nodes composed of computer nodes of m medical institutions, the computer node of the medical institution with the highest reputation score is determined as the initial block producing node.

[0139] Implementation of node reputation mechanism.

[0140] The computer node of each medical institution maintains a local record, which contains a list of reputation scores of the computer nodes of each medical institution in the system. The list is updated in each round of views.

[0141] The computer nodes of medical institutions that serve as signature collection nodes dynamically evaluate the network status of the nodes while collecting voting information, and include the network delay parameters of each node when broadcasting the voting results.

[0142] After receiving the network delay parameters, the computer nodes of each medical institution update the local reputation score list and score and rank the hardware performance, security and network delay of the computer nodes of each medical institution.

[0143] Based on the reputation score results, the computer nodes of medical institutions that serve as block production nodes and the computer nodes of medical institutions that serve as consensus committee nodes are selected through a voting election mechanism.

[0144] Implementation of the pipeline block generation solution.

[0145] The election phase is carried out in parallel with the block production phase. In the election phase, a reputation-based scheme is used to elect block production nodes and committee nodes.

[0146] The computer nodes of the medical institutions that serve as block-producing nodes package transactions from the transaction pool, and generate and broadcast blocks in sequence at predetermined time intervals, that is, send the generated blocks to all computer nodes of the medical institutions that serve as non-block-producing nodes.

[0147] All computer nodes of medical institutions that are not block-producing nodes will immediately verify the validity of the block after receiving it, that is, verify whether the block is legal, including the calculation and verification of the parent block hash value and the calculation and verification of the root hash value of the transaction status tree in the block header.

[0148] After the verification is passed, if the computer node of the medical institution that is not a block-producing node determines that it is the next computer node of the medical institution that is a block-producing node, it will immediately enter the block-producing stage and start the pipeline block-producing.

[0149] System operation and monitoring.

[0150] The system continues to run, and the computer nodes of medical institutions that serve as block-producing nodes continuously generate and broadcast new blocks.

[0151] The management node of the medical data sharing blockchain and the computer nodes of medical institutions that serve as signature collection nodes continuously monitor the network status, including the hardware performance and network latency of the computer nodes of each medical institution.

[0152] If abnormal computer nodes of medical institutions are found (such as hardware performance degradation, excessive network latency, etc.), their reputation scores will be adjusted in a timely manner, and they will be removed from the consensus committee if necessary.

[0153] Every certain number of blocks (for example, 100 blocks), the computer nodes of all medical institutions that serve as ordinary nodes are tested for network delay and their reputation scores are updated.

[0154] Performance evaluation and optimization.

[0155] During the operation of the system, the performance indicators of the BMDS-BFT consensus mechanism, including throughput, latency, etc., are regularly evaluated.

[0156] According to the evaluation results, the system is optimized, such as adjusting the weight coefficient, optimizing the pipeline block plan, etc.

[0157] How to adjust the weight coefficient:

[0158] In the comprehensive reputation scoring formula, it is necessary to set weights for indicators such as hardware performance, security, and network latency. If the administrator pays more attention to system performance, the weight coefficients of hardware performance and network status can be increased, so that computer nodes of medical institutions with higher performance are more likely to be selected as block nodes. If the administrator pays more attention to the security of the system, the security coefficient can be increased, so that computer nodes of medical institutions with higher security weights are more likely to be selected as block nodes.

[0159] When the computer nodes of medical institutions as block-producing nodes produce blocks, they originally only produce one block at a time. If optimization is to be performed to achieve higher performance, when the computer nodes of medical institutions as block-producing nodes produce blocks, they can produce three blocks in one view, which can improve the overall throughput of the system.

[0160] In this specific embodiment, a node reputation mechanism is introduced, and each node is scored based on security, hardware performance, and network latency. The top m nodes (generally 4-30) with the highest reputation scores are selected to form a consensus committee, which effectively reduces the complexity of communication. The node with the highest reputation value is elected as the block node by voting, so that the best performance node is elected in each round of view to perform the block task, and some nodes with the lowest reputation value are replaced every certain number of blocks, further improving the efficiency and fairness of consensus. At the same time, k (generally 2) nodes with better performance are set as special signature collection nodes to effectively prevent single point failure. A pipeline parallel mechanism is also introduced to execute the block node election, block packaging and broadcasting process pipelines in parallel, effectively reducing the time consumption of the preparation (Prepare) phase of PBFT and improving the parallel efficiency and consensus efficiency of block production. At the same time, multiple blocks are allowed to be produced in one view, and multiple blocks are produced and broadcasted in batches to avoid the impact of verification failure on the overall block efficiency due to excessive transactions packed in a single block.

[0161] This specification also provides a computer device, which can be found in Figure 6 The computer device structure diagram of the data processing method based on the alliance chain provided by the embodiment of this specification is shown, and the computer device may specifically include an input device 61, a processor 62, and a memory 63. Among them, the memory 63 is used to store processor executable instructions. When the processor 62 executes the instructions, the steps of the data processing method based on the alliance chain described in any of the above embodiments are implemented.

[0162] In this embodiment, the input device may specifically be one of the main devices for information exchange between the user and the computer system. The input device may include a keyboard, a mouse, a camera, a scanner, a light pen, a handwriting input board, a voice input device, etc.; the input device is used to input the original data and the program for processing these numbers into the computer. The input device can also obtain and receive data transmitted from other modules, units, and devices. The processor can be implemented in any appropriate manner. For example, the processor can take the form of a computer-readable medium, a logic gate, a switch, an application-specific integrated circuit (ASIC), a programmable logic controller, and an embedded microcontroller, etc., such as a microprocessor or a processor and a computer-readable program code (such as software or firmware) that can be executed by the (micro) processor. The memory may specifically be a memory device used to store information in modern information technology. The memory may include multiple levels. In a digital system, anything that can store binary data can be a memory; in an integrated circuit, a circuit with a storage function without a physical form is also called a memory, such as a RAM, a FIFO, etc.; in a system, a storage device with a physical form is also called a memory, such as a memory stick, a TF card, etc.

[0163] In this embodiment, the functions and effects specifically realized by the computer device can be explained in comparison with other embodiments and will not be described in detail here.

[0164] A computer storage medium for a data processing method based on a consortium chain is also provided in an implementation manner of this specification, wherein the computer storage medium stores computer program instructions, and when the computer program instructions are executed, the steps of the data processing method based on a consortium chain described in any of the above embodiments are implemented.

[0165] In this embodiment, the storage medium includes but is not limited to a random access memory (RAM), a read-only memory (ROM), a cache, a hard disk (HDD) or a memory card. The memory can be used to store computer program instructions. The network communication unit can be an interface for network connection communication set in accordance with the standard specified by the communication protocol.

[0166] In this embodiment, the functions and effects specifically implemented by the program instructions stored in the computer storage medium can be explained in comparison with other embodiments and will not be repeated here.

[0167] Obviously, those skilled in the art should understand that the modules or steps of the above-mentioned embodiments of this specification can be implemented by a general computing device, they can be concentrated on a single computing device, or distributed on a network composed of multiple computing devices, and optionally, they can be implemented by a program code executable by a computing device, so that they can be stored in a storage device and executed by the computing device, and in some cases, the steps shown or described can be executed in a different order from that here, or they can be made into individual integrated circuit modules, or multiple modules or steps therein can be made into a single integrated circuit module for implementation. In this way, the embodiments of this specification are not limited to any specific combination of hardware and software.

[0168] It should be understood that the above description is for illustration and not for limitation. Many embodiments and many applications beyond the examples provided will be apparent to those skilled in the art upon reading the above description. Therefore, the scope of this specification should not be determined with reference to the above description, but should be determined with reference to the preceding claims and the full scope of equivalents to which these claims belong.

[0169] The above description is only the preferred embodiment of this specification and is not intended to limit this specification. For those skilled in the art, the embodiments of this specification may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of this specification shall be included in the protection scope of this specification.

Claims

1. A data processing method based on alliance chain, characterized in that: The alliance chain includes a management node and multiple computing nodes, and the management node and the multiple computing nodes both store reputation score data, and the reputation score data includes the reputation score value of each computing node in the multiple computing nodes; The reputation score value of each computing node is determined based on the hardware performance data, security data and network delay data of the corresponding computing node; the method includes: The management node selects at least four committee nodes and at least two signature collection nodes from the multiple computing nodes based on the reputation score value of each computing node in the multiple computing nodes; The at least four committee nodes vote for the block-producing node according to the reputation score value of each committee node among the at least four committee nodes, and send the voting data to the at least two signature collection nodes to elect a committee node from the at least four committee nodes as the block-producing node, and use the other committee nodes among the at least four committee nodes except the block-producing node as consensus nodes; The block-producing node generates a block and submits the generated block to the consensus node. The consensus node votes on the block and sends the voting data to the signature collection node to verify the block. If the block verification passes, the block is written into the alliance chain.

2. The data processing method based on alliance chain according to claim 1 is characterized in that: The management node sorts the multiple computing nodes from large to small according to the reputation score values; At least two computing nodes are randomly selected from a preset number of computing nodes in the front as the signature collection nodes; the other computing nodes in the preset number of computing nodes except the signature collection nodes are used as committee nodes; the preset number is greater than or equal to six.

3. The data processing method based on alliance chain according to claim 1 is characterized in that: The at least four committee nodes vote on the block-producing node according to the reputation score value of each committee node among the at least four committee nodes, and send the voting data to the signature collection node; the signature collection node reaches a consensus on the final block-producing node according to the collected voting data, and sends the consensus data to the committee node; The committee node verifies the consensus data of the signature collection node. If there is no computing node challenge result, a consensus is reached and the block-producing node is selected. If a computing node initiates a challenge, the evidence of the challenging party's computing node is reviewed.

4. The data processing method based on alliance chain according to claim 1 is characterized in that: The block producing node is one of the following: The committee node with the highest reputation score among the at least four committee nodes; a committee node with the highest performance index among the at least four committee nodes; the performance index is determined based on performance data of the corresponding committee node; A committee node having the highest sum of performance index and network status index among the at least four committee nodes; The performance indicator is determined based on the performance data of the corresponding committee node, and the network status indicator is determined based on the network delay data of the corresponding committee node.

5. The data processing method based on alliance chain according to claim 1 is characterized in that: The consensus node votes on the block and sends the voting data to the signature collection node; the signature collection node reaches consensus on the block based on the collected voting data and sends the consensus data to the committee node; The committee node verifies the consensus data of the signature collection node to verify the block, and if the verification passes, the block is written into the alliance chain.

6. The data processing method based on alliance chain according to claim 1 is characterized in that: Also includes: The signature collection node generates network delay data of the committee node or the consensus node when receiving the voting data of the committee node or the consensus node; When broadcasting the voting result, the signature collection node broadcasts the network delay data of the committee node or the consensus node, so that the committee node or the consensus node updates the local reputation score data according to the received network delay data.

7. The data processing method based on alliance chain according to claim 1 is characterized in that: Also includes: The signature collection node performs a network delay test on the other computing nodes among the multiple computing nodes except the committee node and the signature collection node every a certain number of blocks, and broadcasts the obtained network delay data to the multiple computing nodes, so that the multiple computing nodes update local reputation score data according to the received network delay data.

8. The data processing method based on alliance chain according to claim 1 is characterized in that: The selection of the block producing node and the generation of the block by the block producing node are performed in parallel; and / or, The block generation of the block producing node and the block broadcasting of the block producing node are executed in parallel by multiple threads.

9. The data processing method based on alliance chain according to claim 8 is characterized in that: The block-producing node generates a preset number of blocks in one round of consensus, where the preset number is greater than or equal to 2.

10. A computer-readable storage medium having computer instructions stored thereon, characterized in that: When the instructions are executed by a processor, the steps of the method according to any one of claims 1 to 9 are implemented.

Images