Block chain transaction processing method, device and equipment

Abstract

The invention provides a block chain transaction processing method, device and equipment, and the method is suitable for a block chain system with a committee member node and a non-committee member node, and comprises the steps: at least one committee member node carries out the consensus chaining of a transaction received in a current era, so as to update the local chain of each node in the block chain system; the at least one committee member node sends a first chain corresponding to a newly generated block in the current era to the at least one non-committee member node after the current era is overtime; the at least one non-committee member node performs consensus according to the received at least one first chain, and determines whether a malicious committee member node exists according to a consensus result; and if a malicious committee member node exists, updating a local chain of each node in the block chain system based on the block serving as the rollback point. By adopting the method, malicious nodes in the committee member nodes can be effectively found, and the security of block chain transaction is ensured.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to a blockchain transaction processing method, apparatus, and device. Background Technology

[0002] Blockchain is a decentralized network without a centralized management body; therefore, a consensus mechanism is needed to ensure the consistency and security of data among nodes. A common blockchain consensus protocol design paradigm is based on "committee selection." Its core idea is to select a subset of nodes from all nodes in the system to form a "committee," which then runs a consensus protocol to reach an agreement on block order. Compared to paradigms where all nodes run the consensus protocol, committee-based consensus protocols offer advantages such as better performance and ease of deployment and operation due to the smaller size of the selected committee.

[0003] The biggest challenge of consensus protocols based on "committee selection" is balancing performance and security. If we assume a blockchain system has n nodes, of which f are faulty or malicious, and if we want to select λ committee nodes from these n nodes while ensuring that no more than 1 / 3 of the committee nodes are faulty, statistically, the committee size would need to be in the thousands. This violates the original design intent of "committee selection" consensus protocols, which is that in practical applications, running a consensus protocol with thousands of nodes rarely achieves very good performance.

[0004] Achieving a balance between high performance and security within a finite-sized committee is a pressing issue that needs to be addressed. Summary of the Invention

[0005] This application provides a blockchain transaction processing method, apparatus, and device for achieving a balance between high performance and security in a limited-size committee.

[0006] Firstly, this application provides a blockchain transaction processing method applicable to blockchain systems with committee member nodes and non-committee member nodes, the method comprising:

[0007] At least one committee member node performs consensus on the transactions received in the current epoch and uploads them to the blockchain to update the local chain of each node in the blockchain system.

[0008] After the current epoch times out, at least one committee member node will send the first chain corresponding to the newly generated block in the current epoch to at least one non-committee member node.

[0009] At least one non-committee member node reaches consensus based on at least one first chain received, and determines whether there is a malicious committee member node based on the consensus result;

[0010] If a malicious committee member node exists, the local chain of each node in the blockchain system will be updated based on the block that serves as the rollback point.

[0011] The blockchain transaction processing method provided in this application achieves rapid consensus on the transaction information to be processed by the blockchain system through a small group of committee member nodes. This is more efficient than requiring all nodes in the blockchain to reach consensus on the transaction information. Furthermore, non-committee members in the blockchain also participate in the consensus on the first chain received to determine whether there are malicious nodes among the committee member nodes. This effectively identifies malicious nodes and enhances the robustness of the blockchain system. The system achieves a good trade-off between theory and practice by precisely controlling consensus input conditions and detection responses without sacrificing performance.

[0012] In one possible design, the at least one non-committee member node performs consensus based on at least one first chain received, including:

[0013] At least one non-committee member node determines the first chain in conflict based on at least one first chain received;

[0014] At least one non-committee member node constructs a proof of wrongdoing based on the first chain of the conflict; the proof of wrongdoing includes at least the conflicting block in the first chain of the conflict and the committee member node that reached consensus on the conflicting block; the conflicting block is a different block corresponding to the same block height in at least two first chains.

[0015] At least one non-committee member node broadcasts the malicious proof and reaches consensus based on each malicious proof.

[0016] In one possible design, the consensus based on proofs of wrongdoing includes:

[0017] At least one non-committee member node inputs its own constructed proof of wrongdoing, along with the received proof of wrongdoing, into the Multivalue Verifiable Byzantine Consensus (MVBA) protocol to reach consensus and identify the malicious committee member node.

[0018] In one possible design, the block serving as the rollback point is determined as follows:

[0019] The last block of the longest subchain in the local chain of at least one non-committee member node that does not contain conflicting blocks is identified as the block to be rolled back.

