A data compression method, block synchronization method and related device

Abstract

The embodiment of the application discloses a data compression method, a block synchronization method and related equipment, wherein the method comprises the following steps: performing object extraction processing on transaction data in m+1 blocks to obtain P objects, P being a positive integer; acquiring a first state value of each object in the n-1th block on the blockchain in the target consensus node and a second state value in the n+mth block, and performing root calculation processing to obtain a first state root and a second state root corresponding to a target interval; based on the transaction data in the m+1 blocks, the first state value and the second state value of each object, the first state root and the second state root corresponding to the target interval, performing operation processing by using a zero-knowledge proof circuit to obtain an interval transaction of the target interval; and performing compression processing on the blockchain in the target consensus node by using the interval transaction. The embodiment of the application can reduce the storage burden of the target consensus node.

Description

Technical Field

[0001] This application relates to the field of computer technology, specifically to the field of blockchain technology, and particularly to a data compression method based on a blockchain network, a block synchronization method based on a blockchain network, a data compression device based on a blockchain network, a blockchain node device, a computer-readable storage medium, and a computer program product. Background Technology

[0002] With the rapid development of computer technology, blockchain technology has gradually attracted user attention, and more and more users and enterprises are choosing to store data on the blockchain to prevent data tampering. However, in practice, it has been found that as the amount of data on the blockchain gradually increases, the massive historical data contained in the blockchain requires a large amount of storage space, thus placing a heavy storage burden on the blockchain nodes in the blockchain network. Therefore, how to reduce the storage burden on blockchain nodes has become a hot research topic. Summary of the Invention

[0003] This application provides a data compression method, block synchronization method, and related equipment based on a blockchain network, which can compress transaction data in the blockchain and reduce the storage load of blockchain nodes.

[0004] On one hand, this application provides a data compression method based on a blockchain network. The blockchain network contains one or more consensus nodes. The method is executed by a target consensus node in the blockchain network. The blockchain in the blockchain network has a target interval, which contains m+1 blocks from the nth block to the (n+m)th block, where n and m are both integers greater than zero. The method includes:

[0005] Extract objects from the transaction data in m+1 blocks to obtain P objects, where P is a positive integer.

[0006] Obtain the first state value of each object in the (n-1)th block of the blockchain in the target consensus node, and perform root calculation on the first state value of each object to obtain the first state root corresponding to the target interval;

[0007] Obtain the second state value of each object in the (n+m)th block of the blockchain in the target consensus node, and perform root calculation on the second state value of each object to obtain the second state root corresponding to the target interval;

[0008] Based on the transaction data in m+1 blocks, the first and second state values ​​of each object, and the first and second state roots corresponding to the target interval, a zero-knowledge proof circuit is used for computation to obtain the interval transactions of the target interval.

[0009] The blockchain in the target consensus node is compressed using interval transactions; the target interval in the blockchain of the compressed target consensus node does not contain transaction data, but it does contain interval transactions.

[0010] In this embodiment of the application, the blockchain in the target consensus node is provided with a target interval, which contains m+1 blocks, such as the nth block to the (n+mth block)th block on the chain. The target consensus node can obtain the first state value of the object corresponding to the transaction data in the (n-1th block)th block, and the second state value of each object in the (n+mth block). The first state value can be understood as the state value of the transaction data corresponding to the object before it is executed, and the second state value can be understood as the state value of the transaction data corresponding to the object after it is executed. In this way, the first state root of the target interval is obtained based on the state value before the transaction data is executed, and the second state root of the target interval is obtained based on the second state value after the transaction data is executed, along with the transaction data in m+1 blocks, the first state value, and the second state value. By using a zero-knowledge proof circuit, the interval transaction of the target interval can be obtained, which contains relevant information about the target interval. Finally, by deleting the transaction data in m+1 blocks in the blockchain of the target consensus node and adding the interval transaction to one of the m+1 blocks, the transaction data in the target interval is compressed, thereby freeing up the storage space of the target consensus node and reducing the storage load.

[0011] On the other hand, this application provides a block synchronization method based on a blockchain network. The blockchain network includes one or more consensus nodes, and the method is executed by a first consensus node other than the target consensus node in the blockchain network. A target interval is defined on the blockchain of the blockchain network, containing m+1 blocks between the nth block and the (n+m)th block, where n and m are both positive integers. The method includes:

[0012] Synchronize the i-th block on the blockchain from the second consensus node in the blockchain network. The second consensus node is any consensus node in the blockchain network other than the first consensus node, where i is an integer and i∈[n,n+m].

[0013] If the i-th block contains the identifier of the interval transaction, then obtain the interval transaction based on the identifier of the interval transaction;

[0014] The range trading was verified, and the verification results were obtained;

[0015] If the verification result is successful, the updated state value of the write set of the transaction data in the interval transaction will be stored.

[0016] In this embodiment, after obtaining the interval transaction, the first consensus node (i.e., the validator) can synchronize the block headers of m+1 blocks between the nth block and the (n+m)th block from the blockchain of the second consensus node, and skip the Merkle root verification step; then, after the interval transaction is successfully verified, the interval transaction is stored in the m+1 blocks, which can realize the replacement of all transaction data in the target interval with the interval transaction of the target interval, thereby freeing up the storage space of the first consensus node (or any consensus node in the blockchain network that performs data compression) and reducing the storage load of the first consensus node.

[0017] On the other hand, embodiments of this application provide a data compression device based on a blockchain network. The blockchain network includes one or more consensus nodes. The device includes a target consensus node in the blockchain network. A target interval is defined on the blockchain of the blockchain network. The target interval includes m+1 blocks from the nth block to the (n+m)th block, where n and m are both positive integers. The device includes:

[0018] The processing unit is used to extract objects from the transaction data in m+1 blocks to obtain P objects, where P is a positive integer.

[0019] The acquisition unit is used to acquire the first state value of each object in the (n-1)th block of the blockchain in the target consensus node, and to perform root calculation processing on the first state value of each object to obtain the first state root corresponding to the target interval.

[0020] The acquisition unit is also used to acquire the second state value of each object in the (n+m)th block of the blockchain in the target consensus node, and to perform root calculation processing on the second state value of each object to obtain the second state root corresponding to the target interval.

[0021] The processing unit is also used to perform calculations based on the transaction data in m+1 blocks, the first state value and the second state value of each object, and the first state root and the second state root corresponding to the target interval, using a zero-knowledge proof circuit to obtain the interval transaction of the target interval.

[0022] The processing unit is also used to compress the blockchain in the target consensus node using interval transactions; wherein the target interval in the blockchain of the compressed target consensus node does not contain transaction data, but contains interval transactions.

[0023] In one implementation, the processing unit is further used for:

[0024] Receive a data compression request, which carries compression information.

[0025] In response to the data compression request, perform the step of extracting objects from the transaction data in m+1 blocks to obtain P objects;

[0026] The data compression request is initiated by the target object after inputting compression information into the target consensus node; or, the data compression request is sent by any consensus node in the blockchain network other than the target consensus node.

[0027] The compressed information includes: the starting block height n of the target range, the ending block height n+m of the target range, the threshold number of transaction data contained in the target range, and the node identifier of the target consensus node.

[0028] In one implementation, m+1 blocks store one or more transaction data, each transaction data including a transaction and the transaction result after the transaction is executed; any one of P objects refers to the data that needs to be written based on the transaction result in a transaction data;

[0029] The processing unit is also used for:

[0030] Sort one or more transaction data according to the order of their on-chain times in m+1 blocks to obtain a transaction sequence;

[0031] Sort the P objects according to the order of the transaction data in the transaction sequence to obtain the object sequence. The order of the P objects in the object sequence is consistent with the order of the transaction data corresponding to each object in the transaction sequence.

[0032] In one implementation, the processing unit, used to perform root calculation processing on the first state value of each object to obtain the first state root corresponding to the target interval, specifically performs the following:

[0033] Based on the first state value of each object in the object sequence, construct the first Merkle tree of the target interval. The order of the leaf nodes in the first Merkle tree is consistent with the order of the objects in the object sequence.

[0034] Perform root hash calculation on the first Merkle tree to obtain the first root hash of the first Merkle tree;

[0035] The first hash is determined as the first state root of the target interval.

[0036] In one implementation, the processing unit, used to perform root calculation processing on the second state value of each object to obtain the second state root corresponding to the target interval, specifically performs the following:

[0037] Based on the second state value of each object in the object sequence, construct the second Merkle tree of the target interval. The order of the leaf nodes in the second Merkle tree is consistent with the order of the objects in the object sequence.

[0038] Perform root hash calculation on the second Merkle tree to obtain the second root hash of the second Merkle tree;

[0039] The second root hash is determined as the second state root of the target interval.

[0040] In one implementation, the processing unit, based on transaction data from m+1 blocks, the first and second state values ​​of each object, and the first and second state roots corresponding to the target interval, performs computational processing using a zero-knowledge proof circuit to obtain the interval transactions for the target interval. Specifically, it is used for:

[0041] Obtain a zero-knowledge proof circuit, which is derived from the transformation of the proposition to be proved. The proposition to be proved is used to indicate the verification of the correctness of the interval transaction.

[0042] Construct a transaction set based on the transaction data in m+1 blocks;

[0043] A zero-knowledge proof circuit is used to verify the first and second state values ​​of each object, the first and second state roots corresponding to the target interval, and the transaction set, thereby generating proof information for the target interval.

[0044] Range trading is constructed based on the proof information to determine the target range;

[0045] The number of transaction data contained in the transaction set is equal to the quantity threshold. If the number of transaction data in m+1 blocks is equal to the quantity threshold, then the transaction set contains the transaction data in m+1 blocks. If the number of transaction data in m+1 blocks is less than the quantity threshold, then the transaction set contains the transaction data in m+1 blocks and empty transaction data, and the sum of the number of empty transaction data and the number of transaction data in m+1 blocks is equal to the quantity threshold.

[0046] In one implementation, the proof information for the target interval includes: the output information of the zero-knowledge proof circuit; and a processing unit, used to verify the first and second state values ​​of each object, the first and second state roots corresponding to the target interval, and the transaction set using the zero-knowledge proof circuit, specifically for generating the proof information for the target interval:

[0047] Construct the first candidate Merkle tree for the target interval based on the first state value of each object, and compare the first candidate state root of the first candidate Merkle tree with the first state root corresponding to the target interval to obtain the first comparison result;

[0048] Construct a second candidate Merkle tree for the target interval based on the second state value of each object, and compare the second candidate state root of the second candidate Merkle tree with the second state root corresponding to the target interval to obtain the second comparison result;

[0049] Obtain the field containing the write set for each transaction data (excluding empty transaction data) from the transaction set, and perform a hash calculation on the write set field for each transaction data to obtain the write set hash;

[0050] The hash of the transaction set is obtained by performing hash calculation on the hash values ​​of the transaction data excluding empty transaction data in the transaction set;

[0051] The output information of the zero-knowledge proof circuit includes: the first comparison result, the second comparison result, the write set hash, and the transaction set hash.

[0052] In one implementation, the proof information for the target interval further includes: a proof string; and a processing unit, which is also used for:

[0053] Obtain the key generation algorithm, and generate the prover public string and the validator public string according to the key generation algorithm; the prover public string is the key used by the prover, and the prover includes the target consensus node; the validator public string is the key used by the validator, and the validator includes any consensus node in the blockchain network that needs to synchronize blocks in the target interval.

[0054] Based on the prover's common string, a proof string is generated for the computation process of the zero-knowledge proof circuit to obtain the output information; the generation of the proof string indicates that the target consensus node has executed the computation process based on the zero-knowledge proof circuit.

[0055] In one implementation, the processing unit, when performing compression processing on the blockchain in the target consensus node using interval transactions, is specifically used for:

[0056] Clear the transaction data in the m+1 blocks contained in the blockchain of the target consensus node; and,

[0057] Replace the target transaction data in the i-th block of the blockchain in the target consensus node with the interval transaction, where i is an integer and i∈[n,n+m].

[0058] In one implementation, the target transaction data refers to the transaction data with the earliest on-chain time in the i-th block;

[0059] Blockchains in a blockchain network include either consortium blockchains or private blockchains.

[0060] The target interval transactions include: the threshold number of transaction data contained in the target interval, the starting block height n of the target interval, the ending block height n+m of the target interval, proof information, validator public string, the write set of each transaction data in m+1 blocks on the blockchain of the target consensus node, the interval identifier of the target interval, and the candidate transaction set hash; the candidate transaction set hash is generated based on the hash values ​​of the transaction data in m+ blocks on the blockchain of the target consensus node.

[0061] In this embodiment, the blockchain in the target consensus node has a target interval containing m+1 blocks, such as the nth block to the (n+mth)th block on the chain. The processing unit can obtain the first state value of the object corresponding to the transaction data in the (n-1)th block, and the second state value of each object in the (n+m)th block. The first state value can be understood as the state value of the transaction data corresponding to the object before execution, and the second state value can be understood as the state value of the transaction data corresponding to the object after execution. Thus, the first state root of the target interval is obtained based on the state value before the transaction data is executed, and the second state root of the target interval, the transaction data in the m+1 blocks, the first state value, and the second state value are obtained based on the second state value after the transaction data is executed. A zero-knowledge proof circuit is used to obtain the interval transaction of the target interval, which contains relevant information of the target interval. Finally, by deleting the transaction data in the m+1 blocks in the blockchain of the target consensus node and adding the interval transaction to one of the m+1 blocks, the transaction data in the target interval is compressed, thereby releasing the storage space of the target consensus node and reducing the storage load.

[0062] On the other hand, this application proposes a block synchronization device based on a blockchain network. The blockchain network includes one or more consensus nodes, and the device includes a first consensus node in the blockchain network other than the target consensus node. A target interval is defined on the blockchain of the blockchain network, containing m+1 blocks from the nth block to the (n+m)th block, where n and m are both positive integers. The device includes:

[0063] The acquisition unit is used to synchronize the i-th block on the blockchain from the second consensus node in the blockchain network. The second consensus node is any consensus node in the blockchain network other than the first consensus node, where i is an integer and i∈[n,n+m].

[0064] The acquisition unit is also used to acquire the interval transaction based on the interval transaction identifier if the i-th block contains the identifier of the interval transaction;

[0065] The processing unit is used to verify the range transactions and obtain the verification results;

[0066] The processing unit is also used to store the updated state value of the write set of transaction data in the interval transaction if the verification result is successful.

[0067] In one implementation, the interval transaction includes: a write set of each transaction data in m+1 blocks on the blockchain of the target consensus node, proof information, a validator common string, and a candidate transaction set hash; the proof information includes the output information of the zero-knowledge proof circuit and the proof string; the zero-knowledge proof circuit is generated based on the proposition to be proved, which is used to indicate the verification of the correctness of the interval transaction; the validator common string is generated by the target consensus node for the validators according to the key generation algorithm, and the validators include the first consensus node; the candidate transaction set hash is obtained by the target consensus node by hashing the hash values ​​of the transaction data in m+1 blocks;

[0068] The processing unit is used to verify range transactions. Upon obtaining the verification result, it is specifically used for:

[0069] Verification information is generated based on the write set of each transaction in m+1 blocks and the hash of the candidate transaction set;

[0070] The output information of the zero-knowledge proof circuit in the proof information is verified using the verification information;

[0071] If the verification passes, the proof string in the proof information is verified based on the verifier's common string to obtain the verification result.

[0072] In one implementation, the processing unit, when generating verification information based on the write set of each transaction data in m+1 blocks and the hash of the candidate transaction set, specifically performs the following:

[0073] Extract the corresponding P objects from the write set of transaction data in the interval transaction, and obtain the third state value of the P objects in the (n-1)th block from the blockchain of the first consensus node;

[0074] Root calculation is performed on the third state values ​​of P objects to obtain the first reference state root; and,

[0075] The write set of transaction data in the interval transaction is pre-processed to obtain the updated fourth state values ​​of P objects, and the root calculation is performed on the updated fourth state values ​​of the P objects to obtain the second reference state root; and,

[0076] Perform a hash calculation on the field containing the write set of the transaction data in the interval transaction to obtain the reference write set hash;

[0077] The verification information includes: the first reference state root, the second reference state root, the reference write set hash, and the candidate transaction set hash.

[0078] In one implementation, the output information of the zero-knowledge proof circuit in the proof information includes: a first comparison result, a second comparison result, a write set hash, and a transaction set hash; the first comparison result is obtained by comparing the first candidate state root of the first candidate Merkle tree constructed by the target consensus node based on the first state values ​​of P objects with the first state root of the target interval; the second comparison result is obtained by comparing the second candidate state root of the second candidate Merkle tree constructed by the target consensus node based on the second state values ​​of P objects with the second state root of the target interval.

[0079] The processing unit, used to verify the output information of the zero-knowledge proof circuit in the proof information using verification information, is specifically used for:

[0080] If both the first comparison result and the second comparison result are successful, then the first state root of the target interval is compared with the first reference state root to obtain the first reference comparison result; and the second state root of the target interval is compared with the second reference state root to obtain the second reference comparison result.

[0081] The write set comparison result is obtained by comparing the reference write set hash with the write set hash in the output information of the zero-knowledge proof circuit.

[0082] The transaction set hash in the output information of the zero-knowledge proof circuit is compared with the candidate transaction set hash in the interval transaction to obtain the transaction comparison result;

[0083] If the first reference comparison result, the second reference comparison result, the write set comparison result, and the transaction comparison result are all successfully compared, then the verification is considered successful.

[0084] In one implementation, the processing unit, when retrieving the interval transaction based on the interval transaction identifier if the i-th block contains an identifier for the interval transaction, specifically performs the following:

