Block chain processing method, related device and medium

Abstract

The invention provides a block chain processing method, a related device and a medium. The method comprises the following steps: acquiring a target block to be recorded on a block chain; determining that the target block chain node is a non-full storage node of the target block based on a predetermined non-full storage node determination rule; storing partial data of the target block at the target block chain node; and in response to a received block acquisition request of the target block, acquiring the target block from a full-amount storage node in the block chain network, and verifying the acquired target block by using the target block verification data, the full-amount storage node being a block chain node storing all data of the target block. According to the embodiment of the invention, occupation of a storage space in a block chain network can be reduced on the premise that the data security of the block chain is not reduced. The embodiment of the invention is applied to the scenes of newly adding the block in the block chain network, querying the block in the block chain network and the like.

Description

Technical Field

[0001] This disclosure relates to the field of blockchain technology, and in particular to a blockchain processing method, related apparatus and medium. Background Technology

[0002] A blockchain network is a distributed structure containing a large number of blockchain nodes. Each blockchain node maintains the same blockchain in its own storage space. That is, for every new block added to the blockchain, the storage space of all blockchain nodes in the network must be increased by the same block, consuming a significant amount of storage space. It is generally believed that only when each blockchain node maintains the complete set of blockchain data can the blockchain data be verified, thereby ensuring blockchain data security. Summary of the Invention

[0003] This disclosure provides a blockchain processing method, related apparatus, and medium that can reduce the storage space occupied in the blockchain network without compromising the security of blockchain data.

[0004] According to one aspect of this disclosure, a blockchain processing method is provided, executed by a target blockchain node in a blockchain network, the blockchain processing method comprising:

[0005] Retrieve the target block to be recorded on the blockchain;

[0006] Based on the predetermined non-full storage node determination rules, the target blockchain node is determined to be a non-full storage node of the target block, wherein the non-full storage node is a blockchain node that only stores a portion of the data of the target block, and the portion of data includes the target block verification data;

[0007] The target blockchain node stores the portion of data from the target block.

[0008] In response to receiving a block retrieval request for the target block, the target block is retrieved from the full storage node in the blockchain network, and the retrieved target block is verified using the target block verification data, wherein the full storage node is a blockchain node that stores all the data of the target block.

[0009] According to one aspect of this disclosure, a blockchain data processing apparatus is provided, the blockchain processing apparatus being located at a target blockchain node in a blockchain network, the blockchain processing apparatus comprising:

[0010] The acquisition unit is used to acquire the target block to be recorded on the blockchain.

[0011] The first determining unit is used to determine, based on a predetermined non-full storage node determining rule, that the target blockchain node is a non-full storage node of the target block, wherein the non-full storage node is a blockchain node that only stores a portion of the data of the target block, and the portion of data includes target block verification data;

[0012] The first storage unit is used to store the portion of the data of the target block in the target blockchain node;

[0013] The first verification unit is configured to, in response to receiving a block retrieval request for the target block, retrieve the target block from a full storage node in the blockchain network, and verify the retrieved target block using the target block verification data, wherein the full storage node is a blockchain node that stores all the data of the target block.

[0014] Optionally, the number of blockchain nodes in the blockchain network is 3f+1, where f is a positive integer;

[0015] The first determining unit is specifically used for:

[0016] Based on the predetermined rules for determining non-full storage nodes, the starting non-full storage node is determined in the blockchain network;

[0017] In the blockchain network, 2f blockchain nodes are counted starting from the initial non-full storage node;

[0018] If the target blockchain node belongs to the 2f blockchain nodes, the target blockchain node is determined to be the non-full storage node of the target block.

[0019] Optionally, the first determining unit is further configured to:

[0020] Obtain the target block height of the target block;

[0021] The blockchain node index is determined based on the remainder of the target block height modulo a first number, wherein the first number is the number of blockchain nodes in the blockchain network.

[0022] The blockchain node corresponding to the blockchain node index in the blockchain network is determined as the starting non-full storage node.

[0023] Optionally, there may be multiple full storage nodes;

[0024] The first verification unit is specifically used for:

[0025] Obtain the channel status between each full storage node and the target blockchain node;

[0026] Based on the channel state, the target full storage node is determined from each full storage node;

[0027] The target block is obtained from the target full storage node.

[0028] Optionally, the target block verification data includes a first target block digest value;

[0029] The first verification unit is specifically used for:

[0030] Calculate the total transaction digest value of each transaction in the target block obtained;

[0031] Calculate the overall state data summary value of each transaction in the target block;

[0032] Based on the total transaction digest value, the total status data digest value, and the full block header data in the target block, calculate the second target block digest value of the target block;

[0033] The obtained target block is verified by comparing the first target block digest value with the second target block digest value.

[0034] Optionally, the target block verification data includes information about the first on-chain initiating node;

[0035] The first verification unit is further configured to:

[0036] If the first target block digest value is consistent with the second target block digest value, extract the second on-chain initiating node information from the obtained target block;

[0037] The target block is verified by comparing the information of the first on-chain initiating node with the information of the second on-chain initiating node.

[0038] Optionally, the first verification unit is further configured to:

[0039] If the information of the first on-chain initiating node is consistent with the information of the second on-chain initiating node, obtain the first signature reserved by the on-chain initiating node;

[0040] Extract the second signature of the on-chain initiating node from the obtained target block;

[0041] The obtained target block is verified based on the comparison between the first signature and the second signature.

[0042] Optionally, the first verification unit is further configured to:

[0043] Calculate the transaction digest value of each transaction in the target block;

[0044] Generate a transaction summary tree, wherein the bottom-level nodes of the transaction summary tree are the transaction summary values ​​of each transaction, and the order of the transaction summary values ​​is consistent with the order of the transactions in the target block. The other nodes in the transaction summary tree, except for the bottom-level nodes, are obtained by performing a summary operation on the concatenation of two adjacent nodes at the next lower level of the other nodes, until the root node of the top level is generated.

[0045] Based on the root node, the total transaction summary value is determined.

[0046] Optionally, the first verification unit is further configured to:

[0047] Calculate the state data digest value of each transaction in the target block after execution;

[0048] Generate a state data digest tree, wherein the bottom-level nodes of the state data digest tree are the state data digest values ​​after each transaction is executed, and the other nodes in the state data digest tree are obtained by performing a digest operation on the concatenation of two adjacent nodes at the next lower level of the other nodes, until the root node of the top level is generated.

[0049] Based on the root node, the total state data summary value is determined.

[0050] Optionally, the first storage unit is specifically used for:

[0051] In the target blockchain node, a first key-value pair is stored, wherein the first key-value pair indicates the correspondence between the target block digest value and the target block height;

[0052] In the target blockchain node, a second key-value pair is stored, wherein the second key-value pair indicates the correspondence between the target block height and the key data of the block header, and the key data of the blockchain header contains the target block verification data.

[0053] Optionally, the block retrieval request includes the target digest value of the target block;

[0054] The first verification unit is specifically used for:

[0055] The step of responding to receiving a block retrieval request for the target block, retrieving the target block from the full storage node in the blockchain network, and verifying the retrieved target block using the target block verification data includes:

[0056] The target block height is determined based on the target block digest value and the first key-value pair;

[0057] Obtain the target block at the target block height from the full storage node in the blockchain network;

[0058] Based on the target block height and the second key-value pair, obtain the block header key data, and extract the target block verification data from the block header key data;

[0059] The target block is verified using the target block verification data.

[0060] Optionally, the data may also include target transaction verification data;

[0061] The blockchain processing device further includes:

[0062] The second verification unit is configured to, in response to a transaction retrieval request for a target transaction in the target block, retrieve the target transaction of the target block from the full storage node in the blockchain network, and verify the retrieved target transaction using the target transaction verification data.

[0063] Optionally, the first storage unit is specifically used for:

[0064] The target blockchain node stores a third key-value pair, wherein the third key-value pair indicates the correspondence between the target transaction identifier, the target block height, and the target transaction index.

[0065] Optionally, the transaction acquisition request includes the target transaction identifier of the target transaction;

[0066] The second verification unit is specifically used for:

[0067] Based on the target transaction identifier and the third key-value pair, the target block height and the target transaction index are determined;

[0068] From the full storage node in the blockchain network, obtain the target block at the target block height, and from the target block, obtain the target transaction with the target transaction index;

[0069] The target transaction is verified using the target transaction verification data.

[0070] Optionally, the target transaction verification data includes a first target transaction digest value and a first target transaction status data digest value;

[0071] The first storage unit is specifically used for:

[0072] In the target blockchain node, a fourth key-value pair is stored, wherein the fourth key-value pair indicates the correspondence between the target transaction identifier and the first target transaction digest value;

[0073] The target blockchain node stores a fifth key-value pair, wherein the fifth key-value pair indicates the correspondence between the target transaction identifier and the first target transaction status data digest value.

[0074] Optionally, the second verification unit is specifically used for:

[0075] Based on the target transaction identifier and the fourth key-value pair, obtain the first target transaction digest value;

[0076] Perform a digest operation on the target transaction to obtain a second target transaction digest value;

[0077] Based on the target transaction identifier and the fifth key-value pair, obtain the first target transaction status data digest value;

[0078] Perform a digest operation on the state data after the target transaction is executed to obtain a second target transaction state data digest value;

[0079] The obtained target transaction is verified based on the comparison between the first target transaction digest value and the second target transaction digest value, and the comparison between the first target transaction status data digest value and the second target transaction status data digest value.

[0080] Optionally, the target transaction verification data includes a first target transaction digest value and a first target transaction status data digest value;

[0081] The first storage unit is specifically used for:

[0082] The target blockchain node stores a sixth key-value pair, wherein the sixth key-value pair indicates the correspondence between the target transaction identifier, the first target transaction digest value, and the first target transaction status data digest value.

[0083] Optionally, the second verification unit is specifically used for:

[0084] Based on the target transaction identifier and the sixth key-value pair, obtain the first target transaction digest value and the first target transaction status data digest value;

[0085] Perform a digest operation on the target transaction to obtain a second target transaction digest value;

[0086] Perform a digest operation on the state data after the target transaction is executed to obtain a second target transaction state data digest value;

[0087] The obtained target transaction is verified based on the comparison between the first target transaction digest value and the second target transaction digest value, and the comparison between the first target transaction status data digest value and the second target transaction status data digest value.

[0088] Optionally, the blockchain processing device further includes:

[0089] The second determining unit is used to determine, based on a predetermined non-full storage node determining rule, that the target blockchain node is the full storage node of the target block;

[0090] The second storage unit is used to store the key-value pair table of the target block in the target blockchain node;

[0091] A generation unit is configured to generate the target block using the key-value pair table in response to receiving the block acquisition request for the target block.

[0092] Optionally, the key-value pair table includes a seventh key-value pair and an eighth key-value pair, wherein the seventh key-value pair indicates the correspondence between the target block height and the full data of the block header, and the eighth key-value pair indicates the correspondence between the target block height, the transaction index, and the transaction, and the full data of the block header contains the total number of transactions in the target block;

[0093] The generation unit is specifically used for:

[0094] Based on the block acquisition request, obtain the target block height of the target block;

[0095] Based on the target block height and the seventh key-value pair, obtain the full data of the block header, and extract the total number of transactions from the full data of the block header;

[0096] Based on the total number of transactions, obtain the transactions corresponding to the target block height and each transaction index in the eighth key-value pair;

[0097] The target block is generated based on the target block height and the transactions corresponding to each transaction index.

[0098] Optionally, the key-value pair table further includes a ninth key-value pair, wherein the ninth key-value pair indicates the correspondence between the target block digest value and the target block height; the block acquisition request includes the target block digest value of the target block;

[0099] The generation unit is specifically used for:

[0100] Obtain the target block digest value from the block retrieval request;

[0101] The target block height is determined based on the target block digest value and the ninth key value pair.

[0102] Optionally, the generation unit is further configured to:

[0103] Initialize the index of the transaction to be retrieved to 0;

[0104] The target process is executed iteratively until the transaction index to be obtained is not less than the total number of transactions. The target process includes: obtaining the transaction in the eighth key-value pair whose target block height corresponds to the transaction index to be obtained, and incrementing the transaction index to be obtained by 1.

[0105] Optionally, the key-value pair table further includes a tenth key-value pair, wherein the tenth key-value pair indicates the correspondence between the target block height and the additional information;

[0106] The generation unit is further specifically used for:

[0107] Based on the target block height and the tenth key-value pair, obtain the additional information;

[0108] The target block is generated based on the target block height, the transactions corresponding to each transaction index, and the additional information.

[0109] Optionally, the blockchain processing device further includes:

[0110] The second acquisition unit is used to acquire the target transaction using the key-value pair table in response to receiving a transaction acquisition request for the target transaction in the target block.

[0111] Optionally, the key-value pair includes an eleventh key-value pair and an eighth key-value pair, wherein the eleventh key-value pair indicates the correspondence between the target transaction identifier, the target block height, and the target transaction index, and the eighth key-value pair indicates the correspondence between the target block height, the target transaction index, and the target transaction; the transaction acquisition request includes the target transaction identifier;

[0112] The second acquisition unit is specifically used for:

[0113] Obtain the target transaction identifier from the transaction acquisition request;

[0114] Based on the target transaction identifier and the eleventh key-value pair, obtain the target block height and the target transaction index;

[0115] The target transaction is obtained from the eighth key value based on the target block height and the target transaction index.

[0116] According to one aspect of this disclosure, an electronic device is provided, including a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the blockchain processing method as described above.

[0117] According to one aspect of this disclosure, a computer-readable storage medium is provided, the storage medium storing a computer program that, when executed by a processor, implements the blockchain processing method as described above.

[0118] According to one aspect of this disclosure, a computer program product is provided, comprising a computer program that is read and executed by a processor of a computer device, causing the computer device to perform the blockchain processing method as described above.

[0119] In this embodiment, according to a predetermined rule for determining non-full storage nodes, only a subset of blockchain nodes are full storage nodes for the target block, meaning they store the full data of the target block. The remaining blockchain nodes are non-full storage nodes for the target block, storing only a portion of the target block's data, including target block verification data. This significantly reduces the storage space occupied in the blockchain network. When a non-full storage node receives a block retrieval request for the target block, it retrieves the target block from the full storage nodes in the blockchain network and verifies the retrieved target block using its own stored target block verification data. This ensures blockchain data security while reducing the storage space occupied.

[0120] Other features and advantages of this disclosure will be set forth in the following description and will be apparent in part from the description or may be learned by practicing the disclosure. The objectives and other advantages of this disclosure may be realized and obtained by means of the structures particularly pointed out in the description, claims and drawings. Attached Figure Description

[0121] The accompanying drawings are provided to further understand the technical solutions of this disclosure and constitute a part of the specification. They are used together with the embodiments of this disclosure to explain the technical solutions of this disclosure and do not constitute a limitation on the technical solutions of this disclosure.

[0122] Figure 1 This is an architecture diagram of the system to which the blockchain processing method according to embodiments of this disclosure is applied;

[0123] Figure 2A This is a schematic diagram of the blockchain processing method according to embodiments of the present disclosure in the scenario of adding a new block in a blockchain network;

[0124] Figure 2BThis is a schematic diagram illustrating a scenario where the blockchain processing method according to embodiments of this disclosure queries blocks in a blockchain network.

[0125] Figure 3 This is a main flowchart of a blockchain processing method according to embodiments of the present disclosure;

[0126] Figure 4 This is a schematic diagram of the blockchain of each node in a blockchain network according to an embodiment of the present disclosure;

[0127] Figure 5 This is a flowchart of a blockchain processing method according to an embodiment of the present disclosure;

[0128] Figure 6 yes Figure 3 Step 320 is a flowchart of determining that the target blockchain node is a non-full storage node of the target block;

[0129] Figure 7 yes Figure 6 Step 610 is a flowchart of determining the starting non-full storage node in the blockchain network;

[0130] Figure 8 yes Figure 3 A flowchart of step 330 storing partial data of the target block;

[0131] Figure 9A This is a schematic diagram of the full block header data and partial block header data according to an embodiment of the present disclosure;

[0132] Figure 9B This is a schematic diagram of the storage structure corresponding to the block header data according to an embodiment of the present disclosure;

[0133] Figure 10 yes Figure 3 A flowchart of step 340, which uses the target block verification data to verify the obtained target block;

[0134] Figure 11 yes Figure 3 A flowchart of step 340, obtaining the target block from the target full storage node;

[0135] Figure 12 yes Figure 3 Another flowchart for step 340, which uses the target block verification data to verify the obtained target block;

[0136] Figure 13 yes Figure 12 A flowchart for step 1210 of the process of calculating the total transaction summary value;

[0137] Figure 14This is a schematic diagram of a transaction summary tree provided in an embodiment of this disclosure;

[0138] Figure 15 yes Figure 12 A flowchart for step 1220 of the process of calculating the total state data summary value;

[0139] Figure 16 This is a schematic diagram of a state data digest tree according to an embodiment of the present disclosure;

[0140] Figure 17 yes Figure 12 A flowchart for step 1240, which verifies the obtained target block;

[0141] Figure 18 yes Figure 17 A flowchart for step 1720, which verifies the obtained target block;

[0142] Figure 19 This is a flowchart illustrating the acquisition of a target transaction at a non-full storage node according to an embodiment of the present disclosure;

[0143] Figure 20 This is a schematic diagram illustrating the acquisition of a target transaction at a non-full storage node according to an embodiment of the present disclosure;

[0144] Figure 21 yes Figure 3 Another flowchart for step 330, which stores part of the target block's data;

[0145] Figure 22A and Figure 22B This is a schematic diagram of the storage structure corresponding to the target verification data according to an embodiment of the present disclosure;

