Transaction distribution method in blockchain system, blockchain node and blockchain system

Abstract

A transaction distribution method, a blockchain node and a blockchain system, the method comprising: a first node obtaining a plurality of transactions from a transaction pool; generating a first transaction package, the first transaction package comprising a first package header and the plurality of transactions, the first package header comprising a package header hash value of a last transaction package generated by the first node and a first hash value of the plurality of transactions; generating 3f+1 shards based on the first transaction package; providing the 3f+1 shards to 3f+1 nodes of n nodes respectively, and providing the first package header to each of the 3f+1 nodes; a second node verifying a first shard according to the package header hash value of the last transaction package in the first package header; and in the case that the first shard is verified successfully, storing the first shard for recovering the first transaction package.

Description

Technical Field

[0001] The embodiments in this specification belong to the field of blockchain technology, and in particular relate to a transaction distribution method, a blockchain node, and a blockchain system. Background Technology

[0002] Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and cryptographic algorithms. In a blockchain system, data blocks are sequentially linked together to form a chain-like data structure, and a distributed ledger is cryptographically guaranteed to be immutable and unforgeable. Due to its decentralized, immutable, and autonomous characteristics, blockchain is receiving increasing attention and application. Summary of the Invention

[0003] The purpose of this invention is to provide a transaction distribution method in a blockchain to improve the efficiency of transaction distribution in a blockchain.

[0004] This specification provides a transaction distribution method in a blockchain system, the blockchain system including a first node and n-1 second nodes, where n is equal to or greater than 3f+1, and f is the maximum number of malicious nodes allowed in the blockchain system. The method includes:

[0005] The first node retrieves multiple transactions from the transaction pool; based on the multiple transactions, it generates a first transaction packet, the first transaction packet including a first packet header and the multiple transactions, the first packet header including the packet header hash value of the previous transaction packet generated by the first node and the first hash value corresponding to the multiple transactions; based on the first transaction packet, it generates 3f+1 shards, the 3f+1 shards including 2f+1 data blocks obtained by dividing the first transaction packet, and f encoded blocks generated based on the 2f+1 data blocks; the 3f+1 shards are respectively provided to 3f+1 nodes out of the n nodes, and the first packet header is provided to each of the 3f+1 nodes;

[0006] The second node among the n-1 second nodes that obtains the first fragment of the 3f+1 fragments verifies the first fragment based on the packet header hash value of the previous transaction packet in the first packet header; if the verification of the first fragment is successful, the first fragment is stored for use in restoring the first transaction packet.

[0007] A second aspect of this specification provides a transaction distribution method in a blockchain system, the blockchain system including a first node and n-1 second nodes, where n is equal to or greater than 3f+1, and f is the maximum number of malicious nodes allowed in the blockchain system. The method is executed by any of the second nodes and includes:

[0008] The first node receives a first packet header and a first fragment from 3f+1 fragments of a first transaction packet. The first transaction packet also includes multiple transactions received by the first node. The first packet header includes the packet header hash value of the previous transaction packet generated by the first node and the first hash value corresponding to the multiple transactions. The 3f+1 fragments include 2f+1 data blocks obtained by dividing the first transaction packet and f encoded blocks generated based on the 2f+1 data blocks.

[0009] The first fragment is verified based on the packet header hash value of the previous transaction packet in the first packet header;

[0010] If the first fragment passes verification, the first fragment is stored for use in restoring the first transaction packet.

[0011] A third aspect of this specification provides a blockchain system comprising a first node and n-1 second nodes, wherein n is equal to or greater than 3f+1, and f is the maximum allowed number of malicious nodes in the blockchain system.

[0012] The first node is used for: obtaining multiple transactions from the transaction pool; generating a first transaction packet based on the multiple transactions, the first transaction packet including a first packet header and the multiple transactions, the first packet header including the packet header hash value of the previous transaction packet generated by the first node and the first hash value corresponding to the multiple transactions; generating 3f+1 shards based on the first transaction packet, the 3f+1 shards including 2f+1 data blocks obtained by dividing the first transaction packet and f encoded blocks generated based on the 2f+1 data blocks; providing the 3f+1 shards to 3f+1 nodes out of the n nodes respectively, and providing the first packet header to each of the 3f+1 nodes;

[0013] The second node among the n-1 second nodes that obtains the first fragment among the 3f+1 fragments is used to: verify the first fragment according to the packet header hash value of the previous transaction packet in the first packet header; if the verification of the first fragment is successful, store the first fragment for use in restoring the first transaction packet.

[0014] A fourth aspect of this specification provides a second node in a blockchain system, the blockchain system including a first node and n-1 second nodes, wherein n is equal to or greater than 3f+1, f is the maximum number of malicious nodes allowed in the blockchain system, and the second node includes:

[0015] The receiving unit is configured to receive from the first node a first packet header and a first fragment from 3f+1 fragments of a first transaction packet. The first transaction packet also includes multiple transactions received by the first node. The first packet header includes the packet header hash value of the previous transaction packet generated by the first node and the first hash values ​​corresponding to the multiple transactions. The 3f+1 fragments include 2f+1 data blocks obtained by dividing the first transaction packet and f encoded blocks generated based on the 2f+1 data blocks.