[0085] If the i-th block on the blockchain of the second consensus node contains the identifier of the interval transaction, and the i-th block does not contain the interval transaction, then a first retrieval request is sent to the second consensus node, so that the second consensus node responds to the first retrieval request and returns the target node identifier of any consensus node in the blockchain network that stores the interval transaction.

[0086] Obtain the range transaction from the consensus node corresponding to the target node identifier based on the target node identifier;

[0087] Alternatively, a second retrieval request can be sent to the second consensus node, so that the second consensus node responds to the second retrieval request, retrieves and returns the range transaction from any consensus node in the blockchain network that stores the range transaction.

[0088] In one implementation, the identifier of an interval transaction is stored in the i-th block of the blockchain on the second consensus node's network after the second consensus node successfully verifies the interval transaction; the verification of interval transactions in the blockchain network by the second consensus node includes:

[0089] Retrieve range transactions, which include the hash of the candidate transaction set and the write set of transaction data in the target range;

[0090] The write set of transaction data from block n to block n+m is obtained from the blockchain of the second consensus node, and the write set of transaction data obtained from the blockchain of the second consensus node is compared with the write set of transaction data in the interval transaction to obtain the write set comparison result;

[0091] Obtain the hash values ​​of transaction data from block n to block n+m in the blockchain of the second consensus node, and perform hash calculation on the hash values ​​of the transaction data to obtain the transaction hash value;

[0092] The transaction hash value is compared with the hash of the candidate transaction set in the interval transaction to obtain the transaction hash comparison result;

[0093] If both the set comparison result and the transaction hash comparison result are successful, then the verification result is obtained, and the verification result is successful.

[0094] In this embodiment, after acquiring the interval transaction, the acquisition unit can synchronize the block headers of m+1 blocks between the nth block and the (n+m)th block from the blockchain in the second consensus node, and skip the Merkle root verification step; then, after the processing unit successfully verifies the interval transaction, it stores the interval transaction in the m+1 blocks, which can realize the replacement of all transaction data in the target interval with the interval transaction of the target interval, thereby releasing the storage space of the first consensus node (or any consensus node in the blockchain network that performs data compression) and reducing the storage load of the first consensus node.

[0095] On the other hand, this application provides a blockchain node device, which includes:

[0096] A processor is used to load and execute computer programs;

[0097] A computer-readable storage medium storing a computer program that, when executed by a processor, implements the aforementioned data compression method and block synchronization method based on a blockchain network.

[0098] On the other hand, this application provides a computer-readable storage medium storing a computer program adapted to be loaded by a processor and executed by the aforementioned data compression method and block synchronization method based on a blockchain network.

[0099] On the other hand, this application provides a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. The processor of a blockchain node device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the blockchain node device to perform the aforementioned data compression method and block synchronization method based on the blockchain network. Attached Figure Description

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

[0101] Figure 1a This application illustrates a schematic diagram of the structure of a blockchain provided in an exemplary embodiment.

[0102] Figure 1b This application shows a schematic diagram of the structure of a data sharing system provided in an exemplary embodiment;

[0103] Figure 1c An architectural diagram of a two-layer blockchain network provided by an exemplary embodiment of this application is shown;

[0104] Figure 2 A schematic flowchart of a data compression method based on a blockchain network provided in an exemplary embodiment of this application is shown;

[0105] Figure 3 This illustration shows a schematic diagram of a blockchain network with a target range provided in an exemplary embodiment of this application;

[0106] Figure 4a This illustration shows a schematic diagram of a target consensus node initiating a data compression request upon receiving compression information input by a target object, according to an exemplary embodiment of this application.

[0107] Figure 4bThis illustration shows a schematic diagram of a target consensus node obtaining a data compression request from other blockchain nodes in a blockchain network, according to an exemplary embodiment of this application.

[0108] Figure 5 This illustration shows a schematic diagram of a transaction sequence and an object sequence provided in an exemplary embodiment of this application;

[0109] Figure 6 This illustration shows a schematic diagram of constructing a first Merkle tree for a target interval based on a first state value of each object in a sequence of objects, provided by an exemplary embodiment of this application.

[0110] Figure 7 This illustration shows a schematic diagram of a second Merkle tree for constructing a target interval based on the second state value of each object in a sequence of objects, provided by an exemplary embodiment of this application.

[0111] Figure 8 A schematic diagram of a zero-knowledge proof circuit provided in an exemplary embodiment of this application is shown;

[0112] Figure 9 This illustration shows a schematic diagram of constructing a transaction set based on transaction data in m+1 blocks, provided by an exemplary embodiment of this application.

[0113] Figure 10 This illustration shows a schematic diagram of an exemplary embodiment of the present application providing a method for obtaining output information based on a zero-knowledge proof circuit.

[0114] Figure 11 This illustration shows a schematic diagram of a blockchain compression process based on interval transactions, provided by an exemplary embodiment of this application.

[0115] Figure 12 The illustration shows a flowchart of a block synchronization method based on a blockchain network provided in an exemplary embodiment of this application;

[0116] Figure 13 This illustration shows a schematic diagram of a consensus process for interval transactions provided by a second consensus node according to an exemplary embodiment of this application;

[0117] Figure 14a This illustration shows a schematic diagram of obtaining a range transaction according to an exemplary embodiment of this application;

[0118] Figure 14b This illustration shows a schematic diagram of obtaining a range transaction according to an exemplary embodiment of this application;

[0119] Figure 14c This illustration shows a schematic diagram of obtaining a range transaction according to an exemplary embodiment of this application;

[0120] Figure 15 This illustration shows a schematic diagram of the structure of a data compression device based on a blockchain network provided in an exemplary embodiment of this application;

[0121] Figure 16 This illustration shows a schematic diagram of the structure of a block synchronization device based on a blockchain network, provided in an exemplary embodiment of this application.

[0122] Figure 17 A schematic diagram of the structure of a blockchain node device provided in an exemplary embodiment of this application is shown. Detailed Implementation

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

[0124] This application relates to blockchain, which is the foundation of blockchain technology. Blockchain is a novel 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 network transactions, used to verify the validity of the information (anti-counterfeiting) and generate the next block. A schematic diagram of a blockchain structure can be found... Figure 1a ,like Figure 1a As shown, Blockchain 101 consists of multiple blocks. The first block of the blockchain is called the genesis block (or simply the genesis block). The genesis block includes a block header and a block body. The block header stores the input information feature value, version number, timestamp, and difficulty value, while the block body stores the input information. The next block after the genesis block takes the genesis block as its parent block. The next block also includes a block header and a block body. The block header stores the input information feature value of the current block, the block header feature value of the parent block, the version number, timestamp, and difficulty value, while the block body stores the transaction data itself. This process continues, ensuring that the block data stored in each block of the blockchain is related to the block data stored in the parent block, thus guaranteeing the security of the input information in the blocks.

[0125] A blockchain can be maintained by blockchain nodes contained within a blockchain network; wherein, a blockchain network can be understood as a data sharing system, referring to a system used for data sharing between blockchain nodes, an exemplary structure of which can be found here. Figure 1b ;like Figure 1b As shown, the data sharing system may include multiple blockchain nodes 101. Each blockchain node 101 can be a server connected to the blockchain network, or a terminal (such as a client running on a terminal) connected to the blockchain network. The specific form of the blockchain node 101 is not limited here. Each blockchain node 101 in the blockchain network has a corresponding node identifier, and each blockchain node 101 can store the node identifiers of other blockchain nodes 101 in the blockchain network, so that the generated blocks can be broadcast to other blockchain nodes 101 in the data sharing system based on the node identifiers of other blockchain nodes 101. Each blockchain node 101 can maintain a node identifier list, storing the node name and node identifier in the node identifier list; the node identifier list can be found in Table 1.

[0126] Table 1

[0127] Node Name Node identifier Node 1 117.114.151.174 Node 2 117.116.189.145 … … Node X (X is a positive integer) xx.xxx.xxx.xxx

[0128] As shown in Table 1, a node identifier can be an IP (Internet Protocol) address or any other information that can be used to identify the node; for example, a node identifier can also be a binary sequence code (such as 110001110). Table 1 only uses IP addresses as an example. Each blockchain node in the blockchain network maintains a list of node identifiers. When any consensus node in the blockchain network (such as a blockchain node with consensus functionality) adds a consensus-passed block to its blockchain, other nodes in the blockchain network retrieve the node identifier of that consensus node from their respective maintained list of node identifiers and synchronize the consensus-passed block from the blockchain of that consensus node based on its node identifier, thereby achieving data synchronization in the blockchain network.

[0129] Currently, there are three main types of blockchains: public blockchains, consortium blockchains, and private blockchains. A public blockchain is one where any node in the network (e.g., a blockchain node corresponding to a single object or a group of objects) can send transaction data, and the transaction data can be effectively confirmed; any node can participate in the consensus process. A consortium blockchain is one where some nodes in the network can participate in the block consensus process, while other nodes do not have access to the consensus process. For example, within a consortium blockchain network, multiple pre-selected blockchain nodes can be designated as ledger nodes (e.g., blockchain nodes with consensus permissions). Each block on the consortium blockchain is jointly decided by all pre-selected blockchain nodes (i.e., pre-selected blockchain nodes participate in the consensus process). Other connected blockchain nodes besides the pre-selected blockchain nodes can participate in transactions but do not participate in the consensus process. A private blockchain is one where a single blockchain node in the network has exclusive write permissions (e.g., writing the block after consensus).

[0130] In practical applications, whether it's a public blockchain, consortium blockchain, or private blockchain, an increasing amount of transaction data is stored. Each consensus node in the blockchain network stores the blockchain itself (e.g., any blockchain from the public, consortium, or private blockchains). However, the number of transactions a blockchain network can process per second is limited. This reduces the consensus efficiency of the blockchain network to some extent, resulting in low transaction throughput (Transactions Per Second, TPS) and increased storage load on the consensus nodes. Therefore, processing the transaction data stored on the blockchain to alleviate the storage burden on consensus nodes and save storage space is crucial for the development of blockchain technology. However, practice has shown that different types of blockchains have different processing needs for transaction data. For example, although historical transaction data in public blockchains (such as transaction data already stored in generated blocks) already places a significant storage burden on full nodes (e.g., blockchain nodes maintaining a blockchain containing all block headers and the corresponding block bodies), public blockchains lack the motivation and need to perform on-chain data processing to reduce the storage load on full nodes, in order to ensure the traceability of every transaction. For example, the situation with consortium blockchains and private blockchains is different from that of public blockchains. In detail, when the participants in a consortium blockchain (or private blockchain) decide that the on-chain data is "invalid" based on the actual application situation, they have the motivation and need to perform on-chain data processing to increase the storage space of blockchain nodes and reduce storage pressure.

[0131] Taking e-invoice business as an example of a consortium blockchain, assuming the target transaction received in the consortium blockchain is to upload a target invoice to the blockchain, then after the consensus node executes the target transaction, it can store the transaction data (such as the invoice information of the target invoice, or invoice data) and the status value of this transaction being written to disk (or stored). However, e-invoice business is time-sensitive. A transaction data stored on the consortium blockchain will become an "expired transaction" after a sufficiently long time interval. An "expired transaction" can be simply understood as transaction data that is no longer accessed. Therefore, consortium blockchains and private blockchains have the motivation to process on-chain data to reduce the storage burden on blockchain nodes. For ease of explanation, the blockchain in the blockchain network provided in the embodiments of this application includes either a consortium blockchain or a private blockchain. If a consortium blockchain is used as an example for introduction, this is hereby stated.

[0132] The following is a brief introduction to the transaction data contained in the blocks of the aforementioned blockchain: ① Each transaction data includes a transaction and the transaction result after the transaction is executed. The transaction contains a timestamp, the smart contract name, method name (e.g., the name of the methods contained in the smart contract), smart contract parameters, signature, and other information. The transaction result contains parameters related to the transaction result (e.g., error codes) and a write set. The write set stores the transaction's state value in key-value pairs. The write set of the transaction data enables rapid updates to the on-chain state value. This means that blockchain nodes that need to synchronize transaction data do not need to execute the transaction once; they can quickly update the on-chain state value using only the write set in the transaction data, reducing workload and increasing the state value update rate to some extent. ② The state value of the transaction data can be understood as the state value of the object corresponding to the transaction data. The object corresponding to the transaction data can refer to the data that needs to be written based on the transaction result in the transaction data. The state value of the object can refer to the specific changes to the data in the transaction result after the transaction is executed. For example, if the target transaction's task is to deduct a target amount of electronic resources from the account balance, then after the target transaction is executed, the amount of electronic resources in the account balance changes. The object corresponding to this transaction data could refer to the account balance after the target transaction is executed, and the object's status value could refer to the remaining amount of electronic resources in the account balance after deducting the target amount. As another example, if the target transaction's task is to store invoice data, then the object corresponding to this target transaction could refer to the stored invoice, and the object's status value could refer to the specific invoice information contained in the invoice (such as the invoice issuer's information, invoice type, etc.). When the data (such as the invoice information to be stored) is included in the smart contract parameters and needs to be finally written to disk, because this data appears in the transaction's contract parameters, the write set of the transaction result, and the transaction's status value, this data will be stored three times.

[0133] Based on the aforementioned need for processing transaction data in consortium blockchains and private blockchains, this application proposes a data compression scheme based on blockchain networks. Specifically, it is a data compression scheme for consortium blockchains (or private blockchains) within a blockchain network. This scheme allows the blockchain to significantly compress transaction data within a target range, provided that the state values ​​(or state data) of the objects corresponding to the transaction data are recoverable. This reduces the amount of data stored on the blockchain, thereby reducing the storage load on the consensus nodes maintaining the blockchain. The target range in the blockchain may include m+1 blocks from the starting block height n to the ending block height n+m; where n and m are both positive integers.

[0134] The data compression scheme based on a blockchain network provided in this application embodiment can be executed by a target consensus node in the blockchain network. As described above, the blockchain network contains one or more consensus nodes, and the target consensus node can refer to the consensus node designated to perform data compression processing among these one or more consensus nodes. To facilitate a better understanding of the data compression scheme proposed in this application embodiment, the type of blockchain network in which the target consensus node resides is described below. Specifically, the target consensus node can belong to a single-layer network (such as...). Figure 1bThe single-layer blockchain network shown can be a consensus node that maintains the entire blockchain among one or more consensus nodes, or a node that maintains the entire blockchain in any sub-network of a two-layer or multi-layer network. This application embodiment does not limit whether the blockchain network where the target consensus node is located is a single-layer network or a two-layer or multi-layer network; this is stated here. Here, "layer" refers to the number of sub-networks contained in the blockchain network. The division of sub-networks can be based on considerations such as business needs, communication connections, and security. Inter-access between blockchain nodes belonging to the same sub-network is secured by a consensus mechanism, while inter-access between blockchain nodes in different sub-networks requires additional identity management and / or network control. For example, when blockchain is applied in certain scenarios, such as: bill business scenarios, data storage scenarios for government or commercial institutions, etc.; in these scenarios, not all nodes in the blockchain network have sufficient resources and necessity to become nodes executing blockchain consensus. Furthermore, for data security considerations, the common data-peer blockchain deployment method is not applicable when important data is involved in the blockchain system. To adapt to business needs (such as separation of internal and external networks, business networks, and office networks) and further improve data security and confidentiality, a two-layer chain can be adopted. This involves using a P2P (Peer-to-Peer) network to form a two-layer network architecture of "witness sub-network - consensus sub-network" to enhance data security. A P2P network is a peer-to-peer network where each node is called a peer node. Based on a specific network protocol, P2P networks eliminate the need for a central node to maintain network state. Each node maintains the overall network state and its connections with neighboring nodes through broadcast interactions.

[0135] Figure 1c This application illustrates an exemplary embodiment of an architecture diagram of a two-layer blockchain network; as shown... Figure 1c As shown, the blockchain network includes a witness subnetwork and a consensus subnetwork. The target consensus node provided in this embodiment can be a consensus node in the consensus subnetwork. Specifically: ① The witness subnetwork includes business nodes. Business nodes in the witness subnetwork mainly perform business execution (e.g., business nodes are used to query whether a transaction is on the chain), do not perform accounting consensus, and obtain block headers and / or partially authorized visible block data from the consensus subnetwork through identity authentication. ② The consensus subnetwork is the core network in the blockchain network, used for accounting consensus within the blockchain network. The consensus subnetwork includes one or more consensus nodes (or accounting nodes), which are used to reach consensus on blocks to achieve on-chain storage of blocks.

[0136] Furthermore, the witness subnetwork and the consensus subnetwork can interact through a routing proxy network (or routing boundary network) between them. That is, the routing proxy network is used to isolate the witness subnetwork and the consensus subnetwork. The routing proxy network contains one or more routing proxy nodes (or simply proxy nodes). This allows the routing proxy nodes to forward data sent by business nodes in the witness subnetwork to the consensus nodes in the consensus subnetwork, improving the security of data in the consensus subnetwork. Taking electronic invoices as an example, a company initiates an invoice request through a business node in the witness subnetwork. This request is then forwarded through the routing proxy network from the business node in the witness subnetwork to the consensus node in the consensus network. After executing the transaction, the consensus node writes the transaction data (such as the invoice) and the state value of the transaction (such as the invoice information) to disk. Subsequently, the consensus node clears the transaction back to the business node in the witness subnetwork. Although the business node does not execute the transaction, it still needs to store the transaction data and the state value of the transaction. That is, the business node does not need to re-execute the transaction but quickly updates the state value through the write set in the transaction result.