[0146] Figure 23 yes Figure 19 Step 1910 is a flowchart of verifying the acquired target transaction using the target transaction verification data;

[0147] Figure 24 yes Figure 3 A flowchart of step 330, which stores the target transaction verification data through multiple key-value pairs;

[0148] Figure 25 yes Figure 23 Step 2330 is a flowchart of verifying the acquired target transaction using the target transaction verification data when the target transaction verification data is stored in multiple key-value pairs;

[0149] Figure 26 yes Figure 3 A flowchart of step 330 in the middle of the process of storing target transaction verification data through single key-value pairs;

[0150] Figure 27 yes Figure 23 Step 2330 is a flowchart of verifying the acquired target transaction using the target transaction verification data when the target transaction verification data is stored in single key-value pairs;

[0151] Figure 28 This is a flowchart of blockchain data processing when the target blockchain node is the full storage node of the target block, according to an embodiment of the present disclosure;

[0152] Figure 29 This is a schematic diagram of blockchain data processing when the target blockchain node is the full storage node of the target block, according to an embodiment of the present disclosure;

[0153] Figure 30A and Figure 30B This is a schematic diagram of a target block in a full storage node according to an embodiment of the present disclosure;

[0154] Figure 31 yes Figure 28 A flowchart of step 2830, which uses a key-value pair table to generate the target block;

[0155] Figure 32 yes Figure 31 A flowchart for step 3110 of obtaining the target block height;

[0156] Figure 33 yes Figure 31 Step 3130 is a flowchart of obtaining the target block height and the transactions corresponding to each transaction index in the eighth key-value pair according to the total number of transactions;

[0157] Figure 34 yes Figure 31 A flowchart of step 3140 generating the target block;

[0158] Figure 35 yes Figure 5 A flowchart illustrating the process of generating a target block from a full storage node;

[0159] Figure 36 This is a flowchart illustrating the process of obtaining a target transaction at a full storage node according to an embodiment of this disclosure;

[0160] Figure 37 This is a schematic diagram illustrating the acquisition of a target transaction at a full storage node according to an embodiment of the present disclosure;

[0161] Figure 38 yes Figure 36 A flowchart of step 3610 using a key-value table to obtain the target transaction;

[0162] Figure 39 This is a block diagram of a blockchain processing apparatus according to embodiments of the present disclosure;

[0163] Figure 40 This is a terminal structure diagram of performing a blockchain processing method according to embodiments of this disclosure;

[0164] Figure 41 This is a server architecture diagram for performing a blockchain processing method according to embodiments of this disclosure. Detailed Implementation

[0165] To make the objectives, technical solutions, and advantages of this disclosure clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and are not intended to limit the scope of this disclosure.

[0166] Before providing a further detailed description of the embodiments of this disclosure, the terms and concepts used in these embodiments are explained, and they are subject to the following interpretations:

[0167] Blockchain: Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. Essentially, a blockchain is a decentralized database, a chain of data blocks linked together using cryptographic methods. Each data block contains information about a batch of transactions, used to verify the validity of the information (anti-counterfeiting) and to link it to the previous block.

[0168] Block data includes information such as transactions, block headers, and block appended data. It is similar to logs in a database system, but blocks are anchored by hashes to prevent tampering. The characteristics of this data are that it is continuously growing, will not be deleted or modified, and its query demand is relatively low.

[0169] A blockchain network is a technological infrastructure that allows applications to access blockchain transactions and smart contract services. It consists of multiple nodes, which can be computers or other devices, that collectively maintain a distributed database.

[0170] A blockchain network is a distributed structure containing a large number of blockchain nodes. Each blockchain node maintains the same blockchain in its own storage space. That is, for every new block added to the blockchain, the storage space of all blockchain nodes in the network must be increased by the same block, consuming a significant amount of storage space. For example, in a blockchain network with four nodes, if a block occupies 1MB of memory on a single node, then that block occupies 4MB of memory across the entire blockchain network. Since the number of blocks in a blockchain network is typically massive, this results in an explosive growth of block data. If the blockchain network adds 100 million new blocks, the additional storage space occupied by the block data would be 4TB. Furthermore, it is generally believed that only when each blockchain node maintains the complete blockchain data can the blockchain data be verified, thereby ensuring blockchain data security.

[0171] Based on this, the present disclosure provides a blockchain processing method, related apparatus, and medium, which can reduce the storage space occupied in the blockchain network without compromising the security of blockchain data.

[0172] System architecture and scenario description of the embodiments disclosed herein

[0173] Figure 1 This is a system architecture diagram of the blockchain processing method applied according to embodiments of this disclosure. Figure 1 As shown, the system used in the blockchain processing method includes: external node 110, interface node 120, and blockchain network 130.

[0174] External node 110 is a node provided for objects to perform block queries. Objects can input the blocks they want to query at external node 110. External node 110 is typically a terminal and can include various forms such as desktop computers, laptops, PDAs (personal digital assistants), mobile phones, in-vehicle terminals, home theater terminals, and dedicated terminals. Furthermore, external node 110 can be a single device or a collection of multiple devices. For example, multiple devices connected via a local area network, sharing a single display device to work collaboratively, constitute a terminal, namely external node 1110. Terminal 110 can also communicate with the Internet 120 via wired or wireless means to exchange data.

[0175] Interface node 120 serves as the communication interface between external node 110 and the blockchain network 130. External node 110 communicates with blockchain nodes in the blockchain network 130 and exchanges data through interface node 120.

[0176] Blockchain network 130 refers to a network that uploads target blocks to the blockchain after reaching a consensus. Blockchain network 130 can also provide corresponding blocks based on query blocks input by an object at external node 110. It consists of multiple blockchain nodes. Blockchain nodes need to store large amounts of data; therefore, they are typically servers. Communication between blockchain network 130 and external node 110 is specifically achieved through communication between a specific blockchain node within blockchain network 130 and external node 110.

[0177] The embodiments disclosed herein can be applied in various scenarios, such as Figure 2A The storage of the electronic invoice shown Figure 2B The examples shown include scenarios such as querying electronic invoices.

[0178] exist Figure 2A In the illustrated electronic invoice storage scenario, the client needs to store a 1MB electronic invoice A on the blockchain network. Blockchain nodes 2 and 3 store the full data of electronic invoice A; therefore, the blockchain adds 1MB of storage space to each of these nodes. Blockchain nodes 1 and 4 only store a portion of the electronic invoice A data, and this portion occupies 0.1MB of storage space. Therefore, it can be determined that after the data corresponding to electronic invoice A is uploaded to the blockchain network, the blockchain network adds 2.2MB of storage space.

[0179] exist Figure 2B In the scenario shown for querying electronic invoices, refer to Figure 2A Blockchain node 1 only stores a portion of the data for electronic invoice A, but in response to a request for electronic invoice A from a client, blockchain node 1 can return the correct electronic invoice A to the client.

[0180] Reference Figure 2A and Figure 2B It is evident that the blockchain processing method provided in this disclosure can reduce the storage space occupied in the blockchain network without compromising the security of blockchain data.

[0181] It should be understood that the above description only illustrates some application scenarios of this disclosure. The business scenarios to which this disclosure can be applied may include, but are not limited to, the specific embodiments described above.

[0182] General Description of Embodiments in this Disclosure

[0183] It should be emphasized that the embodiments disclosed herein are applicable to a variety of application scenarios, such as Figure 2A The storage of the electronic invoice shown Figure 2BThe example shown is the querying of electronic invoices. Related blockchain networks contain a large number of blockchain nodes, and with each new block added to the blockchain, the storage space of all blockchain nodes in the network increases by the same amount, consuming a significant amount of storage space. Furthermore, it is generally believed that only when each blockchain node maintains the full amount of blockchain data can the blockchain data be verified, thereby ensuring blockchain data security. Some embodiments of this disclosure provide a blockchain processing method, related apparatus, and medium that can reduce the storage space occupied in the blockchain network without compromising blockchain data security.

[0184] The blockchain processing method involves the target blockchain node storing a portion of the data from the target block and using this portion of data to verify the target block corresponding to the requested block. This method can reduce the storage space occupied in the blockchain network without compromising blockchain data security.

[0185] The blockchain processing method provided in this disclosure is executed by a target blockchain node in a blockchain network. For example... Figure 3 As shown, according to one embodiment of this disclosure, a blockchain processing method includes:

[0186] Step 310: Obtain the target block to be recorded on the blockchain;

[0187] Step 320: Based on the predetermined non-full storage node determination rules, determine that the target blockchain node is a non-full storage node of the target block. The non-full storage node is a blockchain node that only stores part of the data of the target block, and the part of the data includes the target block verification data.

[0188] Step 330: Store a portion of the target block's data on the target blockchain node;

[0189] Step 340: In response to receiving the block retrieval request for the target block, retrieve the target block from the full storage node in the blockchain network, and verify the retrieved target block using the target block verification data. The full storage node is a blockchain node that stores all the data of the target block.

[0190] It should be noted that the target blockchain node is a blockchain node within a blockchain network. (Regarding...) Figure 2A and Figure 2B The target blockchain node in the blockchain network shown can be any one of blockchain node 1, blockchain node 2, blockchain node 3, and blockchain node 4.

[0191] Steps 310 to 340 are described in detail below.

[0192] In step 310, the target block to be recorded on the blockchain is obtained.

[0193] The target block is the block that is expected to be recorded on the blockchain. In addition, the blockchain nodes in the target blockchain network have reached a consensus on adding the target block, and then each blockchain node in the target blockchain network processes the target block to record it on the blockchain.

[0194] In step 320, based on the predetermined non-full storage node determination rules, the target blockchain node is determined to be a non-full storage node of the target block. The non-full storage node is a blockchain node that only stores a portion of the data of the target block, including the target block verification data.

[0195] Non-full storage nodes are blockchain nodes that store only a portion of the target block's data, including target block verification data. Target block verification data is the data used to verify the target block, thereby ensuring its correctness, guaranteeing blockchain data security, and reducing the storage space occupied by the target block on the non-full storage node.

[0196] Figure 4 This is a schematic diagram of the blockchain of each node in a blockchain network provided in an embodiment of this disclosure. (Refer to...) Figure 4 Blockchain nodes 3 and 4 are non-full storage nodes for block 1; blockchain nodes 1 and 4 are non-full storage nodes for block 2; blockchain nodes 1 and 2 are non-full storage nodes for block 3; and blockchain nodes 2 and 3 are non-full storage nodes for block 4. The term "non-full storage node" refers to a specific block; the target blockchain node may be a non-full storage node for the target block, but not for other blocks.

[0197] The non-full storage node determination rule is a set of rules used to determine whether a blockchain node is a non-full storage node for a target block. There are many algorithms for determining non-full storage nodes, which can be configured as needed. However, regardless of the algorithm, the core principle is consistency; that is, all blockchain nodes in the blockchain network must process data according to the same non-full storage node determination rule.

[0198] The rules for determining non-full storage nodes can be calculated based on the information in the target block and the information of the target blockchain node, or they can be determined by looking up a table and using a table of multiple blocks corresponding to the target blockchain node when it is a non-full storage node.

[0199] In step 330, a portion of the target block's data is stored on the target blockchain node.

[0200] After determining that the target blockchain node is a non-full storage node for the target block, the target block is pruned to obtain partial data of the target block, and this partial data is stored on the target blockchain node.

[0201] Reference Figure 4 If blocks 0, 1, and 2 are already recorded on the blockchain network, and block 3 is the target block to be recorded on the blockchain, then blockchain node 1, according to the predetermined rules for determining non-full storage nodes, determines itself as a non-full storage node for block 3. Therefore, blockchain node 1 stores a portion of the data in the target block.

[0202] In step 340, in response to receiving a block retrieval request for the target block, the target block is retrieved from the full storage node in the blockchain network, and the retrieved target block is verified using the target block verification data. The full storage node is a blockchain node that stores all the data of the target block.

[0203] A full storage node is a blockchain node that stores all the data for the target block. (See reference...) Figure 4 Blockchain node 1 and blockchain node 2 are the full storage nodes for block 1, blockchain node 2 and blockchain node 3 are the full storage nodes for block 2, blockchain node 3 and blockchain node 4 are the full storage nodes for block 3, and blockchain node 4 and blockchain node 1 are the full storage nodes for block 4.

[0204] For a target block, the blockchain nodes in the blockchain network can be divided into two categories: full storage nodes and non-full storage nodes. Full storage nodes store all the data of the target block, while non-full storage nodes store only a portion of the target block's data. Therefore, based on predetermined rules for determining non-full storage nodes, it can be determined whether a blockchain node is a full storage node or a non-full storage node for the target block.

[0205] A block retrieval request corresponds to a target block; a block retrieval request is a request to retrieve a target block from the blockchain network.