[0016] The verification unit is used to verify the first fragment based on the first packet header;

[0017] A storage unit is used to store the first fragment for use in restoring the first transaction packet if the first fragment is verified to be valid.

[0018] The fifth aspect of this specification provides a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method described in the second aspect.

[0019] The sixth aspect of this specification provides a blockchain node, including a memory and a processor, wherein the memory stores executable code, and the processor executes the executable code to implement the method described in the second aspect.

[0020] In the scheme provided in the embodiments of this specification, each node distributes transaction packet fragments and transaction packet headers to other nodes in the form of erasure coding. The nodes that receive the fragments and packet headers can verify whether there is a fork in the transaction packet chain of each node based on the packet header, thereby preventing the forked transaction packets generated by malicious nodes from being successfully broadcast. Attached Figure Description

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

[0022] Figure 1 This is a diagram of a blockchain architecture in one embodiment;

[0023] Figure 2This is a schematic diagram of the consensus process in the PBFT consensus algorithm;

[0024] Figure 3 This is a flowchart of a transaction distribution method in a blockchain as described in the embodiments of this specification;

[0025] Figure 4 This is a schematic diagram of the batch chains generated by each node in the embodiments of this specification;

[0026] Figure 5 This is a schematic diagram illustrating the process of a node broadcasting a fragment to other nodes in an embodiment of this specification;

[0027] Figure 6 A flowchart of the consensus method in the blockchain as described in the embodiments of this specification;

[0028] Figure 7 This is an architecture diagram of the first node in a blockchain according to an embodiment of this specification;

[0029] Figure 8 This is an architecture diagram of a second node in a blockchain according to an embodiment of this specification. Detailed Implementation

[0030] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0031] Figure 1 A blockchain architecture diagram from one embodiment is shown. Figure 1 The blockchain architecture diagram shown indicates that the blockchain includes N nodes. Figure 1 The diagram illustrates nodes 1 through 8. The lines connecting the nodes schematically represent P2P (Peer-to-Peer) connections, such as TCP connections, used for data transfer between nodes. These nodes can store the entire ledger, i.e., the state of all blocks and all accounts. Each node in the blockchain can produce the same state by executing the same transactions, and each node can store the same state database.

[0032] In the blockchain field, a transaction refers to a unit of task executed and recorded within the blockchain. A transaction typically includes a From field, a To field, and a Data field. Specifically, in the case of a transfer transaction, the From field represents the account address initiating the transaction (i.e., initiating a transfer task to another account), the To field represents the account address receiving the transaction (i.e., receiving the transfer), and the Data field includes the transfer amount.

[0033] Blockchain provides the functionality of smart contracts. A smart contract on the blockchain is a contract that can be triggered and executed through transactions within the blockchain system. Smart contracts can be defined in the form of code. Calling a smart contract on the blockchain involves initiating a transaction pointing to the smart contract's address, causing each node in the blockchain to run the smart contract code in a distributed manner.

[0034] In a contract deployment scenario, for example, Bob sends a transaction containing information about creating a smart contract (i.e., deploying the contract) to a server such as... Figure 1 In the blockchain shown, the `data` field of the transaction includes the code (such as bytecode or machine code) of the contract to be created, and the `to` field of the transaction is empty, indicating that the transaction is used to deploy the contract. After the nodes reach an agreement through the consensus mechanism, they determine the contract address "0x6f8ae93…". Each node adds a contract account corresponding to the contract address of the smart contract to the state database, allocates state storage corresponding to the contract account, stores the contract code, and saves the hash value of the contract code in the contract's state storage, thus the contract is successfully created.

[0035] In scenarios where contracts are invoked, for example, Bob sends a transaction to invoke a smart contract, such as... Figure 1 In the blockchain shown, the `from` field of this transaction is the address of the account of the transaction initiator (i.e., Bob), the `to` field is the aforementioned "0x6f8ae93…", which is the address of the smart contract being invoked, and the `data` field of the transaction includes the method and parameters for invoking the smart contract. After consensus is reached on this transaction in the blockchain, each node in the blockchain can execute the transaction, thereby executing the contract separately, and updating the state database based on the execution of the contract.

[0036] One of the decentralized characteristics that distinguishes blockchain technology from traditional technologies is its distributed ledger system, where records are kept on multiple nodes, rather than a centralized system. For a blockchain system to become a robust, publicly accessible, and tamper-proof decentralized system of honest and trustworthy data records, it needs to ensure the security, clarity, and irreversibility of distributed data records in the shortest possible time. In different types of blockchain networks, consensus algorithms are typically used to maintain consistency across the nodes recording the ledger—the consensus mechanisms mentioned earlier. For example, blockchain nodes can implement block-level consensus mechanisms. After a node (e.g., a unique node) generates a block, if this block is recognized by other nodes, those nodes record the same block. As another example, blockchain nodes can implement transaction-level consensus mechanisms. After a node (e.g., a unique node) acquires a blockchain transaction, if this transaction is recognized by other nodes, each node that recognized the transaction can add it to its own latest maintained block, ultimately ensuring that all nodes produce the same latest block. A consensus mechanism is a mechanism by which blockchain nodes reach a unified consensus on block information (or block data), ensuring that the latest block is accurately added to the blockchain. Current mainstream consensus mechanisms include Proof of Work (POW), Proof of Stake (POS), Delegated Proof of Stake (DPoS), and Practical Byzantine Fault Tolerance (PBFT). In various consensus algorithms, consensus on a proposal is typically determined after a predetermined number of nodes reach agreement on the data to be agreed upon. Specifically, in the PBFT algorithm, for 3(f+1)+1>N≥3f+1 consensus nodes, f malicious nodes can be tolerated. That is, consensus is considered successful when at least 2f+1 of the N consensus nodes reach agreement.