[0020] In one possible design, the method further includes:

[0021] If there is no conflict on the first chain, then at least one non-committee member node updates its local chain based on the first chain.

[0022] In one possible design, the at least one non-committee member node performs consensus based on at least one first chain received, including:

[0023] At least one non-committee member node determines a set of first chains based on at least one first chain received; any first chain in the set of first chains is a first chain that has been verified and is unique.

[0024] The broadcast objects are determined based on the first chain set, and consensus is reached based on each broadcast object.

[0025] In one possible design, the consensus based on each broadcast object includes:

[0026] The self-constructed broadcast object and the received broadcast object are input into the Multi-Value Byzantine Consensus (MBA) protocol for consensus to identify malicious committee member nodes.

[0027] In one possible design, the method further includes:

[0028] If a second chain is output after consensus through the MBA protocol and there are no malicious committee member nodes, then the local chain of each node in the blockchain system is updated according to the second chain.

[0029] In one possible design, determining the broadcast object based on the first chain set includes:

[0030] If the first chain set contains only one first chain, then the first chain is used as a broadcast object;

[0031] If the first chain set contains multiple first chains, then conflict blocks are determined based on the multiple first chains, and a malicious proof is constructed for the conflict blocks, and the malicious proof is broadcast as a target.

[0032] If the first chain set is an empty set, then the empty set will be used as the broadcast object.

[0033] In one possible design, the block serving as the rollback point is determined as follows:

[0034] The last block of the local chain of at least one non-committee member node at the end of the previous epoch is identified as the block to be rolled back.

[0035] In one possible design, the method further includes:

[0036] Remove malicious committee member nodes from the blockchain system.

[0037] In one possible design, before at least one committee member node reaches consensus on and uploads the transactions received in the current epoch, the following steps are also included:

[0038] All nodes in the blockchain system run a random number generation algorithm a preset number of times to elect at least one committee member node in the blockchain system; wherein the preset number of times is equal to the number of the at least one committee member node.

[0039] Secondly, this application also provides a blockchain transaction processing device, which is applicable to blockchain systems with committee member nodes and non-committee member nodes, and includes a processing unit and a sending and receiving unit;

[0040] The processing unit is used to perform consensus and upload transactions received in the current epoch to the blockchain in order to update the local chains of each node in the blockchain system.

[0041] The transceiver unit is used to send the first chain corresponding to the newly generated block in the current epoch to at least one non-committee member node after the current epoch times out.

[0042] The processing unit is configured to reach a consensus based on at least one first chain received, and to determine whether there are malicious committee member nodes based on the consensus result.

[0043] The processing unit is also used to update the local chain of each node in the blockchain system based on the block that serves as the rollback point if there is a malicious committee member node.

[0044] In one possible design, the processing unit, when performing consensus based on at least one received first chain, specifically performs the following: based on the at least one received first chain, determine the first chain with a conflict; based on the conflicting first chain, construct a malicious proof; the malicious proof at least records the conflicting block in the conflicting first chain and the committee member node that reached consensus on the conflicting block; the conflicting block is a different block corresponding to the same block height in at least two first chains; broadcast the malicious proof and perform consensus based on each malicious proof.

[0045] In one possible design, the processing unit, when reaching consensus based on various malicious proofs, specifically performs the following: inputting its own constructed malicious proof and the received malicious proof into the Multivalued Verifiable Byzantine (MVBA) consensus protocol to reach consensus and identify malicious committee member nodes.

[0046] In one possible design, the processing unit is further configured to identify the last block of the longest subchain in the local chain of at least one non-committee member node that does not contain conflicting blocks as the block to be rolled back.

[0047] In one possible design, if there is no conflict in the first chain, the processing unit is also used to update the local chain based on the first chain.

[0048] In one possible design, the processing unit, when performing consensus based on at least one received first chain, specifically performs the following: determining a set of first chains based on at least one received first chain; any first chain in the set of first chains being a verified and unique first chain; determining broadcast objects based on the set of first chains; and performing consensus based on each broadcast object.

[0049] In one possible design, the processing unit, when performing consensus based on each broadcast object, specifically performs the following: inputting the broadcast object it constructs and the received broadcast object into the Multi-Value Byzantine Consensus (MBA) protocol for consensus, and identifying malicious committee member nodes.