[0206] After receiving a block retrieval request for the target block, the target blockchain node, being a non-full storage node (only storing a portion of the target block's data), needs to retrieve the target block from a full storage node in the blockchain network. Subsequently, the target blockchain node uses the target block verification data to verify the retrieved target block, thereby reducing the possibility of malicious activity by the full storage node that retrieved the target block.

[0207] Verification of the target block is to ensure the correctness of the target block obtained from the full storage node.

[0208] Reference Figure 4 Assuming the target block is block 3 and the target blockchain node is blockchain node 1, in response to receiving a request to retrieve the target block, i.e., block 3, blockchain node 1 retrieves block 3 from either blockchain node 3 or blockchain node 4 in the blockchain network and verifies the retrieved target block using local target block verification data.

[0209] in addition, Figure 4 Block 0 is the genesis block of the blockchain. It is the first block in the blockchain network, marking the birth of the blockchain network, and all other blocks in the blockchain are linked to it. In addition, block 0 is the starting point of the blockchain, and it contains a lot of configuration information. Therefore, each node in the blockchain network, namely blockchain node 1, blockchain node 2, blockchain node 3, and blockchain node 4, must store the complete data of block 0.

[0210] It should be noted that if the block to be recorded on the blockchain is a configuration block, then this configuration block needs to be stored on all nodes of the blockchain network. A configuration block contains configuration adjustments for the entire blockchain network, including adding or removing nodes, configuring consensus algorithms, managing permissions, and managing contracts. Typically, a configuration block contains only one configuration adjustment transaction.

[0211] Reference Figure 5 In response to a block retrieval request from a client, blockchain node 1 queries its local database for the target block. If the target block does not exist in the local database, it indicates that blockchain node 1 is not a full storage node for the target block. In this case, blockchain node 1 can retrieve the target block from the full storage node, i.e., blockchain node 2, and verify the retrieved target block using the target block verification data. If the verification is successful, the target block from blockchain node 2 is returned to the client. If the verification fails, a different full storage node needs to be selected to retrieve a new target block.

[0212] In the embodiments described in steps 310 to 340 above, according to the predetermined rules for determining non-full storage nodes, only a subset of blockchain nodes are full storage nodes for the target block, meaning they store the full data of the target block. The remaining blockchain nodes are non-full storage nodes for the target block, storing only a portion of the target block's data, including target block verification data. This significantly reduces the storage space occupied in the blockchain network. When a non-full storage node receives a block retrieval request for the target block, it retrieves the target block from the full storage nodes in the blockchain network and verifies the retrieved target block using its own stored target block verification data. This ensures blockchain data security while reducing the storage space occupied.

[0213] The above is a general description of steps 310 to 340. Since step 310 has been described in detail above, the specific implementation process of steps 320 to 340 will be described in detail below.

[0214] Detailed description of step 320

[0215] In step 320, based on the predetermined non-full storage node determination rules, the target blockchain node is determined to be a non-full storage node of the target block. The non-full storage node is a blockchain node that only stores a portion of the data of the target block, including the target block verification data.

[0216] In one embodiment, the number of blockchain nodes in the blockchain network is 3f+1, where f is a positive integer.

[0217] Reference Figure 6 Step 320 includes:

[0218] Step 610: Based on the predetermined rules for determining non-full storage nodes, determine the starting non-full storage node in the blockchain network;

[0219] Step 620: In the blockchain network, count 2f blockchain nodes starting from the initial non-full storage node;

[0220] Step 630: If the target blockchain node belongs to 2f blockchain nodes, determine that the target blockchain node is a non-full storage node of the target block.

[0221] It should be noted that the number of blockchain nodes in the blockchain network is 3f+1. This blockchain network uses the Byzantine Fault Tolerance (BFT) consensus algorithm, where f is the maximum number of malicious nodes that may appear in the blockchain network, which can also be understood as the maximum number of target blocks that each node in the blockchain network may fail to reach. Therefore, f is a positive integer. Figure 4 The blockchain network shown has 4 blockchain nodes, so the value of f for this network is 1. If the number of blockchain nodes in the network is 13, then the value of f for this network is 4.

[0222] Steps 610 to 630 are described in detail below.

[0223] In step 610, the starting non-full storage node is determined in the blockchain network based on the predetermined non-full storage node determination rules.

[0224] The initial non-full storage node is the first non-full storage node among multiple non-full storage nodes in the blockchain network. (Refer to...) Figure 4If the target block is block 1, the starting non-full storage node is blockchain node 3. If the target block is block 2, the starting non-full storage node is blockchain node 4. If the target block is block 3, the starting non-full storage node is blockchain node 1. If the target block is block 4, the starting non-full storage node is blockchain node 2.

[0225] In step 620, in the blockchain network, 2f blockchain nodes are counted, starting from the initial non-full storage node.

[0226] In a defined blockchain network, 2f blockchain nodes are counted starting from the initial non-full storage node. These 2f block nodes are all non-full storage nodes for the target block.

[0227] The blockchain nodes in a blockchain network are typically arranged in ascending order of their node identifiers. The counting process starts from the node storing the incomplete block and proceeds up to 2f nodes. The specific order of these nodes can be determined based on their arrangement. For example, Figure 4 The four blockchain nodes are arranged sequentially as blockchain node 1, blockchain node 2, blockchain node 3, and blockchain node 4. Starting from blockchain node 2, count two blockchain nodes, resulting in blockchain node 2 and blockchain node 3. If the number of blockchain nodes following the non-full storage node is less than 2f, then continue counting from the blockchain node ranked 1. For example, for... Figure 4 The four blockchain nodes shown are counted by two starting from blockchain node 4, resulting in blockchain node 4 and blockchain node 1.

[0228] It should be noted that the order of the blockchain nodes in a blockchain network can be arranged in other ways, such as ascending order or random order. Regardless of the order of the blockchain nodes in the blockchain network, it is only necessary to ensure that the order is consistent across all blockchain nodes.

[0229] Figure 4 The blockchain network shown has a value of f = 1 for 4 blockchain nodes. If the target block is block 3, then the starting non-full storage node is blockchain node 1. Starting from blockchain node 3, count 2 blockchain nodes to determine them as non-full storage nodes. Therefore, blockchain node 1 and blockchain node 2 can be determined as non-full storage nodes for block 3.

[0230] In step 630, if the target blockchain node belongs to 2f blockchain nodes, the target blockchain node is determined to be a non-full storage node of the target block.

[0231] If the 2f blockchain nodes starting from the initial non-full storage node are the non-full storage nodes of the target block, then if the target blockchain node belongs to the 2f blockchain nodes, then the target blockchain node is the non-full storage node of the target block.

[0232] Reference Figure 4 Assuming the target block is block 3 and the target blockchain node is blockchain node 1, the initial non-full storage node determined in the blockchain network based on the predetermined non-full storage node determination rules is blockchain node 1. Therefore, blockchain node 1 and blockchain node 2 are determined as non-full storage nodes for block 3. Thus, the target blockchain node is block 3, i.e., the non-full storage node for the target block.

[0233] It should be noted that for a blockchain network containing 3f+1 blockchain nodes, the number of nodes storing the target block in parts other than full is 2f, so the number of nodes storing the target block in full is f+1. Since f is the maximum number of target blocks that may fail among the nodes in the blockchain network, the blockchain network can retain at least one correct target block, ensuring the security of the blockchain data.

[0234] In the embodiments described in steps 610 to 630 above, the number of blockchain nodes in the blockchain network is 3f+1, which meets the requirements of the Byzantine Fault Tolerance consensus algorithm. Based on the predetermined non-full storage node determination rules, the initial non-full storage node can be determined in the blockchain network, thereby determining 2f blockchain nodes. Then, the number of full storage nodes for the target block in the target blockchain network is f+1. Based on the Byzantine Fault Tolerance consensus algorithm, f is the maximum number of target blocks that may fail for each node in the blockchain network. Therefore, the blockchain network can retain at least one correct target block, reducing the storage space occupied by the blockchain network while ensuring the security of blockchain data.

[0235] In one embodiment, if the number of blockchain nodes in the blockchain network is 3f+2, a starting non-full storage node is first determined in the blockchain network based on a predetermined non-full storage node determination rule, and 2f+1 blockchain nodes are counted from the starting non-full storage node. If the target blockchain node belongs to the 2f+1 blockchain nodes, the target blockchain node is determined to be a non-full storage node of the target block.

[0236] In one embodiment, if the number of blockchain nodes in the blockchain network is 3f+3, a starting non-full storage node is first determined in the blockchain network based on a predetermined non-full storage node determination rule, and 2f+2 blockchain nodes are counted from the starting non-full storage node. If the target blockchain node belongs to the 2f+2 blockchain nodes, the target blockchain node is determined to be a non-full storage node of the target block.

[0237] The above is a general description of steps 610 to 630. Since steps 620 and 630 have been described in detail above, only the specific implementation steps of step 610 will be described in detail below.

[0238] In step 610, the starting non-full storage node is determined in the blockchain network based on the predetermined non-full storage node determination rules.

[0239] In one embodiment, reference is made to Figure 7 Step 610 includes:

[0240] Step 710: Obtain the target block height of the target block;

[0241] Step 720: Determine the blockchain node index based on the remainder of the target block height modulo the first number, where the first number is the number of blockchain nodes in the blockchain network.

[0242] Step 730: Determine the blockchain node corresponding to the blockchain node index in the blockchain network as the starting non-full storage node.

[0243] Steps 710 to 730 are described in detail below.

[0244] In step 710, the target block height of the target block is obtained.

[0245] The target block height is used to indicate the position of the target block on the blockchain, that is, the number of blocks between the genesis block of the blockchain and the target block.

[0246] The height of the genesis block is defined as 0, and the height of each subsequent block on the blockchain increases sequentially.

[0247] Reference Figure 4 Block 0 has a block height of 0, Block 1 has a block height of 1, Block 2 has a block height of 2, Block 3 has a block height of 3, and Block 4 has a block height of 4.

[0248] In step 720, the blockchain node index is determined based on the remainder of the target block height modulo a first number, where the first number is the number of blockchain nodes in the blockchain network.

[0249] The first number is the number of blockchain nodes in the blockchain network. For Figure 2A and Figure 2B The blockchain network shown has a first number of 4.

[0250] A blockchain node index corresponds one-to-one with each blockchain node in the blockchain network; the blockchain node index is used to distinguish each blockchain node in the network. (See reference...) Figure 4The block node index of blockchain node 1 can be considered as 1, the block node index of blockchain node 2 can be considered as 2, the block node index of blockchain node 3 can be considered as 3, and the block node index of blockchain node 4 can be considered as 4.

[0251] After determining the target block height, a modulo operation is performed on the target block height and the first number to obtain a remainder. This remainder is the remainder when the target block height is modulo the first number, and its value ranges from 0 to the first number minus 1. The remainder of the target block height modulo the first number corresponds one-to-one with each node in the blockchain network. Therefore, based on this remainder, the blockchain node index can be determined.

[0252] Figure 4 The nodes shown represent all nodes in the blockchain network, with a first number of 4. Assume the target block is block 2, and the target block height of block 2 is 2. Taking the modulo operation between the target block height 2 and the first number 4 yields a remainder of 2. The blockchain node index corresponding to the remainder 2 is 4.

[0253] It should be noted that the correspondence between the remainder of the target block height modulo the first number and the blockchain node index can be arbitrarily combined, as long as the remainder of the target block height modulo the first number corresponds one-to-one with the blockchain node index of the blockchain network.

[0254] In step 730, the blockchain node corresponding to the blockchain node index in the blockchain network is determined as the starting non-full storage node.

[0255] After determining the blockchain node index, the blockchain node corresponding to the blockchain node index is identified in the blockchain network, and this node is used as a non-full storage node.

[0256] Reference Figure 4 Assuming the target block is block 2, and the target block height of block 2 is 2, based on the remainder of the target block height 2 modulo the first number 4, the blockchain node index is determined to be 4, and thus blockchain node 4 is determined to be the starting non-full storage node of the target block.

[0257] The embodiments of steps 710 to 730 above determine the blockchain node index based on the remainder of the target block height modulo a first number, i.e., the number of blockchain nodes in the blockchain network, and then determine the starting non-full storage node. In determining the blockchain node index, the remainder of the target block height modulo a first number corresponds to a first number of values, which can then correspond one-to-one with the index of each blockchain node in the blockchain network. This ensures that the full storage data and non-full storage data of each block are evenly distributed across the blockchain nodes in the blockchain network, reducing the difference in storage space occupied by each blockchain node, and making the performance of each blockchain node as consistent as possible, thereby improving the performance of the blockchain network.

[0258] Detailed description of step 330

[0259] In step 330, a portion of the target block's data is stored on the target blockchain node.

[0260] In one embodiment, reference is made to Figure 8 Step 330 includes:

[0261] Step 810: In the target blockchain node, store the first key-value pair, wherein the first key-value pair indicates the correspondence between the target block digest value and the target block height;

[0262] Step 820: On the target blockchain node, store a second key-value pair, wherein the second key-value pair indicates the correspondence between the target block height and the key data of the block header, and the key data of the blockchain header contains the target block verification data.

[0263] Steps 810 and 820 are described in detail below.

[0264] In step 810, a first key-value pair is stored in the target blockchain node, wherein the first key-value pair indicates the correspondence between the target block digest value and the target block height.

[0265] The target block digest value corresponds to the target block; specifically, it is the block hash value of the target block. The target block digest value is unique; even a minor change to the block content will result in a significant change in the target block digest value.

[0266] The target block height is used to indicate the position of the target block on the blockchain, that is, the number of blocks between the genesis block of the blockchain and the target block.

[0267] The first key-value pair indicates the correspondence between the target block digest value and the target block height. (See reference...) Figure 9BIn the first key-value pair, the target block digest value is used as the first key, and the target block height is used as the first value. Therefore, by searching the database of the target blockchain node based on the target block digest value, the target block height of the target block can be determined.

[0268] In step 820, a second key-value pair is stored in the target blockchain node, wherein the second key-value pair indicates the correspondence between the target block height and the block header key data, and the blockchain header key data contains the target block verification data.

[0269] The key data in the block header is a portion of the block header data of the target block, and this portion of the block header data includes the target block verification data.

[0270] Reference Figure 9A The key data in the block header is the data obtained after trimming the block header. The key data in the block header only includes the ChainID, BlockHeight, Block Digest, and Proposer information. The ChainID is an identifier used to distinguish different blockchains. In a blockchain network with multiple blockchains, it distinguishes different blockchains. The ChainID is mainly used to prevent transactions from being submitted repeatedly across different blockchain networks, ensuring the security and uniqueness of transactions. The Block Height indicates the block's position on the blockchain. The Block Digest is the Block Hash; each block generates a unique hash value, ensuring the security and integrity of the block data. The Proposer information identifies the block's producer.

[0271] based on Figure 9A The block headers before and after pruning are shown, and it is clear that the storage space occupied by the key data in the block header is significantly reduced compared to the block headers in related technologies.

[0272] The key data in the block header only includes the chain identifier, block height, block digest value, and on-chain initiating node information. The block digest value and on-chain initiating node information can be used as verification data for the target block.

[0273] The second key-value pair is used to indicate the correspondence between the target block height and the block header key data. (See reference...) Figure 9B In the second key-value pair, the target block height is used as the second key, and the block header key data is used as the second value. Therefore, by searching the database of the target blockchain node based on the target block height, the block header key data of the target block can be determined, and thus the target block verification data can be determined.

[0274] It should be noted that the block header key data stored in the second key-value pair is the serialized information of the block header key data. Specifically, the block header key data is serialized according to a certain order and format, and converted into a byte string. Furthermore, different blockchains may use different serialization methods, but they generally follow the principle of fixed or variable length conversion.

[0275] The embodiments of steps 810 and 820 described above store the trimmed block header using key-value storage. Specifically, the target block digest value and target block height are stored using a first key-value pair, and the target block height and key block header data are stored using a second key-value pair. The setting of the first and second key-value pairs facilitates the retrieval of target block verification data by target block height or target block digest value, thus improving the retrieval efficiency of target block verification data.

[0276] Detailed description of step 340

[0277] In step 340, in response to receiving a block retrieval request for the target block, the target block is retrieved from the full storage node in the blockchain network, and the retrieved target block is verified using the target block verification data. The full storage node is a blockchain node that stores all the data of the target block.

[0278] In the embodiments of steps 810 and 820 above, a first key-value pair and a second key-value pair are stored in the target blockchain node. The first key-value pair indicates the correspondence between the target block digest value and the target block height, and the second key-value pair indicates the correspondence between the target block height and the block header key data. In this case, in one embodiment, the block retrieval request includes the target block digest value of the target block, referring to... Figure 10 Step 340 includes:

[0279] Step 1010: Determine the target block height based on the target block digest value and the first key-value pair;

[0280] Step 1020: Obtain the target block with the target block height from the full storage nodes in the blockchain network;

[0281] Step 1030: Based on the target block height and the second key-value pair, obtain the key data of the block header, and extract the target block verification data from the key data of the block header;

[0282] Step 1040: Verify the obtained target block using the target block verification data.

[0283] Steps 1010 to 1040 are described in detail below.

[0284] In step 1010, the target block height is determined based on the target block digest value and the first key-value pair.

[0285] The block retrieval request contains the target block digest value. The target blockchain node uses the target block digest as the key to search its local database, obtains the first key-value pair, and then determines the height of the target block.

[0286] In step 1020, the target block with the target block height is obtained from the full storage node in the blockchain network.

[0287] The full storage node stores all the data of the target block. The target blockchain node can obtain the target block with the target block height from the full storage node in the blockchain network. Specifically, the target blockchain node sends the target block height to the full storage node to obtain the target block with that height. The full storage node then returns the target block to the target blockchain node based on the target block height.

[0288] In step 1030, based on the target block height and the second key-value pair, the block header key data is obtained, and the target block verification data is extracted from the block header key data.

[0289] After obtaining the target block at the target block height, the target blockchain node needs to verify the target block. Specifically, it searches the local database based on the target block height to obtain the second key-value pair, thereby determining the key data of the block header, and extracting the target block verification data from the key data of the block header.

[0290] In step 1040, the obtained target block is verified using the target block verification data.

[0291] After determining the target block verification data, the obtained target block is verified using the target block verification data. If the verification is successful, the target block is returned to the client or node corresponding to the block retrieval request. If the verification fails, another full storage node is used to retrieve the target block again.

[0292] Reference Figure 5 and Figure 9BAfter receiving a block retrieval request, blockchain node 1 parses the request to obtain the target block digest value. Based on the target block digest value, it determines the first key-value pair, and then determines the target block height. Blockchain node 1 queries its local database for the target block based on the target block height. If the target block exists in the local database, blockchain node 1 becomes the full storage node for the target block and returns it to the client. If the target block does not exist in the local database, the full storage node in the blockchain network, i.e., blockchain node 2, obtains the target block at the target block height. Blockchain node 1 determines the second key-value pair based on the target block height, and then determines the key data of the block header. It parses the key data of the block header to obtain the target block verification data. Finally, blockchain node 1 uses the target block data to verify the target block from blockchain node 2.

[0293] In the embodiments of steps 1010 to 1040 above, the block acquisition request includes the target block digest value of the target block. Based on the target block digest value and the first key-value pair, the target block height can be determined. Then, based on the second key-value pair, the block header key data corresponding to the target block height can be determined. The target block from the full storage node is verified using the target block data in the block header key data. This method improves the verification efficiency of the target block and ensures the security of blockchain data by looking up the target block height and block header key data through the first key-value pair and the second key-value pair.

[0294] In another embodiment, the block retrieval request includes the target block height. The target blockchain node first retrieves the target block with the target block height from the full storage node in the blockchain network, and based on the target block height and the second key-value pair, retrieves the block header key data, and extracts the target block verification data from the block header key data. Finally, the retrieved target block is verified using the target block verification data.

[0295] In one embodiment, the full storage node consists of multiple full storage nodes, as shown in the reference. Figure 11 Step 340 includes:

[0296] Step 1110: Obtain the channel status between each full storage node and the target blockchain node;

[0297] Step 1120: Based on the channel state, determine the target full storage node from among the various full storage nodes;

[0298] Step 1130: Obtain the target block from the target full storage node.

[0299] Steps 1110 to 1130 are described in detail below.

[0300] In step 1110, the channel status between each full storage node and the target blockchain node is obtained respectively.

[0301] Channel state describes the channel attributes of the communication link between the target blockchain node and the full storage node. Channel state can include congestion levels and channel length between each full storage node and the target blockchain node.

[0302] In step 1120, the target full storage node is determined from each full storage node based on the channel state.

[0303] The target full storage node is determined among all full storage nodes in the target block based on the channel state. The target full storage node is the node with the best channel state among all full storage nodes, i.e., the node with the shortest communication time.

[0304] In step 1130, the target block is obtained from the target full storage node.

[0305] After determining the target full storage node, the target block is obtained from the target full storage node.

[0306] It should be noted that if the verification of the target block obtained from the target full storage node based on the target block verification data fails, it is necessary to re-determine the full storage node from all full storage nodes other than the target full storage node based on the channel status in order to re-obtain the target block.

[0307] Reference Figure 2A and Figure 2B Assume blockchain node 2 is the target blockchain node, and blockchain nodes 3 and 4 are the full storage nodes for the target block. Under the same congestion conditions, since the channel length between blockchain nodes 2 and 4 is shorter than the channel length between blockchain nodes 2 and 3, blockchain node 4 is chosen as the target full storage node.

[0308] The embodiments of steps 1110 to 1130 above determine the target full storage node from among the full storage nodes based on the channel state between each full storage node and the target blockchain node in order to obtain the target block. This method can effectively reduce the communication time between the target full storage node and the target blockchain node, thereby improving the efficiency of obtaining the target block and improving the efficiency of blockchain processing.

[0309] In another embodiment, the target block verification data includes a first target block digest value, referred to Figure 12 Step 340 includes:

[0310] Step 1210: Calculate the total transaction digest value of each transaction in the obtained target block;

[0311] Step 1220: Calculate the total state data digest value of each transaction in the target block;

[0312] Step 1230: Calculate the second target block digest value of the target block based on the total transaction digest value, the total status data digest value, and the full block header data in the target block;

[0313] Step 1240: Verify the obtained target block based on the comparison between the first target block digest value and the second target block digest value.

[0314] It should be noted that the target block verification data includes the first target block digest value. The first target block digest value refers to the block digest value of the target block stored by the target blockchain node during its storage phase. This differs from the second target block digest value described below. The second target block digest value is the block digest value generated by the target blockchain node during its verification phase. The block digest value needs to reflect the various transactions within the block (e.g., "100 resources transferred from resource pool A to resource pool B"), the state of each transaction object after execution (e.g., the remaining resources in resource pool A, the remaining resources in resource pool B), and other data in the block header (such as block version, timestamp, etc.). Therefore, during the storage phase of the target blockchain node, the first target block digest value is determined by the total transaction digest value, the total state data digest value, and the full block header data calculated during the storage phase of the target blockchain node. During the verification phase of the target blockchain node, the second target block digest value is determined by the total transaction digest value, total state data digest value, and full block header data of each transaction calculated during the verification phase of the target blockchain node, as shown in steps 1210-1230. During the storage phase of the target blockchain node, the method for determining the first target block digest value by the total transaction digest value, total state data digest value, and full block header data of each transaction calculated during the storage phase of the target blockchain node is similar to steps 1210-1230; therefore, the description of steps 1210-1230 can be referred to.

[0315] Steps 1210 to 1240 are described in detail below.

[0316] In step 1210, the total transaction digest value of each transaction in the obtained target block is calculated.

[0317] The target block records multiple transactions, and the total transaction digest value is determined based on the individual transactions recorded in the target block.

[0318] The total transaction digest value is specifically the root hash value (TxRoot) of the block transactions, and it is unique. The total transaction digest value ensures the integrity and immutability of all transactions within the target block. For example, if block 4 records transactions a, b, c, d, and e, then the total transaction digest value of block 4 is determined based on transactions a, b, c, d, and e.

[0319] In step 1220, the total state data summary value of each transaction in the acquired target block is calculated.

[0320] The overall state data digest value is determined based on the read-write sets of each transaction in the target block. Specifically, the overall state data digest value is the root hash value (RWSetRoot) of the read-write set. The read-write set is a data structure used to describe the data state references and updates involved in the transaction process of the block. The read-write set typically consists of two parts: a read set and a write set. The read set records the data state accessed during the transaction, and the write set records the data state that needs to be updated during the transaction. If the target block contains two transactions: transaction a and transaction b, where transaction a is "retrieves 20 resources from resource pool 1 with 100 resources," and transaction b is "transfers 10 resources from resource pool 2 with 90 resources to resource pool 1," then the read-write set of the target block is {Transaction a: 100 resources before execution and 80 resources after execution in resource pool 1; Transaction b: 80 resources before execution and 90 resources after execution in resource pool 1; 90 resources before execution and 80 resources after execution in resource pool 2}.

[0321] In step 1230, the second target block digest value of the target block is calculated based on the total transaction digest value, the total status data digest value, and the full block header data in the target block.

[0322] The full block header data is all the data in the block header of the target block.

[0323] Reference Figure 9AThe key data in the block header is the data obtained by trimming the full block header data. The full block header data includes the ChainID, BlockHeight, BlockVersion, Previous Configuration Block Height, Previous Block Digest, Timestamp, Proposer, Signature, ConsensusArgs, Directed Acyclic Graph Hash (DagHash), Total Transaction Digest, Total State Data Digest, Total Transaction Count (TxCount), and BlockType. The ChainID is an identifier used to distinguish different blockchains. The Block Height indicates the block's position on the blockchain. The Block Version identifies the protocol and specification used by the current block. The Previous Configuration Block Height refers to the block height of the block whose blockchain configuration was last modified; it can also be understood as the block height of the previous configuration block. The previous block digest value is specifically the previous block hash (PreBlockHash), which is the hash value of the block preceding the current block. The timestamp refers to the generation time of the current block. The on-chain initiating node information is the block generator identifier. The on-chain initiating node signature is the signature of the block generator. Consensus parameters refer to the parameters used in the blockchain network to ensure that all blockchain nodes reach a consensus on transactions and blocks. The directed acyclic graph hash refers to the hash value of the directed acyclic graph corresponding to each transaction in the block. A directed acyclic graph is a decentralized database that treats each transaction as a block, and each block can be linked to multiple previous transactions for verification. The total transaction digest value is the root hash value (TxRoot) of the block transactions. Specifically, the total transaction digest value is the root hash value (RWSetRoot) of the block read / write set, a data structure used to describe the data state references and updates involved in the transaction process of a block. The total number of transactions refers to the total number of transactions recorded in the block. Block type refers to the type of the current block, such as a regular block that records transactions or a configuration block.

[0324] After determining the total transaction digest value and the total status data digest value, first extract the other data besides the total transaction digest value and the total status data digest value from the block header of the target block, such as... Figure 9A The block version, previous block digest value, timestamp, etc., are shown. Then, the total transaction digest value, total status data digest value, and other extracted data are serialized, and a digest algorithm is used to perform a digest operation on the serialized data to obtain a digest value, which is the second target block digest value of the target block.

[0325] In step 1240, the obtained target block is verified based on the comparison between the first target block digest value and the second target block digest value.

[0326] After determining the second target block digest value, the block header key data is retrieved from the second key-value pair based on the target block height, thus obtaining the target block verification data. Additionally, the target block verification data includes the first target block digest value. If the first target block digest value is equal to the second target block digest value, the target block verification is successful. If the first target block digest value is not equal to the second target block digest value, the target block verification fails, and a new target block needs to be obtained by replacing the entire storage node.

[0327] Reference Figure 5 and Figure 9B After receiving the target block, blockchain node 1 first parses the target block to calculate the total transaction digest value and the total state data digest value of each transaction in the target block. Based on the total transaction digest value, the total state data digest value, and other information in the full data of the block header, a second target block digest value is calculated. Then, the target block is verified by comparing the first target block digest value and the second target block digest value.

[0328] In the embodiments described in steps 1210 to 1240 above, the target block verification data includes a first target block digest value. The first target block digest value is determined by the total transaction digest value, total state data digest value, and full block header data of each transaction calculated during the storage phase of the target blockchain node. The second target block digest value is determined by the total transaction digest value, total state data digest value, and full block header data of each transaction calculated during the verification phase of the target blockchain node. If the full data stored in the full storage node has not been tampered with, the second target block digest value should be consistent with the first target block digest value. In this case, the obtained target block should be reliable. By verifying whether the two are consistent, the correctness of the obtained target block is ensured. Furthermore, the first and second target block digest values ​​not only consider each transaction but also the changes in the state of the transaction object caused by transaction execution and the full block header data, further improving the correctness of the obtained target block.

[0329] The above is a general description of steps 1210 and 1240. Since step 1230 has been described in detail above, the specific implementation process of steps 1210, 1220 and 1240 will be described in detail below.

[0330] In step 1210, the total transaction digest value of each transaction in the obtained target block is calculated.

[0331] In one embodiment, reference is made to Figure 13 Step 1210 includes:

[0332] Step 1310: Calculate the transaction digest value of each transaction in the target block;

[0333] Step 1320: Generate a transaction summary tree. The bottom-level nodes of the transaction summary tree are the transaction summary values ​​of each transaction. The order of the transaction summary values ​​is consistent with the order of each transaction in the target block. Other nodes in the transaction summary tree, except for the bottom-level nodes, are obtained by performing a summary operation after concatenating two adjacent nodes at the next lower level of other nodes, until the root node of the top level is generated.

[0334] Step 1330: Determine the total transaction summary value based on the root node.

[0335] Steps 1310 to 1330 are described in detail below.

[0336] In step 1310, the transaction digest value of each transaction in the target block is calculated.

[0337] The transaction digest value corresponds to the transaction; specifically, it is the transaction hash value. The hash of each transaction in the target block is calculated to determine its unique hash value. The transaction digest value is a digital fingerprint used in blockchain technology to uniquely identify a transaction, ensuring the integrity and immutability of transaction data.

[0338] In step 1320, a transaction summary tree is generated. The bottom-level nodes of the transaction summary tree are the transaction summary values ​​of each transaction. The order of the transaction summary values ​​is consistent with the order of each transaction in the target block. The other nodes in the transaction summary tree, except for the bottom-level nodes, are obtained by performing a summary operation after concatenating two adjacent nodes at the next lower level of the other nodes, until the root node of the top level is generated.

[0339] A transaction digest tree is a tree determined based on the transaction digest values ​​corresponding to each transaction in the target block. In the transaction digest tree, the bottom-level nodes are the transaction digest values ​​of each transaction in the target block, and the order of the transaction digest values ​​is consistent with the order of their corresponding transactions in the target block. All other nodes except the bottom-level node are determined by performing a digest operation, i.e., a hash operation, on the concatenation of two adjacent nodes at the next lower level.

[0340] Reference Figure 14The target block records transactions 1, 2, 3, and 4. A digest operation is performed on each transaction to obtain transaction digest value 1 for transaction 1, transaction digest value 2 for transaction 2, transaction digest value 3 for transaction 3, and transaction digest value 4 for transaction 4. Transaction digest values ​​1, 2, 3, and 4 are the bottom-level nodes of the transaction digest tree of the target block. A digest operation is performed on the concatenated result of transaction digest values ​​1 and 2 to obtain transaction digest value 12. Similarly, transaction digest value 34 is determined based on transaction digest values ​​1 and 2. Finally, a digest operation is performed on the concatenated result of transaction digest values ​​12 and 34 to obtain transaction digest value 1234. Transaction digest value 1234 is the root node of the transaction digest tree of the target block.

[0341] In step 1330, the total transaction summary value is determined based on the root node.

[0342] After determining the transaction digest tree based on the transaction digest values ​​of each transaction, the root node of this transaction digest tree is used as the total transaction digest value of the target block. For Figure 14 The transaction summary tree shown corresponds to the target block, and the transaction summary value 1234 is the total transaction summary value.

[0343] The embodiments of steps 1310 to 1330 above construct a transaction digest tree based on the transaction digest values ​​of each transaction in the target block, and use the root node of the transaction digest tree as the total transaction digest value. The total transaction digest value is used to determine the second target block digest value. Therefore, the comparison between the first target block digest value and the second target block digest value can verify each transaction in the target block, improve the verification effect, and improve the security of blockchain data.

[0344] In step 1220, the total state data summary value of each transaction in the acquired target block is calculated.

[0345] In one embodiment, reference is made to Figure 15 Step 1220 includes:

[0346] Step 1510: Calculate the state data digest value of each transaction in the target block after execution;

[0347] Step 1520: Generate a state data digest tree. The bottom-level nodes of the state data digest tree are the state data digest values ​​after each transaction is executed. Other nodes in the state data digest tree, except for the bottom-level nodes, are obtained by performing a digest operation on the concatenation of two adjacent nodes at the next lower level of other nodes, until the root node of the top level is generated.

[0348] Step 1530: Determine the total state data summary value based on the root node.

[0349] Steps 1510 to 1530 are described in detail below.

[0350] In step 1510, the state data digest value of each transaction in the target block after execution is calculated.

[0351] The state data digest value is specifically the transaction read-write set hash value. A transaction read-write set is a data structure used for referencing and updating data states during the execution of a transaction corresponding to that set; it records the state data after the transaction is executed. The hash calculation is performed on the transaction read-write sets corresponding to each transaction in the target block to obtain the state data digest value after the execution of each transaction in the target block.

[0352] In step 1520, a state data digest tree is generated. The bottom-level nodes of the state data digest tree are the state data digest values ​​after each transaction is executed. Other nodes in the state data digest tree, except for the bottom-level nodes, are obtained by performing a digest operation on the concatenation of two adjacent nodes at the next lower level of other nodes, until the root node of the top level is generated.

[0353] The state data digest tree is a tree determined based on the state data digest values ​​of each transaction in the target block after execution. In the state data digest tree, the bottom-level nodes are the state data digest values ​​of each transaction in the target block after execution. All other nodes are determined by performing a hash operation on the concatenation of two adjacent nodes at the next lower level.

[0354] It should be noted that the order of each status data digest value in the bottom-level node of the status data digest tree can be arbitrarily determined, but usually the order of the status data digest values ​​is determined by the order of the transaction digest values ​​in the bottom-level node of the transaction digest tree.

[0355] Reference Figure 16 The target block includes read / write sets for transactions 1, 2, 3, and 4. A digest operation is performed on the read / write sets corresponding to each transaction to obtain state data digest value 1, state data digest value 2, state data digest value 3, and state data digest value 4. State data digest values ​​1, 2, 3, and 4 are the bottom-level nodes of the target block's state data digest tree. A digest operation is performed on the concatenated result of state data digest value 1 and state data digest value 2 to obtain state data digest value 12. Similarly, state data digest value 34 is determined based on state data digest values ​​1 and 2. Finally, a digest operation is performed on the concatenated result of state data digest value 12 and state data digest value 34 to obtain state data digest value 1234. State data digest value 1234 is the root node of the target block's state data digest tree.

[0356] In step 1530, the total state data summary value is determined based on the root node.

[0357] After determining the state data digest tree based on the state data digest values ​​after each transaction is executed, the root node of this state data digest tree is used as the total state data digest value of the target block. For Figure 16 The state data digest tree shown corresponds to the target block, and the state data digest value 1234 is the total state data digest value.

[0358] The embodiments of steps 1510 to 1530 above construct a state data digest tree based on the state data digest values ​​after the execution of each transaction of the target block, and take the root node of the state data digest tree as the total state data digest value. The total state data digest value is used to determine the second target block digest value. Then, the comparison between the first target block digest value and the second target block digest value can verify the read and write sets of each transaction of the target block, further improving the verification effect of each transaction and improving the security of blockchain data.

[0359] In step 1240, the obtained target block is verified based on the comparison between the first target block digest value and the second target block digest value.

[0360] In one embodiment, the target block verification data includes information about the first on-chain initiating node, as referred to... Figure 17 Step 1240 includes:

[0361] Step 1710: If the digest value of the first target block is consistent with the digest value of the second target block, extract the information of the second on-chain initiating node from the obtained target block;

[0362] Step 1720: Verify the obtained target block based on the comparison between the information of the first on-chain initiating node and the information of the second on-chain initiating node.

[0363] It should be noted that the target block verification data includes the information of the first on-chain initiating node, which is also used to verify the target block. The first on-chain initiating node information is the information recorded by the target blockchain node, referring to the identifier of the target block's generator. For example, if the target block was generated by blockchain node 3, then the on-chain initiating node information would record the node identifier of blockchain node 3.

[0364] Steps 1710 and 1720 are described in detail below.

[0365] In step 1710, if the first target block digest value is consistent with the second target block digest value, the second on-chain initiating node information is extracted from the obtained target block.

[0366] The second on-chain initiating node information is the on-chain initiating node information recorded in the target block.

[0367] If the digest value of the first target block matches the digest value of the second target block, it indicates that the transaction and transaction read / write set of the target block have been successfully verified. Therefore, the target block can be further verified, specifically by extracting the information of the second on-chain initiating node from the obtained target block.

[0368] Additionally, if the digest value of the first target block is inconsistent with the digest value of the second target block, it indicates that the target block verification has failed and other full storage nodes need to be replaced to obtain a new target block.

[0369] In step 1720, the obtained target block is verified based on the comparison between the information of the first on-chain initiating node and the information of the second on-chain initiating node.

[0370] If the first target block digest value and the second target block digest value are the same, the information of the first on-chain initiating node and the information of the second on-chain initiating node are compared to further verify the obtained target block.

[0371] Reference Figure 5 In the process of verifying the target block from blockchain node 2 (the full storage node), blockchain node 1 first determines whether the first target block digest value in the target block verification data matches the second target block digest value. If they match, it then verifies whether the first on-chain initiating node information in the target block verification data matches the second on-chain initiating node information to further verify the target block. If they don't match, blockchain node 1 replaces the full storage node with a different one than blockchain node 2 and re-acquires the target block. For example, if the first on-chain initiating node is blockchain node 3 and the second on-chain initiating node is blockchain node 4, then blockchain node 1 will replace the full storage node with blockchain node 3 and re-acquire the target block.

[0372] In the embodiments of steps 1710 and 1720 above, if the first target block digest value and the second target block digest value are consistent, the target block is further verified through the on-chain initiating node information to ensure that the on-chain initiating node information in the target block is consistent with the target block verification data. If the full data stored in the full storage node has not been tampered with, the first on-chain initiating node information and the second on-chain initiating node information should be consistent. If they are inconsistent, it indicates that they may have been tampered with. By verifying whether they are consistent, the correctness of the obtained target block is ensured. Based on the verification through the target block digest value, further verification of the target block through the on-chain initiating node information improves the verification effect of the target block, ensures the correctness of the finally obtained target block, and further improves the security of blockchain data.

[0373] The above is a general description of steps 1710 and 1720. Since step 1710 has been described in detail above, the specific implementation process of step 1720 will be described in detail below.

[0374] In step 1720, the obtained target block is verified based on the comparison between the first on-chain initiating node information and the second on-chain initiating node information.

[0375] In one embodiment, reference is made to Figure 18 Step 1720 includes:

[0376] Step 1810: If the information of the first on-chain initiating node is consistent with the information of the second on-chain initiating node, obtain the first signature reserved by the on-chain initiating node;

[0377] Step 1820: Extract the second signature of the on-chain initiating node from the obtained target block;

[0378] Step 1830: Verify the obtained target block based on the comparison of the first signature and the second signature.

[0379] Steps 1810 to 1830 are described in detail below.

[0380] In step 1810, if the information of the first on-chain initiating node is consistent with the information of the second on-chain initiating node, the first signature reserved by the on-chain initiating node is obtained.

[0381] The first signature is the signature of the initiating node stored on the target blockchain node. The signature is an important concept in blockchain technology, and its main purpose is to ensure the security and integrity of blocks and transactions.

[0382] If the information of the first on-chain initiating node matches that of the second on-chain initiating node, it indicates that the verification of the on-chain initiating node information of the target block has been successful. Therefore, the first signature reserved by the on-chain initiating node corresponding to the target block can be obtained for further verification of the target block.

[0383] In step 1820, the second signature of the on-chain initiating node is extracted from the obtained target block.

[0384] The second signature is the signature recorded from the target block obtained from the full storage node.

[0385] In step 1830, the obtained target block is verified based on the comparison of the first signature and the second signature.

[0386] After determining the first signature held by the target blockchain node and the second signature in the obtained target block, the first and second signatures are compared, and the obtained target block is verified based on the comparison result. Assuming the first signature is ANC#$, if the second signature is ANC#$, the verification is successful. If the second signature is not ANC#$, the verification fails.

[0387] Reference Figure 5 After the second target block digest value and the second on-chain initiating node of the target block are successfully verified, blockchain node 1 verifies the signature in the target block, that is, whether the second signature of the on-chain initiating node is correct. Specifically, blockchain node 1 obtains the first signature of the on-chain initiating node from its local database to determine whether the first signature and the second signature are consistent. If they are consistent, the verification is successful. If they are inconsistent, the verification fails, and blockchain node 1 needs to replace it with a different full storage node than blockchain node 2 and re-obtain the target block.

[0388] The target block verification data includes the first target block digest value and the first on-chain initiating node information. During the verification process based on this data, the second target block digest value and the second on-chain initiating node information are verified sequentially. The second target block digest value is calculated based on all transactions and the full block header data of the acquired target block. Additionally, the second signature in the target block is verified using the first signature reserved by the on-chain initiating node. Only if the second target block digest value, the second on-chain initiating node information, and the second signature are successfully verified is the acquired target block successfully verified. If any one of these verifications fails, a different full-scale storage node must be used to re-acquire the target block.

[0389] The embodiments described in steps 1810 to 1830 further verify the target block through signatures. If the full data stored in the full storage node has not been tampered with, then the first signature and the second signature are consistent. At this point, the obtained target block should be reliable. By verifying whether the two are consistent, the correctness of the obtained target block is ensured. In addition, the setting of the first signature and the second signature further increases the diversity of verification data, improves the verification effect of the target block, ensures the correctness of the final target block, and improves the security of blockchain data.

[0390] Steps 310 to 340 have been explained in detail above. The following sections will elaborate on some specific points and related concepts. These topics include the acquisition of the target transaction and the processing of the blockchain by the full storage node.

[0391] Acquisition of the target transaction

[0392] In the blockchain processing, the blockchain network can provide block query services, that is, provide the corresponding target block based on the block retrieval request. In addition, the blockchain network also needs to provide transaction query services, that is, provide the corresponding target transaction based on the transaction retrieval request.

[0393] In one embodiment, some of the data further includes target transaction verification data, as referred to Figure 19 After step 330, the blockchain processing method provided in this disclosure embodiment further includes:

[0394] Step 1910: In response to the transaction retrieval request for the target transaction in the target block, retrieve the target transaction of the target block from the full storage node in the blockchain network, and verify the retrieved target transaction using the target transaction verification data.

[0395] It should be noted that the data stored on the target blockchain node also includes target transaction verification data, which is the data recorded by the target node for verifying the target transaction.

[0396] Step 1910 will be described in detail below.

[0397] In step 1910, in response to a transaction retrieval request for a target transaction in the target block, the target transaction of the target block is retrieved from the full storage node in the blockchain network, and the retrieved target transaction is verified using the target transaction verification data.

[0398] A transaction retrieval request corresponds to a target transaction; it is a request to retrieve the target transaction from the blockchain network.

[0399] After receiving a transaction retrieval request for the target block, the target blockchain node, being a non-full storage node (only storing a portion of the target block's data and lacking the specific transaction data), needs to retrieve the target transaction from a full storage node in the blockchain network. Subsequently, the target blockchain node verifies the retrieved transaction using the target transaction verification data to reduce the likelihood of malicious activity by the full storage node retrieving the target transaction.

[0400] Reference Figure 20 In response to a transaction retrieval request from a client, blockchain node 1 queries its local database for the target transaction. If the target transaction does not exist in the local database, it indicates that blockchain node 1 is not a full storage node for the target block. In this case, blockchain node 1 can retrieve the target transaction from the full storage node of the target block, namely blockchain node 2, and verify the retrieved target transaction using the target transaction verification data. If the verification is successful, the target transaction from blockchain node 2 is returned to the client. If the verification fails, a different full storage node needs to be selected to retrieve a new target transaction.

[0401] In the embodiment of step 1910 above, the target blockchain node, as a non-full storage node for the target block, stores target transaction verification data. The non-full storage node can use its stored target transaction verification data to verify the target transaction obtained from the full storage node in the blockchain network, ensuring the security of the blockchain data. Furthermore, since the non-full storage node does not store the complete target block, it reduces the storage space occupied by blockchain data on the target blockchain node, thereby reducing the storage space occupied by the blockchain network.

[0402] The above is a general description of step 1910. The following section describes the specific implementation process of step 1910 in conjunction with step 330.

[0403] In one embodiment, reference is made to Figure 21 Step 330 includes:

[0404] Step 2110: On the target blockchain node, store a third key-value pair, wherein the third key-value pair indicates the correspondence between the target transaction identifier, the target block height, and the target transaction index.

[0405] Step 2110 will be described in detail below.

[0406] In step 2110, a third key-value pair is stored in the target blockchain node, wherein the third key-value pair indicates the correspondence between the target transaction identifier, the target block height, and the target transaction index.

[0407] The target transaction identifier refers to the transaction identifier (TxI d) of the target transaction. The transaction identifier is used to uniquely identify each transaction on the blockchain, and each transaction has a unique transaction identifier.

[0408] The target block height is used to indicate the position of the target block to which the target transaction belongs on the blockchain, that is, the number of blocks from the genesis block of the blockchain to the target block.

[0409] The target transaction index refers to the position of the target transaction within its corresponding target block. In a blockchain network, the target transaction is determined based on the target block height and the target transaction index.

[0410] The third key-value pair indicates the correspondence between the target transaction identifier, the target block height, and the target transaction index. (See reference...) Figure 22A and Figure 22B In the third key-value pair, the target transaction identifier is used as the third key, and the target block height and target transaction index are used as the third values. Therefore, by searching the database of the target blockchain node based on the target transaction identifier, the target block height of the target block to which the target transaction belongs and the target transaction index of the target transaction can be determined.

[0411] In the embodiment of step 2110 above, the target transaction identifier, target block height, and target transaction index are stored in a key-value storage manner, and the target identifier is the key in the key-value pair. Therefore, by searching for the target block height and target transaction index in the key-value pair using the target transaction identifier, the location of the target transaction can be quickly determined, thus improving the efficiency of obtaining the target transaction.

[0412] In step 1910, in response to a transaction retrieval request for a target transaction in the target block, the target transaction of the target block is retrieved from the full storage node in the blockchain network, and the retrieved target transaction is verified using the target transaction verification data.

[0413] In the embodiment of step 2110 above, a third key-value pair is stored in the target blockchain node, and the third key-value pair indicates the correspondence between the target transaction identifier, the target block height, and the target transaction index. In this case, in one embodiment, the transaction acquisition request includes the target transaction identifier of the target transaction, referring to... Figure 23 Step 1910 includes:

[0414] Step 2310: Determine the target block height and target transaction index based on the target transaction identifier and the third key-value pair;

[0415] Step 2320: Obtain the target block of the target block height from the full storage nodes in the blockchain network, and obtain the target transaction index of the target transaction in the target block;

[0416] Step 2330: Verify the acquired target transaction using the target transaction verification data.

[0417] Steps 2310 to 2330 are described in detail below.

[0418] In step 2310, the target block height and target transaction index are determined based on the target transaction identifier and the third key-value pair.

[0419] The transaction retrieval request contains the target transaction identifier. The target blockchain node uses the target transaction identifier as the key to search its local database, obtains a third key-value pair, and then determines the target block height and the target transaction index.

[0420] In step 2320, the target block with the target block height is obtained from the full storage nodes in the blockchain network, and the target transaction with the target transaction index is obtained from the target block.

[0421] The full storage node stores all the data of the target block. The target blockchain node can obtain the target block with the target block height from the full storage node in the blockchain network, and then retrieve the target transaction index from the target block. Specifically, the target blockchain node sends the target block height and the target transaction index to the full storage node. The full storage node finds the target block based on the target block height, locates the target transaction index within the target block, and finally returns the target transaction to the target blockchain node.

[0422] In step 2330, the acquired target transaction is verified using the target transaction verification data.

[0423] After acquiring the target transaction, the target blockchain node needs to verify its correctness and completeness. If the verification is successful, the target transaction is returned to the client or node corresponding to the transaction acquisition request. If the verification fails, another full storage node is used to reacquire the target transaction.

[0424] Reference Figure 20 , Figure 22A and Figure 22BAfter receiving a transaction retrieval request from a client, blockchain node 1 parses the request to obtain the target transaction identifier. Using the target transaction identifier as the key, blockchain node 1 determines the third key-value pair from its local database, thereby determining the target block height and the target transaction index. Then, blockchain node 1 queries its local database using the target block height and the target transaction index as keys to retrieve the target transaction. If the target transaction exists in blockchain node 1's database, it is returned to the client. If the target transaction does not exist, it is retrieved from all storage nodes in the blockchain network based on the target block height and the target transaction index, and the retrieved target transaction is verified using the target transaction verification data.

[0425] In the embodiments of steps 2310 to 2330 above, a third key-value pair is set. The third key-value pair uses the target transaction identifier as the key and the target block height and target transaction index as the values. Based on the target transaction identifier and the third key-value pair, the target block height and target transaction index can be quickly determined, reducing the time spent searching for the target block height and target transaction index. As a result, the target transaction can be quickly queried from all data nodes based on the target block height and target transaction index, thus improving the query efficiency for the target transaction.

[0426] The above is a general description of steps 2310 to 2330. Since steps 2310 and 2320 have been described in general, the specific implementation process of step 2330 will be described in detail below in conjunction with step 330.

[0427] In one embodiment, the target transaction verification data includes a first target transaction digest value and a first target transaction status data digest value.

[0428] Reference Figure 24 Step 330 includes:

[0429] Step 2410: In the target blockchain node, store the fourth key-value pair, wherein the fourth key-value pair indicates the correspondence between the target transaction identifier and the first target transaction digest value;

[0430] Step 2420: In the target blockchain node, store the fifth key-value pair, wherein the fifth key-value pair indicates the correspondence between the target transaction identifier and the first target transaction state data digest value.

[0431] It should be noted that the target transaction verification data includes the first target transaction digest value and the first target transaction status data digest value.

[0432] The first target transaction digest value is the transaction digest value of the target transaction recorded by the target blockchain node. The transaction digest value is specifically the transaction hash value (TxHash). The transaction digest value is a digital fingerprint used in blockchain technology to uniquely identify a transaction, ensuring the integrity and immutability of transaction data.

[0433] The first target transaction state data digest value is the transaction state data digest value of the target transaction recorded by the target blockchain node. Specifically, the transaction state data digest value is the transaction read-write set hash value (TxRWSetHash), which is obtained by hashing the transaction read-write set corresponding to the target transaction.

[0434] Steps 2410 and 2420 are described in detail below.

[0435] In step 2410, a fourth key-value pair is stored in the target blockchain node, wherein the fourth key-value pair indicates the correspondence between the target transaction identifier and the first target transaction digest value.

[0436] The fourth key-value pair indicates the correspondence between the target transaction identifier and the first target transaction summary value. (See reference...) Figure 22A In the fourth key-value pair, the target transaction identifier is used as the fourth key, and the first target transaction digest value is used as the fourth value. Therefore, by searching the database of the target blockchain node based on the target transaction identifier, the first target transaction digest value of the target transaction can be determined.

[0437] In step 2420, a fifth key-value pair is stored in the target blockchain node, wherein the fifth key-value pair indicates the correspondence between the target transaction identifier and the first target transaction state data digest value.

[0438] The fifth key-value pair indicates the correspondence between the target transaction identifier and the first target transaction status data digest value. (See reference...) Figure 22A In the fifth key-value pair, the target transaction identifier is used as the fifth key, and the first target transaction state data digest value is used as the fifth value. Therefore, by searching the database of the target blockchain node based on the target transaction identifier, the first target transaction state data digest value of the target transaction can be determined.

[0439] It should be noted that, in order to distinguish the target transaction identifier in the third, fourth, and fifth key-value pairs within the target blockchain node's database, this embodiment of the disclosure may add a prefix to the target transaction identifier. (Refer to...) Figure 22A The target transaction identifier in the third key-value pair is represented as TxI d, the target transaction identifier in the fourth key-value pair is represented as HTxI d, and the target transaction identifier in the fifth key-value pair is represented as RTxI d.

[0440] In the embodiments of steps 2410 and 2420 above, a fourth key-value pair and a fifth key-value pair are stored in the target blockchain node. The fourth key-value pair indicates the correspondence between the target transaction identifier and the first target transaction digest value, and the fifth key-value pair indicates the correspondence between the target transaction identifier and the first target transaction status data digest value. The key-value storage method facilitates the quick retrieval of the first target transaction digest value from the fourth key-value pair and the quick retrieval of the first target transaction status data digest value from the fifth key-value pair using the target transaction identifier. The rapid retrieval of the first target transaction digest value and the first target transaction status digest value improves the speed of obtaining the data required for verification, thereby improving the processing efficiency of transaction acquisition requests.

[0441] In step 2330, the acquired target transaction is verified using the target transaction verification data.

[0442] In embodiments of steps 2410 and 2420 described above, a fourth key-value pair and a fifth key-value pair are stored in the target blockchain node. The fourth key-value pair indicates the correspondence between the target transaction identifier and the first target transaction digest value, and the fifth key-value pair indicates the correspondence between the target transaction identifier and the first target transaction status data digest value. In this case, in one embodiment, referring to... Figure 25 Step 2330 includes:

[0443] Step 2510: Obtain the first target transaction digest value based on the target transaction identifier and the fourth key-value pair;

[0444] Step 2520: Perform a digest operation on the target transaction to obtain the second target transaction digest value;

[0445] Step 2530: Based on the target transaction identifier and the fifth key-value pair, obtain the first target transaction status data digest value;

[0446] Step 2540: Perform a digest operation on the state data after the target transaction is executed to obtain the second target transaction state data digest value;

[0447] Step 2550: Verify the obtained target transaction based on the comparison of the first target transaction digest value and the second target transaction digest value, and the comparison of the first target transaction status data digest value and the second target transaction status data digest value.

[0448] Steps 2510 to 2550 are described in detail below.

[0449] In step 2510, the first target transaction digest value is obtained based on the target transaction identifier and the fourth key-value pair.

[0450] The transaction retrieval request contains the target transaction identifier. Parsing the transaction retrieval request yields the target transaction representation.

[0451] The target blockchain node searches its local database using the target transaction identifier as the key to obtain the fourth key-value pair, and then determines the first target transaction digest value.

[0452] In step 2520, a digest operation is performed on the target transaction to obtain the second target transaction digest value.

[0453] The second target transaction digest value is a transaction digest value determined based on the target transaction obtained from the full storage node. Specifically, the transaction digest value is the transaction hash value.

[0454] After determining the target transaction, a digest operation, i.e. a hash operation, is performed on the target transaction to obtain the second target transaction digest value.

[0455] In step 2530, the first target transaction status data digest value is obtained based on the target transaction identifier and the fifth key-value pair.

[0456] The target blockchain node searches its local database using the target transaction identifier as the key to obtain the fifth key-value pair, and then determines the first target transaction status data digest value.

[0457] In step 2540, a digest operation is performed on the state data after the target transaction is executed to obtain the second target transaction state data digest value.

[0458] The second target transaction status data digest value is a transaction status data digest value determined based on the status data of the target transaction after execution obtained from the full storage node. Specifically, the transaction status data digest value is the transaction read-write set hash value.

[0459] After identifying the target transaction, a hash operation is performed on the state data after the target transaction is executed to obtain a hash value for the second target transaction state data. Specifically, a hash operation is performed on the target transaction read / write set corresponding to the target transaction to obtain the hash value for the second target transaction state data.

[0460] In step 2550, the obtained target transaction is verified based on the comparison between the first target transaction digest value and the second target transaction digest value, and the comparison between the first target transaction status data digest value and the second target transaction status data digest value.

[0461] After determining the second target transaction digest value and the second target transaction status data digest value, the first target transaction digest value and the second target transaction digest value, as well as the first target transaction status data digest value and the second target transaction status data digest value, are compared respectively to verify the target transaction based on the comparison results.

[0462] If the first target transaction digest value and the second target transaction digest value are the same, and the first target transaction status data digest value and the second target transaction status data digest value are also the same, then the target transaction verification is successful. If the first target transaction digest value and the second target transaction digest value are not the same, or if the first target transaction status data digest value and the second target transaction status data digest value are not the same, then the target transaction verification fails, and the target transaction needs to be retrieved again from other full storage nodes.

[0463] Reference Figure 20 and Figure 22A Blockchain node 1 is a non-full storage node for the target block. After receiving the target block from blockchain node 2 (the full storage node), blockchain node 1 parses the target transaction to calculate the second target transaction digest value and the second target transaction status data digest value. Based on the target transaction identifier, it searches for the fourth and fifth key-value pairs to determine the first target transaction digest value and the first target transaction status data digest value. Then, it compares the first and second target transaction digest values, and the first and second target transaction status data digest values, respectively. If both are equal, the verification is successful, and the target block is returned to the client. Otherwise, the verification fails, and another node needs to be used to re-obtain the target transaction.

[0464] The embodiments of steps 2510 to 2550 described above use a lookup in the fourth key-value pair based on the target transaction identifier to quickly determine the first target transaction digest value, and a lookup in the fifth key-value pair based on the target transaction identifier to quickly determine the first target transaction status data digest value. Both the first target transaction digest value and the first target transaction status data digest value are target verification data. The rapid acquisition of the target verification data facilitates the early verification of the second target transaction digest value and the second target transaction status data digest value of the target transaction obtained from the full storage node, improving the verification efficiency of the target transaction. Furthermore, the verification of the second target transaction digest value and the second target transaction status data digest value of the target transaction improves the verification effect of the target transaction and ensures the security of the blockchain data.

[0465] In one embodiment, the target transaction verification data includes a first target transaction digest value and a first target transaction status data digest value.

[0466] Reference Figure 26 Step 330 includes:

[0467] Step 2610: In the target blockchain node, store the sixth key-value pair, wherein the sixth key-value pair indicates the correspondence between the target transaction identifier, the first target transaction digest value, and the first target transaction status data digest value.

[0468] Step 2610 will be described in detail below.

[0469] In step 2610, a sixth key-value pair is stored in the target blockchain node, wherein the sixth key-value pair indicates the correspondence between the target transaction identifier, the first target transaction digest value, and the first target transaction status data digest value.

[0470] The sixth key-value pair indicates the correspondence between the target transaction identifier, the first target transaction digest value, and the first target transaction status data digest value. (See reference...) Figure 22B In the sixth key-value pair, the target transaction identifier is used as the sixth value, and the first target transaction digest value and the first target transaction status data digest value are used as the sixth key. Therefore, by searching the database of the target blockchain node based on the target transaction identifier, the target transaction verification data, namely the first target transaction digest value and the first target transaction status data digest value, can be determined.

[0471] It should be noted that, referring to Figure 22B In this embodiment, the third key-value pair and the sixth key-value pair are merged. In the merged key-value pair, the target transaction identifier is the key, and the target block height, target transaction index, first target transaction digest value, and first target transaction status data digest value are the keys. Therefore, by searching the database of the target blockchain node based on the target transaction identifier, the target block height of the target block to which the target transaction belongs, the target transaction index, the first target transaction digest value, and the first target transaction status data digest value can be determined. Thus, during the verification process of the target transaction, it is not necessary to search the local database again using the target transaction identifier as the key, thereby improving the verification efficiency of the target transaction.

[0472] In the embodiment of step 2610 above, a sixth key-value pair is stored in the target blockchain node. The sixth key-value pair indicates the correspondence between the target transaction identifier, the first target transaction digest value, and the first target transaction status data digest value. That is, multiple values ​​are corresponding to the target transaction identifier as the key. The target transaction verification data is stored in the form of a single key. The first target transaction digest value and the first target transaction status data digest value can be determined with only one query, which reduces the time required to query the key-value pair and improves the verification efficiency of the target transaction.

[0473] In an embodiment of step 2610 above, a sixth key-value pair is stored in the target blockchain node, and the sixth key-value pair indicates the correspondence between the target transaction identifier, the first target transaction digest value, and the first target transaction status data digest value. In this case, in one embodiment, refer to... Figure 27 Step 2330 includes:

[0474] Step 2710: Based on the target transaction identifier and the sixth key-value pair, obtain the first target transaction digest value and the first target transaction status data digest value;

[0475] Step 2720: Perform a digest operation on the target transaction to obtain the second target transaction digest value;

[0476] Step 2730: Perform a digest operation on the state data after the target transaction is executed to obtain the second target transaction state data digest value;

[0477] Step 2740: Verify the obtained target transaction based on the comparison of the first target transaction digest value and the second target transaction digest value, and the comparison of the first target transaction status data digest value and the second target transaction status data digest value.

[0478] Steps 2710 to 2740 are described in detail below.

[0479] In step 2710, the first target transaction digest value and the first target transaction status data digest value are obtained based on the target transaction identifier and the sixth key-value pair.

[0480] The sixth key-value pair indicates the correspondence between the target transaction identifier, the first target transaction digest value, and the first target transaction status data digest value. Therefore, by looking up the target transaction identifier in the sixth key-value pair, the first target transaction digest value and the first target transaction status data digest value can be determined.

[0481] In step 2720, a digest operation is performed on the target transaction to obtain the second target transaction digest value.

[0482] After determining the target transaction, a digest operation, i.e. a hash operation, is performed on the target transaction to obtain the second target transaction digest value.

[0483] In step 2730, a digest operation is performed on the state data after the target transaction is executed to obtain the second target transaction state data digest value.

[0484] After determining the target transaction, a digest operation is performed on the state data after the target transaction is executed. That is, a hash calculation is performed on the transaction read and write set of the target transaction to obtain the digest value of the second target transaction state data.

[0485] In step 2740, the obtained target transaction is verified based on the comparison between the first target transaction digest value and the second target transaction digest value, and the comparison between the first target transaction status data digest value and the second target transaction status data digest value.

[0486] The acquired target transaction can be verified based on the target transaction verification data, namely the first target transaction digest value and the first target transaction status data digest value. Specifically, the first target transaction digest value and the second target transaction digest value, as well as the first target transaction status data digest value and the second target transaction status data digest value, are compared respectively, and the target transaction is verified based on the comparison results.

[0487] If the first target transaction digest value and the second target transaction digest value are the same, and the first target transaction status data digest value and the second target transaction status data digest value are also the same, then the target transaction verification is successful. If the first target transaction digest value and the second target transaction digest value are not the same, or if the first target transaction status data digest value and the second target transaction status data digest value are not the same, then the target transaction verification fails, and the target transaction needs to be retrieved again from other full storage nodes.

[0488] Reference Figure 20 and Figure 22B Blockchain node 1 is a non-full storage node for the target block. After receiving the target block from blockchain node 2 (the full storage node), blockchain node 1 parses the target transaction to calculate the second target transaction digest value and the second target transaction status data digest value. Based on the target transaction identifier, it searches for the sixth key-value pair to determine the first target transaction digest value and the first target transaction status data digest value. Then, it compares the first and second target transaction digest values, and the first and second target transaction status data digest values, respectively. If the first and second target transaction digest values ​​are equal, and the first and second target transaction status data digest values ​​are also equal, the verification is successful, and the target block is returned to the client. Otherwise, the verification fails, and another node needs to be used to re-obtain the target transaction.

[0489] In the embodiments described above, steps 2710 to 2740, when storing the correspondence between the target transaction identifier, the first target transaction digest value, and the first target transaction status data digest value through a sixth key-value pair, can quickly determine the first target transaction digest value and the first target transaction status data digest value (i.e., the target transaction verification data) from the sixth key-value pair based on the target transaction identifier. Storing the target transaction verification data through a single key-value pair reduces repeated queries on the key-value pair, improves the efficiency of obtaining the target transaction verification data, and thus improves the efficiency of verifying the target transaction.

[0490] It should be noted that the blockchain network provided in this disclosure provides a transaction query service, the corresponding interface of which is GetTxByI d(TxI d[]byte). This interface indicates that it can provide a service to query information of a target transaction based on the target transaction identifier, where TxI d[] represents the target transaction identifier of the target transaction corresponding to the transaction acquisition request.

[0491] Full storage node's processing of the blockchain

[0492] For the target block, the blockchain network includes not only non-full storage nodes but also full storage nodes. Full storage nodes store all the data of the target block and can also provide block query services and transaction query services.

[0493] In one embodiment, reference is made to Figure 28 After step 310, the blockchain processing method provided in this embodiment further includes:

[0494] Step 2810: Based on the predetermined non-full storage node determination rules, determine that the target blockchain node is the full storage node of the target block;

[0495] Step 2820: Store the key-value pair table of the target block on the target blockchain node;

[0496] Step 2830: In response to receiving a block retrieval request for the target block, generate the target block using a key-value pair table.

[0497] Steps 2810 to 2830 are described in detail below.

[0498] In step 2810, based on the predetermined non-full storage node determination rules, the target blockchain node is determined to be the full storage node of the target block.

[0499] For a target block, blockchain nodes in the blockchain network can be divided into full storage nodes and non-full storage nodes. Based on predetermined rules for determining non-full storage nodes, it can be determined that the target blockchain node is a full storage node for the target block.

[0500] It should be noted that the number of blockchain nodes in the blockchain network is 3f+1, where f is the maximum number of malicious nodes that may appear in the blockchain network, which can also be understood as the maximum number of target blocks that each node in the blockchain network may fail to store, and f is a positive integer. Based on the predetermined rules for determining non-full storage nodes, a starting full storage node is determined in the blockchain network. Then, f+1 blockchain nodes are counted starting from the starting full storage node. If the target blockchain node belongs to f+1 blockchain nodes, the target blockchain node is determined to be the full storage node for the target block.

[0501] In addition, the blockchain node index of the starting full storage node is determined based on the remainder of the target block height modulo a first number, where the first number is the number of blockchain nodes in the blockchain network.

[0502] Reference Figure 4 Assuming the target block is block 3 and the target blockchain node is blockchain node 4, then the total number of blockchain nodes in the blockchain network is 4. The remainder of the target block height modulo the number of blockchain nodes is 3, thus determining that the initial full storage node is blockchain node 3. Since the number of blockchain nodes is 4, we can determine that f is 1, thus determining that the number of full storage nodes is 2. Therefore, blockchain nodes 3 and 4 are the full storage nodes for the target block, and the target blockchain node is the full storage node.

[0503] It should be noted that regardless of whether the number of blockchain nodes in the blockchain network is 3f+1, 3f+2, or 3f+3, the number of full storage nodes in the blockchain network is always f+1. Therefore, in the scenario where a blockchain node acts maliciously, the blockchain network can retain at least one correct target block.

[0504] In step 2820, the key-value pair table of the target block is stored in the target blockchain node.

[0505] The key-value mapping table is the storage structure of all the data of the target block in the target blockchain node. Figure 30A This is a schematic diagram of the block structure provided in an embodiment of this disclosure. The complete data of the target block includes the full block header data, a transaction set, a directed acyclic graph, and additional information. Additional information refers to data added after the block is generated; this data does not participate in the calculation of the block digest value. The additional information is mainly used to store some extra information, such as additional attributes of transactions and block metadata.

[0506] Figure 30B It is a key-value table of the target block, which stores all the data of the target block.

[0507] In step 2830, in response to receiving a block retrieval request for the target block, the target block is generated using a key-value pair table.

[0508] Since the target blockchain node is the full storage node for the target block, after receiving the block retrieval request for the target block, it can directly generate the target block through the key-value pair table stored in the local database.

[0509] Reference Figure 29Blockchain node 2 is the full storage node for the target block. After receiving a block retrieval request from the client, blockchain node 2 can process the request to generate the target block corresponding to the request, and then return the generated target block to the client.

[0510] In the embodiments of steps 2810 to 2830 above, the target blockchain node is the full storage node of the target block and stores all the data of the target block through a key-value pair table. Therefore, after receiving the block retrieval request of the target block, it is only necessary to generate the target block using the key-value pair table, which improves the generation speed of the target block. In addition, the full storage node in this method provides a block query service, so both full storage nodes and non-full storage nodes in the blockchain network can provide block query services, which provides security for blockchain data processing.

[0511] The above is a general description of steps 2810 to 2830. Since steps 2810 and 2820 have been described in detail above, the specific implementation process of step 2830 will be described in detail below.

[0512] In step 2830, in response to receiving a block retrieval request for the target block, the target block is generated using a key-value pair table.

[0513] In one embodiment, the key-value pair table includes a seventh key-value pair and an eighth key-value pair, wherein the seventh key-value pair indicates the correspondence between the target block height and the full data of the block header, and the eighth key-value pair indicates the correspondence between the target block height, the transaction index and the transaction, and the full data of the block header contains the total number of transactions in the target block.

[0514] Reference Figure 31 Step 2830 includes:

[0515] Step 3110: Based on the block retrieval request, obtain the target block height of the target block;

[0516] Step 3120: Based on the target block height and the seventh key-value pair, obtain the full block header data and extract the total number of transactions from the full block header data;

[0517] Step 3130: Based on the total number of transactions, obtain the transactions corresponding to the target block height and each transaction index in the eighth key-value pair;

[0518] Step 3140: Generate the target block based on the target block height and the transactions corresponding to each transaction index.

[0519] It should be noted that the seventh key-value pair is used to indicate the correspondence between the target block height and the full block header data. (See reference...) Figure 30BIn the seventh key-value pair, the target block height is used as the seventh key, and the full block header data is used as the seventh value.

[0520] The seventh key-value pair stores the full block header data, which is the serialized information of the full block header data. Specifically, the full block header data is serialized according to a certain order and format, converting it into a byte string. Furthermore, different blockchains may use different serialization methods, but they generally follow the principle of fixed or variable length conversion.

[0521] The eighth key-value pair indicates the correspondence between the target block height and the full block header data. (See reference...) Figure 30B In the eighth value pair, the target block height and transaction index are used as the eighth key, and the transaction is used as the eighth value.

[0522] It should be noted that, referring to Figure 9A The block header data includes the total number of transactions, which indicates the total number of transactions recorded in the target block. Figure 30A The total number of transactions corresponding to the block shown is 4.

[0523] Steps 3110 to 3140 are described in detail below.

[0524] In step 3110, the target block height of the target block is obtained based on the block acquisition request.

[0525] In response to a received block retrieval request, the request is parsed to determine the target block height. The block retrieval request may directly contain the target block height, or it may contain other information about the target block. The target blockchain node then queries a key-value table based on the other information in the block retrieval request to determine the target block height.

[0526] In step 3120, based on the target block height and the seventh key-value pair, the full block header data is obtained, and the total number of transactions is extracted from the full block header data.

[0527] Since the seventh key-value pair indicates the correspondence between the target block height and the full block header data, the full block header data can be determined by searching the seventh key-value pair with the target block height as the key, and thus the total number of transactions in the target block can be determined.

[0528] In step 3130, based on the total number of transactions, the transactions corresponding to the target block height and each transaction index in the eighth key-value pair are obtained.

[0529] The eighth key-value pair indicates the correspondence between the target block height, transaction index, and transaction. Therefore, the eighth key-value pair stores all transactions in the target block. Based on the total number of transactions, the transaction index of each transaction in the target block can be determined. Then, based on the target block height and each transaction index, the total number of transactions can be obtained from the eighth key-value pair.

[0530] The eighth key-value pair is used to indicate the correspondence between the target block height, the transaction index, and the transaction. Specifically, the eighth key-value pair includes the total number of key-value pairs for the transactions.

[0531] In step 3140, a target block is generated based on the target block height and the transactions corresponding to each transaction index.

[0532] Based on the target block height and the transactions corresponding to each transaction index, the transaction set of the target block can be determined. Then, based on the transaction set, the full data of the block header, and other data information in the target block, the target block can be generated.

[0533] Reference Figure 29 and Figure 30B Blockchain node 2 is the full storage node for the target block. Upon receiving a block retrieval request from the client, it parses the request to obtain the target block height. Then, using the target block height as the key, it queries the local database to obtain the seventh key-value pair, thereby determining the full block header data. This full block header data includes the total number of transactions in the block header. Based on the total number of transactions, it retrieves the transactions corresponding to the target block height and each transaction index from the eighth key-value pair, generating the target block based on the total number of transactions and the full block header data.

[0534] In the embodiments of steps 3110 to 3140 above, a seventh key-value pair and an eighth key-value pair are stored in the blockchain node. The seventh key-value pair indicates the correspondence between the target block height and the full data of the block header, and the eighth key-value pair indicates the correspondence between the target block height, the transaction index, and the transaction. During the processing of the block acquisition request, the full data of the block header and each transaction of the target block header can be obtained based on the seventh key-value pair and the eighth key-value pair, thereby improving the correctness of the generated target block. Moreover, the key-value storage method improves the query efficiency of the full data of the block header and each transaction, and improves the processing efficiency of the block acquisition request.

[0535] The above is a general description of steps 3110 to 3140. Since step 3120 has been described in detail above, the specific implementation process of steps 3110, 3130 and 3140 will be described in detail below.

[0536] In step 3110, the target block height of the target block is obtained based on the block acquisition request.

[0537] In one embodiment, the key-value pair table further includes a ninth key-value pair, wherein the ninth key-value pair indicates the correspondence between the target block digest value and the target block height; the block retrieval request includes the target block digest value of the target block.

[0538] Reference Figure 32 Step 3110 includes:

[0539] Step 3210: Obtain the target block digest value from the block retrieval request;

[0540] Step 3220: Determine the target block height based on the target block digest value and the ninth key value pair.

[0541] It should be noted that the ninth key-value pair is used to indicate the correspondence between the target block digest value and the target block height. (See reference...) Figure 30B In the ninth key-value pair, the target block digest value is used as the ninth key, and the target block height is used as the ninth value.

[0542] The target block digest value corresponds to the target block, specifically the block hash value of the target block.

[0543] Steps 3210 and 3220 are described in detail below.

[0544] In step 3210, the target block digest value is obtained from the block retrieval request.

[0545] The block retrieval request contains the target block digest value of the target block. Therefore, the target block digest value can be extracted from the block retrieval request.

[0546] In step 3220, the target block height is determined based on the target block digest value and the ninth key value pair.

[0547] After determining the target block digest value, the target block height is obtained by searching the ninth key-value pair with the target block digest value as the key.

[0548] Reference Figure 29 and 30B Blockchain node 2, as the full storage node of the target block, can determine the target block digest value after receiving the block retrieval request, and then query the target block height corresponding to the target block digest value from the ninth key-value pair.

[0549] In the embodiments of steps 3210 and 3220 above, the block retrieval request includes the target block digest value of the target block. Based on the target block digest value and the ninth key-value pair, the height of the target block can be determined. This method can provide a service for querying the target block based on the target block digest value by setting the ninth key-value pair.

[0550] In step 3130, based on the total number of transactions, the transactions corresponding to the target block height and each transaction index in the eighth key-value pair are obtained.

[0551] In one embodiment, reference is made to Figure 33 Step 3130 includes:

[0552] Step 3310: Initialize the transaction index to be acquired to 0;

[0553] Step 3320: Iteratively execute the target process until the transaction index to be obtained is not less than the total number of transactions.

[0554] The target process includes:

[0555] Step 3330: Obtain the transaction corresponding to the target block height and the transaction index to be obtained in the eighth key-value pair, and increment the transaction index to be obtained by 1.

[0556] Steps 3310 to 3330 are described in detail below.

[0557] In step 3310, the transaction index to be acquired is initialized to 0.

[0558] The transaction index to be retrieved is the position of the transaction within the target block. Within the target block, the transaction indices of multiple transactions increment from 0, therefore the initialization of the transaction index to be retrieved is 0.

[0559] In step 3320, the target process is executed iteratively until the transaction index to be obtained is not less than the total number of transactions.

[0560] The target execution process involves retrieving all transactions recorded in the target block. Since the total number of transactions is equal to the total number of transactions recorded in the target block, iteration stops when the index of the transaction to be retrieved is not less than the total number of transactions, in order to determine the total number of transactions.

[0561] In step 3330, the transaction corresponding to the target block height and the transaction index to be obtained in the eighth key-value pair is obtained, and the transaction index to be obtained is incremented by 1.

[0562] During the iterative execution of the target process, the corresponding transaction is first retrieved from the eighth key-value pair based on the target block height and the current transaction index to be retrieved, and the transaction index to be retrieved is incremented by 1. If the transaction index to be retrieved is less than the total number of transactions, the iterative execution of the target process continues. If the transaction index to be retrieved is not less than the total number of transactions, the iterative execution of the target process stops.

[0563] Reference Figure 29 and Figure 30BThe process begins by initializing the target block height and the target transaction index (i) to 0. Then, using the target block height and the target transaction index as keys, it queries the local database for the eighth key-value pair to retrieve the transaction corresponding to that index. The target transaction index is then incremented by 1. If the target transaction index (i) is less than the total number of transactions, the process returns to the step using the target block height and the target transaction index as keys. If the target transaction index is not less than the total number of transactions, the transaction query is stopped. Figure 30A If the target block shown has a total of 4 transactions, then the transaction query will stop when the transaction index to be obtained is 4.

[0564] In the embodiments of steps 3310 to 3330 above, the index of the transaction to be acquired is initialized to 0, and the target process is executed iteratively to acquire the total number of transactions. Specifically, the target process determines the transaction corresponding to the target block height and the index of the transaction to be acquired based on the eighth key-value pair. This method ensures the integrity of acquiring the multiple transactions corresponding to the target block, thereby improving the generation effect of the target block.

[0565] In step 3140, a target block is generated based on the target block height and the transactions corresponding to each transaction index.

[0566] In one embodiment, the key-value pair table further includes a tenth key-value pair, wherein the tenth key-value pair indicates the correspondence between the target block height and the additional information.

[0567] Reference Figure 34 Step 3140 includes:

[0568] Step 3410: Obtain additional information based on the target block height and the tenth key-value pair;

[0569] Step 3420: Generate the target block based on the target block height and the transaction and additional information corresponding to each transaction index.

[0570] It should be noted that the tenth key-value pair is used to indicate the correspondence between the target block height and additional information. (See reference...) Figure 30B In the tenth key-value pair, the target block height is used as the tenth key, and the additional information is used as the tenth value.

[0571] Additional data corresponds to the target block. Additional data refers to data appended after the block is generated; this data does not participate in the calculation of the block digest value. Additional data is mainly used to store extra information, such as transaction attributes and block metadata.

[0572] In the data of the target blockchain node, in order to distinguish the target block height in the tenth key-value pair from the target block height of other key-value pairs, the tenth key can be represented as ABlockHeight.

[0573] Steps 3410 and 3420 are described in detail below.

[0574] In step 3410, additional information is obtained based on the target block height and the tenth key-value pair.

[0575] By finding the tenth key-value pair based on the target block height, the additional information of the target block corresponding to the target block height can be determined.

[0576] In step 3420, the target block is generated based on the target block height and the transaction and additional information corresponding to each transaction index.

[0577] The target block height corresponds to the transactions in each transaction index, which are the individual transactions within the target block. After determining the additional information, the target block is generated based on the full block header data, the individual transactions within the target block, and the additional information.

[0578] Reference Figure 29 and Figure 30B In the process of determining the transaction of the target block, blockchain node 2 appends each transaction to the block as it is generated, and the block includes the full data of the block header. After all the transactions of the target block have been generated, additional information is retrieved from the tenth key-value pair in the local database using the target block height as the key, and the additional information is added to the block to generate the target block.

[0579] It should be noted that, referring to Figure 30A The target block also includes a directed acyclic graph, which can be determined based on the data information corresponding to each transaction in the target block.

[0580] In the embodiments of steps 3410 and 3420 above, a tenth key-value pair is stored in the target blockchain node. The tenth key-value pair is used to indicate the correspondence between the target block height and the additional information. Therefore, the additional information can be determined from the tenth key-value pair based on the target block height to ensure the integrity of the generated target block.

[0581] In one embodiment, reference is made to Figure 5 Blockchain node 2 is the full storage node for the target block, and it can generate the target block based on requests from blockchain node 1, which is a non-full storage node. Figure 5 The process of blockchain node 2 generating the target block is as follows: Figure 35As shown. Blockchain node 2 uses the target block height as the key to query the local database, obtaining the seventh key-value pair, and thus determining the full data of the block header, which includes the total number of transactions in the block header. Next, it initializes the transaction index i to be retrieved to 0, and then uses the target block height and the transaction index to retrieve the eighth key-value pair in the local database to retrieve the transaction corresponding to the target block height and the transaction index. Then, it increments the transaction index i by 1. If the transaction index i is less than the total number of transactions, it returns to the step using the target block height and the transaction index as the key. If the transaction index i is not less than the total number of transactions, it stops iterating through the target process. During the process of determining the transactions for the target block, blockchain node 2 appends each generated transaction to the block, and the block includes the full data of the block header. After all transactions for the target block are generated, it retrieves additional information from the tenth key-value pair in the local database using the target block height as the key, and adds the additional information to the block, thus generating the target block.

[0582] In one embodiment, reference is made to Figure 36 After step 2820, the blockchain processing method provided in this embodiment further includes:

[0583] Step 3610: In response to receiving a transaction retrieval request for the target transaction in the target block, retrieve the target transaction using the key-value pair table.

[0584] Step 3610 will be described in detail below.

[0585] In step 3610, in response to receiving a transaction retrieval request for the target transaction in the target block, the target transaction is retrieved using a key-value pair table.

[0586] The full storage node in this embodiment can also provide transaction query services. Specifically, the target blockchain node, as the full storage node of the target block, retrieves the target transaction using a key-value table after receiving a transaction retrieval request for the target transaction in the target block.

[0587] Reference Figure 37 Blockchain node 2, as a full storage node, responds to the transaction retrieval request of the target transaction in the target block by using the key-value pair table to retrieve the target transaction.

[0588] In the embodiment of step 3610 above, the target blockchain node responds to the transaction retrieval request received from the target transaction in the target block by retrieving the target transaction using a key-value pair table, so that the full storage node can provide transaction query requests, thus ensuring the security of blockchain data processing.

[0589] The above is a general description of step 3610. The following is a detailed description of the specific implementation process of step 3610.

[0590] In step 3610, in response to receiving a transaction retrieval request for the target transaction in the target block, the target transaction is retrieved using a key-value pair table.

[0591] In one embodiment, the key-value table includes an eleventh key-value pair and an eighth key-value pair, wherein the eleventh key-value pair indicates the correspondence between the target transaction identifier, the target block height, and the target transaction index, and the eighth key-value pair indicates the correspondence between the target block height, the target transaction index, and the target transaction. The transaction acquisition request includes the target transaction identifier.

[0592] Reference Figure 38 Step 3610 includes:

[0593] Step 3810: Obtain the target transaction identifier from the transaction acquisition request;

[0594] Step 3820: Based on the target transaction identifier and the eleventh key-value pair, obtain the target block height and the target transaction index;

[0595] Step 3830: Based on the target block height and the target transaction index, retrieve the target transaction from the eighth key-value pair.

[0596] It should be noted that the eighth key-value pair is used to indicate the correspondence between the target block height, the target transaction index, and the target transaction. (See reference...) Figure 30B In the eighth key-value pair, the target block height and the target transaction index are used as the eighth key, and the target transaction is used as the eighth value.

[0597] The eleventh key-value pair indicates the correspondence between the target transaction identifier, the target block height, and the target transaction index. (See reference...) Figure 30B In the eleventh key-value pair, the target transaction identifier is used as the eleventh key, and the target block height and the target transaction index are used as the eleventh value.

[0598] Steps 3810 to 3830 are described in detail below.

[0599] In step 3810, the target transaction identifier is obtained from the transaction acquisition request.

[0600] The transaction retrieval request contains the target transaction identifier. Therefore, the target blockchain node can determine the target transaction identifier from the received transaction retrieval request.

[0601] In step 3820, the target block height and target transaction index are obtained based on the target transaction identifier and the eleventh key-value pair.

[0602] After determining the target transaction identifier, the eleventh key-value pair can be found based on the target transaction identifier to determine the target block height of the target block to which the target transaction belongs and the target transaction index of the target transaction.

[0603] In step 3830, the target transaction is retrieved from the eighth key-value pair based on the target block height and the target transaction index.

[0604] By finding the eighth key-value pair based on the target block height and the target transaction index, the target transaction corresponding to the target block height and the target transaction index can be determined.

[0605] Reference Figure 37 and Figure 30B Blockchain node 2, acting as the full storage node for the target block, responds to the received transaction retrieval request by parsing it to obtain the target transaction identifier. Then, using the target transaction identifier as the key, it queries the eleventh key-value pair in the local database to determine the target block height and the target transaction index. Based on the target transaction identifier and the target transaction index, the target transaction can be retrieved from the eighth key-value pair.

[0606] The embodiments of steps 3810 to 3830 described above include an eighth key-value pair and an eleventh key-value pair. The eighth key-value pair indicates the correspondence between the target block height, the target transaction index, and the target transaction. The eleventh key-value pair indicates the correspondence between the target transaction identifier, the target block height, and the target transaction index. Therefore, during the process of querying a target transaction, the eighth and eleventh key-value pairs can be searched based on the transaction retrieval request to determine the target transaction, thereby ensuring the accuracy of the retrieved target transaction and enabling the full storage nodes to provide a service for querying target transactions based on the target transaction identifier. Furthermore, the use of the eighth and eleventh key-value pairs allows for rapid retrieval of target transactions, improving the efficiency of blockchain data processing.

[0607] It is understood that although the steps in the above flowcharts are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated in this embodiment, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the above flowcharts may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps.

[0608] It should be noted that in various specific embodiments of this application, when processing is required based on data related to the characteristics of the target object, such as target object attribute information or a set of attribute information, the permission or consent of the target object will be obtained first. Furthermore, the collection, use, and processing of this data will comply with relevant laws, regulations, and standards. In addition, when embodiments of this application require obtaining target object attribute information, separate permission or consent from the target object will be obtained through pop-ups or redirection to a confirmation page. Only after obtaining the target object's separate permission or consent will the necessary target object-related data for the normal operation of the embodiments of this application be obtained.

[0609] Description of apparatus and devices according to embodiments of this disclosure

[0610] Figure 39 This is a schematic diagram of the structure of a blockchain processing device provided in an embodiment of the present disclosure. The blockchain processing device 3900 is located at a target blockchain node in a blockchain network and includes:

[0611] Acquisition unit 3910 is used to acquire the target block to be recorded on the blockchain.

[0612] The first determining unit 3920 is used to determine, based on a predetermined non-full storage node determining rule, that the target blockchain node is a non-full storage node of the target block, wherein the non-full storage node is a blockchain node that only stores a portion of the data of the target block, and the portion of the data includes the target block verification data.

[0613] The first storage unit 3930 is used to store part of the data of the target block on the target blockchain node.

[0614] The first verification unit 3940 is used to respond to a block retrieval request for a target block received, retrieve the target block from a full storage node in the blockchain network, and verify the retrieved target block using the target block verification data. The full storage node is a blockchain node that stores all the data of the target block.

[0615] Optionally, the number of blockchain nodes in the blockchain network is 3f+1, where f is a positive integer;

[0616] The first determining unit 3920 is specifically used for:

[0617] Based on the predetermined rules for determining non-full storage nodes, the starting non-full storage node is determined in the blockchain network;

[0618] In a blockchain network, count 2f blockchain nodes starting from the initial non-full storage node;

[0619] If the target blockchain node belongs to 2f blockchain nodes, then the target blockchain node is determined to be a non-full storage node of the target block.

[0620] Optionally, the first determining unit 3920 is further used for:

[0621] Get the target block height of the target block;

[0622] The blockchain node index is determined based on the remainder of the target block height modulo a first number, where the first number is the number of blockchain nodes in the blockchain network.

[0623] The blockchain node corresponding to the blockchain node index in the blockchain network is determined as the starting non-full storage node.

[0624] Optionally, there may be multiple full storage nodes;

[0625] The first verification unit 3940 is specifically used for:

[0626] Obtain the channel status between each full storage node and the target blockchain node;

[0627] Based on the channel state, the target full storage node is determined from each full storage node;

[0628] Retrieve the target block from the target full storage node.

[0629] Optionally, the target block verification data includes the first target block digest value;

[0630] The first verification unit 3940 is specifically used for:

[0631] Calculate the total transaction digest value of each transaction in the target block;

[0632] Calculate the overall state data summary value of each transaction in the target block;

[0633] Calculate the second target block digest value of the target block based on the total transaction digest value, the total status data digest value, and the full block header data in the target block;

[0634] The obtained target block is verified by comparing the digest values ​​of the first target block and the second target block.

[0635] Optionally, the target block verification data includes information about the first node to initiate the blockchain.

[0636] The first verification unit 3940 is also specifically used for:

[0637] If the digest value of the first target block is the same as the digest value of the second target block, extract the information of the second on-chain initiating node from the obtained target block;

[0638] The target block is verified by comparing the information of the first and second on-chain initiating nodes.

[0639] Optionally, the first verification unit 3940 is further used for:

[0640] If the information of the first on-chain initiating node is consistent with that of the second on-chain initiating node, obtain the first signature reserved by the on-chain initiating node.

[0641] Extract the second signature of the on-chain initiating node from the obtained target block;

[0642] The target block is verified by comparing the first signature and the second signature.

[0643] Optionally, the first verification unit 3940 is further used for:

[0644] Calculate the transaction digest value for each transaction in the target block;

[0645] Generate a transaction summary tree, where the bottom-level nodes of the transaction summary tree are the transaction summary values ​​of each transaction. The order of the transaction summary values ​​is consistent with the order of each transaction in the target block. Other nodes in the transaction summary tree, except for the bottom-level nodes, are obtained by performing a summary operation on the concatenation of two adjacent nodes at the next lower level of other nodes, until the root node of the top level is generated.

[0646] Determine the total transaction summary value based on the root node.

[0647] Optionally, the first verification unit 3940 is further used for:

[0648] Calculate the state data summary value of each transaction in the target block after execution;

[0649] Generate a state data digest tree, where the bottom-level nodes of the state data digest tree are the state data digest values ​​after each transaction is executed. Other nodes in the state data digest tree, except for the bottom-level nodes, are obtained by performing a digest operation on the concatenation of two adjacent nodes at the next lower level of other nodes, until the root node of the top level is generated.

[0650] Determine the overall state data summary value based on the root node.

[0651] Optionally, the first storage unit 3930 is specifically used for:

[0652] In the target blockchain node, the first key-value pair is stored, where the first key-value pair indicates the correspondence between the target block digest value and the target block height;

[0653] In the target blockchain node, a second key-value pair is stored, which indicates the correspondence between the target block height and the key data in the block header. The key data in the blockchain header contains the target block verification data.

[0654] Optionally, the block retrieval request includes the target digest value of the target block;

[0655] The first verification unit 3940 is specifically used for:

[0656] In response to receiving a block retrieval request for a target block, the system retrieves the target block from all storage nodes in the blockchain network and verifies the retrieved target block using target block verification data, including:

[0657] The target block height is determined based on the target block digest value and the first key-value pair;

[0658] Obtain the target block at the target block height from all storage nodes in the blockchain network;

[0659] Based on the target block height and the second key-value pair, obtain the key data of the block header, and extract the target block verification data from the key data of the block header;

[0660] Verify the obtained target block using the target block verification data.

[0661] Optionally, some of the data also includes target transaction verification data;

[0662] The blockchain processing device 3900 also includes:

[0663] The second verification unit is used to respond to a transaction retrieval request for a target transaction in the target block, retrieve the target transaction of the target block from the full storage node in the blockchain network, and verify the retrieved target transaction using the target transaction verification data.

[0664] Optionally, the first storage unit 3930 is specifically used for:

[0665] In the target blockchain node, a third key-value pair is stored, which indicates the correspondence between the target transaction identifier, the target block height, and the target transaction index.

[0666] Optionally, the transaction acquisition request includes the target transaction identifier of the target transaction;

[0667] The second verification unit is specifically used for:

[0668] The target block height and target transaction index are determined based on the target transaction identifier and the third key-value pair;

[0669] Obtain the target block at the target block height from all storage nodes in the blockchain network, and obtain the target transaction index from the target transaction within the target block;

[0670] The target transaction is verified using the target transaction verification data.

[0671] Optionally, the target transaction verification data includes a first target transaction digest value and a first target transaction status data digest value;

[0672] The first storage unit 3930 is specifically used for:

[0673] In the target blockchain node, a fourth key-value pair is stored, wherein the fourth key-value pair indicates the correspondence between the target transaction identifier and the first target transaction digest value;

[0674] In the target blockchain node, a fifth key-value pair is stored, where the fifth key-value pair indicates the correspondence between the target transaction identifier and the first target transaction state data digest value.

[0675] Optionally, the second verification unit is specifically used for:

[0676] Based on the target transaction identifier and the fourth key-value pair, obtain the first target transaction digest value;

[0677] Perform a digest operation on the target transaction to obtain the digest value of the second target transaction;

[0678] Based on the target transaction identifier and the fifth key-value pair, obtain the first target transaction status data digest value;

[0679] Perform a digest operation on the state data after the target transaction is executed to obtain a digest value of the second target transaction state data.

[0680] The obtained target transaction is verified by comparing the first target transaction digest value and the second target transaction digest value, and by comparing the first target transaction status data digest value and the second target transaction status data digest value.

[0681] Optionally, the target transaction verification data includes a first target transaction digest value and a first target transaction status data digest value;

[0682] The first storage unit 3930 is specifically used for:

[0683] In the target blockchain node, a sixth key-value pair is stored, which indicates the correspondence between the target transaction identifier, the first target transaction digest value, and the first target transaction status data digest value.

[0684] Optionally, the second verification unit is specifically used for:

[0685] Based on the target transaction identifier and the sixth key-value pair, obtain the first target transaction digest value and the first target transaction status data digest value;

[0686] Perform a digest operation on the target transaction to obtain the digest value of the second target transaction;

[0687] Perform a digest operation on the state data after the target transaction is executed to obtain a digest value of the second target transaction state data.

[0688] The obtained target transaction is verified by comparing the first target transaction digest value and the second target transaction digest value, and by comparing the first target transaction status data digest value and the second target transaction status data digest value.

[0689] Optionally, the blockchain processing device 3900 also includes:

[0690] The second determining unit is used to determine, based on a predetermined non-full storage node determining rule, whether the target blockchain node is the full storage node of the target block.

[0691] The second storage unit is used to store the key-value pair table of the target block in the target blockchain node;

[0692] The generation unit is used to generate the target block using a key-value pair table in response to a received block retrieval request for the target block.

[0693] Optionally, the key-value pair table contains a seventh key-value pair and an eighth key-value pair, wherein the seventh key-value pair indicates the correspondence between the target block height and the full data of the block header, and the eighth key-value pair indicates the correspondence between the target block height, the transaction index and the transaction, and the full data of the block header contains the total number of transactions in the target block;

[0694] The generating unit is specifically used for:

[0695] Based on the block retrieval request, obtain the target block height of the target block;

[0696] Based on the target block height and the seventh key-value pair, obtain the full block header data and extract the total number of transactions from the full block header data;

[0697] Based on the total number of transactions, retrieve the transactions corresponding to the target block height and each transaction index in the eighth key-value pair;

[0698] The target block is generated based on the target block height and the transactions corresponding to each transaction index.

[0699] Optionally, the key-value pair table also includes a ninth key-value pair, wherein the ninth key-value pair indicates the correspondence between the target block digest value and the target block height; the block retrieval request includes the target block digest value of the target block;

[0700] The generating unit is specifically used for:

[0701] Retrieve the target block digest value from the block retrieval request;

[0702] The target block height is determined based on the target block digest value and the ninth key value pair.

[0703] Optionally, the generating unit is further used for:

[0704] Initialize the index of the transaction to be retrieved to 0;

[0705] The target process is executed iteratively until the transaction index to be obtained is not less than the total number of transactions. The target process includes: obtaining the transaction whose target block height in the eighth key-value pair corresponds to the transaction index to be obtained, and incrementing the transaction index to be obtained by 1.

[0706] Optionally, the key-value pair table also includes a tenth key-value pair, wherein the tenth key-value pair indicates the correspondence between the target block height and the additional information;

[0707] The generating unit is also specifically used for:

[0708] Based on the target block height and the tenth key-value pair, obtain additional information;

[0709] The target block is generated based on the target block height and the transactions and additional information corresponding to each transaction index.

[0710] Optionally, the blockchain processing device 3900 also includes:

[0711] The second acquisition unit 3910 is used to retrieve the target transaction using a key-value pair table in response to receiving a transaction acquisition request for the target transaction in the target block.

[0712] Optionally, the key-value pair includes an eleventh key-value pair and an eighth key-value pair, wherein the eleventh key-value pair indicates the correspondence between the target transaction identifier, the target block height, and the target transaction index, and the eighth key-value pair indicates the correspondence between the target block height, the target transaction index, and the target transaction; the transaction acquisition request includes the target transaction identifier;

[0713] The second acquisition unit 3910 is specifically used for:

[0714] Obtain the target transaction identifier from the transaction acquisition request;

[0715] Based on the target transaction identifier and the eleventh key-value pair, obtain the target block height and the target transaction index;

[0716] The target transaction is retrieved from the eighth key value based on the target block height and the target transaction index.

[0717] Reference Figure 40 , Figure 40 This is a structural block diagram of a terminal portion of the blockchain processing method according to an embodiment of the present disclosure. The terminal includes: a radio frequency (RF) circuit 4010, a memory 4015, an input unit 4030, a display unit 4040, a sensor 4050, an audio circuit 4060, a wireless fidelity (WiFi) module 4070, a processor 4080, and a power supply 4090, among other components. Those skilled in the art will understand that... Figure 40 The terminal structure shown does not constitute a limitation on mobile phones or computers and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0718] The RF circuit 4010 can be used to receive and transmit signals during information transmission or calls. In particular, it receives downlink information from the base station and processes it with the processor 4080; in addition, it transmits uplink data to the base station.

[0719] The memory 4015 can be used to store software programs and modules. The processor 4080 executes various functional applications and data processing of the content terminal by running the software programs and modules stored in the memory 4015.

[0720] The input unit 4030 can be used to receive input numeric or character information, and to generate key signal inputs related to the settings and function control of the content terminal. Specifically, the input unit 4030 may include a touch panel 4031 and other input devices 4032.

[0721] Display unit 4040 can be used to display input or provided information, as well as various menus of the content terminal. Display unit 4040 may include display panel 4041.

[0722] Audio circuit 4060, speaker 4061, and microphone 4062 provide an audio interface.

[0723] In this embodiment, the processor 4080 included in the terminal can execute the blockchain processing method of the previous embodiment.

[0724] Figure 41This is a partial structural block diagram of a server for implementing the blockchain processing method of this disclosure. The server can vary significantly due to different configurations or performance, and may include one or more Central Processing Units (CPUs) 4122 (e.g., one or more processors) and a memory 4132, and one or more storage media 4130 (e.g., one or more mass storage devices) for storing application programs 4142 or data 4144. The memory 4132 and storage media 4130 can be temporary or persistent storage. The program stored in the storage media 4130 may include one or more modules (not shown in the diagram), each module including a series of instruction operations on the server. Furthermore, the CPU 4122 may be configured to communicate with the storage media 4130 and execute the series of instruction operations in the storage media 4130 on the server.

[0725] The server may also include one or more power supplies 4126, one or more wired or wireless network interfaces 4150, one or more input / output interfaces 4158, and / or one or more operating systems 4141, such as Windows Server™, MacOSX™, Unix™, Linux™, FreeBSD™, etc.

[0726] The central processing unit 4122 in the server can be used to execute the blockchain processing method of the present disclosure embodiments.

[0727] This disclosure also provides a computer-readable storage medium for storing program code for executing the blockchain processing methods of the foregoing embodiments.

[0728] This disclosure also provides a computer program product comprising a computer program. A processor of a computer device reads and executes the computer program, causing the computer device to perform the blockchain processing method described above.

[0729] In this application embodiment, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0730] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in this disclosure and the foregoing drawings are used to distinguish similar terms and are not necessarily used to describe a particular order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this disclosure described herein can be implemented, for example, in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “including,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatuses.