[0137] It should be noted that when the embodiments of this application are applied to specific products or technologies, such as when a business node synchronizes the block containing transaction data from the consensus node, it needs to obtain the permission or consent of the target object that generated the transaction data; and the collection, use and processing of related data need to comply with the relevant laws, regulations and standards of the relevant countries and regions, such as the acquisition and uploading of transaction data need to comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0138] It is worth noting that the data compression scheme based on blockchain networks proposed in this application's embodiments references the zk-rollup scheme to some extent. The zk-rollup scheme is a layer 2 scaling scheme based on zero-knowledge proofs. The principle of the zk-rollup scheme can be roughly summarized as follows: complex calculations and proof generation are performed outside of layer 1, while on-chain verification of the proofs and storage of some data ensures data availability—this is the layer 2 scheme. Taking Ethereum as an example, the Ethereum public chain is layer 1. The problem with layer 1 is its low efficiency and low TPS (transactions per second). The layer 2 scheme is an off-chain scaling solution for the blockchain, aiming to move some operations from layer 1 to layer 2 for processing, and then return the results to layer 1. In this way, layer 1 ensures consensus, decentralization, and immutability, while layer 2 ensures high performance and versatility.

[0139] It should be noted that the current zk-rollup scheme is not used for compressing historical data in the blockchain, but rather for improving the performance of public chains and expanding on-chain data capacity. The current zk-rollup scheme for data expansion can be simply summarized as follows: 1) Pack a batch of transactions in layer 2 to create a range (batch); 2) Change the world state in the zero-knowledge proof circuit (e.g., each blockchain node in the blockchain network stores the same state value of the same transaction at the same time) and verify the signature of each transaction in the range; 3) Construct a brand new transaction for the range, which includes the current world state, the world state after the range, the zk-SNARK proof, and a lightweight field corresponding to each transaction to indicate the state change; 4) Upload the brand new transaction to the layer 1 chain, and the remaining nodes verify the proof information of the brand new transaction (or zk-SNARK proof). If the proof information passes the verification, the world state is updated using the information contained in this transaction. The zk-rollup scheme allows for computationally expensive operations to be performed in layer 2, while lightweight data is uploaded to layer 1 to update the current state of nodes, along with a zk-SNARK proof to demonstrate the existence and correctness of computations in layer 2.

[0140] The zk-rollup scheme differs from the data compression scheme described in this application in the following ways: 1) The fundamental purpose is different: the purpose of zk-rollup in data expansion is to increase capacity, while the purpose of zk-rollup in data compression is to compress data; 2) The application of zero-knowledge proofs differs: zero-knowledge proofs are used in data expansion to prove the correlation between state updates and a batch of transactions, while zero-knowledge proofs are used in data compression to prove the correlation between write sets and a batch of transactions; 3) There may be differences in the underlying blockchain: when zk-rollup is applied to data expansion, the world state is required for zero-knowledge proofs, but some blockchains may not maintain a world state, which limits the application scenarios of zk-rollup. For example, zk-rollup is mainly used in Ethereum, so the world state of Ethereum is used as input when performing zero-knowledge proofs. However, the blockchains (or consortium blockchains) involved in data compression scenarios do not maintain a separate world state, which means that zk-rollup cannot be directly used to achieve data compression in data compression scenarios. Therefore, this application embodiment makes certain adjustments to the current zk-rollup scheme to make it suitable for data compression scenarios, thereby realizing the application of zero-knowledge proof and zk-rollup scheme in the scenario of compressing historical transaction data in consortium blockchains.

[0141] The following describes the zero-knowledge proof involved in the aforementioned zk-rollup scheme. Specifically, the data compression scheme based on a blockchain network provided in this application embodiment is implemented using zero-knowledge proof (zkp) technology; specifically, it is implemented using zero-knowledge succinct non-interactive argument of knowledge (zk-snark) technology. Zero-knowledge proof is a protocol involving two or more parties, that is, a series of steps required for two or more parties to complete a task; for example, the two parties involved in zero-knowledge proof may include: a prover (such as an object proving the correctness of a statement) and a verifier (such as an object verifying whether the proof provided by the prover for a statement is correct); in this application embodiment, the prover may include a target consensus node used for compressing transaction data within a target interval on the blockchain, and the verifier may include other nodes in the blockchain network that are to be synchronized within the target interval. During a zero-knowledge proof process, the prover can interact with the verifier multiple times without providing any useful information to the verifier, in order to convince the verifier of the correctness of a statement. Zero-knowledge concise non-interactive knowledge arguments are also a type of agreement involving two or more parties who can judge the correctness of a statement. However, unlike zero-knowledge proofs, zero-knowledge concise non-interactive knowledge arguments achieve the goal of non-interaction at the cost of accepting some controversy; in other words, in the process of a zero-knowledge concise non-interactive knowledge argument, the prover and the verifier only exchange data once to judge the correctness of the statement.

[0142] This application embodiment uses zero-knowledge concise non-interactive knowledge proof technology to implement a data compression scheme based on a blockchain network. Specifically, through zero-knowledge concise non-interactive knowledge proof technology, verifiers can synchronize the state values ​​of transaction data within the target range by synchronizing transactions only from the target consensus node (such as the prover) on the blockchain, thus avoiding the need to synchronize all transaction data within the target range, thereby reducing the storage burden on verifiers. The following is a brief introduction to the data compression scheme provided in this application embodiment, based on the operating principle of zero-knowledge concise non-interactive knowledge proof. The operating principle of zero-knowledge concise non-interactive knowledge proof can be divided into four steps, including:

[0143] 1) In a blockchain network, the target consensus node can transform the proposition to be proven into a zero-knowledge proof circuit. The proposition to be proven refers to the proposition that needs to be judged or verified between the prover and the verifier. Specifically, operators can be used to express the operational logic corresponding to the proposition to be proven, thereby obtaining the zero-knowledge proof circuit corresponding to the proposition.

[0144] 2) The prover (such as the target consensus node in the blockchain network) uses a generation algorithm to generate public parameters, a prover key, and a verifier key for the proposition to be proven. Since the generated prover key and verifier key are public (accessible to any node in the blockchain network), this embodiment refers to the prover key as the prover public string and the verifier key as the verifier public string. The use of these two terms will not be limited thereafter. The public parameters are randomly generated strings using the generation algorithm and cannot be disclosed. These public parameters have a significant impact on the security of the proof process.

[0145] 3) The prover generates proof information for the target interval on the blockchain in the target consensus node by using the prover key and the zero-knowledge proof circuit (i.e., the R1CS circuit transformed from the proposition to be proved).

[0146] 4) Verifiers (such as newly added consensus nodes in the blockchain network) use their verifier keys to verify the proof information generated by the target consensus node. When the verification of the proof information is successful, the verifier determines that the data provided by the prover is valid, such as the newly added consensus node determining that the interval transactions synchronized from the target consensus node's blockchain are correct or existent. Conversely, when the verification of the proof information fails, the verifier determines that the data provided by the prover is invalid, such as the newly added consensus node determining that the interval transactions synchronized from the target consensus node's blockchain are incorrect or do not exist. The term "correct" for an interval transaction means that the content contained in the interval transaction is legal. The term "existence" for an interval transaction means that the interval transaction is not obtained out of thin air, but is generated by the target consensus node based on the transaction data of the target interval on the target consensus node's blockchain.

[0147] In steps 2)-4), the generation algorithms included in the zero-knowledge concise non-interactive knowledge argument can include: a key generation algorithm, a prover algorithm, and a verifier algorithm. Specifically: the key generation algorithm can generate prover and verifier keys based on common parameters; the prover algorithm can generate proof information for the proposition to be proven based on the prover key; and the verifier algorithm can verify the proof information generated by the prover based on the verifier key, obtaining a verification result, which can also be called a circuit check result.

[0148] It should be noted that the above is only a brief introduction to the operating principle of zero-knowledge concise non-interactive knowledge argumentation; in practical application scenarios, the operating principle of zero-knowledge concise non-interactive knowledge argumentation also includes other aspects. For example, the above description of the three algorithms included in zero-knowledge concise non-interactive knowledge argumentation is only an exemplary explanation; taking the key generation algorithm as an example, in the process of generating the prover key and the verifier key based on public parameters, in addition to public parameters, the key generation algorithm also involves information such as the key generation procedure; the embodiments of this application will not describe this in detail here.

[0149] Based on the data compression scheme based on blockchain networks described above, this application proposes a more detailed data compression method based on blockchain networks. The data compression method proposed in this application will be described in detail below with reference to the accompanying drawings.

[0150] Figure 2 The illustration shows a flowchart of a data compression method based on a blockchain network according to an exemplary embodiment of this application; the data compression method can be executed by a target consensus node in the blockchain network, and the data compression method may include, but is not limited to, steps S201-S205:

[0151] S201: Extract objects from the transaction data in m+1 blocks to obtain P objects.

[0152] As described above, a blockchain network contains one or more consensus nodes, and each consensus node in the blockchain network jointly maintains a blockchain. Specifically, each consensus node stores its own blockchain in the blockchain network. When a new block is added to the blockchain of any consensus node, other consensus nodes in the blockchain network can synchronize the new block from the blockchain of that consensus node according to the node identifier of that consensus node, thereby realizing the distributed storage of data in the blockchain network.

[0153] In this blockchain network, a target interval is defined on the blockchain itself. This target interval contains m+1 blocks, and these m+1 blocks can include the nth block to the (n+m)th block on the blockchain, where n and m are both positive integers. In other words, the target interval on the blockchain includes m+1 blocks between the nth block and the (n+m)th block. An exemplary schematic diagram of a blockchain network with a target interval can be found [see attached diagram]. Figure 3 ,like Figure 3As shown, the blockchain in the target consensus node contains a genesis block with a block height of 0, block 1 linked after the genesis block with a block height of 1, block 2 linked after block 1 with a block height of 2, ...; assuming n=2 and m=3, then the target interval is determined to be the four blocks between the 2nd block and the 2+3rd block on the blockchain, that is, the target interval on the blockchain is the 2nd block to the 5th block.

[0154] Furthermore, the target interval contains m+1 blocks storing one or more transaction data. Each transaction data includes a transaction and the transaction result after the transaction is executed. The transaction result after the transaction is executed contains a write set for the transaction, which includes the state values ​​of the objects corresponding to the transaction stored in key-value pairs. After object extraction processing is performed on the transaction data in the m+1 blocks, the objects corresponding to the transaction data contained in each of the m+1 blocks can be extracted. In this embodiment, for ease of explanation, it is taken as an example that the transaction data in the m+1 blocks corresponds to P objects, where P is a positive integer. Any one of the P objects refers to the data that needs to be written based on the transaction result of a transaction data. It should be noted that a more detailed description of the state values ​​of the objects corresponding to the transaction data can be found in the relevant descriptions of the foregoing embodiments, and will not be repeated here.

[0155] Based on the above introduction to the target interval set on the blockchain in the blockchain network, when the target consensus node receives a data compression request, it can perform object extraction processing on the transaction data in the m+1 blocks of the target interval on the blockchain of the target consensus node, to obtain P objects corresponding to the transaction data contained in each of the m+1 blocks. Specifically, the implementation process of the target consensus node extracting objects from the transaction data in the m+1 blocks to obtain P objects may include: first, extracting transaction data from each block in the m+1 blocks; the transaction data includes the transaction and the transaction result after the transaction is executed; the transaction result includes the object corresponding to the transaction and the object's state value; then, extracting the objects involved in each transaction from the extracted transaction data, thereby obtaining the P objects corresponding to the m+1 blocks.

[0156] It should be noted that the data compression request received by the target consensus node can be initiated by the target consensus node after the target object inputs compression information into the target consensus node, or it can be sent or forwarded by any consensus node in the blockchain network other than the target consensus node. The implementation process of the target consensus node obtaining the data compression request is described below with reference to the accompanying diagrams, in which:

[0157] 1) The data compression request received by the target consensus node is initiated by the target consensus node after the target object inputs compression information into the target consensus node. An exemplary diagram illustrating how a target consensus node initiates a data compression request upon receiving compression information input from the target object can be found here. Figure 4a ,like Figure 4a As shown, when the target consensus node is a terminal, the display screen (or terminal screen, display screen, etc.) included in the terminal can output an information acquisition interface. In this way, the user using the terminal (i.e. the target object mentioned above) can input compressed information through the information acquisition interface. Correspondingly, after the terminal detects the compressed information input in the information acquisition interface, it can initiate a data compression request based on the input compressed information.

[0158] 2) The data compression request received by the target consensus node is sent by any consensus node in the blockchain network other than the target consensus node. An exemplary diagram illustrating how the target consensus node obtains a data compression request from other blockchain nodes in the blockchain network can be found here. Figure 4b ,like Figure 4b As shown, the blockchain network is a two-layer network comprising a witness subnetwork and a consensus subnetwork. Therefore, the data compression request received by the target consensus node can be sent or forwarded by any consensus node in the consensus subnetwork other than the target consensus node (or sent by a business node in the witness subnetwork and forwarded through a routing proxy network). More specifically, this "any consensus node" may be a data compression request generated based on the target object inputting compression information into that consensus node, or it may be the data compression request obtained from other blockchain nodes (such as consensus nodes or business nodes) in the blockchain network (such as the consensus subnetwork or the witness subnetwork).

[0159] For example, the witness subnetwork includes a service node 401. If service node 401 receives compressed information input from the target object, it generates a data compression request based on the compressed information and forwards the data compression request to the consensus subnetwork via a routing node in the routing proxy network. It should be noted that when sending the data compression request, service node 401 can specify to send the data compression request to any one or more consensus nodes in the consensus subnetwork, such as specifying to send the data compression request to consensus node 402 in the consensus subnetwork. Then, consensus node 402 forwards the data compression request to the target consensus node (e.g., consensus node 403) according to the node identifier of the target consensus node in the compressed information. Of course, service node 401 can also directly send the data compression request to the target consensus node via the routing proxy network. This application embodiment does not limit the specific implementation method of the service node sending the data compression request.

[0160] As described above, the data compression request received by the target consensus node carries compression information. This information includes: the starting block height *n* of the target interval, the ending block height *n+m* of the target interval, a threshold for the number of transactions contained in the target interval (or batch size), and the node identifier of the target consensus node. Specifically, the starting block height *n* is the block height of the first block contained in the target interval. The ending block height *n+m* is the block height of the last block contained in the target interval. The threshold for the number of transactions contained in the target interval refers to the total number of transactions set for the target interval; for example, a threshold of 30 means that the target interval contains a total of 30 transactions. In this way, the target consensus node, responding to the data compression request, can quickly determine the target interval on the blockchain within the target consensus node based on the compression information carried in the request.

[0161] S202: Obtain the first state value of each object in the (n-1)th block of the blockchain in the target consensus node, and perform root calculation on the first state value of each object to obtain the first state root corresponding to the target interval.

[0162] It should be noted that, considering the aim of compressing transaction data within a target interval on the blockchain to free up storage space for the target consensus node, this application embodiment supports generating new interval transactions based on the transaction data in the interval to be compressed (i.e., the target interval) on the blockchain, using the first state value before execution and the second state value after execution. These new interval transactions then replace the transaction data in the target interval, thereby compressing the transaction data within the target interval and reducing the storage load on the target consensus node. Based on the data compression approach described above, after receiving a data compression request, the target consensus node can determine the target interval on its blockchain and extract P objects from it. Then, it can obtain the first state value of the transaction data corresponding to the P objects before execution. This first state value is stored in the (n-1)th block on the blockchain of the target consensus node, preceding the target interval. In other words, the first state value of each of the P objects in the (n-1)th block on the blockchain of the target consensus node is obtained. The first state value of any object in the (n-1)th block indicates the state value of the transaction data corresponding to that object before execution. Then proceed with the next steps to generate a new range trade.

[0163] In specific implementation, after extracting the first state value of each of the P objects from the (n-1)th block of the blockchain in the target consensus node, a first Merkle tree for the target interval can be constructed based on the first state value of each object. A root hash calculation is then performed on the first Merkle tree to obtain its first root hash, which is then determined as the first state root (pre-state-root) of the target interval. It is particularly important to note that this embodiment involves multiple Merkle tree constructions. To ensure the consistency of each constructed Merkle tree, the more detailed process of constructing the first Merkle tree for the target interval based on the first state value of each object in the above implementation may include: constructing the first Merkle tree for the target interval based on the first state value of each object in the object sequence. The object sequence contains P objects arranged in order according to the arrangement of transaction data in the transaction sequence; the transaction sequence contains transaction data from m+1 blocks sorted according to a sorting rule. The sorting rules may include: if a block contains at least two transaction data, then sort the at least two transaction data according to the order in which they were uploaded to the blockchain; if there are multiple blocks, then sort the transaction data corresponding to each block according to the linking order between the blocks, thereby obtaining a transaction sequence.

[0164] The following is combined with Figure 5 The process of determining the object sequence based on P objects is described below. First, the transaction data contained in each block is extracted from the target interval on the blockchain of the target consensus node. For example, the nth block in the target interval contains transaction data 1 and transaction data 2, and the on-chain time of transaction data 1 is earlier than that of transaction data 2. The (n+1)th interval contains transaction data 3. Then, according to the aforementioned sorting rules, one or more transaction data in the (m+1)th blocks are sorted to obtain the transaction sequence, which can be represented as: Transaction data 1 → Transaction data 2 → Transaction data 3 → … → Transaction data P. Next, according to the order of the transaction data in the transaction sequence, the P objects extracted from each transaction data are sorted to obtain the object sequence, such as transaction data 1 corresponding to object 1, transaction data 2 corresponding to object 2, transaction data 3 corresponding to object 3, and so on. Therefore, the object sequence constructed according to the transaction sequence can be represented as: Object 1 → Object 2 → Object 3 → … → Object P. Based on the exemplary object sequence and transaction sequence given above, it is easy to see that the order in which the P objects in the object sequence are arranged is consistent with the order in which the transaction data corresponding to each object is arranged in the transaction sequence.