[0050] In one possible design, the processing unit is further configured to update the local chain of each node in the blockchain system based on the second chain if a second chain is output after consensus via the MBA protocol and there are no malicious committee member nodes.

[0051] In one possible design, the processing unit, when determining the broadcast object based on the first chain set, specifically performs the following: if the first chain set contains only one first chain, then the first chain is used as the broadcast object; if the first chain set contains multiple first chains, then conflict blocks are determined based on the multiple first chains, and a malicious proof is constructed for the conflict blocks, and the malicious proof is used as the broadcast object; if the first chain set is an empty set, then the empty set is used as the broadcast object.

[0052] In one possible design, the processing unit is further configured to identify the last block of the local chain of at least one non-committee member node at the end of the previous epoch as the block that serves as the rollback point.

[0053] In one possible design, the processing unit is also used to remove malicious committee member nodes from the blockchain system.

[0054] In one possible design, before consensus is reached on transactions received in the current epoch and uploaded to the blockchain, the processing unit is further configured to run a random number generation algorithm a preset number of times to elect at least one committee member node in the blockchain system; wherein the preset number of times is equal to the number of the at least one committee member node.

[0055] Thirdly, this application also provides a blockchain transaction processing device, which includes: a processor and a memory communicatively connected to the processor;

[0056] The memory stores computer-executed instructions;

[0057] The processor executes computer execution instructions stored in the memory to implement the method described in the first aspect above.

[0058] Fourthly, this application also provides a computer-readable storage medium comprising a program that, when executed on a device, causes the device to perform the method as described in any one of the first aspects above.

[0059] Fifthly, this application also provides a computer program product, the computer program product comprising a computer program that, when executed by a processor, implements the method described in the first aspect above. Attached Figure Description

[0060] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying 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.

[0061] Figure 1 This is a schematic diagram of the blockchain transaction processing method provided in the embodiments of this application;

[0062] Figure 2 A schematic diagram of the consensus of committee member nodes provided in the embodiments of this application;

[0063] Figure 3 A schematic diagram of consensus among non-committee member nodes provided in this application embodiment. Figure 1 ;

[0064] Figure 4 A schematic diagram of consensus among non-committee member nodes provided in this application embodiment. Figure 2 ;

[0065] Figure 5 Schematic diagram of the blockchain transaction processing device provided in the embodiments of this application Figure 1 ;

[0066] Figure 6 Schematic diagram of the blockchain transaction processing device provided in the embodiments of this application Figure 2 . Detailed Implementation

[0067] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0068] The application scenarios described in this application are for the purpose of more clearly illustrating the technical solutions of this application, and do not constitute a limitation on the technical solutions provided in this application. Those skilled in the art will understand that with the emergence of new application scenarios, the technical solutions provided in this application are also applicable to similar technical problems. In the description of this application, unless otherwise stated, "multiple" means two or more.

[0069] The following is an explanation of the terminology used in the embodiments of this application:

[0070] Byzantine Fault Tolerance (BFT) is a consensus algorithm in distributed systems designed to address unreliability and failures among nodes, particularly the presence of malicious nodes. The BFT protocol aims to maintain consistency and reliability in blockchain systems even when some nodes fail or are attacked. However, with the rapid increase in the number of blockchain nodes, the performance of the BFT protocol deteriorates sharply, and consensus latency in large-scale networks increases significantly, requiring each consensus round to wait for responses from the vast majority of nodes.

[0071] Byzantine Atomic Broadcast (BAB) Protocol: The BAB protocol is a distributed consensus protocol used to solve the problem of reliable message propagation in Byzantine fault-tolerant environments. This protocol ensures that all correct nodes can agree on the message order even in the presence of Byzantine nodes that may engage in arbitrary malicious behavior. The BAB protocol satisfies two key properties: security (all correct nodes receive the message set in the same order) and liveness (correctly broadcast messages are received by all correct nodes). It is typically implemented based on Byzantine fault-tolerant algorithms, such as PBFT or Hotstuff, and can maintain system operation even when less than one-third of the nodes are Byzantine nodes. It is a fundamental component in blockchain systems for ensuring transaction consistency. The behavior of a node inputting transactions into the protocol is called bab-propose, and any node can call this protocol interface; the behavior of the protocol outputting transactions after consensus is reached is called bab-deliver, and all nodes execute this behavior, with the transactions ordered in the bab-deliver process being identical.