[0731] It should be understood that in this disclosure, "at least one item" refers to one or more items, and "more than one item" refers to two or more items. "And / or" is used to describe the relationship between related content, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related content are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0732] It should be understood that in the description of the embodiments disclosed herein, "multiple" means two or more, "greater than", "less than", "exceeding" etc. are understood to exclude the number itself, and "above", "below", "within" etc. are understood to include the number itself.

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

[0734] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0735] Furthermore, the functional units in the various embodiments of this disclosure can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0736] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this disclosure, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this disclosure. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0737] It should also be understood that the various implementation methods provided in this disclosure can be combined arbitrarily to achieve different technical effects.

[0738] The above is a detailed description of the embodiments of this disclosure. However, this disclosure is not limited to the above embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of this disclosure. All such equivalent modifications or substitutions are included within the scope defined by the claims of this disclosure.

Claims

1. A blockchain processing method, characterized in that, The blockchain processing method, executed by a target blockchain node in the blockchain network, includes: Retrieve the target block to be recorded on the blockchain; Based on the predetermined non-full storage node determination rules, the target blockchain node is determined to be a non-full storage node of the target block, wherein the non-full storage node is a blockchain node that only stores a portion of the data of the target block, and the portion of data includes the target block verification data; The target blockchain node stores the portion of data from the target block. In response to receiving a block retrieval request for the target block, the target block is retrieved from the full storage node in the blockchain network, and the retrieved target block is verified using the target block verification data, wherein the full storage node is a blockchain node that stores all the data of the target block.