[0037] Figure 2 This is a schematic diagram of the consensus process in the PBFT consensus algorithm. Figure 2As shown, according to the PBFT consensus algorithm, the consensus process can be divided into four phases: Request, Pre-Prepare (PP), Prepare (P), and Commit (C). Assume a blockchain includes four consensus nodes: n1 to n4. Node n1 is, for example, the master node, and nodes n2 to n4 are, for example, slave nodes. According to the PBFT algorithm, f=1 malicious nodes can be tolerated among nodes n1 to n4. Specifically, in the Request phase, blockchain users can send requests to node n1 through their user devices. These requests can be, for example, in the form of blockchain transactions. In the Pre-Prepare phase, after receiving multiple transactions from one or more user devices, node n1 can package these transactions into a consensus proposal and send the consensus proposal, along with its signature, to other consensus nodes (i.e., nodes n2 to n4) for block generation. The consensus proposal may include information such as the transaction bodies and the submission order of the transactions. In the Prepare phase, each slave node can sign the consensus proposal and send it to the other nodes. Assuming node n4 is a malicious node, after nodes n1, n2, and n3 receive signatures of the consensus proposal from 2f = 2 other consensus nodes, they can determine that the preparation phase is complete and can proceed to the commit phase. For example, if... Figure 2 As shown, after receiving the signatures from nodes n2 and n3, node n1 verifies that both signatures are correct for the consensus proposal, thus determining that the preparation phase is complete. Similarly, after receiving and verifying the signatures from node n3 and node n1 (from the preparation phase), node n2 determines that the preparation phase is complete. In the commit phase, each consensus node signs the consensus proposal and sends it to the other consensus nodes. Each consensus node, after receiving the commit phase signatures from 2f = 2 other consensus nodes, determines that the commit phase is complete and consensus is successful. For example, after receiving and verifying the commit phase signatures from nodes n2 and n3, node n1 determines that the commit phase is complete. Therefore, node n1 can execute the multiple transactions according to the consensus proposal, update the world state based on the execution results of the multiple transactions, generate and store a block including the multiple transactions (e.g., block B1), and return the execution results of the multiple transactions to the user device. Similarly, after determining that the commit phase is complete, nodes n2 and n3 execute the multiple transactions, update the world state based on the execution results of the multiple transactions, and generate and store a block. Through the above process, storage consistency is achieved among nodes n1, n2, and n3. In other words, even with the presence of a malicious node, nodes n1 through n4 can still achieve successful consensus on the consensus proposal and complete the execution of the block.

[0038] As mentioned above, consensus in a blockchain requires reaching agreement on a large number of transactions. If a consensus proposal includes multiple transactions to be agreed upon, the large data volume of the proposal results in a significant bandwidth load on the master node when sending it, thus substantially impacting consensus performance. In one related technology, the master node replaces the transactions in the block with their hash values ​​when transmitting the block. However, in this technology, the bandwidth consumption for transmitting the consensus proposal is still linearly related to the number of transactions in the block; when there are many transactions in the block, the bandwidth load on the consensus proposal remains high.

[0039] This specification provides a transaction distribution scheme before consensus. Each consensus node distributes transactions in the form of transaction packets before consensus is reached and maintains a transaction packet chain locally. This allows the master node to generate a consensus proposal based on the transaction packet chains maintained by each consensus node, thereby reducing the bandwidth load on the master node when sending consensus proposals. In this scheme, each node distributes transaction packet fragments and packet headers to other nodes in the form of erasure coding. Nodes receiving the fragments and headers can verify whether there are forks in the transaction packet chains of each node based on the headers, thus preventing malicious nodes from successfully broadcasting forked transaction packets. Simultaneously, based on erasure coding technology, the difference in reception progress of the same transaction packet among different nodes is reduced.

[0040] Figure 3 This is a flowchart illustrating a transaction distribution method in a blockchain according to an embodiment of this specification. This method can be executed by multiple nodes in the blockchain, where each node can execute the steps performed by node 1, or node 2, or both simultaneously. In the case where nodes simultaneously execute the steps performed by nodes 1 and 2, each node in the blockchain receives transactions from different clients in parallel, constructs its own transaction pool, and distributes the transactions in its respective pool to other nodes in parallel. The operations of nodes 1 and 2 are described below as examples.