[0072] Multi-valued Byzantine Agreement (MBA) protocol: This protocol can handle complex data structures, such as transaction sets or block data, and is a distributed protocol that allows nodes to reach consensus on arbitrary values. Through multiple rounds of communication, this protocol ensures that honest nodes in the network can still reach a consensus on a proposed value even in the presence of malicious nodes. MBA typically employs mechanisms such as random leader election, voting confirmation, and threshold signatures to accelerate the consensus process and ensure consistency (all correct nodes will receive the same output value) and validity (if all correct nodes input the same value, all correct nodes will output that value). Many modern blockchain systems, such as Algorand and Dfinity, use variants of the MBA protocol as their core consensus mechanism, providing strong consistency guarantees while maintaining high throughput. Each node calls the protocol's input interface `mba-propose` to input an arbitrary value, and then obtains the final consensus output value through the `mba-decide` interface.

[0073] The Multi-valued Byzantine Agreement (MVBA) protocol is designed specifically for handling complex value consensus in Byzantine environments. This protocol allows nodes in a distributed system to reach consensus on any complex value that meets specific formatting requirements, even in the presence of malicious nodes. Core characteristics of the MVBA protocol include validity (the final decided value must be a verified valid value), consistency (all correct nodes will ultimately decide the same value), and termination (the protocol can be completed within a finite time). Typical implementations of the MVBA protocol often combine techniques such as random selectors, witness proofs, and distributed verifiable random functions to optimize communication complexity while ensuring security. The MVBA protocol is widely used in high-performance blockchain systems, such as HoneyBadgerBFT, providing a robust consensus foundation for asynchronous network environments. Each node calls the protocol's input interface `mvba-propose` to input an arbitrary value, and then obtains the final consensus output value through the `mvba-decide` interface.

[0074] Currently, there are two main ways to achieve consensus in blockchain: the first is consensus by all nodes, where all nodes in the blockchain reach consensus by running a consensus protocol. However, the first method suffers from poor performance when the number of blockchain nodes is large. The second method, as mentioned in the background section, is consensus based on the "committee selection" method. As described in the background section, the second method urgently needs to achieve a balance between high performance and security in a limited-sized committee.

[0075] Based on the problems existing in the above two consensus methods, this application proposes the following... Figure 1 The method shown is applicable to blockchains with committee member nodes and non-committee member nodes. Specifically, the method includes:

[0076] Step 101: At least one committee member node performs consensus on the transactions received in the current epoch and uploads them to the blockchain to update the local chain of each node in the blockchain system.

[0077] For example, in blockchain, an epoch is a concept used to define a specific period of time, usually associated with some key events or state changes on the blockchain. Different blockchain protocols may have different definitions and applications of epochs. For instance, in the Ethereum protocol, an epoch refers to the total time taken to complete 30,000 blocks.

[0078] For example, at least one committee member node in a blockchain can be determined as follows: all nodes in the blockchain system run a random number generation algorithm a preset number of times to elect at least one committee member node, ensuring the randomness of the committee member nodes; wherein, the preset number of times is equal to the number of at least one committee member node, and this application does not limit the random number generation algorithm used to elect committee member nodes. Specifically, all nodes run the random number generation algorithm once to determine one committee member node. Thus, the number of times the random number generation function is run can be controlled. Generally speaking, a number of committee member nodes in the range of 10 to 20 is more appropriate, and the number of committee member nodes can be adjusted accordingly according to actual business needs; this application does not limit this.

[0079] For example, after the committee member nodes in the blockchain are selected, at least one committee member node will reach a consensus on the transactions received in the current epoch and upload them to the chain. Taking the BAB protocol used by committee member node ① for consensus as an example, the transaction information received by committee member node ① is denoted as tx. Committee member node ① calls bab-propose(tx) to reach a consensus, and after bab-deliver(B), it broadcasts the packaged block B, which has reached a consensus among the committee members, to all nodes. Each node that receives the packaged block B updates its local chain according to block B. The overall execution flow of step 101 can be found in [reference needed]. Figure 2 .

[0080] Step 102: After the current epoch times out, at least one committee member node sends the first chain corresponding to the newly generated block in the current epoch to at least one non-committee member node.