2. The blockchain processing method according to claim 1, characterized in that, The number of blockchain nodes in the blockchain network is 3f+1, where f is a positive integer; The determination of the target blockchain node as a non-full storage node of the target block based on the predetermined non-full storage node determination rules includes: Based on the predetermined rules for determining non-full storage nodes, the starting non-full storage node is determined in the blockchain network; In the blockchain network, 2f blockchain nodes are counted starting from the initial non-full storage node; If the target blockchain node belongs to the 2f blockchain nodes, the target blockchain node is determined to be the non-full storage node of the target block.

3. The blockchain processing method according to claim 2, characterized in that, The determination of the starting non-full storage node in the blockchain network based on the predetermined non-full storage node determination rules includes: Obtain the target block height of the target block; The blockchain node index is determined based on the remainder of the target block height modulo a first number, wherein the first number is the number of blockchain nodes in the blockchain network. The blockchain node corresponding to the blockchain node index in the blockchain network is determined as the starting non-full storage node.

4. The blockchain processing method according to any one of claims 1-3, characterized in that, The target block verification data includes the first target block digest value; The step of verifying the acquired target block using the target block verification data includes: Calculate the total transaction digest value of each transaction in the target block obtained; Calculate the overall state data summary value of each transaction in the target block; Based on the total transaction digest value, the total status data digest value, and the full block header data in the target block, calculate the second target block digest value of the target block; The obtained target block is verified by comparing the first target block digest value with the second target block digest value.