[0041] like Figure 3 As shown, in step S301, node 1 generates a transaction packet Batch (the name of the Batch is, for example, Bth1_5, and hereinafter referred to as Bth1_5), wherein the Batch includes a packet header and a transaction list.

[0042] Node 1 retrieves several transactions from its transaction pool and generates Bth1_5 based on these transactions. Specifically, Bth1_5 may include a header and a body. The body includes a list of the transactions, and the header includes field information for several fields. The header at least includes the hash value of the header of the previous batch generated by Node 1 and the hash value corresponding to the transaction list. The hash value corresponding to the transaction list is, for example, the root hash value of the Merkle tree formed by multiple transactions in the list (hereinafter referred to as the Merkle root hash value), used for verifying these transactions.

[0043] By including the hash value of the previous batch's header in the packet header, multiple batches generated by a node form a sequentially connected batch chain. Other nodes can then verify whether the latest batch has forked based on the packet headers of each batch in this chain, thereby verifying whether the newly generated batch meets the requirements.

[0044] By including the hash value corresponding to the transaction list in the Batch header, the Batch header is associated with several transactions included in the Batch, so the hash value of the header can also be used to verify whether the transactions in the Batch are consistent.

[0045] In one implementation, the header of Bth1_5 may also include the batch height of Bth1_5 in the batch chain.

[0046] Each node in the blockchain can generate its own batch chain, just like node 1. Figure 4 This is a schematic diagram of the batch chains generated by each node in the embodiments of this specification. Figure 4 As shown, in each batch chain, the subsequent batch is connected to the previous batch through the packet header hash value of the previous batch included in the packet header.

[0047] In the case of parallel transaction distribution across nodes, the Bth1_5 packet header may also include the length of the batch chain generated by other nodes received by the node that generated the batch.

[0048] In addition, as described in the embodiments of this specification, node 1 can also distribute Bth1_5 in the form of multiple fragments, so that the packet header of Bth1_5 can also include the hash values ​​of all fragments corresponding to Bth1_5, such as Merkle root hash values.

[0049] Additionally, the header of Bth1_5 can also include node 1's signature on the other contents of the header.

[0050] Table 1 is a schematic diagram of the data structure of the Batch header in the embodiments of this specification.

[0051] Tx Merkle Root Batch Height Batch Tips List Slice Merkle Root Signature

[0052] Table 1

[0053] The batch header may include the six fields shown in Table 1. The Previous Batch Hash corresponds to the header hash of the previous batch in the batch chain generated by node 1, where the header hash is the hash of all data included in the header (e.g., the data corresponding to Table 1). Tx Merkle Root corresponds to the Merkle root hash of the transaction list included in the batch; Batch Height corresponds to the height of this batch in the batch chain generated by node 1; Batch Tip List corresponds to the length of each batch chain obtained by node 1; Slice Merkle Root corresponds to the Merkle root hash of the multiple slices corresponding to this batch; and Signature corresponds to the signature of node 1 for the first five items in Table 1.

[0054] In step S303, node 1 generates n fragments of Batch.

[0055] Assume a blockchain comprises n consensus nodes, where 3(f+1)+1>n≥3f+1, meaning that at most f malicious nodes can be included among the n consensus nodes. In this case, 3f+1 shards can be generated based on, for example, Bth1_5 as described above, for distributing the batch. Specifically, node 1 divides Bth1_5 into 2f+1 data blocks. Then, based on the erasure coding algorithm, f encoded blocks can be generated from these 2f+1 data blocks. Both the 2f+1 data blocks and the f encoded blocks can be considered shards of Bth1_5, resulting in a total of 3f+1 shards of Bth1_5. According to the erasure coding algorithm, each consensus node can recover Bth1_5 after receiving at least 2f+1 shards.

[0056] In step S305, node 1 sends the packet header and fragments of Bth1_5 to node 2.

[0057] After generating 3f+1 fragments of Bth1_5, Node 1 can send these 3f+1 fragments to 3f+1 of the n consensus nodes, and send the header of Bth1_5 to each of these 3f+1 nodes. Specifically, Node 1 can send the header of Bth1_5 and, for example, fragment slice2 from the 3f+1 fragments to Node 2.

[0058] Figure 5This diagram illustrates the process of a node broadcasting a shard to other nodes in an embodiment of this specification. Taking a blockchain including nodes n1-n4 as an example, where n=4 and f=1, node n1 generates a batch of 4 shards (e.g., s). n1 s n2 s n3 and s n4 After that, Figure 5 The first stage on the left side will, for example, be a fragment s. n2 Send to node n2, and send the shard s n3 Send to node n3, and send the shard s n4 Send to node n4. Figure 5 In the second stage on the right side, node n2 can receive the fragment s from node n1. n2 The data is sent to nodes n3 and n4 respectively. Node n3 can then process the fragments s received from node n1. n3 The data is sent to nodes n2 and n4 respectively. Node n4 can then process the fragments s received from node n1. n4 It is sent to nodes n2 and n3 respectively. In addition, node n1 will also send data to its corresponding shard s. n1 Send them to nodes n2, n3, and n4 respectively.