[0165] Furthermore, an exemplary process for constructing the first Merkle tree of the target interval based on the first state value of each object in the object sequence can be found in [reference needed]. Figure 6 ;like Figure 6As shown, after extracting P objects from the transaction data in the target interval of the blockchain in the target consensus node, the P objects can be arranged according to the order of each transaction in the transaction sequence to obtain an object sequence. Each object in this object sequence is used as the leaf node of the first Merkle tree constructed; that is, the order of the leaf nodes in the first Merkle tree constructed based on each object in the object sequence is consistent with the order of each object in the object sequence. Then, based on the first state value of each object in the (n-1)th interval as the intermediate node of the first Merkle tree, a hash calculation is performed on the first state value of each object to obtain the hash value corresponding to each object. Finally, a root hash calculation is performed on the hash values ​​of each object to obtain the first root hash of the first Merkle tree. In this application embodiment, the type of hash algorithm used for hashing the first state value and for root hashing the hash values ​​of each object is not limited; for example, the hash algorithm may include, but is not limited to, MD4 (Message Digest4) algorithm, MD5 (Message Digest5) algorithm, SHA1 (Secure HashAlgorithm1) algorithm, etc. This application embodiment does not limit which hash algorithm is specifically used.

[0166] S203: Obtain the second state value of each object in the (n+m)th block of the blockchain in the target consensus node, and perform root calculation on the second state value of each object to obtain the second state root corresponding to the target interval.

[0167] In practice, upon receiving a data compression request, the target consensus node determines a target interval on its blockchain and extracts P objects from that interval. Then, it obtains the second state value of the transaction data corresponding to each of the P objects after execution. This second state value is stored in the last block (i.e., the (n+m)th block) of the target interval. In other words, it obtains the second state value (post-state-root) of each of the P objects in the (n+m)th block of the target consensus node's blockchain. The second state value of any object in the (n+m)th block indicates the state value of the transaction data corresponding to that object after execution. Subsequent steps are then executed to generate new interval transactions.

[0168] Similar to the specific implementation process described in step S202, which involves constructing the first Merkle tree of the target interval based on the first state values ​​of each object in the object sequence, after the target consensus node obtains the second state value of each of the P objects in the (n+m)th block, it can construct the second Merkle tree of the target interval based on the second state value of each object in the object sequence. The order of the leaf nodes in the second Merkle tree is consistent with the order of the objects in the object sequence. Then, a root hash calculation is performed on the second Merkle tree to obtain the second root hash. Finally, the second root hash is determined as the second state root of the target interval. An exemplary process for constructing the second Merkle tree of the target interval based on the second state value of each object in the object sequence can be found in [reference needed]. Figure 7 For details on the construction process of the second Merkle tree, please refer to [link to relevant documentation]. Figure 6 The specific construction process shown is not detailed here.

[0169] S204: Based on the transaction data in m+1 blocks, the first and second state values ​​of each object, and the first and second state roots corresponding to the target interval, a zero-knowledge proof circuit is used for computation to obtain the interval transactions of the target interval.

[0170] Based on the aforementioned steps, after obtaining the transaction data from the m+1 blocks in the target interval, the first and second state values ​​of each object involved in the transaction data, and the first and second state roots generated based on the state values ​​for the target interval, the zero-knowledge proof circuit can be invoked for computation to obtain the interval transactions for the target interval. The interval transactions do not contain the transaction data of each block in the m+1 blocks, but contain relevant information about the target interval. Based on this relevant information, the state value of the transaction data contained in any block of the m+1 blocks can be recovered. This allows for a significant reduction in the storage load of the target consensus node through interval transactions, while still ensuring that the state value of the blockchain in the target consensus node can be recovered at any given time based on the compressed interval transactions.

[0171] The specific process of generating range trading within the target range may include the following steps s11-s14, wherein:

[0172] s11: Obtaining the zero-knowledge proof circuit. As described above, the zero-knowledge proof circuit is generated based on the proposition to be proved; the zero-knowledge proof circuit contains the operational logic for generating proof information for the target interval and the operational logic for verifying the interval transactions generated for the target interval; based on this, the zero-knowledge proof circuit can be called an arithmetic circuit (Rank One Constrain System, R1CS). An exemplary structure of a zero-knowledge proof circuit can be found in [reference needed]. Figure 8This zero-knowledge circuit consists of several addition gates, multiplication gates, and constant gates, such as... Figure 8 The zero-knowledge proof circuit shown includes two multiplication gates and one addition gate. Assuming the input information of the zero-knowledge proof circuit is a, b, and c, the addition gate adds a and b to obtain a + b, and the multiplication gate multiplies b and c to obtain b * c. Then, the multiplication gate multiplies a + b and b * c to obtain the output information (a + b) * b * c of the zero-knowledge proof circuit. It should be noted that some common computational logics, such as calculating expressions and hash values, can also be represented as zero-knowledge proof circuits.

[0173] In practical applications, initializing the proposition to be proved yields a zero-knowledge proof circuit. When input information is fed into the zero-knowledge proof circuit, operations are performed sequentially according to the gates within the circuit to obtain its output information. This output information can be simply understood as the answer obtained from solving the proposition to be proved. The proposition to be proved can be set by the development object or business object based on actual business needs.

[0174] It should also be noted that, in this embodiment, after initializing the zero-knowledge proof circuit based on the zero-knowledge concise non-interactive knowledge proof technology, a key generation algorithm for the zero-knowledge concise non-interactive knowledge proof technology can be obtained. Based on this key generation algorithm, a prover public string is generated for the prover, and a verifier public string is generated for the verifier. The prover public string is the key used by the prover, and the prover includes the target consensus node. The verifier public string is the key used by the verifier, and the verifier includes any consensus node in the blockchain network that needs to synchronize blocks in the target interval. Furthermore, the generated verifier public string is stored in the blockchain to achieve on-chain verification of the verifier public string, thus ensuring its security. Furthermore, the zero-knowledge proof circuit and prover public string obtained from the initialization are made public off-chain, such as by placing the zero-knowledge proof circuit and prover public string on a website page. In this way, any consensus node (such as the target consensus node) in the blockchain network that has the permission and need to obtain the zero-knowledge proof circuit and / or prover public string can open the website page through the link address (such as the website address) to obtain the zero-knowledge proof circuit and / or prover public string.

[0175] s12: Construct a transaction set based on transaction data from m+1 blocks. Considering that the threshold for the number of input transaction data is set when creating the zero-knowledge proof circuit (i.e., the number of transaction data input to the zero-knowledge proof circuit is fixed), when the total number of transaction data in m+1 blocks is less than the threshold, empty transaction data is needed to pad the set, ensuring that the total number of transaction data in the transaction set input to the zero-knowledge proof circuit equals the threshold. Specifically, the transaction data in m+1 blocks is statistically analyzed to obtain the number of transaction data in m+1 blocks. If the number of transaction data in m+1 blocks equals the threshold, the transaction set contains the transaction data from m+1 blocks. If the number of transaction data in m+1 blocks is less than the threshold, a target number of empty transaction data is obtained and added to the transaction set. At this point, the transaction set contains the transaction data from m+1 blocks and the empty transaction data, and the sum of the number of empty transaction data (i.e., the target number) and the number of transaction data in m+1 blocks equals the threshold. The aforementioned empty transaction data refers to transactions represented in the default format, which do not contain transaction data.

[0176] An exemplary diagram illustrating the construction of a transaction set based on transaction data from m+1 blocks can be found here. Figure 9 ,like Figure 9 As shown, assuming the target interval on the blockchain of the target consensus node contains the following transaction data: transaction data 1, transaction data 2, transaction data 3, ..., transaction data X, where X is an integer greater than 3; if X is less than the quantity threshold set for the target interval, then the quantity threshold can be subtracted from X to obtain the difference Y, which indicates that Y empty transaction data are needed to fill the transaction set. Then, Y empty transaction data are obtained and added to the transaction set to obtain a transaction set containing the quantity threshold.

[0177] s13: A zero-knowledge proof circuit is used to verify the first and second state values ​​of each object, the first and second state roots corresponding to the target interval, and the transaction set, generating proof information for the target interval. Based on the foregoing description, the zero-knowledge proof circuit is generated based on the proposition to be proved, and the circuit contains the computational logic for generating proof information. Therefore, by inputting the first and second state values ​​of each object, the first and second state roots corresponding to the target interval, and the transaction set into the zero-knowledge proof circuit, proof information for the target interval can be directly generated based on the circuit's output information.

[0178] The proof information for the target interval may include: the output information of the zero-knowledge proof circuit corresponding to the target interval, and the proof string (or zk-SNARK). Specifically: ① The output information of the zero-knowledge proof circuit corresponding to the target interval includes: the first candidate state root generated by the zero-knowledge proof circuit based on the first state value of each object in the input information, and the first comparison result between this first candidate state root and the first state root corresponding to the target interval generated by the target consensus node; the second candidate state root generated by the zero-knowledge proof circuit based on the second state value of each object in the input information, and the second comparison result between this second candidate state root and the second state root corresponding to the target interval generated by the target consensus node; the write set hash calculated by the zero-knowledge proof circuit based on the write set field of each transaction data in the transaction set; and the transaction set hash calculated by the zero-knowledge proof circuit based on the hash values ​​of all transaction data in the transaction set except for empty transaction data. ② The proof string is generated based on the calculation process of the prover's public string for the zero-knowledge proof circuit to obtain the output information; that is, the proof string can refer to the calculation process generated by the prover for the zero-knowledge proof circuit, and the generation of this proof string can be used to indicate that the prover (such as the target consensus node) has performed the calculation process based on the zero-knowledge proof circuit. The proof string can be a string composed of multiple characters, including but not limited to: English characters (i.e., letters), numbers, and punctuation marks (such as commas ",", periods ".", square brackets "【】").

[0179] In this embodiment of the application, the process of generating the proof string in the proof information of the target interval can be found in the relevant content described above; the following is in conjunction with... Figure 10 The focus is on the calculation process of the zero-knowledge proof circuit verifying the first and second state values ​​of each object, the first and second state roots corresponding to the target interval, and the transaction set to obtain the output information of the zero-knowledge proof circuit. This calculation process can roughly include steps 1-4. This application embodiment does not limit the execution order of steps 1-5, but this is explained here. Figure 10 As shown:

[0180] Step 1: Input the first and second state values ​​of each object, the first and second state roots corresponding to the target interval, and the transaction set into the zero-knowledge proof circuit. The first and second state values ​​of each object, as well as the transaction set, are non-public inputs to the zero-knowledge proof circuit. Non-public inputs can be simply understood as input information accessible only to the verifier, effectively ensuring the confidentiality of the first and second state values ​​of the input objects. The first and second state roots corresponding to the target interval are public inputs to the zero-knowledge proof circuit; conversely, public inputs refer to input information that any blockchain node in the blockchain network with a need for access can access (or obtain).

[0181] Step 2: The zero-knowledge proof circuit constructs a first candidate Merkle tree for the target interval based on the first state value (or pre-state) of each object in the input information, calculates the first candidate state root of the first candidate Merkle tree, and then compares the first candidate state root with the first state root corresponding to the target interval contained in the input information to obtain a first comparison result. If the first comparison result is successful, it indicates that the verification of the first state root of the target interval is successful, meaning that the first state root corresponding to the target interval generated by the target consensus node is the same as the first candidate state root corresponding to the target interval generated by the zero-knowledge proof circuit, i.e., the first state root corresponding to the target interval generated by the prover is correct. Conversely, if the first comparison result is unsuccessful, it indicates that the verification of the first state root corresponding to the target interval is unsuccessful, meaning that the first state root corresponding to the target interval generated by the target consensus node is different from the first candidate state root corresponding to the target interval generated by the zero-knowledge proof circuit, i.e., the first state root corresponding to the target interval generated by the prover is incorrect. Furthermore, the first comparison result obtained based on the above implementation process is a publicly available output of the zero-knowledge proof circuit, meaning that this first comparison result can be accessed by any blockchain node in the blockchain network.

[0182] Step 3: The zero-knowledge proof circuit constructs a second candidate Merkle tree for the target interval based on the second state value (or post-state) of each object in the input information, calculates the second candidate state root of the second candidate Merkle tree, and then compares the second candidate state root with the second state root corresponding to the target interval contained in the input information to obtain a second comparison result. If the second comparison result is successful, it indicates that the verification of the second state root of the target interval is successful, meaning that the second state root corresponding to the target interval generated by the target consensus node is the same as the second candidate state root corresponding to the target interval generated by the zero-knowledge proof circuit, i.e., the second state root corresponding to the target interval generated by the prover is correct. Conversely, if the second comparison result is unsuccessful, it indicates that the verification of the second state root corresponding to the target interval is unsuccessful, meaning that the second state root corresponding to the target interval generated by the target consensus node is different from the second candidate state root corresponding to the target interval generated by the zero-knowledge proof circuit, i.e., the second state root corresponding to the target interval generated by the prover is incorrect. Furthermore, the second comparison result obtained based on the above implementation process is a publicly available output of the zero-knowledge proof circuit, meaning that this second comparison result can be accessed by any blockchain node in the blockchain network.

[0183] Step 4: The zero-knowledge proof circuit obtains the write set field for each transaction (excluding empty transactions) from the transaction set of the input information. The write set field for any transaction is located within the transaction results contained in that transaction. Then, a hash calculation is performed on the write set field for each transaction to obtain the write set hash. The write set field can be a string representing the write set of the transaction. For example, the write set field for transaction 1 in the transaction set is represented as RwSet1, for transaction 2 as RwSet2, and for transaction 3 as RwSet3. The resulting write set hash can be represented as hash(RwSet1|RwSet2|RwSet3|…). It should be noted that the hash algorithm is described in the preceding section and will not be repeated here. Furthermore, based on the above implementation process, the write set hash is a publicly available output of the zero-knowledge proof circuit, meaning that this write set hash can be accessed by any blockchain node in the blockchain network.

[0184] Step 5: The zero-knowledge proof circuit obtains the hash value of each transaction (excluding empty transactions) from the transaction set in the input information. Then, it uses a hash algorithm to calculate the hash value of each transaction (excluding empty transactions) to obtain the transaction set hash. As described above, the hash algorithm may include algorithms such as MD5. This application embodiment does not limit the specific hash algorithm used, but this is only stated here. Furthermore, the calculated transaction set hash is a publicly available output of the zero-knowledge proof circuit, meaning that this transaction set hash can be accessed by any blockchain node in the blockchain network.

[0185] In summary, based on the specific implementation process shown in steps 1-5 above, the output information of the zero-knowledge proof circuit can be obtained. Then, based on the output information of the zero-knowledge proof circuit and the proof string generated by the prover using the prover's common string as the calculation process of the zero-knowledge proof circuit, the proof information of the target interval can be constructed.

[0186] s14: Constructing range trading for the target range based on proof information.

[0187] The target interval transactions constructed based on the proof information may include: a threshold for the number of transaction data contained in the target interval, the starting block height n of the target interval, the ending block height n+m of the target interval, proof information, validator public string, the write set of each transaction data in m+1 blocks on the blockchain of the target consensus node, the interval identifier of the target interval, and the hash of the candidate transaction set, etc. Among these: ① The process of obtaining the threshold for the number of transaction data contained in the target interval, the starting block height n of the target interval, and the ending block height n+m of the target interval can be found in the relevant description of the specific implementation process shown in step S201 above, and will not be repeated here. ② The write set of each transaction data in m+1 blocks on the blockchain of the target consensus node can be obtained from the blocks contained in the blockchain of the target consensus node; the specific acquisition process is not limited. ③ The interval identifier of the target interval can be used to uniquely identify the target interval on the blockchain of the target consensus node; that is, the interval range of the target interval on the blockchain of the target consensus node can be quickly located based on this interval identifier. ④ The candidate transaction set hash is generated by the target consensus node based on the hash values ​​of transaction data in m+1 blocks of its blockchain. That is, the target consensus node can obtain the hash value of each transaction from the m+1 blocks stored on its blockchain, and then use a hash algorithm to re-hash the hash value of each transaction to obtain the candidate transaction set hash. For a detailed description of the hash algorithm, please refer to step S202; it will not be repeated here. ⑤ The verifier public string is generated using the key generation algorithm mentioned above. ⑥ The proof information is generated by the target consensus node for the target interval using a zero-knowledge proof circuit.

[0188] It should be noted that the specific generation process of the information contained in the above-mentioned trading ranges can be found in the aforementioned descriptions, and will not be repeated here.

[0189] S205: Use interval transactions to compress the blockchain in the target consensus node.

[0190] In practice, the transaction data in the m+1 blocks of the blockchain in the target consensus node can be cleared. The block bodies of the cleared m+1 blocks will not contain transaction data, thus freeing up the storage space of the target consensus node to a certain extent. Then, the target transaction data in the i-th block of the blockchain in the target consensus node is replaced with the interval transactions of the target interval, where i is an integer and i∈[n,n+m]. That is, the generated interval transactions of the target interval can be stored in any block of the target interval (such as the i-th block). Specifically, the interval transactions can be used to replace the target transaction data in any block for storage. This is equivalent to using interval transactions with smaller storage space to replace the massive transaction data of the target interval that occupy storage space, thereby reducing the storage burden of the target consensus node. As described above, each block in the target interval contains cleared transaction data. Therefore, replacing the target transaction data in the i-th block with an interval transaction means storing the interval transaction in the storage space (or storage location) where the target transaction data in the i-th block is located. Furthermore, considering that all transaction data in the block body of the i-th block is cleared, the target transaction data in the i-th block can refer to the transaction data with the earliest on-chain time in the i-th block.