5. The blockchain processing method according to claim 4, characterized in that, The target block verification data includes the information of the first on-chain initiating node; The step of verifying the obtained target block based on the comparison between the first target block digest value and the second target block digest value includes: If the first target block digest value is consistent with the second target block digest value, extract the second on-chain initiating node information from the obtained target block; The target block is verified by comparing the information of the first on-chain initiating node with the information of the second on-chain initiating node.

6. The blockchain processing method according to claim 5, characterized in that, The verification of the obtained target block based on the comparison between the first on-chain initiating node information and the second on-chain initiating node information includes: If the information of the first on-chain initiating node is consistent with the information of the second on-chain initiating node, obtain the first signature reserved by the on-chain initiating node; Extract the second signature of the on-chain initiating node from the obtained target block; The obtained target block is verified based on the comparison between the first signature and the second signature.

7. The blockchain processing method according to any one of claims 1-6, characterized in that, The storage of the portion of data of the target block on the target blockchain node includes: In the target blockchain node, a first key-value pair is stored, wherein the first key-value pair indicates the correspondence between the target block digest value and the target block height; In the target blockchain node, a second key-value pair is stored, wherein the second key-value pair indicates the correspondence between the target block height and the key data of the block header, and the key data of the blockchain header contains the target block verification data.

8. The blockchain processing method according to claim 7, characterized in that, The block retrieval request includes the target block digest value of the target block; The step of responding to receiving a block retrieval request for the target block, retrieving the target block from the full storage node in the blockchain network, and verifying the retrieved target block using the target block verification data includes: The target block height is determined based on the target block digest value and the first key-value pair; Obtain the target block at the target block height from the full storage node in the blockchain network; Based on the target block height and the second key-value pair, obtain the block header key data, and extract the target block verification data from the block header key data; The target block is verified using the target block verification data.