[0059] In this way, when the batch is large, the node that generates the batch only needs to distribute 3f+1 fragments to other consensus nodes. Other nodes that receive the fragments broadcast the fragments to each other, which can spread the transmission delay of the batch generated by the node, so that the progress of all consensus nodes receiving the batch will not be significantly different.

[0060] refer to Figure 5 For example, node 1 can similarly generate 3f+1 fragments s1-sm, m=3f+1 based on Bth1_5, and send fragments s1 and s2 to node 2 in association with the packet header of Bth1_5.

[0061] In step S307, node 2 verifies the fragment based on the packet header associated with the fragment.

[0062] After receiving the packet header and fragment s2 of Bth1_5, Node 2 verifies fragment s2. Specifically, Node 2 can determine whether it has received all fragments corresponding to Node 2 whose batch height is lower than that of Bth1_5, based on the Previous Batch Hash field or Batch Height field in the packet header of Bth1_5. If not, Node 2 temporarily stores fragment s2 and requests the missing fragment from Node 1.

[0063] If the above conditions are met, node 2 obtains the fragment of the previous batch (i.e., Bth1_4) of Bth1_5 and the header of Bth1_4, and determines whether the hash value of the header of Bth1_4 is consistent with the Previous Batch Hash in Bth1_5. If they are consistent, the verification of fragment s2 continues. If they are inconsistent, the verification is determined to be unsuccessful and the verification process is terminated.

[0064] If the packet header hash of Bth1_4 matches the Previous Batch Hash in Bth1_5, node 2 determines whether it has received fragment s2′. The Previous Batch Hash in the packet header associated with fragment s2′ is the same as that of fragment s2, but the hash value of the packet header associated with fragment s2′ is different from that of fragment s2. If node s2 determines that it has received fragment s2′, then fragment s2 is considered an invalid fragment. If node s2 determines that it has not received fragment s2′, then fragment s2 is considered valid.

[0065] In one implementation, where the header also includes the signature of node 1, node 2 may first verify whether the signature of node 1 is correct after the verification begins.

[0066] In one implementation, node 1 sends the header of Bth1_5 and shard s2 to node 2 along with the Merkle proof data for shard s2. This Merkle proof data includes, for example, the hash values ​​of each node associated with the path from the leaf node of shard s2 to the root node of the shard Merkle tree. The root hash value of the shard Merkle tree can be calculated based on the hash value of shard s2 and the Merkle proof data for shard s2. This calculated root hash value can be verified using the Slice Merkle Root field in the header of Bth1_5. If they match, further verification of shard s2 can proceed; otherwise, shard s2 is deemed non-compliant.

[0067] After receiving the header and fragment s1 of Bth1_5, node 2 can verify fragment s1 in a similar manner to fragment s2.

[0068] In step S309, if all the above verifications of the shards pass, node 2 stores the shards for use in recovering transaction packet Bth1_5.

[0069] For s2, node 2 can be as follows: Figure 5 As shown, shard s2 is broadcast to all consensus nodes except node 1.

[0070] For s1, if the verification is successful, Node 2 does not need to broadcast s1 to other consensus nodes when determining that s1 corresponds to Node 1.

[0071] Each consensus node can recover transaction packet Bth1_5 once it receives at least 2f+1 compliant fragments. After recovering transaction packet Bth1_5, the consensus node can also verify whether the Tx Merkle Root in the header of transaction packet Bth1_5 matches the Merkle root hash value of the transaction list included in transaction packet Bth1_5. If they do not match, it can be confirmed that transaction packet Bth1_5 does not meet the requirements.

[0072] By verifying the shards of a batch based on the packet header as described above, honest nodes will not forward contradictory shards (such as s2 and s2′ mentioned above), thus preventing consensus nodes from correctly recovering the forked batch and avoiding malicious nodes from creating forks on the batch chain.

[0073] Figure 6 This is a flowchart of the consensus method in the blockchain as described in the embodiments of this specification.

[0074] like Figure 6 As shown, firstly, in step S601, the master node generates a consensus proposal based on the Batch chain information obtained by each consensus node. The consensus proposal includes the packet headers of multiple Batches in each Batch chain.

[0075] refer to Figure 4 Each consensus node generates its own batch chain and distributes each batch it generates to other consensus nodes through sharding. Due to factors such as network latency, the batch chains obtained locally by each consensus node may be inconsistent.

[0076] Assuming Node 1 is the master node, while sending its generated batch fragments and headers to other consensus nodes as described above, Node 1 also receives batch fragments and headers generated by other consensus nodes. For example, it receives the header and fragments of Bth2_5 from Node 2. The Batch Tip List field in the Bth2_5 header indicates the height of each batch chain obtained by Node 2. Similarly, as shown in Table 2, Node 1 can obtain the heights (i.e., Batch Tip Lists) of each batch chain obtained by other consensus nodes:

[0077] Node 1 [1:5,2:5,3:5,4:5] Node 2 [1:5,2:5,3:4,4:3] Node 3 [1:3,2:4,3:5,4:5] Node 4 [1:3,2:3,3:4,4:5] … …

[0078] Table 2