[0081] For example, in each epoch, committee member nodes generate a first chain based on newly generated blocks in the current epoch. When the epoch times out, at least one committee member node sends its first chain generated in the current epoch to at least one non-committee member node. For instance, suppose there are three committee member nodes in the blockchain system, denoted as committee member node ① to committee member node ③. The first chain generated by committee member node ① based on newly generated blocks in the current epoch is denoted as first chain ①, the first chain generated by committee member node ② based on newly generated blocks in the current epoch is denoted as first chain ②, and the first chain generated by committee member node ③ based on newly generated blocks in the current epoch is denoted as first chain ③. Then, after the current epoch times out, committee member node ① sends first chain ① to at least one non-committee member node in the blockchain system, similarly, committee member node ② sends first chain ② to at least one non-committee member node in the blockchain system, and committee member node ③ sends first chain ③ to at least one non-committee member node in the blockchain system.

[0082] Step 103: At least one non-committee member node performs consensus based on at least one first chain received, and determines whether there are malicious committee member nodes based on the consensus result.

[0083] Step 104: If there is a malicious committee member node, update the local chain of each node in the blockchain system based on the block that serves as the rollback point.

[0084] This application provides two schemes for at least one non-committee member node to reach consensus based on at least one first chain received:

[0085] Option 1: At least one non-committee member node determines the conflicting first chain based on at least one first chain received; at least one non-committee member node constructs a malicious proof based on the conflicting first chain; at least one non-committee member node broadcasts the malicious proof; at least one non-committee member node inputs its constructed malicious proof and the received malicious proof into the MVBA protocol for consensus to determine the malicious committee member node.

[0086] For any non-committee member node among at least one non-committee member node, if there are at least two different first chains among the first chains received by that non-committee member node, then it is determined that these two first chains conflict. For example, if the first chain ① and the first chain ② received by non-committee member node ① are different, then it can be determined that the first chain ① and the first chain ② conflict.

[0087] The aforementioned proof of wrongdoing can also be called evidence of wrongdoing or proof of confusion. The proof of wrongdoing must at least record the conflicting blocks in the first chain and the committee member nodes that reached a consensus on the conflicting blocks. A conflicting block refers to different blocks in at least two first chains that correspond to the same block height.

[0088] For example, suppose that the block corresponding to block height h of the first chain ① is block A, and the block corresponding to block height h of the first chain ② is block B. Then blocks A and B are conflicting blocks. The malicious proof constructed by non-committee member node ① based on the first chain ① and the first chain ② includes conflicting blocks A and B, as well as the committee member nodes that reach consensus on these two conflicting blocks.

[0089] Before broadcasting the proof of wrongdoing, non-committee members select the longest non-collision subchain on their local chain and calculate the hash value of the last block of that subchain. They then broadcast the proof of wrongdoing and the hash value to other non-committee member nodes. Upon receiving the proof of wrongdoing and the hash value, other non-committee member nodes verify the proof of wrongdoing. If the verification is successful, the proof of wrongdoing is added to the local proof of wrongdoing set. If any non-committee member node that receives the broadcast message has not yet broadcast the proof of wrongdoing and the hash value, then that non-committee member node needs to calculate the hash value using the same calculation method and continue to broadcast the proof of wrongdoing and the hash value to other non-committee member nodes. It should be noted that the proof of wrongdoing broadcast at this time includes the proof of wrongdoing constructed by the node itself and the proof of wrongdoing in the local proof of wrongdoing set.

[0090] When any non-committee member node receives a broadcast message containing proof of wrongdoing and a hash value, it will call the MVBA protocol's mvba-propose function based on its own constructed proof of wrongdoing and the received proof of wrongdoing. After consensus is reached, it will output mvba-decide. The preset threshold can be set to nf, where n is the total number of nodes in the blockchain and f is the number of malicious nodes in the blockchain system.

[0091] The MVBA protocol output includes proofs of malicious behavior and the hash value corresponding to the block that serves as the rollback point. After receiving the MVBA protocol output, each node can identify malicious nodes among the committee members based on the proofs of malicious behavior, punish the malicious nodes, and remove them from the blockchain system. It also rolls back the local chain to the block corresponding to the hash value in the output, ensuring consistency across all nodes. Afterward, the local set of proofs of malicious behavior can be cleared to enter the next epoch.

[0092] Furthermore, if there is no conflicting first chain, it indicates that the first chain sent by each committee member node to the non-committee member node is the same. It can be assumed that there are no malicious nodes among the committee member nodes or that each committee member node has not engaged in malicious behavior in the current epoch. Therefore, at least one non-committee member node can directly update its local chain based on the first chain.