[0191] The following is combined Figure 11 Taking the i-th block as the first block contained in the target interval (i.e., the n-th block), and the target transaction data as the first transaction in the i-th block, a schematic diagram is given of using interval transactions to compress the blockchain in the target consensus node; Figure 11As shown, assuming the target interval includes blocks n to (n+m) of the blockchain; where the block body of block n contains transaction data 1, transaction data 2, and transaction data 3, the block body of block (n+1) contains transaction data 4, ..., and the block (n+m) contains transaction data 5 and transaction data 6, then after obtaining the interval transactions, the transaction data in each block from block n to (n+m) is first deleted (or cleared). Then, the interval transaction replaces the first transaction in block n (e.g., transaction data 1). Specifically, the interval transaction is placed at the storage location of the first transaction in block n, resulting in the compressed blockchain in the target consensus node. Through this compression method, interval transactions with smaller storage space can replace the massive amount of transaction data occupying storage space in the target interval, significantly reducing the storage load on the target consensus node in the blockchain network. Furthermore, the compressed blockchain contains interval transactions, and each interval transaction contains a write set of each transaction data. This ensures that the state value of the blockchain at any point in time can be recovered from the compressed data. For example, to recover the state value of the transaction data in the (n+3)th block of the target interval, the state value of the object corresponding to the transaction data in the (n+3)th block can be recovered from the state values ​​contained in the write sets of each block before the (n+3)th block.

[0192] In this embodiment, the blockchain in the target consensus node has a target interval containing m+1 blocks, such as the nth block to the (n+mth)th block on the chain. The target consensus node can obtain the first state value of the object corresponding to the transaction data in the (n-1th)th block, and the second state value of each object in the (n+mth)th block. The first state value can be understood as the state value of the transaction data corresponding to the object before execution, and the second state value can be understood as the state value of the transaction data corresponding to the object after execution. Thus, the first state root of the target interval is obtained based on the state value before the transaction data is executed, and the second state root of the target interval, the transaction data in the m+1 blocks, the first state value, and the second state value are obtained based on the second state value after the transaction data is executed. Using a zero-knowledge proof circuit, the interval transaction of the target interval can be obtained, which contains relevant information of the target interval. Finally, by deleting the transaction data in the m+1 blocks in the blockchain of the target consensus node and adding the interval transaction to one of the m+1 blocks, the compression processing of the transaction data in the target interval is achieved. The data compression schemes described above significantly reduce the storage load on the target consensus nodes while also ensuring that: 1) the state value of the blockchain at any given time can be recovered from the compressed data; 2) it can be proven that the generated interval transactions in the target interval are compressed from the transaction data contained in the target interval before compression, thus proving the existence of interval transactions, i.e., there is a correlation between interval transactions and transaction data in the target interval; and 3) it can also be proven that the interval transactions in the target interval are correctly compressed, rather than tampered with.

[0193] The above Figure 2 The illustrated embodiment mainly describes the implementation process of compressing the blockchain in the target consensus node (such as a prover) in a blockchain network based on zero-knowledge proof. The following section will combine... Figure 12 This paper elaborates on the implementation process of validators (such as the first consensus node) verifying the zero-knowledge proof circuit. Figure 12 The illustration shows a flowchart of a block synchronization method based on a blockchain network according to an exemplary embodiment of this application; the block synchronization method can be executed by a first consensus node in the blockchain network other than the target consensus node, and the block synchronization method may include, but is not limited to, steps S1201-S1204:

[0194] S1201: Synchronize the i-th block on the blockchain from the second consensus node in the blockchain network.

[0195] It should be understood that when a new consensus node is added to the blockchain network, this node needs to synchronize the various blocks on the blockchain sequentially, starting from the genesis block, according to the linked order of the blocks, to achieve distributed data storage in the blockchain network. If the first consensus node in the blockchain network is performing block synchronization, then this first consensus node can synchronize the genesis block, the first block, ..., the i-th block from the blockchain of the second consensus node to achieve distributed data storage. The first consensus node can be a newly added consensus node in the blockchain network, or a consensus node that already exists in the blockchain network but has not yet synchronized to the i-th block. The second consensus node is any consensus node in the blockchain network other than the first consensus node. For example, if the second consensus node is... Figure 2 The target consensus node mentioned in the illustrated embodiment. The process by which the first consensus node synchronizes the i-th block on the blockchain from the second consensus node can be understood as follows: the first consensus node sends a block synchronization request to the second consensus node based on the block height i of the i-th block to be synchronized; in response to the block synchronization request, the second consensus node sends the i-th block to the first consensus node, specifically sending the block header and block body of the i-th block to the first consensus node.

[0196] S1202: If the i-th block contains the identifier of the interval transaction, then obtain the interval transaction based on the identifier of the interval transaction.

[0197] When the first consensus node synchronizes the i-th block from the blockchain of the second consensus node, the first consensus node obtains the block header and block body of the i-th block. If the block body of the i-th block contains the identifier of the interval transaction, it is determined that the blockchain in the blockchain network has undergone data compression processing, and then the step of obtaining the interval transaction based on the identifier of the interval transaction is executed.

[0198] It is worth noting that after the target consensus node generates a range transaction for the target range in this embodiment, other consensus nodes with consensus permissions in the blockchain network where the target consensus node is located (such as the second consensus node) need to reach a consensus on the range transaction. Only after the consensus is successful will other consensus nodes in the blockchain network store the identifier of the range transaction and decide whether to store the range transaction based on their own data compression needs. In other words, the identifier of the range transaction is stored in the i-th block of the blockchain in the second consensus node after the second consensus node (or other consensus nodes in the blockchain network) successfully verifies the range transaction.

[0199] The following is combined with Figure 13 This paper takes the second consensus node in a blockchain network as an example to provide a brief introduction to the consensus process of the second consensus node for interval transactions. In the specific implementation:

[0200] First, the second consensus node responds to broadcast events for interval transactions (such as events generated when the target consensus node sends the interval transaction to the second consensus node, or events generated when other consensus nodes in the blockchain network forward the interval transaction to the second consensus node) and obtains the interval transaction. The interval transaction contains the candidate transaction set hash and the write set of transaction data in the target interval. The candidate transaction set hash is obtained by the target consensus node based on the hash values ​​of the transaction data in blocks n to n+m on the blockchain of the target consensus node.

[0201] Secondly, the hash values ​​of transaction data from block n to block (n+m) are obtained from the blockchain of the second consensus node, and hash calculations are performed on these hash values ​​to obtain the transaction hash value calculated by the second consensus node. Then, the transaction hash value calculated by the second consensus node is compared with the hash values ​​of the candidate transaction set included in the interval transactions, calculated by the target consensus node, to obtain the transaction hash comparison result. If the comparison result is successful, it means that the transaction hash value calculated by the second consensus node is the same as the hash value of the candidate transaction set included in the interval transactions, calculated by the target consensus node, and the candidate transaction set hash is determined to be correct. Conversely, if the comparison result is unsuccessful, it means that the transaction hash value calculated by the second consensus node is different from the hash value of the candidate transaction set included in the interval transactions, calculated by the target consensus node, and the candidate transaction set hash is determined to be incorrect.

[0202] Secondly, the write set of transaction data from block n to block (n+m) is obtained from the blockchain of the second consensus node. This write set is then compared with the write set of transaction data within the interval transactions to obtain the write set comparison result. If the write set comparison result is successful, it indicates that the state values ​​corresponding to the transaction data in the interval transactions are correct, meaning the write set of transaction data in the interval transactions has not been tampered with. Conversely, if the write set comparison result is unsuccessful, it indicates that one or more of the state values ​​corresponding to the transaction data in the interval transactions are incorrect. This application embodiment does not limit the execution order of the two verification steps given above; this is only a description of the specific steps.

[0203] Finally, if both the write set comparison result and the transaction hash comparison result are successful, it means that the candidate transaction set hash in the interval transaction is correct and the write set of the transaction data in the interval transaction has not been tampered with. Then the verification result is obtained and the verification result is successful.

[0204] Furthermore, upon successful verification, the second consensus node stores the identifier of the interval transaction. If the second consensus node requires data compression, it further compresses the blockchain within itself based on the interval transaction to enable the second consensus node to store the interval transaction. For the specific implementation process of the second consensus node compressing the blockchain based on the interval transaction, please refer to the aforementioned... Figure 2 The specific implementation process of the first consensus node compressing the blockchain in the first consensus node based on interval transactions in the illustrated embodiment will not be repeated here.

[0205] Based on the above description of the verification of interval transactions by the second consensus node, it is clear that the presence of an interval transaction identifier in the i-th block of the second consensus node does not necessarily mean that the i-th block contains an interval transaction. Therefore, the specific process of obtaining the interval transaction based on its identifier differs depending on whether the blockchain of the second consensus node stores the interval transaction. Optionally, if the blockchain of the second consensus node stores an interval transaction (e.g., the block body of the i-th block contains the interval transaction), the first consensus node can directly obtain the interval transaction from the second consensus node. Optionally, if the i-th block of the blockchain of the second consensus node only contains the interval transaction identifier and not the interval transaction itself, the first consensus node obtains the interval transaction from a consensus node in the blockchain network that stores the interval transaction based on its identifier. The following, with reference to the accompanying diagrams, describes the implementation process of the first consensus node obtaining the interval transaction based on its identifier in two scenarios: when the blockchain of the second consensus node stores an interval transaction, and when it does not store an interval transaction.

[0206] (1) The i-th block on the blockchain of the second consensus node contains the identifier of the interval transaction, and the i-th block contains the interval transaction. A schematic diagram of obtaining the interval transaction under this implementation can be found in [reference needed]. Figure 14a ,like Figure 14a As shown, assuming i = n, the block body of the nth block on the blockchain of the second consensus node stores the interval transactions. Since the first consensus node has synchronized the block body of the ith block from the second consensus node in the previous steps, the first consensus node can directly obtain the interval transactions from the block body of the ith block.

[0207] (2) The i-th block on the blockchain of the second consensus node contains the identifier of the interval transaction, but the i-th block does not contain any interval transactions. Under this implementation, the embodiments of this application support the following two optional implementation processes for obtaining interval transactions, wherein:

[0208] In one implementation, the second consensus node returns the target node identifier of any consensus node storing interval transactions to the first consensus node, so that the first consensus node can retrieve the interval transactions from that consensus node based on the target node identifier. Specifically, if the first consensus node finds that the i-th block synchronized from the blockchain of the second consensus node does not contain interval transactions, the first consensus node can send a first retrieval request to the second consensus node. This first retrieval request requests the second consensus node to return the target node identifier of the consensus node storing interval transactions in the blockchain network, such as returning the node identifier of the target consensus node. In response to the first retrieval request, the second consensus node retrieves the target node identifier of any consensus node storing interval transactions in the blockchain network from the node identifier list maintained by the second consensus node (as mentioned in Table 1 above), and then returns the target node identifier to the first consensus node, so that the first consensus node can retrieve the interval transactions from the consensus node corresponding to the target node identifier based on the target node identifier. For example, the first consensus node sends an interval transaction retrieval request to the consensus node corresponding to the target node identifier, and the consensus node corresponding to the target node identifier returns the interval transactions in response to the interval transaction retrieval request. An exemplary diagram illustrating the process of obtaining a range transaction via a first acquisition request can be found here. Figure 14b .

[0209] In other implementations, the second consensus node retrieves a range transaction from any consensus node in the blockchain network that stores range transactions and forwards it to the first consensus node. Specifically, if the first consensus node finds that the i-th block synchronized from the second consensus node's blockchain does not contain a range transaction, the first consensus node can send a second retrieval request to the second consensus node. This second retrieval request requests the second consensus node to retrieve and return the range transaction from any consensus node in the blockchain network that stores it. Upon receiving the second retrieval request from the first consensus node, the second consensus node can respond by retrieving the range transaction from any consensus node in the blockchain network that stores it. The second consensus node then returns the range transaction to the first consensus node. An exemplary diagram illustrating the retrieval of a range transaction via a second retrieval request can be found [link to diagram]. Figure 14c .

[0210] S1203: Verify the range trading and obtain the verification results.

[0211] As described above, the interval transactions generated by the target consensus node for the target interval include: the write set of each transaction data in m+1 blocks on the blockchain of the target consensus node, proof information, validator public string, and candidate transaction set hash. The proof information includes the output information of the zero-knowledge proof circuit and the proof string; the validator public string is generated by the target consensus node for the validator according to the key generation algorithm, and in this embodiment, the validator includes the first consensus node; the candidate transaction set hash is obtained by the target consensus node performing hash calculations on the hash values ​​of the transaction data in m+1 blocks.

[0212] In specific implementation, the first consensus node verifies the interval transactions, and the specific implementation process for obtaining the verification result may include steps s21-s23, wherein:

[0213] s21: Based on the write set of each transaction in the m+1 blocks of the interval transaction and the hash of the candidate transaction set, generate verification information. The generated verification information includes: a first reference state root, a second reference state root, a reference write set hash, and a candidate transaction hash. The generation process of each piece of information included in the verification information is explained below. Specifically:

[0214] ① The process of generating the first reference state root. In the specific implementation, P corresponding transactions are extracted from the write set of transaction data in the interval transactions, and the third state value of the P objects in the (n-1)th block is obtained from the blockchain of the first consensus node; then, the third state value of the P objects is processed by root calculation to obtain the first reference state root. The specific implementation process of the root calculation process of the third state value of the P objects can be found in the relevant description of the specific implementation process of the first consensus node to perform root calculation process of the first state value of the P objects described above, and will not be repeated here.

[0215] ② The process of generating the second state root. In specific implementation, the write set of transaction data in the interval transaction is obtained, and the write set of transaction data in the interval transaction is pre-executed to obtain the updated fourth state values ​​of P objects; in other words, after obtaining the write set of transaction data in the interval transaction, the write set can be pre-executed to update the state values ​​of P objects and obtain the updated fourth state values ​​of P objects; then, the root calculation process is performed on the updated fourth state values ​​of P objects to obtain the second reference state value. As described above, the write set corresponding to any transaction data contains the current state value of that transaction data. Therefore, the pre-execution of the write set mentioned above can be simply understood as using the state values ​​(i.e., the fourth state values) of the transaction data in the write set to update the third state value of the transaction data on the blockchain in the first consensus node to obtain the updated fourth state value.

[0216] ③ Refer to the process of generating the write set hash. In the specific implementation, the field containing the write set of transaction data in the m+1 blocks of the interval transactions is obtained. Then, the write set field of the transaction data in the interval transactions is hashed to obtain the reference write set hash.

[0217] ④ As described above, the candidate transaction set hash is directly contained in the interval transaction; therefore, the first consensus node can directly obtain the candidate transaction set hash from the interval transaction.

[0218] In summary, based on the implementation processes shown in ①, ②, ③ and ④ above, the first consensus node can generate verification information based on interval transactions.

[0219] s22: Verify the output information of the zero-knowledge proof circuit in the proof information of the interval transaction using the verification information.

[0220] Based on the foregoing description, the output information of the zero-knowledge proof circuit in the proof information includes: a first comparison result, a second comparison result, a write set hash, and a transaction set hash. The first comparison result is obtained by comparing the first candidate state root of the first candidate Merkle tree constructed by the target consensus node based on the first state values ​​of P objects with the first state root of the target interval. The second comparison result is obtained by comparing the second candidate state root of the second candidate Merkle tree constructed by the target consensus node based on the second state values ​​of P objects with the second state root of the target interval. The write set hash is obtained by the target consensus node performing a hash calculation based on the write set field of each transaction data in the input information of the zero-knowledge proof circuit. The transaction set hash is obtained by the target consensus node performing a hash operation based on the hash values ​​of the transaction data in the zero-knowledge proof circuit. It should be noted that the specific generation process of each piece of information included in the output information of the aforementioned zero-knowledge proof circuit can be found in the foregoing... Figure 2 The specific implementation process described in the illustrated embodiments will not be repeated here.

[0221] The specific implementation process of verifying the output information of the zero-knowledge proof circuit based on verification information may include: First, if both the first comparison result and the second comparison result are successful, it indicates that the target consensus node has been determined: the first state root generated by the target consensus node based on the first state value of the transaction data in the blockchain is the same as the first candidate state value generated by the zero-knowledge proof circuit, and the second state root generated by the target consensus node based on the second state value of the transaction data in the blockchain is the same as the second candidate state value generated by the zero-knowledge proof circuit. Then, the first state root of the target interval is compared with the first reference state root to obtain the first reference comparison result; similarly, the second state root of the target interval is compared with the second reference state root to obtain the second reference comparison result. Currently, since the first comparison result is successful, the first candidate state root is the same as the first state root, so here we can also compare the first candidate state root with the first reference state root to obtain the first reference comparison result; similarly, since the second comparison result is successful, the second candidate state root is the same as the second state root, so here we can also compare the second candidate state root with the second reference state root to obtain the second reference comparison result. Secondly, the hash of the reference write set is compared with the hash of the write set in the output information of the zero-knowledge proof circuit to obtain the write set comparison result; and the hash of the transaction set in the output information of the zero-knowledge proof circuit is compared with the hash of the candidate transaction set in the interval transaction to obtain the transaction comparison result; finally, if the first reference comparison result, the second reference comparison result, the write set comparison result and the transaction comparison result are all successfully compared, then the verification is confirmed to be successful.

[0222] s23: If the verification passes, the proof string in the proof information is verified according to the verifier's common string to obtain the verification result.