[0079] In Table 2, taking node 2 as an example, the ratio 1:5 in [1:5, 2:5, 3:4, 4:3] indicates that the highest height of the batch received by node 2 from the batch chain generated by node 1 is 5. Node 1 can split the batches in each batch chain according to the batch chains obtained by each node in Table 2 to generate a consensus proposal.

[0080] In one implementation, node 1 can split a batch chain according to the minimum progress of each consensus node. For example, as shown in Table 2, Bth1_1 to Bth1_3 from the batch chain generated by node 1 are included in the consensus proposal.

[0081] In another implementation, node 1 can divide the consensus chain based on the reception progress of a batch chain reached by 2f+1 nodes among multiple consensus nodes. For example, as shown in Table 2, in the case where the blockchain only includes four nodes, nodes 1 to 4, three of the four nodes have obtained the first four batches in the batch chain corresponding to node 2. Therefore, Bth2_1 to Bth2_4 in the batch chain generated by node 2 are included in the consensus proposal.

[0082] The consensus proposal includes the header of each proposed batch, the Merkle root hash of all transactions in all proposed batches, and the master node's signature on the above two items.

[0083] In step S603, the master node sends the consensus proposal to each slave node.

[0084] Specifically, see reference Figure 2 During the preparation phase, the master node sends the consensus proposal to each slave node. Afterwards, the master node performs the preparation and commit phases of the consensus process.

[0085] In step S605, the slave node verifies the consensus proposal based on the batch chain of each consensus node stored locally in order to reach a consensus.

[0086] During the preparation phase, after receiving the consensus proposal from the master node, the slave node determines whether it has stored all the batches included in the consensus proposal locally. If not, it requests the batch from other consensus nodes. If it does, it assembles the transactions from all the batches included in the consensus proposal, calculates the Merkle root hash of all transactions, and determines whether the calculated Merkle root hash matches the Merkle root hash of all transactions in the consensus proposal. If they match, it verifies the master node's signature. If the verification passes, it enters the preparation phase of the consensus process.

[0087] In the scheme of the embodiments of this specification, transaction distribution is based on the data structure of multiple batch chains and erasure coding technology, so that transaction distribution is not required in the consensus stage. Furthermore, the consensus proposal includes a batch header to indicate the proposed transactions, which greatly reduces the data volume of the consensus proposal and thus improves consensus performance.

[0088] Figure 7 This is an architecture diagram of a first node in a blockchain system according to an embodiment of this specification. The blockchain also includes n-1 second nodes, where n is equal to or greater than 3f+1, and f is the maximum number of malicious nodes allowed by the blockchain system. The first node includes:

[0089] Acquisition unit 71 is used to acquire multiple transactions from the transaction pool;

[0090] The generation unit 72 is configured to generate a first transaction packet based on the plurality of transactions. The first transaction packet includes a first packet header and the plurality of transactions. The first packet header includes the packet header hash value of the previous transaction packet generated by the first node and the first hash value corresponding to the plurality of transactions. Based on the first transaction packet, 3f+1 fragments are generated. The 3f+1 fragments include 2f+1 data blocks obtained by dividing the first transaction packet and f encoded blocks generated based on the 2f+1 data blocks.

[0091] The sending unit 73 is used to provide the 3f+1 fragments to 3f+1 of the n nodes respectively, and to provide the first packet header to each of the 3f+1 nodes.

[0092] Figure 8 This is an architecture diagram of a second node in a blockchain system according to an embodiment of this specification. The blockchain system includes a first node and n-1 second nodes, where n is equal to or greater than 3f+1, and f is the maximum number of malicious nodes allowed in the blockchain system. The second node includes:

[0093] The receiving unit 81 is configured to receive from the first node a first packet header and a first fragment from 3f+1 fragments of a first transaction packet. The first transaction packet also includes multiple transactions received by the first node. The first packet header includes the packet header hash value of the previous transaction packet generated by the first node and the first hash value corresponding to the multiple transactions. The 3f+1 fragments include 2f+1 data blocks obtained by dividing the first transaction packet and f encoded blocks generated based on the 2f+1 data blocks.

[0094] Verification unit 82 is used to verify the first fragment based on the first packet header;

[0095] Storage unit 83 is used to store the first fragment for use in restoring the first transaction packet if the first fragment verification is successful.

[0096] This specification also provides a computer-readable storage medium storing a computer program thereon, which, when executed in a computer, causes the computer to perform actions such as... Figure 3 or Figure 6 The method shown.

[0097] This specification also provides a blockchain node, including a memory and a processor. The memory stores executable code, and when the processor executes the executable code, it implements... Figure 3 or Figure 6 The method shown.

[0098] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0099] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0100] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or physical entities, or by products with certain functions. A typical implementation device is a server system. Of course, this application does not exclude the possibility that, with the future development of computer technology, the computer implementing the functions of the above embodiments can be, for example, a personal computer, a laptop computer, an in-vehicle human-machine interaction device, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0101] While one or more embodiments of this specification provide the operational steps of the methods described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive means. The order of steps listed in the embodiments is merely one possible order of execution among many steps and does not represent the only possible order. In actual device or end product execution, the methods shown in the embodiments or drawings may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitations, the presence of other identical or equivalent elements in the process, method, product, or apparatus that includes the elements is not excluded. For example, the use of terms such as "first," "second," etc., is to denote names and does not indicate any particular order.