9. The blockchain processing method according to any one of claims 1-8, characterized in that, The data also includes target transaction verification data; After storing the partial data of the target block on the target blockchain node, the blockchain processing method further includes: In response to a transaction retrieval request for a target transaction in the target block, the target transaction of the target block is retrieved from the full storage node in the blockchain network, and the retrieved target transaction is verified using the target transaction verification data.

10. The blockchain processing method according to claim 9, characterized in that, The storage of the portion of data of the target block on the target blockchain node includes: The target blockchain node stores a third key-value pair, wherein the third key-value pair indicates the correspondence between the target transaction identifier, the target block height, and the target transaction index.

11. The blockchain processing method according to claim 10, characterized in that, The transaction acquisition request includes the target transaction identifier of the target transaction; The step of responding to a transaction retrieval request for a target transaction in the target block, retrieving the target transaction of the target block from the full storage node in the blockchain network, and verifying the retrieved target transaction using the target transaction verification data, includes: Based on the target transaction identifier and the third key-value pair, the target block height and the target transaction index are determined; From the full storage node in the blockchain network, obtain the target block at the target block height, and from the target block, obtain the target transaction with the target transaction index; The target transaction is verified using the target transaction verification data.

12. The blockchain processing method according to claim 11, characterized in that, The target transaction verification data includes a first target transaction digest value and a first target transaction status data digest value; The storage of the portion of data of the target block on the target blockchain node includes: In the target blockchain node, a fourth key-value pair is stored, wherein the fourth key-value pair indicates the correspondence between the target transaction identifier and the first target transaction digest value; The target blockchain node stores a fifth key-value pair, wherein the fifth key-value pair indicates the correspondence between the target transaction identifier and the first target transaction status data digest value.