[0223] As described above, the proof string in the proof information is generated by the prover using the prover's public string to calculate the output information of the zero-knowledge proof circuit. The generation of the proof string indicates that the target consensus node has executed the calculation process based on the zero-knowledge proof circuit. The prover's public string is the key used by the prover, and the prover includes the target consensus node. Therefore, the specific implementation process of verifying the proof string in the proof information based on the verifier's public string can include: obtaining the verifier's public string from the blockchain in the blockchain network, and using the verification public string to verify the proof string in the proof information of the target range to obtain the verification result. Here, the proof string is generated by the prover (i.e., all nodes) using the prover string to calculate the output information of the zero-knowledge proof circuit. When the verification result is successful, it can be determined that the target consensus node has indeed completed the calculation process of the zero-knowledge proof circuit. The specific implementation of this calculation process can be found in the aforementioned operational logic for obtaining the output information of the zero-knowledge proof circuit, and will not be elaborated here.

[0224] S1204: If the verification result is successful, store the updated state value of the write set of the transaction data in the interval transaction.

[0225] In specific implementation, when it is determined that the proof information in the interval transaction has been successfully verified, the embodiment of this application supports the first consensus node to store the interval transaction, specifically by storing the updated state value of the write set of the transaction data in the interval transaction; for example, storing the interval transaction at the storage location where the first transaction data in the synchronized i-th block is located.

[0226] It should be noted that, in this embodiment, after the first consensus node obtains the interval transaction, it supports synchronizing the block headers of each block from the nth block to the (n+mth block) on the blockchain of the second consensus node; then, after the interval transaction is successfully verified, the first consensus node stores the interval transaction in the target interval. Specifically, the process of the first consensus node synchronizing the block headers of the nth block to the (n+mth block) from the second consensus node after obtaining the interval transaction may include: the first consensus node obtaining the starting block height n and the ending block height n+m of the target interval from the interval transaction; then, based on the starting block height n and the ending block height n+m, synchronizing and storing the nth block to the (n+mth block) from the blockchain of the second consensus node, skipping the step of verifying the Merkle root in each synchronized block.

[0227] In this embodiment, after obtaining the interval transaction, the first consensus node (i.e., the validator) can synchronize the block headers of m+1 blocks between the nth block and the (n+m)th block from the blockchain of the second consensus node, and skip the Merkle root verification step; then, after the interval transaction is successfully verified, the interval transaction is stored in the m+1 blocks, which can realize the replacement of all transaction data in the target interval with the interval transaction of the target interval, thereby freeing up the storage space of the first consensus node (or any consensus node in the blockchain network that performs data compression) and reducing the storage load of the first consensus node.

[0228] The methods of the embodiments of this application have been described in detail above. In order to facilitate better implementation of the methods of the embodiments of this application, the apparatus of the embodiments of this application is provided below.

[0229] Figure 15 This illustration shows a schematic diagram of a data compression device based on a blockchain network, provided in an exemplary embodiment of this application. The data compression device can be a computer program (including program code) running on a target consensus node; the data compression device can be used to execute... Figure 2 The method embodiments shown include some or all of the steps; wherein the blockchain network contains one or more consensus nodes, the device includes a target consensus node in the blockchain network, the blockchain in the blockchain network has a target interval, the target interval contains m+1 blocks between the nth block and the (n+m)th block, where n and m are both integers greater than zero; the device includes the following units:

[0230] Processing unit 1501 is used to extract objects from transaction data in m+1 blocks to obtain P objects, where P is a positive integer.

[0231] The acquisition unit 1502 is used to acquire the first state value of each object in the (n-1)th block of the blockchain in the target consensus node, and to perform root calculation processing on the first state value of each object to obtain the first state root corresponding to the target interval.

[0232] The acquisition unit 1502 is also used to acquire the second state value of each object in the n+m block of the blockchain in the target consensus node, and to perform root calculation processing on the second state value of each object to obtain the second state root corresponding to the target interval.

[0233] The processing unit 1501 is also used to perform calculations based on the transaction data in m+1 blocks, the first state value and the second state value of each object, and the first state root and the second state root corresponding to the target interval, using a zero-knowledge proof circuit to obtain the interval transaction of the target interval.

[0234] Processing unit 1501 is also used to compress the blockchain in the target consensus node using interval transactions; wherein, the target interval in the blockchain of the compressed target consensus node does not contain transaction data, but contains interval transactions.

[0235] In one implementation, the processing unit 1501 is further configured to:

[0236] Receive a data compression request, which carries compression information.

[0237] In response to the data compression request, perform the step of extracting objects from the transaction data in m+1 blocks to obtain P objects;

[0238] The data compression request is initiated by the target object after inputting compression information into the target consensus node; or, the data compression request is sent by any consensus node in the blockchain network other than the target consensus node.

[0239] The compressed information includes: the starting block height n of the target range, the ending block height n+m of the target range, the threshold number of transaction data contained in the target range, and the node identifier of the target consensus node.

[0240] In one implementation, m+1 blocks store one or more transaction data, each transaction data including a transaction and the transaction result after the transaction is executed; any one of P objects refers to the data that needs to be written based on the transaction result in a transaction data;

[0241] Processing unit 1501 is also used for:

[0242] Sort one or more transaction data according to the order of their on-chain times in m+1 blocks to obtain a transaction sequence;

[0243] Sort the P objects according to the order of the transaction data in the transaction sequence to obtain the object sequence. The order of the P objects in the object sequence is consistent with the order of the transaction data corresponding to each object in the transaction sequence.

[0244] In one implementation, the processing unit 1501, when performing root calculation processing on the first state value of each object to obtain the first state root corresponding to the target interval, specifically performs the following:

[0245] Based on the first state value of each object in the object sequence, construct the first Merkle tree of the target interval. The order of the leaf nodes in the first Merkle tree is consistent with the order of the objects in the object sequence.

[0246] Perform root hash calculation on the first Merkle tree to obtain the first root hash of the first Merkle tree;

[0247] The first hash is determined as the first state root of the target interval.

[0248] In one implementation, the processing unit 1501, when performing root calculation processing on the second state value of each object to obtain the second state root corresponding to the target interval, specifically performs the following:

[0249] Based on the second state value of each object in the object sequence, construct the second Merkle tree of the target interval. The order of the leaf nodes in the second Merkle tree is consistent with the order of the objects in the object sequence.

[0250] Perform root hash calculation on the second Merkle tree to obtain the second root hash of the second Merkle tree;

[0251] The second root hash is determined as the second state root of the target interval.

[0252] In one implementation, the processing unit 1501 is used to perform computational processing based on transaction data in m+1 blocks, the first and second state values ​​of each object, and the first and second state roots corresponding to the target interval, using a zero-knowledge proof circuit to obtain the interval transaction of the target interval. Specifically, it is used for:

[0253] Obtain a zero-knowledge proof circuit, which is derived from the transformation of the proposition to be proved. The proposition to be proved is used to indicate the verification of the correctness of the interval transaction.

[0254] Construct a transaction set based on the transaction data in m+1 blocks;

[0255] A zero-knowledge proof circuit is used to verify the first and second state values ​​of each object, the first and second state roots corresponding to the target interval, and the transaction set, thereby generating proof information for the target interval.

[0256] Range trading is constructed based on the proof information to determine the target range;

[0257] The number of transaction data contained in the transaction set is equal to the quantity threshold. If the number of transaction data in m+1 blocks is equal to the quantity threshold, then the transaction set contains the transaction data in m+1 blocks. If the number of transaction data in m+1 blocks is less than the quantity threshold, then the transaction set contains the transaction data in m+1 blocks and empty transaction data, and the sum of the number of empty transaction data and the number of transaction data in m+1 blocks is equal to the quantity threshold.

[0258] In one implementation, the proof information for the target interval includes: the output information of the zero-knowledge proof circuit; and a processing unit 1501, used to perform verification processing on the first and second state values ​​of each object, the first and second state roots corresponding to the target interval, and the transaction set using the zero-knowledge proof circuit, specifically for generating the proof information for the target interval:

[0259] Construct the first candidate Merkle tree for the target interval based on the first state value of each object, and compare the first candidate state root of the first candidate Merkle tree with the first state root corresponding to the target interval to obtain the first comparison result;

[0260] Construct a second candidate Merkle tree for the target interval based on the second state value of each object, and compare the second candidate state root of the second candidate Merkle tree with the second state root corresponding to the target interval to obtain the second comparison result;

[0261] Obtain the field containing the write set for each transaction data (excluding empty transaction data) from the transaction set, and perform a hash calculation on the write set field for each transaction data to obtain the write set hash;

[0262] The hash of the transaction set is obtained by performing hash calculation on the hash values ​​of the transaction data excluding empty transaction data in the transaction set;

[0263] The output information of the zero-knowledge proof circuit includes: the first comparison result, the second comparison result, the write set hash, and the transaction set hash.

[0264] In one implementation, the proof information for the target interval further includes: a proof string; the processing unit 1501 is also used for:

[0265] Obtain the key generation algorithm, and generate the prover public string and the validator public string according to the key generation algorithm; the prover public string is the key used by the prover, and the prover includes the target consensus node; the validator public string is the key used by the validator, and the validator includes any consensus node in the blockchain network that needs to synchronize blocks in the target interval.

[0266] Based on the prover's common string, a proof string is generated for the computation process of the zero-knowledge proof circuit to obtain the output information; the generation of the proof string indicates that the target consensus node has executed the computation process based on the zero-knowledge proof circuit.

[0267] In one implementation, the processing unit 1501, when performing compression processing on the blockchain in the target consensus node using interval transactions, is specifically used for:

[0268] Clear the transaction data in the m+1 blocks contained in the blockchain of the target consensus node; and,

[0269] Replace the target transaction data in the i-th block of the blockchain in the target consensus node with the interval transaction, where i is an integer and i∈[n,n+m].

[0270] In one implementation, the target transaction data refers to the transaction data with the earliest on-chain time in the i-th block;

[0271] Blockchains in a blockchain network include either consortium blockchains or private blockchains.

[0272] The target interval transactions include: the threshold number of transaction data contained in the target interval, the starting block height n of the target interval, the ending block height n+m of the target interval, proof information, validator public string, the write set of each transaction data in m+1 blocks on the blockchain of the target consensus node, the interval identifier of the target interval, and the candidate transaction set hash; the candidate transaction set hash is generated based on the hash values ​​of the transaction data in m+ blocks on the blockchain of the target consensus node.

[0273] According to one embodiment of this application, Figure 15 The data compression device based on a blockchain network shown can be composed of individual or combined units into one or more other units, or some of the units can be further divided into multiple functionally smaller units. This achieves the same operation without affecting the technical effect of the embodiments of this application. The above units are based on logical function division. In practical applications, the function of one unit can be implemented by multiple units, or the function of multiple units can be implemented by one unit. In other embodiments of this application, the data compression device based on a blockchain network may also include other units. In practical applications, these functions can also be implemented with the assistance of other units, and can be implemented by multiple units working together. According to another embodiment of this application, the device can be configured to perform operations such as... Figure 2 The computer program (including program code) for each step involved in the corresponding method shown, to construct such... Figure 15 The data compression apparatus based on a blockchain network shown herein, and the data compression method based on a blockchain network for implementing embodiments of this application, are described. A computer program may be recorded on, for example, a computer-readable recording medium, loaded onto the aforementioned computing device via the computer-readable recording medium, and run therein.

[0274] In this embodiment of the application, the blockchain in the target consensus node is provided with a target interval, which contains m+1 blocks, such as the nth block to the (n+mth block)th block on the chain. The processing unit 1501 can obtain the first state value of the object corresponding to the transaction data in the (n-1th block)th block, and the second state value of each object in the (n+mth block). The first state value can be understood as the state value of the transaction data corresponding to the object before it is executed, and the second state value can be understood as the state value of the transaction data corresponding to the object after it is executed. In this way, the first state root of the target interval is obtained based on the state value before the transaction data is executed, and the second state root of the target interval is obtained based on the second state value after the transaction data is executed, along with the transaction data in m+1 blocks, the first state value, and the second state value. By using a zero-knowledge proof circuit, the interval transaction of the target interval can be obtained, which contains relevant information about the target interval. Finally, by deleting the transaction data in m+1 blocks in the blockchain of the target consensus node and adding the interval transaction to one of the m+1 blocks, the transaction data in the target interval is compressed, thereby freeing up the storage space of the target consensus node and reducing the storage load.

[0275] Figure 16 This illustration shows a schematic diagram of a blockchain-based block synchronization device according to an exemplary embodiment of this application. The blockchain-based block synchronization device can be a computer program (including program code) running on a first consensus node; the blockchain-based block synchronization device can be used to execute... Figure 12 The method embodiments shown include some or all of the steps; wherein the blockchain network contains one or more consensus nodes, and the device includes a first consensus node in the blockchain network other than the target consensus node; the blockchain in the blockchain network has a target interval, which contains m+1 blocks between the nth block and the (n+m)th block, where n and m are both integers greater than zero; the device includes the following units:

[0276] The acquisition unit 1601 is used to synchronize the i-th block on the blockchain from the second consensus node in the blockchain network. The second consensus node is any consensus node in the blockchain network other than the first consensus node, where i is an integer and i∈[n,n+m].

[0277] The acquisition unit 1601 is also used to acquire the interval transaction based on the interval transaction identifier if the i-th block contains the identifier of the interval transaction;

[0278] Processing unit 1602 is used to verify the range transaction and obtain the verification result;

[0279] The processing unit 1602 is also used to store the updated state value of the write set of the transaction data in the interval transaction if the verification result is successful.

[0280] In one implementation, the interval transaction includes: a write set of each transaction data in m+1 blocks on the blockchain of the target consensus node, proof information, a validator common string, and a candidate transaction set hash; the proof information includes the output information of the zero-knowledge proof circuit and the proof string; the zero-knowledge proof circuit is generated based on the proposition to be proved, which is used to indicate the verification of the correctness of the interval transaction; the validator common string is generated by the target consensus node for the validators according to the key generation algorithm, and the validators include the first consensus node; the candidate transaction set hash is obtained by the target consensus node by hashing the hash values ​​of the transaction data in m+1 blocks;

[0281] Processing unit 1602 is used to verify range transactions. When the verification result is obtained, it is specifically used for:

[0282] Verification information is generated based on the write set of each transaction in m+1 blocks and the hash of the candidate transaction set;

[0283] The output information of the zero-knowledge proof circuit in the proof information is verified using the verification information;

[0284] If the verification passes, the proof string in the proof information is verified based on the verifier's common string to obtain the verification result.

[0285] In one implementation, the processing unit 1602, when generating verification information based on the write set of each transaction data in m+1 blocks and the hash of the candidate transaction set, specifically performs the following:

[0286] Extract the corresponding P objects from the write set of transaction data in the interval transaction, and obtain the third state value of the P objects in the (n-1)th block from the blockchain of the first consensus node;

[0287] Root calculation is performed on the third state values ​​of P objects to obtain the first reference state root; and,

[0288] The write set of transaction data in the interval transaction is pre-processed to obtain the updated fourth state values ​​of P objects, and the root calculation is performed on the updated fourth state values ​​of the P objects to obtain the second reference state root; and,

[0289] Perform a hash calculation on the field containing the write set of the transaction data in the interval transaction to obtain the reference write set hash;

[0290] The verification information includes: the first reference state root, the second reference state root, the reference write set hash, and the candidate transaction set hash.

[0291] In one implementation, the output information of the zero-knowledge proof circuit in the proof information includes: a first comparison result, a second comparison result, a write set hash, and a transaction set hash; the first comparison result is obtained by comparing the first candidate state root of the first candidate Merkle tree constructed by the target consensus node based on the first state values ​​of P objects with the first state root of the target interval; the second comparison result is obtained by comparing the second candidate state root of the second candidate Merkle tree constructed by the target consensus node based on the second state values ​​of P objects with the second state root of the target interval.

[0292] Processing unit 1602, when verifying the output information of the zero-knowledge proof circuit in the proof information using verification information, is specifically used for:

[0293] If both the first comparison result and the second comparison result are successful, then the first state root of the target interval is compared with the first reference state root to obtain the first reference comparison result; and the second state root of the target interval is compared with the second reference state root to obtain the second reference comparison result.

[0294] The write set comparison result is obtained by comparing the reference write set hash with the write set hash in the output information of the zero-knowledge proof circuit.

[0295] The transaction set hash in the output information of the zero-knowledge proof circuit is compared with the candidate transaction set hash in the interval transaction to obtain the transaction comparison result;

[0296] If the first reference comparison result, the second reference comparison result, the write set comparison result, and the transaction comparison result are all successfully compared, then the verification is considered successful.

[0297] In one implementation, the processing unit 1602 is used to retrieve the interval transaction based on the interval transaction identifier if the i-th block contains the identifier of the interval transaction, specifically by:

[0298] If the i-th block on the blockchain of the second consensus node contains the identifier of the interval transaction, and the i-th block does not contain the interval transaction, then a first retrieval request is sent to the second consensus node, so that the second consensus node responds to the first retrieval request and returns the target node identifier of any consensus node in the blockchain network that stores the interval transaction.

[0299] Obtain the range transaction from the consensus node corresponding to the target node identifier based on the target node identifier;

[0300] Alternatively, a second retrieval request can be sent to the second consensus node, so that the second consensus node responds to the second retrieval request, retrieves and returns the range transaction from any consensus node in the blockchain network that stores the range transaction.

[0301] In one implementation, the identifier of an interval transaction is stored in the i-th block of the blockchain on the second consensus node's network after the second consensus node successfully verifies the interval transaction; the verification of interval transactions in the blockchain network by the second consensus node includes:

[0302] Retrieve range transactions, which include the hash of the candidate transaction set and the write set of transaction data in the target range;

[0303] The write set of transaction data from block n to block n+m is obtained from the blockchain of the second consensus node, and the write set of transaction data obtained from the blockchain of the second consensus node is compared with the write set of transaction data in the interval transaction to obtain the write set comparison result;