[0102] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, when implementing one or more of these specifications, the functions of each module can be implemented in one or more software and / or hardware components, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.

[0103] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0104] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0105] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0106] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0107] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0108] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0109] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0110] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In a distributed computing environment, program modules can reside in local and remote computer storage media, including storage devices.

[0111] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, system embodiments are basically similar to method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. In the description of this specification, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0112] The above description is merely an embodiment of one or more embodiments of this specification and is not intended to limit the scope of this specification. Various modifications and variations can be made to the one or more embodiments of this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims.

Claims

1. A transaction distribution method in a blockchain system, wherein the blockchain system includes a first node and n-1 second nodes, wherein, n is equal to or greater than 3f+1, where f is the maximum number of malicious nodes allowed in the blockchain system, and the method includes: The first node retrieves multiple transactions from the transaction pool; based on the multiple transactions, it generates a first transaction packet, the first transaction packet including a first packet header and the multiple transactions, the first packet header including the packet header hash value of the previous transaction packet generated by the first node and the first hash value corresponding to the multiple transactions; based on the first transaction packet, it generates 3f+1 shards, the 3f+1 shards including 2f+1 data blocks obtained by dividing the first transaction packet, and f encoded blocks generated based on the 2f+1 data blocks; the 3f+1 shards are respectively provided to 3f+1 nodes out of the n nodes, and the first packet header is provided to each of the 3f+1 nodes; the 3f+1 shards are used for broadcasting among the 3f+1 nodes to distribute the first transaction packet before consensus; The second node among the n-1 second nodes that obtains the first fragment of the 3f+1 fragments verifies the first fragment based on the packet header hash value of the previous transaction packet in the first packet header; if the verification of the first fragment is successful, the first fragment is stored for use in restoring the first transaction packet.

2. The method according to claim 1, wherein verifying the first fragment based on the packet header hash value of the previous transaction packet in the first packet header includes: Determine whether the header hash value of the previous transaction packet in the first packet header is consistent with the header hash value of the second transaction packet, wherein the second transaction packet is the previous transaction packet of the first transaction packet; In cases of inconsistency, the verification of the first fragment is deemed unsuccessful.

3. The method according to claim 2, wherein verifying the first fragment based on the packet header hash value of the previous transaction packet in the first packet header further includes: In cases where the hash value of the header of the previous transaction packet in the first packet header is consistent with the hash value of the header of the second transaction packet, it is determined whether there is a second fragment, wherein the header of the transaction packet corresponding to the second fragment is consistent with the hash value of the header of the previous transaction packet included in the first packet header, and the hash value of the transaction packet corresponding to the second fragment is inconsistent with the hash value of the first packet header. If the second fragment exists, it is determined that the verification of the first fragment fails.

4. The method according to claim 1, wherein the first packet header further includes at least one of the following: the transaction packet height of the first transaction packet in the transaction packet chain generated by the first node, the length of the transaction packet chains generated by each of the other nodes received by the first node, and the second hash value corresponding to the 3f+1 shards.

5. The method according to claim 1 or 4, wherein the first packet header further includes a digital signature of the first node, the digital signature being a signature of other data included in the first packet header, and the method further includes: The second node that obtains the first shard uses the public key of the first node to verify the signature.

6. The method according to claim 4, wherein the first packet header includes the second hash value, the second hash value being the Merkle hash value of the 3f+1 shards, and the step of providing the 3f+1 shards to the 3f+1 nodes among the n nodes includes: The 3f+1 shards and the Merkel proof data corresponding to each shard are respectively provided to 3f+1 of the n nodes; The method further includes: the second node that obtains the first shard verifies the first shard based on the Merkel hash value and the Merkel proof data.

7. The method according to claim 4, wherein the first node and the n-1 second nodes are consensus nodes, the first node is the master node, and the method further comprises: The first node receives from each of the second nodes the length of the transaction packet chain corresponding to each consensus node; Based on the lengths of the n transaction packet chains corresponding to the n consensus nodes obtained by each of the second nodes, a consensus proposal is generated. The consensus proposal includes the packet headers of multiple transaction packets in the n transaction packet chains, the third hash values ​​of all transactions corresponding to the multiple transaction packets, and the signatures of the master node on the packet headers and the third hash values ​​of the multiple transaction packets. The consensus proposal is sent to each of the second nodes to reach a consensus on the consensus proposal.