[0093] For the complete execution process of Option 1, please refer to... Figure 3 Scheme 1 combines the MVBA protocol with a conflict signature detection mechanism to propose a verifiable method for collecting and disseminating malicious evidence. This enables the blockchain system to clearly identify malicious nodes and achieve network-wide removal and state rollback through consensus. A dynamic security enhancement mechanism is designed for a small-scale committee environment, allowing the system to achieve a good trade-off between theory and practice by precisely controlling consensus input conditions and detection responses without sacrificing performance.

[0094] Option 2: At least one non-committee member node determines a set of first chains based on at least one first chain received; any first chain in the set of first chains is a verified and unique first chain; based on the set of first chains, a broadcast object is determined, and the broadcast object constructed by itself and the received broadcast object are input into the MBA protocol for consensus to identify malicious committee member nodes.

[0095] Specifically, if the first chain set contains only one first chain, then that first chain is used as the broadcast object; if the first chain set contains multiple first chains, then conflicting blocks are determined based on the multiple first chains, and malicious proofs are constructed for the conflicting blocks (for an explanation of conflicting blocks and malicious proofs, please refer to Scheme 1, which will not be repeated here), and the malicious proofs are used as the broadcast object; if the first chain set is an empty set, then the empty set is used as the broadcast object.

[0096] The system inputs its own constructed broadcast object and the received broadcast object into the MBA protocol, calls mba-propose, and waits for the output of the MBA protocol. If the second chain is output after consensus by the MBA protocol and there are no malicious committee member nodes, then the local chains of each node in the blockchain system are updated according to the second chain. If a malicious proof is output after consensus by the MBA protocol, then the malicious node among the committee member nodes is identified according to the malicious proof, and the malicious node is removed from the blockchain system. The local chain is also rolled back to the block that serves as the rollback point (the block that serves as the rollback point is determined by identifying the last block of the local chain of at least one non-committee member node at the end of the previous epoch). If an empty set is output after consensus by the MBA protocol, then the epoch ends directly.

[0097] As can be seen from the two schemes above, Scheme 1 and Scheme 2 determine the block used as the rollback point in different ways. In Scheme 1, the last block of the longest subchain without conflicting blocks in the local chain of non-committee member nodes is selected as the rollback point. In Scheme 2, the last block of the local chain of non-committee member nodes at the end of the previous epoch is selected as the rollback point. This is because, in Scheme 2, non-committee member nodes will definitely reach consensus in each epoch. If there are malicious nodes among the committee member nodes, they will definitely be identified. Therefore, the probability of malicious nodes among committee member nodes is significantly reduced, and even if the rollback is to the last block of the local chain at the end of the previous epoch, the performance impact is not significant. In Scheme 1, non-committee member nodes do not necessarily reach consensus in each epoch. Therefore, when a potentially malicious node is detected among the committee member nodes, not all blocks are discarded, but the rollback is to the last block of the longest subchain without conflicting blocks to reduce block waste.

[0098] For the complete execution process of Option 2, please refer to [link / reference]. Figure 4 Option 2 allows for protocol security under a small-scale committee, reducing resource consumption. It achieves rapid consensus on transaction information processed by the blockchain system through the BAB protocol within committee member nodes, and periodically verifies consensus information and malicious node activity using the MBA protocol, ensuring final certainty. Similar to Option 1, it enhances system robustness by identifying, punishing, and removing malicious nodes.

[0099] Figure 5 and Figure 6 The diagram illustrates the possible structure of a blockchain transaction processing apparatus provided in the embodiments of this application. These blockchain transaction processing apparatuses can be used to implement the functions of committee member nodes or non-committee member nodes in the above method embodiments, and thus also achieve the beneficial effects of the above method embodiments.

[0100] like Figure 5 As shown, the blockchain transaction processing device 500 includes a processing unit 510 and a transceiver unit 520. When the blockchain transaction processing device 500 is used to implement... Figure 1 When the method embodiment shown functions as either a committee member node or a non-committee member node:

[0101] The processing unit 510 is used to perform consensus on the transactions received in the current epoch and upload them to the blockchain in order to update the local chain of each node in the blockchain system.

[0102] The transceiver unit 520 is used to send the first chain corresponding to the newly generated block in the current epoch to at least one non-committee member node after the current epoch times out.