[0304] Obtain the hash values ​​of transaction data from block n to block n+m in the blockchain of the second consensus node, and perform hash calculation on the hash values ​​of the transaction data to obtain the transaction hash value;

[0305] The transaction hash value is compared with the hash of the candidate transaction set in the interval transaction to obtain the transaction hash comparison result;

[0306] If both the set comparison result and the transaction hash comparison result are successful, then the verification result is obtained, and the verification result is successful.

[0307] According to one embodiment of this application, Figure 16 The various units in the blockchain-based block synchronization device shown can be individually or entirely merged into one or more other units, or some of the units can be further divided into multiple functionally smaller units. This achieves the same operation without affecting the technical effect of the embodiments of this application. The above units are based on logical function division. In practical applications, the function of one unit can also be implemented by multiple units, or the function of multiple units can be implemented by one unit. In other embodiments of this application, the blockchain-based block synchronization device may also include other units. In practical applications, these functions can also be implemented with the assistance of other units, and can be implemented by multiple units working together. According to another embodiment of this application, the device can be executed by running on a general-purpose computing device, such as a computer, which includes processing elements and storage elements such as a central processing unit (CPU), random access storage medium (RAM), and read-only storage medium (ROM). Figure 12The computer program (including program code) for each step involved in the corresponding method shown, to construct such... Figure 16 The block synchronization device based on a blockchain network shown herein, and the block synchronization method based on a blockchain network for implementing embodiments of this application, are described. The computer program may be recorded on, for example, a computer-readable recording medium, loaded onto the aforementioned computing device via the computer-readable recording medium, and run therein.

[0308] In this embodiment, after acquiring the interval transaction, the acquisition unit 1601 can synchronize the block headers of m+1 blocks between the nth block and the (n+m)th block from the blockchain in the second consensus node, and skip the Merkle root verification step; then, after the interval transaction is successfully verified, the processing unit 1602 stores the interval transaction in the m+1 blocks, which can replace all transaction data in the target interval with the interval transaction of the target interval, thereby releasing the storage space of the first consensus node (or any consensus node in the blockchain network that performs data compression) and reducing the storage load of the first consensus node.

[0309] Figure 17 A schematic diagram of the structure of a blockchain node device provided in an exemplary embodiment of this application is shown. Please refer to [link / reference]. Figure 17 The blockchain node device includes a processor 1701, a communication interface 1702, and a computer-readable storage medium 1703. The processor 1701, communication interface 1702, and computer-readable storage medium 1703 can be connected via a bus or other means. The communication interface 1702 is used to receive and send data. The computer-readable storage medium 1703 can be stored in the memory of the blockchain node device. The computer-readable storage medium 1703 stores computer programs, including program instructions. The processor 1701 executes the program instructions stored in the computer-readable storage medium 1703. The processor 1701 (or CPU (Central Processing Unit)) is the computing and control core of the blockchain node device, suitable for implementing one or more instructions, specifically suitable for loading and executing one or more instructions to achieve corresponding methods or functions.

[0310] This application embodiment also provides a computer-readable storage medium (Memory), which is a memory device in a blockchain node device for storing programs and data. It is understood that the computer-readable storage medium here can include both the built-in storage medium in the blockchain node device and extended storage media supported by the blockchain node device. The computer-readable storage medium provides storage space that stores the processing system of the blockchain node device. Furthermore, the storage space also stores one or more instructions suitable for loading and execution by the processor 1701, which can be one or more computer programs (including program code). It should be noted that the computer-readable storage medium here can be high-speed RAM memory or non-volatile memory, such as at least one disk storage device; optionally, it can also be at least one computer-readable storage medium located remotely from the aforementioned processor.

[0311] In one embodiment, the computer-readable storage medium stores one or more instructions; the processor 1701 loads and executes one or more instructions stored in the computer-readable storage medium to implement the corresponding steps in the above-described embodiment of the data compression method based on a blockchain network. Specifically, the blockchain network includes one or more consensus nodes, the device includes a target consensus node in the blockchain network, and the blockchain in the blockchain network has a target interval containing m+1 blocks from the nth block to the (n+m)th block, where n and m are both integers greater than zero; the processor 1701 loads and executes one or more instructions in the computer-readable storage medium for the following steps:

[0312] Extract objects from the transaction data in m+1 blocks to obtain P objects, where P is a positive integer.

[0313] Obtain the first state value of each object in the (n-1)th block of the blockchain in the target consensus node, and perform root calculation on the first state value of each object to obtain the first state root corresponding to the target interval;

[0314] Obtain the second state value of each object in the (n+m)th block of the blockchain in the target consensus node, and perform root calculation on the second state value of each object to obtain the second state root corresponding to the target interval;

[0315] Based on the transaction data in m+1 blocks, the first and second state values ​​of each object, and the first and second state roots corresponding to the target interval, a zero-knowledge proof circuit is used for computation to obtain the interval transactions of the target interval.

[0316] The blockchain in the target consensus node is compressed using interval transactions; the target interval in the blockchain of the compressed target consensus node does not contain transaction data, but it does contain interval transactions.

[0317] In one implementation, one or more instructions in a computer-readable storage medium are loaded by processor 1701 and the following steps are also performed:

[0318] Receive a data compression request, which carries compression information.

[0319] In response to the data compression request, perform the step of extracting objects from the transaction data in m+1 blocks to obtain P objects;

[0320] The data compression request is initiated by the target object after inputting compression information into the target consensus node; or, the data compression request is sent by any consensus node in the blockchain network other than the target consensus node.

[0321] The compressed information includes: the starting block height n of the target range, the ending block height n+m of the target range, the threshold number of transaction data contained in the target range, and the node identifier of the target consensus node.

[0322] In one implementation, m+1 blocks store one or more transaction data, each transaction data including a transaction and the transaction result after the transaction is executed; any one of P objects refers to the data that needs to be written based on the transaction result in a transaction data;

[0323] One or more instructions in a computer-readable storage medium are loaded by processor 1701 and the following steps are also executed:

[0324] Sort one or more transaction data according to the order of their on-chain times in m+1 blocks to obtain a transaction sequence;

[0325] Sort the P objects according to the order of the transaction data in the transaction sequence to obtain the object sequence. The order of the P objects in the object sequence is consistent with the order of the transaction data corresponding to each object in the transaction sequence.

[0326] In one implementation, when one or more instructions in the computer-readable storage medium are loaded by the processor 1701 and executed to perform root calculation processing on the first state value of each object to obtain the first state root corresponding to the target interval, the following steps are specifically performed:

[0327] Based on the first state value of each object in the object sequence, construct the first Merkle tree of the target interval. The order of the leaf nodes in the first Merkle tree is consistent with the order of the objects in the object sequence.

[0328] Perform root hash calculation on the first Merkle tree to obtain the first root hash of the first Merkle tree;

[0329] The first hash is determined as the first state root of the target interval.

[0330] In one implementation, when one or more instructions in the computer-readable storage medium are loaded by the processor 1701 and are executed to perform root calculation processing on the second state value of each object to obtain the second state root corresponding to the target interval, the following steps are specifically performed:

[0331] Based on the second state value of each object in the object sequence, construct the second Merkle tree of the target interval. The order of the leaf nodes in the second Merkle tree is consistent with the order of the objects in the object sequence.

[0332] Perform root hash calculation on the second Merkle tree to obtain the second root hash of the second Merkle tree;

[0333] The second root hash is determined as the second state root of the target interval.

[0334] In one implementation, when one or more instructions in the computer-readable storage medium are loaded and executed by the processor 1701 based on transaction data in m+1 blocks, the first and second state values ​​of each object, and the first and second state roots corresponding to the target interval, and processed using a zero-knowledge proof circuit to obtain the interval transaction of the target interval, the following steps are specifically executed:

[0335] Obtain a zero-knowledge proof circuit, which is derived from the transformation of the proposition to be proved. The proposition to be proved is used to indicate the verification of the correctness of the interval transaction.

[0336] Construct a transaction set based on the transaction data in m+1 blocks;

[0337] A zero-knowledge proof circuit is used to verify the first and second state values ​​of each object, the first and second state roots corresponding to the target interval, and the transaction set, thereby generating proof information for the target interval.

[0338] Range trading is constructed based on the proof information to determine the target range;

[0339] The number of transaction data contained in the transaction set is equal to the quantity threshold. If the number of transaction data in m+1 blocks is equal to the quantity threshold, then the transaction set contains the transaction data in m+1 blocks. If the number of transaction data in m+1 blocks is less than the quantity threshold, then the transaction set contains the transaction data in m+1 blocks and empty transaction data, and the sum of the number of empty transaction data and the number of transaction data in m+1 blocks is equal to the quantity threshold.

[0340] In one implementation, the proof information for the target interval includes: the output information of the zero-knowledge proof circuit; one or more instructions in a computer-readable storage medium are loaded and executed by the processor 1701. When the zero-knowledge proof circuit verifies the first and second state values ​​of each object, the first and second state roots corresponding to the target interval, and the transaction set to generate the proof information for the target interval, the following steps are specifically performed:

[0341] Construct the first candidate Merkle tree for the target interval based on the first state value of each object, and compare the first candidate state root of the first candidate Merkle tree with the first state root corresponding to the target interval to obtain the first comparison result;

[0342] Construct a second candidate Merkle tree for the target interval based on the second state value of each object, and compare the second candidate state root of the second candidate Merkle tree with the second state root corresponding to the target interval to obtain the second comparison result;

[0343] Obtain the field containing the write set for each transaction data (excluding empty transaction data) from the transaction set, and perform a hash calculation on the write set field for each transaction data to obtain the write set hash;

[0344] The hash of the transaction set is obtained by performing hash calculation on the hash values ​​of the transaction data excluding empty transaction data in the transaction set;

[0345] The output information of the zero-knowledge proof circuit includes: the first comparison result, the second comparison result, the write set hash, and the transaction set hash.

[0346] In one implementation, the proof information for the target interval further includes: a proof string; one or more instructions in a computer-readable storage medium are loaded by processor 1701 and further execute the following steps:

[0347] Obtain the key generation algorithm, and generate the prover public string and the validator public string according to the key generation algorithm; the prover public string is the key used by the prover, and the prover includes the target consensus node; the validator public string is the key used by the validator, and the validator includes any consensus node in the blockchain network that needs to synchronize blocks in the target interval.

[0348] Based on the prover's common string, a proof string is generated for the computation process of the zero-knowledge proof circuit to obtain the output information; the generation of the proof string indicates that the target consensus node has executed the computation process based on the zero-knowledge proof circuit.

[0349] In one implementation, when one or more instructions in the computer-readable storage medium are loaded by the processor 1701 and executed to compress the blockchain in the target consensus node using interval transactions, the following steps are specifically performed:

[0350] Clear the transaction data in the m+1 blocks contained in the blockchain of the target consensus node; and,

[0351] Replace the target transaction data in the i-th block of the blockchain in the target consensus node with the interval transaction, where i is an integer and i∈[n,n+m].

[0352] In one implementation, the target transaction data refers to the transaction data with the earliest on-chain time in the i-th block;

[0353] Blockchains in a blockchain network include either consortium blockchains or private blockchains.

[0354] The target interval transactions include: the threshold number of transaction data contained in the target interval, the starting block height n of the target interval, the ending block height n+m of the target interval, proof information, validator public string, the write set of each transaction data in m+1 blocks on the blockchain of the target consensus node, the interval identifier of the target interval, and the candidate transaction set hash; the candidate transaction set hash is generated based on the hash values ​​of the transaction data in m+ blocks on the blockchain of the target consensus node.

[0355] In another embodiment, the computer-readable storage medium stores one or more instructions; the processor 1701 loads and executes one or more instructions stored in the computer-readable storage medium to implement the corresponding steps in the above-described embodiment of the block synchronization method based on a blockchain network. Specifically, the blockchain network includes one or more consensus nodes, and the device includes a first consensus node in the blockchain network other than the target consensus node; the blockchain in the blockchain network has a target interval, which contains m+1 blocks between the nth block and the (n+m)th block, where n and m are both integers greater than zero; the processor 1701 loads and executes one or more instructions in the computer-readable storage medium for the following steps:

[0356] Synchronize the i-th block on the blockchain from the second consensus node in the blockchain network. The second consensus node is any consensus node in the blockchain network other than the first consensus node, where i is an integer and i∈[n,n+m].

[0357] If the i-th block contains the identifier of the interval transaction, then obtain the interval transaction based on the identifier of the interval transaction;

[0358] The range trading was verified, and the verification results were obtained.

[0359] If the verification result is successful, the updated state value of the write set of the transaction data in the interval transaction will be stored.

[0360] In one implementation, the interval transaction includes: a write set of each transaction data in m+1 blocks on the blockchain of the target consensus node, proof information, a validator common string, and a candidate transaction set hash; the proof information includes the output information of the zero-knowledge proof circuit and the proof string; the zero-knowledge proof circuit is generated based on the proposition to be proved, which is used to indicate the verification of the correctness of the interval transaction; the validator common string is generated by the target consensus node for the validators according to the key generation algorithm, and the validators include the first consensus node; the candidate transaction set hash is obtained by the target consensus node by hashing the hash values ​​of the transaction data in m+1 blocks;

[0361] One or more instructions in a computer-readable storage medium are loaded by processor 1701 and executed to verify range transactions. When the verification result is obtained, the following steps are specifically performed:

[0362] Verification information is generated based on the write set of each transaction in m+1 blocks and the hash of the candidate transaction set;

[0363] The output information of the zero-knowledge proof circuit in the proof information is verified using the verification information;

[0364] If the verification passes, the proof string in the proof information is verified based on the verifier's common string to obtain the verification result.

[0365] In one implementation, when one or more instructions in the computer-readable storage medium are loaded by the processor 1701 and executed to generate verification information based on the write set of each transaction data in m+1 blocks and the hash of the candidate transaction set, the following steps are specifically performed:

[0366] Extract the corresponding P objects from the write set of transaction data in the interval transaction, and obtain the third state value of the P objects in the (n-1)th block from the blockchain of the first consensus node;

[0367] Root calculation is performed on the third state values ​​of P objects to obtain the first reference state root; and,

[0368] The write set of transaction data in the interval transaction is pre-processed to obtain the updated fourth state values ​​of P objects, and the root calculation is performed on the updated fourth state values ​​of the P objects to obtain the second reference state root; and,

[0369] Perform a hash calculation on the field containing the write set of the transaction data in the interval transaction to obtain the reference write set hash;

[0370] The verification information includes: the first reference state root, the second reference state root, the reference write set hash, and the candidate transaction set hash.

[0371] In one implementation, the output information of the zero-knowledge proof circuit in the proof information includes: a first comparison result, a second comparison result, a write set hash, and a transaction set hash; the first comparison result is obtained by comparing the first candidate state root of the first candidate Merkle tree constructed by the target consensus node based on the first state values ​​of P objects with the first state root of the target interval; the second comparison result is obtained by comparing the second candidate state root of the second candidate Merkle tree constructed by the target consensus node based on the second state values ​​of P objects with the second state root of the target interval.

[0372] When one or more instructions in a computer-readable storage medium are loaded by processor 1701 and executed to verify the output information of the zero-knowledge proof circuit in the proof information using verification information, the following steps are specifically performed:

[0373] If both the first comparison result and the second comparison result are successful, then the first state root of the target interval is compared with the first reference state root to obtain the first reference comparison result; and the second state root of the target interval is compared with the second reference state root to obtain the second reference comparison result.

[0374] The write set comparison result is obtained by comparing the reference write set hash with the write set hash in the output information of the zero-knowledge proof circuit.

[0375] The transaction set hash in the output information of the zero-knowledge proof circuit is compared with the candidate transaction set hash in the interval transaction to obtain the transaction comparison result;

[0376] If the first reference comparison result, the second reference comparison result, the write set comparison result, and the transaction comparison result are all successfully compared, then the verification is considered successful.

[0377] In one implementation, one or more instructions in the computer-readable storage medium are loaded by the processor 1701 and executed. If the i-th block contains an identifier for a range transaction, then when retrieving the range transaction based on the identifier, the following steps are specifically performed:

[0378] If the i-th block on the blockchain of the second consensus node contains the identifier of the interval transaction, and the i-th block does not contain the interval transaction, then a first retrieval request is sent to the second consensus node, so that the second consensus node responds to the first retrieval request and returns the target node identifier of any consensus node in the blockchain network that stores the interval transaction.

[0379] Obtain the range transaction from the consensus node corresponding to the target node identifier based on the target node identifier;

[0380] Alternatively, a second retrieval request can be sent to the second consensus node, so that the second consensus node responds to the second retrieval request, retrieves and returns the range transaction from any consensus node in the blockchain network that stores the range transaction.

[0381] In one implementation, the identifier of an interval transaction is stored in the i-th block of the blockchain on the second consensus node's network after the second consensus node successfully verifies the interval transaction; the verification of interval transactions in the blockchain network by the second consensus node includes:

[0382] Retrieve range transactions, which include the hash of the candidate transaction set and the write set of transaction data in the target range;

[0383] The write set of transaction data from block n to block n+m is obtained from the blockchain of the second consensus node, and the write set of transaction data obtained from the blockchain of the second consensus node is compared with the write set of transaction data in the interval transaction to obtain the write set comparison result;

[0384] Obtain the hash values ​​of transaction data from block n to block n+m in the blockchain of the second consensus node, and perform hash calculation on the hash values ​​of the transaction data to obtain the transaction hash value;

[0385] The transaction hash value is compared with the hash of the candidate transaction set in the interval transaction to obtain the transaction hash comparison result;