8. A transaction distribution method in a blockchain system, wherein the blockchain system includes a first node and n-1 second nodes, wherein, n is equal to or greater than 3f+1, where f is the maximum number of malicious nodes allowed in the blockchain system, and the method is executed by any of the second nodes, including: The first transaction packet is received from the first node, which receives a first packet header and a first fragment from 3f+1 fragments. The first transaction packet also includes multiple transactions received by the first node. The first packet header includes the packet header hash value of the previous transaction packet generated by the first node and the first hash values ​​corresponding to the multiple transactions. The 3f+1 fragments include 2f+1 data blocks obtained by dividing the first transaction packet and f encoded blocks generated based on the 2f+1 data blocks. The 3f+1 fragments are used for broadcasting among the n-1 second nodes that have obtained the 3f+1 fragments to distribute the first transaction packet before consensus. The first fragment is verified based on the packet header hash value of the previous transaction packet in the first packet header; If the first fragment passes verification, the first fragment is stored for use in restoring the first transaction packet.

9. The method according to claim 8, further comprising: If it is determined that the first fragment corresponds to any of the second nodes, the first fragment is sent to each of the other second nodes respectively.

10. The method of claim 9, further comprising: The system receives fragments of the first transaction packet corresponding to the other second nodes from the other second nodes. After determining that at least 2f+1 fragments of the first transaction packet have been received, the system generates the first transaction packet based on the at least 2f+1 fragments.

11. The method according to claim 8, wherein verifying the first fragment based on the packet header hash value of the previous transaction packet in the first packet header comprises: Determine whether the header hash value of the previous transaction packet in the first packet header is consistent with the header hash value of the second transaction packet, wherein the second transaction packet is the previous transaction packet of the first transaction packet; In cases of inconsistency, the verification of the first fragment is deemed unsuccessful.

12. The method according to claim 11, wherein verifying the first fragment based on the packet header hash value of the previous transaction packet in the first packet header further comprises: In cases where the hash value of the header of the previous transaction packet in the first packet header is consistent with the hash value of the header of the second transaction packet, it is determined whether there is a second fragment, wherein the header of the transaction packet corresponding to the second fragment is consistent with the hash value of the header of the previous transaction packet included in the first packet header, and the hash value of the transaction packet corresponding to the second fragment is inconsistent with the hash value of the first packet header. If the second fragment exists, it is determined that the verification of the first fragment fails.

13. The method according to claim 11, wherein the first packet header further includes a digital signature of the first node, the digital signature being a signature of other data included in the first packet header, and the method further includes: The signature is verified using the public key of the first node.

14. The method according to claim 11, wherein the first packet header further includes Merkle hash values ​​corresponding to the 3f+1 fragments, and the method further includes: Receive Merkel proof data corresponding to the first fragment from the first node; The first shard is verified based on the Merkel hash value and the Merkel proof data.

15. The method according to claim 8, wherein the first node is the master node, and the method further comprises: The consensus proposal is received from the first node. The consensus proposal includes the headers of multiple transaction packets in the n transaction packet chains corresponding to the n consensus nodes, the third hash value of all transactions corresponding to the multiple transaction packets, and the signatures of the headers and the third hash values ​​of the multiple transaction packets by the first node. The consensus proposal is verified based on the n transaction packets corresponding to the n consensus nodes stored locally.

16. A blockchain system, the blockchain system comprising a first node and n-1 second nodes, wherein, n is equal to or greater than 3f+1, where f is the maximum number of malicious nodes allowed in the blockchain system. The first node is used for: obtaining multiple transactions from the transaction pool; generating a first transaction packet based on the multiple transactions, the first transaction packet including a first packet header and the multiple transactions, the first packet header including the packet header hash value of the previous transaction packet generated by the first node and the first hash value corresponding to the multiple transactions; generating 3f+1 shards based on the first transaction packet, the 3f+1 shards including 2f+1 data blocks obtained by dividing the first transaction packet and f encoded blocks generated based on the 2f+1 data blocks; providing the 3f+1 shards to 3f+1 nodes out of the n nodes respectively, and providing the first packet header to each of the 3f+1 nodes; the 3f+1 shards are used for broadcasting among the 3f+1 nodes to distribute the first transaction packet before consensus; The second node among the n-1 second nodes that obtains the first fragment among the 3f+1 fragments is used to: verify the first fragment according to the packet header hash value of the previous transaction packet in the first packet header; if the verification of the first fragment is successful, store the first fragment for use in restoring the first transaction packet.

17. A second node in a blockchain system, the blockchain system comprising a first node and n-1 second nodes, wherein, n is equal to or greater than 3f+1, where f is the maximum number of malicious nodes allowed in the blockchain system, and the second node includes: The receiving unit is configured to receive from the first node a first transaction packet's first header and a first fragment from 3f+1 fragments. The first transaction packet also includes multiple transactions received by the first node. The first header includes the header hash value of the previous transaction packet generated by the first node and first hash values ​​corresponding to the multiple transactions. The 3f+1 fragments include 2f+1 data blocks obtained by dividing the first transaction packet and f encoded blocks generated based on the 2f+1 data blocks. The 3f+1 fragments are used for broadcasting among the n-1 second nodes that have obtained the 3f+1 fragments to distribute the first transaction packet before consensus. The verification unit is used to verify the first fragment based on the first packet header; A storage unit is used to store the first fragment for use in restoring the first transaction packet if the first fragment is verified to be valid.

18. A blockchain node comprising a memory and a processor, wherein the memory stores executable code, and the processor, when executing the executable code, implements the method of any one of claims 8-15.

Images