[0103] The processing unit 510 is used to perform consensus based on at least one first chain received, and to determine whether there are malicious committee member nodes based on the consensus result.

[0104] The processing unit 510 is also used to update the local chain of each node in the blockchain system based on the block that serves as the rollback point if there is a malicious committee member node.

[0105] In one possible design, the processing unit 510, when performing consensus based on at least one received first chain, specifically performs the following: based on the at least one received first chain, determine the first chain with a conflict; based on the conflicting first chain, construct a malicious proof; the malicious proof at least records the conflicting block in the conflicting first chain and the committee member node that performs consensus on the conflicting block; the conflicting block is a different block corresponding to the same block height in at least two first chains; broadcast the malicious proof and perform consensus based on each malicious proof.

[0106] In one possible design, the processing unit 510, when reaching consensus based on various malicious proofs, specifically performs the following: inputting its own constructed malicious proof and the received malicious proof into the Multi-Value Verifiable Byzantine (MVBA) consensus protocol to reach consensus and identify malicious committee member nodes.

[0107] In one possible design, the processing unit 510 is further configured to identify the last block of the longest subchain in the local chain of at least one non-committee member node that does not contain conflicting blocks as the block to be rolled back.

[0108] In one possible design, if there is no conflicting first chain, the processing unit 510 is also used to update the local chain based on the first chain.

[0109] In one possible design, the processing unit 510, when performing consensus based on at least one received first chain, specifically performs the following: determining a set of first chains based on at least one received first chain; any first chain in the set of first chains being a verified and unique first chain; determining broadcast objects based on the set of first chains; and performing consensus based on each broadcast object.

[0110] In one possible design, the processing unit 510, when performing consensus based on each broadcast object, specifically performs the following: inputting the broadcast object it constructs and the received broadcast object into the Multi-Value Byzantine Consensus (MBA) protocol for consensus, and identifying malicious committee member nodes.

[0111] In one possible design, the processing unit 510 is further configured to update the local chain of each node in the blockchain system according to the second chain if a second chain is output after consensus via the MBA protocol and there are no malicious committee member nodes.

[0112] In one possible design, the processing unit 510, when determining the broadcast object based on the first chain set, specifically performs the following: if the first chain set contains only one first chain, then the first chain is used as the broadcast object; if the first chain set contains multiple first chains, then conflict blocks are determined based on the multiple first chains, and a malicious proof is constructed for the conflict blocks, and the malicious proof is used as the broadcast object; if the first chain set is an empty set, then the empty set is used as the broadcast object.

[0113] In one possible design, the processing unit 510 is further configured to identify the last block of the local chain of at least one non-committee member node at the end of the previous epoch as the block that serves as the rollback point.

[0114] In one possible design, the processing unit 510 is also used to remove malicious committee member nodes from the blockchain system.

[0115] In one possible design, before consensus is reached on transactions received in the current epoch and uploaded to the blockchain, the processing unit 510 is further configured to run a random number generation algorithm a preset number of times to elect at least one committee member node in the blockchain system; wherein the preset number of times is equal to the number of the at least one committee member node.

[0116] For a more detailed description of the processing unit 510 and the transceiver unit 520, please refer to [link / reference needed]. Figure 1 The relevant descriptions in the method embodiments shown are directly obtained and will not be repeated here.

[0117] like Figure 6 As shown, the blockchain transaction processing device 600 includes a processor 610 and an interface circuit 620. The processor 610 and the interface circuit 620 are coupled to each other. It is understood that the interface circuit 620 can be a transceiver or an input / output interface. Optionally, the blockchain transaction processing device 600 may also include a memory 630 for storing instructions executed by the processor 610, or storing input data required by the processor 610 to execute instructions, or storing data generated after the processor 610 executes instructions.

[0118] When the blockchain transaction processing device 600 is used to implement Figure 1 In the method shown, the processor 610 is used to implement the functions of the processing unit 510, and the interface circuit 620 is used to implement the functions of the transceiver unit 520.

[0119] The unit division in this embodiment is illustrative and represents only one logical functional division. In actual implementation, other division methods may be used. Furthermore, the functional units in the various embodiments of this application can be integrated into a single processor, exist as separate physical units, or be integrated into a single unit. The integrated units described above can be implemented in hardware or as software functional units.