[0386] If both the set comparison result and the transaction hash comparison result are successful, then the verification result is obtained, and the verification result is successful.

[0387] Based on the same inventive concept, the principle and beneficial effects of the blockchain node device provided in the embodiments of this application in solving the problem are similar to the principle and beneficial effects of the data compression method and block synchronization method based on the blockchain network in the method embodiments of this application. Please refer to the principle and beneficial effects of the implementation of the method. For the sake of brevity, they will not be repeated here.

[0388] This application also provides a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. The processor of a blockchain node device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the blockchain node device to perform the aforementioned data compression method and block synchronization method based on the blockchain network.

[0389] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed in this application can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0390] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of the present invention are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in or transmitted through a computer-readable storage medium. The computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that a computer can access or a data processing device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state disk (SSD)).

[0391] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this invention should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A data compression method based on a blockchain network, characterized in that, The blockchain network contains one or more consensus nodes, and the method is executed by a target consensus node in the blockchain network. The blockchain in the blockchain network has a target interval, which contains m+1 blocks from the nth block to the (n+m)th block, where n and m are both positive integers. The method includes: The transaction data in the m+1 blocks are processed to extract objects, resulting in P objects, where P is a positive integer; Obtain the first state value of each object in the (n-1)th block of the blockchain in the target consensus node, and construct the first Merkle tree of the target interval based on the first state value of each object in the object sequence; the order of the leaf nodes in the first Merkle tree is consistent with the order of the objects in the object sequence. Perform root hash calculation on the first Merkle tree to obtain the first root hash of the first Merkle tree; and determine the first root hash as the first state root of the target interval; Obtain the second state value of each object in the (n+m)th block of the blockchain in the target consensus node, and construct a second Merkle tree for the target interval based on the second state value of each object in the object sequence; the order of the leaf nodes in the second Merkle tree is consistent with the order of the objects in the object sequence. Perform a root hash calculation on the second Merkle tree to obtain the second root hash of the second Merkle tree; and determine the second root hash as the second state root of the target interval; Based on the transaction data in the m+1 blocks, the first state value and the second state value of each object, and the first state root and the second state root corresponding to the target interval, a zero-knowledge proof circuit is used for computation to obtain the interval transactions of the target interval. The blockchain in the target consensus node is compressed using the interval transaction; wherein, the target interval in the blockchain of the target consensus node after compression does not contain the transaction data, but contains the interval transaction.

2. The method as described in claim 1, characterized in that, The method further includes: Receive a data compression request, wherein the data compression request carries compression information; In response to the data compression request, the step of extracting objects from the transaction data in the m+1 blocks to obtain P objects is performed; The data compression request is initiated by the target object after inputting compression information into the target consensus node; or, the data compression request is sent by any consensus node in the blockchain network other than the target consensus node. The compressed information includes: the starting block height n of the target interval, the ending block height n+m of the target interval, the threshold number of transaction data contained in the target interval, and the node identifier of the target consensus node.

3. The method as described in claim 1, characterized in that, The m+1 blocks store one or more transaction data, each transaction data including a transaction and the transaction result after the transaction is executed; any one of the P objects refers to the data that needs to be written based on the transaction result of a transaction data; The method further includes: The transaction data is sorted according to the order in which one or more transaction data in the m+1 blocks are uploaded to the blockchain to obtain a transaction sequence; The P objects are sorted according to the order of the transaction data in the transaction sequence to obtain an object sequence. The order of the P objects in the object sequence is consistent with the order of the transaction data corresponding to each object in the transaction sequence.

4. The method as described in claim 2, characterized in that, The process of obtaining the interval transactions of the target interval by using a zero-knowledge proof circuit based on the transaction data in the m+1 blocks, the first state value and the second state value of each object, and the first state root and the second state root corresponding to the target interval includes: A zero-knowledge proof circuit is obtained, which is derived from a proposition to be proved, and the proposition to be proved is used to indicate the verification of the correctness of the interval transaction. Construct a transaction set based on the transaction data in the m+1 blocks; Using the zero-knowledge proof circuit, the first state value and second state value of each object, the first state root and second state root corresponding to the target interval, and the transaction set are verified to generate proof information for the target interval. Based on the proof information, an interval transaction for the target interval is constructed; Wherein, the number of transaction data contained in the transaction set is equal to the quantity threshold; if the number of transaction data in the m+1 blocks is equal to the quantity threshold, then the transaction set contains the transaction data in the m+1 blocks; if the number of transaction data in the m+1 blocks is less than the quantity threshold, then the transaction set contains the transaction data in the m+1 blocks and empty transaction data, and the sum of the number of empty transaction data and the number of transaction data in the m+1 blocks is equal to the quantity threshold.

5. The method as described in claim 4, characterized in that, The proof information for the target interval includes: the output information of the zero-knowledge proof circuit; the verification process using the zero-knowledge proof circuit to verify the first and second state values ​​of each object, the first and second state roots corresponding to the target interval, and the transaction set to generate the proof information for the target interval includes: Construct a first candidate Merkle tree for the target interval based on the first state value of each object, and compare the first candidate state root of the first candidate Merkle tree with the first state root corresponding to the target interval to obtain a first comparison result; Construct a second candidate Merkle tree for the target interval based on the second state value of each object, and compare the second candidate state root of the second candidate Merkle tree with the second state root corresponding to the target interval to obtain a second comparison result; The write set field of each transaction data (excluding the empty transaction data) is obtained from the transaction set, and a hash calculation is performed on the write set field of each transaction data to obtain the write set hash. The hash values ​​of the transaction data in the transaction set, excluding the empty transaction data, are hashed to obtain the transaction set hash. The output information of the zero-knowledge proof circuit includes: the first comparison result, the second comparison result, the write set hash, and the transaction set hash.

6. The method as described in claim 5, characterized in that, The proof information for the target interval also includes: a proof string; the method further includes: Obtain the key generation algorithm, and generate a prover public string and a validator public string according to the key generation algorithm; the prover public string is the key used by the prover, and the prover includes the target consensus node; the validator public string is the key used by the validator, and the validator includes any consensus node in the blockchain network that needs to synchronize blocks in the target interval. The proof string is generated based on the prover's public string and the computation process of calculating the output information of the zero-knowledge proof circuit; the generation of the proof string indicates that the target consensus node has executed the computation process based on the zero-knowledge proof circuit.

7. The method as described in claim 1, characterized in that, The step of compressing the blockchain in the target consensus node using the interval transaction includes: The transaction data in the m+1 blocks contained in the blockchain of the target consensus node is cleared; and, Replace the target transaction data in the i-th block of the blockchain in the target consensus node with the interval transaction, where i is an integer and i∈[n,n+m].

8. The method according to any one of claims 1-7, characterized in that, The target transaction data refers to the transaction data with the earliest on-chain time in the i-th block; The blockchain in the blockchain network includes either a consortium blockchain or a private blockchain. The target interval transactions include: a threshold number of transaction data contained in the target interval, the starting block height n of the target interval, the ending block height n+m of the target interval, proof information, validator public string, the write set of each transaction data in the m+1 blocks on the blockchain of the target consensus node, the interval identifier of the target interval, and the candidate transaction set hash; the candidate transaction set hash is generated based on the hash values ​​of the transaction data in the m+ blocks on the blockchain of the target consensus node.

9. A block synchronization method based on a blockchain network, characterized in that, The blockchain network includes one or more consensus nodes, and the method is executed by a first consensus node other than the target consensus node in the blockchain network; the blockchain in the blockchain network has a target interval, which includes m+1 blocks from the nth block to the (n+m)th block, where n and m are both integers greater than zero; the target consensus node is the consensus node in the blockchain network that performs data compression processing on the m+1 blocks; the transaction data included in the m+1 blocks on the blockchain at the target consensus node is cleared, and the i-th block on the blockchain stores the interval transactions; i is an integer, and i∈[n,n+m]; The method includes: Synchronize the i-th block on the blockchain from the second consensus node in the blockchain network, wherein the second consensus node is any consensus node in the blockchain network other than the first consensus node; If the i-th block contains an identifier for a range transaction, then the range transaction is obtained based on the identifier of the range transaction; the range transaction is obtained by the target consensus node through zero-knowledge proof circuitry based on the transaction data in the m+1 blocks, the first state value and the second state value of each object, and the first state root and the second state root corresponding to the target range. The method for obtaining the second state root corresponding to the target interval includes: constructing a second Merkle tree for the target interval based on the second state value of each object in the object sequence, wherein the order of the leaf nodes in the second Merkle tree is consistent with the order of the objects in the object sequence; performing a root hash calculation on the second Merkle tree to obtain the second root hash of the second Merkle tree; and determining the second root hash as the second state root of the target interval; the second state value is stored in the (n+m)th block of the blockchain in the target consensus node; The method for obtaining the first state root corresponding to the target interval includes: constructing a first Merkle tree for the target interval based on the first state value of each object in the object sequence, wherein the order of the leaf nodes in the first Merkle tree is consistent with the order of the objects in the object sequence; performing a root hash calculation on the first Merkle tree to obtain the first root hash of the first Merkle tree; and determining the first root hash as the first state root of the target interval; the first state value exists in the (n-1)th block of the blockchain in the target consensus node; the object is obtained by extracting transaction data from the (m+1)th block; The interval transactions were verified, and the verification results were obtained; If the verification result is successful, the updated state value of the write set of the transaction data in the interval transaction is stored.

10. The method as described in claim 9, characterized in that, The interval transaction includes: a write set, proof information, a validator common string, and a candidate transaction set hash for each transaction data in the m+1 blocks of the blockchain in the target consensus node; the proof information includes the output information of the zero-knowledge proof circuit and the proof string; the zero-knowledge proof circuit is generated based on the proposition to be proved, which is used to indicate the verification of the correctness of the interval transaction; the validator common string is generated by the target consensus node for the validator according to the key generation algorithm, and the validator includes the first consensus node; the candidate transaction set hash is obtained by the target consensus node by hashing the hash values ​​of the transaction data in the m+1 blocks; The verification of the interval transactions, to obtain the verification result, includes: Verification information is generated based on the write set of each transaction data in the m+1 blocks and the hash of the candidate transaction set; The verification information is used to verify the output information of the zero-knowledge proof circuit in the proof information; If the verification passes, the proof string in the proof information is verified according to the verifier common string to obtain the verification result.

11. The method as described in claim 10, characterized in that, The step of generating verification information based on the write set of each transaction data in the m+1 blocks and the hash of the candidate transaction set includes: Extract P corresponding objects from the write set of transaction data in the interval transaction, and obtain the third state value of the P objects in the n-1th block from the blockchain in the first consensus node; Root calculation is performed on the third state values ​​of the P objects to obtain the first reference state root; and, The write set of transaction data in the aforementioned interval transaction is pre-processed to obtain the updated fourth state values ​​of the P objects, and root calculation processing is performed on the updated fourth state values ​​of the P objects to obtain the second reference state root; and, A hash calculation is performed on the field containing the write set of the transaction data in the aforementioned interval transaction to obtain the reference write set hash; The verification information includes: the first reference state root, the second reference state root, the reference write set hash, and the candidate transaction set hash.

12. The method as described in claim 11, characterized in that, The output information of the zero-knowledge proof circuit in the proof information includes: a first comparison result, a second comparison result, a write set hash, and a transaction set hash; the first comparison result is obtained by comparing the first candidate state root of the first candidate Merkle tree constructed by the target consensus node based on the first state values ​​of the P objects with the first state root of the target interval; the second comparison result is obtained by comparing the second candidate state root of the second candidate Merkle tree constructed by the target consensus node based on the second state values ​​of the P objects with the second state root of the target interval. The step of verifying the output information of the zero-knowledge proof circuit in the proof information using the verification information includes: If both the first comparison result and the second comparison result are successful, then the first state root of the target interval is compared with the first reference state root to obtain the first reference comparison result; and the second state root of the target interval is compared with the second reference state root to obtain the second reference comparison result. The reference write set hash is compared with the write set hash in the output information of the zero-knowledge proof circuit to obtain the write set comparison result. The transaction set hash in the output information of the zero-knowledge proof circuit is compared with the candidate transaction set hash in the interval transaction to obtain the transaction comparison result; If the first reference comparison result, the second reference comparison result, the write set comparison result, and the transaction comparison result are all successfully compared, then the verification is deemed successful.

13. The method as described in claim 10, characterized in that, If the i-th block contains an identifier for a range transaction, then obtaining the range transaction based on the identifier includes: If the i-th block on the blockchain of the second consensus node contains the identifier of the interval transaction, and the i-th block does not contain the interval transaction, then a first acquisition request is sent to the second consensus node, so that the second consensus node responds to the first acquisition request and returns the target node identifier of any consensus node in the blockchain network that stores the interval transaction; The interval transaction is obtained from the consensus node corresponding to the target node identifier according to the target node identifier; Alternatively, a second retrieval request may be sent to the second consensus node, so that the second consensus node responds to the second retrieval request, retrieves and returns the interval transaction from any consensus node in the blockchain network that stores the interval transaction.

14. A data compression device based on a blockchain network, characterized in that, The blockchain network includes one or more consensus nodes, and the data compression device includes a target consensus node in the blockchain network. A target interval is defined on the blockchain of the blockchain network, and the target interval includes m+1 blocks from the nth block to the (n+m)th block, where n and m are both positive integers. The data compression device includes: The processing unit is used to perform object extraction processing on the transaction data in the m+1 blocks to obtain P objects, where P is a positive integer. The acquisition unit is used to acquire the first state value of each object in the (n-1)th block of the blockchain in the target consensus node, and construct the first Merkle tree of the target interval according to the first state value of each object in the object sequence; the arrangement order of the leaf nodes in the first Merkle tree is consistent with the arrangement order of each object in the object sequence; Perform root hash calculation on the first Merkle tree to obtain the first root hash of the first Merkle tree; and determine the first root hash as the first state root of the target interval; The acquisition unit is further configured to acquire the second state value of each object in the (n+m)th block of the blockchain in the target consensus node, and construct a second Merkle tree of the target interval based on the second state value of each object in the object sequence; the order of the leaf nodes in the second Merkle tree is consistent with the order of the objects in the object sequence. Perform a root hash calculation on the second Merkle tree to obtain the second root hash of the second Merkle tree; and determine the second root hash as the second state root of the target interval; The processing unit is further configured to perform computational processing using a zero-knowledge proof circuit based on the transaction data in the m+1 blocks, the first state value and the second state value of each object, and the first state root and the second state root corresponding to the target interval, to obtain the interval transactions of the target interval; The processing unit is further configured to compress the blockchain in the target consensus node using the interval transaction; wherein the target interval in the blockchain of the compressed target consensus node does not contain the transaction data, but contains the interval transaction.

15. A block synchronization device based on a blockchain network, characterized in that, The blockchain network includes one or more consensus nodes, and the synchronization device includes a first consensus node in the blockchain network other than the target consensus node. A target interval is defined on the blockchain of the blockchain network. The target interval contains m+1 blocks between the nth block and the (n+m)th block, where n and m are both positive integers. The target interval contains interval transactions. The target consensus node is the consensus node in the blockchain network that performs data compression processing on the m+1 blocks. At the target consensus node, the transaction data included in the m+1 blocks on the blockchain is cleared, and the i-th block on the blockchain stores the interval transactions. i is an integer, and i∈[n,n+m]; The synchronization device includes: The acquisition unit is used to synchronize the i-th block on the blockchain from the second consensus node in the blockchain network. The second consensus node is any consensus node in the blockchain network other than the first consensus node, where i is an integer and i∈[n,n+m]. The acquisition unit is further configured to acquire the interval transaction based on the identifier of the interval transaction if the i-th block contains the identifier of the interval transaction; the interval transaction is obtained by the target consensus node through zero-knowledge proof circuitry based on the transaction data in the m+1 blocks, the first state value and the second state value of each object, and the first state root and the second state root corresponding to the target interval. The method for obtaining the second state root corresponding to the target interval includes: constructing a second Merkle tree for the target interval based on the second state value of each object in the object sequence, wherein the order of the leaf nodes in the second Merkle tree is consistent with the order of the objects in the object sequence; performing a root hash calculation on the second Merkle tree to obtain the second root hash of the second Merkle tree; and determining the second root hash as the second state root of the target interval; the second state value is stored in the (n+m)th block of the blockchain in the target consensus node; The method for obtaining the first state root corresponding to the target interval includes: constructing a first Merkle tree for the target interval based on the first state value of each object in the object sequence, wherein the order of the leaf nodes in the first Merkle tree is consistent with the order of the objects in the object sequence; performing a root hash calculation on the first Merkle tree to obtain the first root hash of the first Merkle tree; and determining the first root hash as the first state root of the target interval; the first state value exists in the (n-1)th block of the blockchain in the target consensus node; the object is obtained by extracting transaction data from the (m+1)th block; The processing unit is also used to verify the interval transactions and obtain verification results; The processing unit is further configured to, if the verification result is successful, store the updated state value of the write set of the transaction data in the interval transaction.

16. A blockchain node device, characterized in that, include: A processor, adapted to execute computer programs; A computer-readable storage medium storing a computer program, which, when executed by the processor, implements the data compression method based on a blockchain network as described in any one of claims 1-8, or implements the block synchronization method based on a blockchain network as described in any one of claims 9-13.

17. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted to be loaded by a processor and executed by the data compression method based on a blockchain network as described in any one of claims 1-8, or to implement the block synchronization method based on a blockchain network as described in any one of claims 9-13.

18. A computer program product, characterized in that, The computer program product includes computer instructions that, when executed by a processor, implement the data compression method based on a blockchain network as described in any one of claims 1-8, or implement the block synchronization method based on a blockchain network as described in any one of claims 9-13.

Images