13. The blockchain processing method according to claim 12, characterized in that, The step of verifying the acquired target transaction using the target transaction verification data includes: Based on the target transaction identifier and the fourth key-value pair, obtain the first target transaction digest value; Perform a digest operation on the target transaction to obtain a second target transaction digest value; Based on the target transaction identifier and the fifth key-value pair, obtain the first target transaction status data digest value; Perform a digest operation on the state data after the target transaction is executed to obtain a second target transaction state data digest value; The obtained target transaction is verified based on the comparison between the first target transaction digest value and the second target transaction digest value, and the comparison between the first target transaction status data digest value and the second target transaction status data digest value.

14. The blockchain processing method according to claim 11, characterized in that, The target transaction verification data includes a first target transaction digest value and a first target transaction status data digest value; The storage of the portion of data of the target block on the target blockchain node includes: The target blockchain node stores a sixth key-value pair, wherein the sixth key-value pair indicates the correspondence between the target transaction identifier, the first target transaction digest value, and the first target transaction status data digest value.

15. The blockchain processing method according to claim 14, characterized in that, The step of verifying the acquired target transaction using the target transaction verification data includes: Based on the target transaction identifier and the sixth key-value pair, obtain the first target transaction digest value and the first target transaction status data digest value; Perform a digest operation on the target transaction to obtain a second target transaction digest value; Perform a digest operation on the state data after the target transaction is executed to obtain a second target transaction state data digest value; The obtained target transaction is verified based on the comparison between the first target transaction digest value and the second target transaction digest value, and the comparison between the first target transaction status data digest value and the second target transaction status data digest value.

16. The blockchain processing method according to any one of claims 1-15, characterized in that, After obtaining the target block to be recorded on the blockchain, the blockchain processing method further includes: Based on the predetermined non-full storage node determination rules, the target blockchain node is determined to be the full storage node of the target block; The target blockchain node stores a key-value pair table of the target block; In response to receiving the block retrieval request for the target block, the target block is generated using the key-value pair table.

17. A blockchain processing device, characterized in that, The blockchain processing device is located at a target blockchain node in the blockchain network, and the blockchain processing device includes: The acquisition unit is used to acquire the target block to be recorded on the blockchain; The first determining unit is used to determine, based on a predetermined non-full storage node determining rule, that the target blockchain node is a non-full storage node of the target block, wherein the non-full storage node is a blockchain node that only stores a portion of the data of the target block, and the portion of data includes target block verification data; The first storage unit is used to store the portion of the data of the target block in the target blockchain node; The first verification unit is configured to, in response to receiving a block retrieval request for the target block, retrieve the target block from a full storage node in the blockchain network, and verify the retrieved target block using the target block verification data, wherein the full storage node is a blockchain node that stores all the data of the target block.

18. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the blockchain processing method according to any one of claims 1 to 16.

19. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the blockchain processing method according to any one of claims 1 to 16.

20. A computer program product comprising a computer program that is read and executed by a processor of a computer device, causing the computer device to perform the blockchain processing method according to any one of claims 1 to 16.

Images