[0120] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0121] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A blockchain transaction processing method, characterized in that, Applicable to blockchain systems with committee member nodes and non-committee member nodes, the method includes: At least one committee member node performs consensus on the transactions received in the current epoch and uploads them to the blockchain to update the local chain of each node in the blockchain system. After the current epoch times out, at least one committee member node will send the first chain corresponding to the newly generated block in the current epoch to at least one non-committee member node. At least one non-committee member node reaches consensus based on at least one first chain received, and determines whether there is a malicious committee member node based on the consensus result; If a malicious committee member node exists, the local chain of each node in the blockchain system will be updated based on the block that serves as the rollback point.

2. The method as described in claim 1, characterized in that, The at least one non-committee member node performs consensus based on at least one first chain received, including: At least one non-committee member node determines the first chain in conflict based on at least one first chain received; At least one non-committee member node constructs a proof of wrongdoing based on the first chain of the conflict; the proof of wrongdoing includes at least the conflicting block in the first chain of the conflict and the committee member node that reached consensus on the conflicting block; the conflicting block is a different block corresponding to the same block height in at least two first chains. At least one non-committee member node broadcasts the malicious proof and reaches consensus based on each malicious proof.

3. The method as described in claim 2, characterized in that, The consensus based on each proof of wrongdoing includes: At least one non-committee member node inputs its own constructed proof of wrongdoing, along with the received proof of wrongdoing, into the Multivalue Verifiable Byzantine Consensus (MVBA) protocol to reach consensus and identify the malicious committee member node.

4. The method as described in claim 2, characterized in that, The blocks used as rollback points are determined in the following ways: The last block of the longest subchain in the local chain of at least one non-committee member node that does not contain conflicting blocks is identified as the block to be rolled back.

5. The method as described in claim 2, characterized in that, The method further includes: If there is no conflict on the first chain, then at least one non-committee member node updates its local chain based on the first chain.

6. The method as described in claim 1, characterized in that, The at least one non-committee member node performs consensus based on at least one first chain received, including: At least one non-committee member node determines a set of first chains based on at least one first chain received; any first chain in the set of first chains is a first chain that has been verified and is unique. The broadcast objects are determined based on the first chain set, and consensus is reached based on each broadcast object.

7. The method as described in claim 6, characterized in that, The consensus based on each broadcast object includes: The self-constructed broadcast object and the received broadcast object are input into the Multi-Value Byzantine Consensus (MBA) protocol for consensus to identify malicious committee member nodes.

8. The method as described in claim 7, characterized in that, The method further includes: If a second chain is output after consensus through the MBA protocol and there are no malicious committee member nodes, then the local chain of each node in the blockchain system is updated according to the second chain.

9. The method as described in claim 6, characterized in that, The step of determining the broadcast object based on the first chain set includes: If the first chain set contains only one first chain, then the first chain is used as a broadcast object; If the first chain set contains multiple first chains, then conflict blocks are determined based on the multiple first chains, and a malicious proof is constructed for the conflict blocks, and the malicious proof is broadcast as a target. If the first chain set is an empty set, then the empty set will be used as the broadcast object.

10. The method as described in claim 6, characterized in that, The blocks used as rollback points are determined in the following ways: The last block of the local chain of at least one non-committee member node at the end of the previous epoch is identified as the block to be rolled back.

11. The method according to any one of claims 1-10, characterized in that, The method further includes: Remove malicious committee member nodes from the blockchain system.

12. The method according to any one of claims 1-10, characterized in that, Before at least one committee member node reaches consensus on and uploads transactions received in the current epoch, the following steps are also included: All nodes in the blockchain system run a random number generation algorithm a preset number of times to elect at least one committee member node in the blockchain system; wherein the preset number of times is equal to the number of the at least one committee member node.

13. A blockchain transaction processing device, characterized in that, This device is suitable for blockchain systems with committee member nodes and non-committee member nodes, and includes processing units and transceiver units; The processing unit is used to perform consensus and upload transactions received in the current epoch to the blockchain in order to update the local chains of each node in the blockchain system. The transceiver unit is used to send the first chain corresponding to the newly generated block in the current epoch to at least one non-committee member node after the current epoch times out. The processing unit is configured to reach a consensus based on at least one first chain received, and to determine whether there are malicious committee member nodes based on the consensus result. The processing unit is also used to update the local chain of each node in the blockchain system based on the block that serves as the rollback point if there is a malicious committee member node.

14. A blockchain transaction processing device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1-12.

Images