Blockchain-based Data Processing Method and Device

Abstract

The present application provides a blockchain-based data processing method and device, including: receiving a data modification request sent by a client, where the data modification request includes a first input data identifier and operation information, processing the first input data identifier and operation information to obtain a log domain data block and a membership proof of the log domain data block, performing zero-knowledge proof processing on the membership proof of the log domain data block to obtain zero-knowledge proof information of the membership proof and a first public parameter, generating a first transaction request according to the zero-knowledge proof information of the membership proof and the first public parameter, and sending the first transaction request to the client. The first transaction request is used to enable the client to verify the zero-knowledge proof information of the membership proof according to the first public parameter. In the above solution, when modifying replicated encrypted data, there is no need to re-execute the replication encryption process. Only the operation information needs to be packaged into a log domain data block and stored in the log domain, reducing the data processing time.

Description

Technical Field

[0001] This application relates to the technical field of financial technology (Fintech), and in particular, to a data processing method and device based on a blockchain. Background Art

[0002] With the development of computer technology, more and more technologies are applied in the financial field, and traditional finance is gradually transforming into financial technology.

[0003] In a blockchain system, each consensus node not only manages the data on the blockchain through a consensus algorithm, but each consensus node is also used to provide replicated storage of data under the blockchain. Usually, when a user needs to modify the replicated data stored in a consensus node, a replication encryption request needs to be re-initiated, and the modified data needs to be replicated and encrypted again, which takes a long time and occupies a large amount of computing power resources. Summary of the Invention

[0004] An embodiment of this application provides a data processing method based on a blockchain. The method is applied to a consensus node in the blockchain, and the method includes:

[0005] Receiving a data modification request sent by a client, where the data modification request includes a first input data identifier and operation information;

[0006] Processing the first input data identifier and the operation information to obtain a log domain data block and a membership proof of the log domain data block;

[0007] Performing a zero-knowledge proof process on the membership proof of the log domain data block to obtain zero-knowledge proof information of the membership proof and a first public parameter;

[0008] Generating a first transaction request according to the zero-knowledge proof information of the membership proof and the first public parameter, and sending the first transaction request to the client. The first transaction request is used to enable the client to verify the zero-knowledge proof information of the membership proof according to the first public parameter.

[0009] Another embodiment of this application provides a data processing method based on a blockchain. The method is used for a client, and the method includes:

[0010] Obtaining a first input data identifier and operation information, and generating a data modification request according to the first input data identifier and the operation information;

[0011] Send a data modification request to the consensus nodes in the blockchain system, where the data modification request is used to enable the consensus nodes to process the first input data identifier and operation information, obtain the log domain data block and the membership proof of the log domain data block, perform zero-knowledge proof processing on the membership proof of the log domain data block, obtain the zero-knowledge proof information of the membership proof and the first common parameter; and generate a first transaction request according to the zero-knowledge proof information of the membership proof and the first common parameter.

[0012] Receive the first transaction request sent by the consensus node, and verify the zero-knowledge proof information of the membership proof according to the first common parameter.

[0013] An embodiment of the present application provides a blockchain-based data processing method, which is applied to a proof node. The method includes:

[0014] Receive the zero-knowledge proof information sent by each consensus node in the blockchain system and the status information of the consensus node when each zero-knowledge proof information is generated;

[0015] Perform recursive aggregation processing on each zero-knowledge proof information and the status information of the consensus node when each zero-knowledge proof information is generated to obtain root zero-knowledge proof information and root status information;

[0016] Generate a fourth transaction request according to the root zero-knowledge proof information and the root status information;

[0017] Send a fourth transaction request to the consensus nodes in the blockchain system. The fourth transaction request is used to enable the blockchain system to store the root zero-knowledge proof according to the root status information;

[0018] Wherein, the zero-knowledge proof information includes any one or a combination of the zero-knowledge proof information of the membership proof, the zero-knowledge proof information of the non-membership proof, and the zero-knowledge proof information of the backup encrypted data.

[0019] An embodiment of the present application provides an electronic device, including: a processor, and a memory communicatively connected to the processor; the memory stores computer execution instructions;

[0020] The processor executes the computer execution instructions stored in the memory to implement the blockchain-based data processing method described in the above embodiment.

[0021] An embodiment of the present application provides a computer-readable storage medium, in which computer execution instructions are stored. When the computer execution instructions are executed by a processor, they are used to implement the blockchain-based data processing method described in the above embodiment.

[0022] The embodiments of the present application provide a data processing method and device based on a blockchain. Two storage areas, namely a data domain and a log domain, are set within a consensus node. The data domain is used to store backup encrypted data, and the log domain stores operation information on the backup encrypted data. When a user needs to modify the backup replicated data, by storing the operation information in the log domain, there is no need to execute the replication encryption algorithm anymore, which can improve data processing efficiency and reduce resource usage. Then, the zero-knowledge proof algorithm is used to verify the membership proof of the log domain data block to generate zero-knowledge proof information, and the client only needs to verify the zero-knowledge proof information, simplifying the verification process. An accumulator is used to generate a membership proof for the log domain data block in the log domain or generate a non-membership proof when deleting the log domain data block, and zero-knowledge proof processing is performed on the membership proof or non-membership proof to obtain the corresponding zero-knowledge proof information, which can further simplify the verification process. The accumulator also supports users to modify data at any time, that is, even if users frequently update data, it can efficiently generate a membership proof or non-membership proof in a short time, and moreover, the function of data version control is realized.

[0023] In addition, when the client stores data in the consensus node, the original input data is processed by doubling and splitting, which can support the storage of data of any length by the user. Zero-knowledge proof processing is performed on the backup encrypted data to obtain zero-knowledge proof information of the backup encrypted data. The client no longer needs to verify the Merkle proof information and only needs to verify the zero-knowledge proof information, simplifying the verification process. The recursive zero-knowledge proof algorithm is used to recursively aggregate the generated zero-knowledge proofs, which can greatly reduce the number of proofs, reduce the bandwidth pressure of the blockchain, reduce the verification calculation pressure, increase the scalability of the system without reducing the security. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] The drawings herein are incorporated into the specification and constitute a part of this specification, showing embodiments consistent with the present application, and are used together with the specification to explain the principles of the present application.

[0025] Figure 1 It is a system structure diagram provided by an embodiment of the present application;

[0026] Figure 2 It is a schematic diagram of the zigzag reverse binary depth robust graph algorithm provided by an embodiment of the present application;

[0027] Figure 3 It is a flowchart of the data processing method provided by an embodiment of the present application;

[0028] Figure 4 It is a schematic diagram of the structure of the storage area provided by an embodiment of the present application;

[0029] Figure 5 It is a flowchart of the data processing method provided by another embodiment of the present application;

[0030] Figure 6 Schematic diagram of a multi-layer bipartite depth robust graph algorithm provided by an embodiment of the present application;

[0031] Figure 7 Flow schematic diagram of a data processing method provided by another embodiment of the present application;

[0032] Figure 8 Flow schematic diagram of a data processing method provided by yet another embodiment of the present application;

[0033] Figure 9 Flow schematic diagram of a data processing method provided by still another embodiment of the present application;

[0034] Figure 10 Schematic diagram of a recursive aggregation algorithm provided by yet another embodiment of the present application;

[0035] Figure 11 Schematic diagram of the structure of an electronic device provided by an embodiment of the present application.

[0036] Through the above-mentioned drawings, specific embodiments of the present application have been shown, and there will be more detailed descriptions hereinafter. These drawings and textual descriptions are not intended to limit the scope of the concept of the present application in any way, but to illustrate the concept of the present application to those skilled in the art by referring to specific embodiments. Detailed Description of Specific Embodiments

[0037] Here, exemplary embodiments will be described in detail, and the examples are shown in the drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. On the contrary, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0038] First, introduce the parameters used in the embodiments of the present application.

[0039] λ: Security parameter

[0040] t: Each timing moment of the discrete timer

[0041] S t : Set of elements of the accumulator at time t

[0042] A t : Value of the accumulator at time t, that is, the product of all elements in the set

[0043] Membership proof and non-membership proof

[0044] pp: Public parameter

[0045] upmsg: Information used to update the proof

[0046] Setup(λ) → pp, A0: Initialize to generate common parameters

[0047] Add(A t , x) → {A t+1 , upmsg}: Add an element and update the accumulator

[0048] Del(A t , x) → {A t+1 , upmsg}: Delete an element and update the accumulator

[0049] Generate a membership proof for x

[0050] Generate a non - membership proof for x

[0051] Update the membership proof of x

[0052] Update the non - membership proof of x

[0053] Verify the membership proof of x

[0054] Verify the non - membership proof of x

[0055] pp: Common parameters

[0056] d: In - degree of the nodes of the deep robust graph

[0057] D, D i : Represent the original data and the i - th data block of the original data respectively

[0058] R, R i : Represent the data after replicated encryption and its i - th data block respectively

[0059] T: Upper limit of the challenge - response delay time

[0060] G, g: Represent a group of unknown order and the generator of the group respectively

[0061] H, H t : Represent all log data and the data update log generated by the user at time t respectively

[0062] FID, CID, BID, τ D : Represent the identity identifier of data D, the identity identifier of the consensus node, the identity identifier of the encrypted backup data R, and the original label of the data block respectively

[0063] l: The length of the set of challenge numbers

[0064] l d : The number of layers of the multi - layer binary depth - robust graph

[0065] l m : The depth of the Merkle tree

[0066] N: The number of data blocks

[0067] aux: Proof auxiliary data, including the Merkle hash tree of data R

[0068] [l]: Represents an integer set of length l {0, 1,..., l - 1}

[0069] a||b: Represents the concatenation of two strings a and b

[0070] Primes(λ): Represents a set of prime numbers less than 2 λ of prime numbers

[0071] H ped (y) → x: Pederson hash function, with the result being 32 bytes

[0072] H primes (y) → x ∈ Primes(λ): Maps the input y to a prime number x in the set of prime numbers

[0073] DSetup(λ, T) → pp, A0: Dynamic replication proof mechanism initialization

[0074] DReplicate(BIDτ D , D) → R, aux: Performs replicated encryption on the original fixed - length data D

[0075] DExtract(BID, τ D , R, aux) → D: Decrypts the replicated - encrypted data R to restore the original data D

[0076] DPoll(N) → r: Randomly selects l challenge numbers from an integer set of length N, r = (r1,..., r l )

[0077] Generate zero - knowledge proof

[0078] DVerify(pp, π, BID, r, A t ) → {0, 1}: Verifies the zero - knowledge proof

[0079] Zero - knowledge proof algorithm: The zero - knowledge proof algorithm can be used to prove and verify the following statement: Given a result verification function F and a public input x, verify the secret input w such that F(x, w) = 1. The infrastructure of the zero - knowledge proof algorithm consists of three sub - algorithms:

[0080] The initialization sub - algorithm, with the formula ZK.Setup, which takes the function F and the security parameter λ as inputs and outputs a set of constant parameters crs and a backdoor td. The set of constant parameters crs consists of two parts. Among them, the part used for proof is called the proof key crs p , and the part used for verification is called the verification key crs v .

[0081] The proof sub - algorithm, with the formula ZK.Prover, which runs on the proof node and takes the proof key crs p , the public input x of the function F, and the secret input w as inputs, and outputs zero - knowledge proof information π.

[0082] The verification sub - algorithm, with the formula ZK.Verifier, which runs on the verification node and takes the verification key crs v , the public input x of the function F, and the zero - knowledge proof information π as inputs, and outputs 0 to indicate rejection or 1 to indicate acceptance. Any device can be used as a proof node and run this verification algorithm.

[0083] As Figure 1 shown, a blockchain storage system 100 provided by an embodiment of the present application includes a plurality of consensus nodes 10 and a plurality of clients 20. In addition to managing the data on the blockchain through a consensus algorithm, each of the plurality of consensus nodes 10 is also used to provide replicated storage of data off - chain.

[0084] Among them, replicated storage of data means that the client 20 requests to store d backups of an input data of N - bit size on the consensus node. At this time, the consensus node needs to provide space corresponding to the multiple of the data size, that is, d * N bits (Bytes) of space. It cannot deceive the client by only using N bits of storage space. The Proof of Replication (PoRep) mechanism belongs to a type of data storage proof and is mainly applied to the scenario of the above - mentioned replicated storage of data. The PoRep mechanism combines the proof of recoverability and the space mechanism, that is, the PoRep mechanism has both recoverability and space guarantee.

[0085] For data replication storage, the general data processing process is as follows: After the client and the consensus node reach a storage transaction, the client transmits the input data off-chain to the consensus node. The consensus node uses the ZigZag Depth-Robust-Graph (ZigZag DRGs) algorithm to perform replication encryption on the input data according to the backup requirements sent by the client to obtain encrypted data blocks and generate replication proofs.

[0086] A bipartite graph is a graph whose vertex set can be partitioned into two disjoint subsets, and each edge in the graph is attached to two vertices that belong to these two disjoint subsets respectively, and the vertices within the two subsets are not adjacent. The ZigZag Depth-Robust-Graph (ZigZag DRGs) is extended based on the principles of the Depth-Robust-Graph (DRG) and the bipartite graph, and its operation process is as Figure 2 shown.

[0087] The ZigZag Depth-Robust-Graph is a multi-layer graph structure, and each layer is an independent Depth-Robust-Graph DRG. The consensus node encrypts the user's input data through the ZigZag DRGs algorithm to obtain encrypted data. If d backups need to be stored, the ZigZag DRGs algorithm is executed d times on the input data to obtain multiple different encrypted data, and the encrypted data blocks are organized and managed using a Merkle tree, that is, each encrypted data block serves as a leaf of the Merkle tree, and the Merkle root is submitted to the blockchain as a storage proof. A sequence number list of the encrypted data blocks to be verified each time is randomly generated, and the consensus node generates Merkle proofs for the encrypted data blocks corresponding to the sequence numbers one by one according to the sequence number list. In addition, to ensure that the consensus node will always store the user's data, each consensus node needs to generate a spacetime proof for all the stored data at regular intervals. The spacetime proof is similar to the replication proof. Since the spacetime proof only needs to ensure the continuous storage of the encrypted data blocks, the spacetime proof only includes the Merkle proof for verifying the encrypted data blocks. However, the above data processing process has the following problems:

[0088] First, the above data processing process cannot update data efficiently. Even if the data changes by one bit, the consensus node needs to re-execute the replication encryption process, which consumes a large amount of time and computing power and frequently erases the storage hard disk.

[0089] Second, the verification node needs to directly verify these Merkle proofs. If the number of participating consensus nodes and the amount of stored data increase, the verification process has low verification efficiency, and the verification node also needs to verify the relationship between the input data and the backup encrypted data, that is, the correctness of the encryption calculation. The verification node also needs to verify the spacetime proof with a large amount of data. That is, the above data processing process also has the problem of poor scalability.

[0090] Thirdly, the above data processing process requires the user to have a fixed data length for storage transactions, that is, the user's data can only start to execute copy encryption when it reaches a certain length, such as filling a 32G sector. Because the copy encryption algorithm divides the input data into fixed - quantity and fixed - length data blocks. If the user adds a small amount of data (much less than 32G), then it is impossible to perform copy encryption on this small amount of data separately, and the correct storage of this part of the data cannot be guaranteed.

[0091] To solve the above problems, first of all, this application improves the data storage structure. There are two storage areas in the consensus node: the data domain and the log domain. Among them, the data domain is marked as the R domain, and the log domain is marked as the H domain. The R domain is used to store backup encrypted data, that is, the data after copy - encrypting the input data. The H domain is used to store the log - domain data blocks for modifying the backup encrypted data, and when the new data stored in the H domain reaches the encryption - limit length, it is merged with the input data and then re - encrypted to obtain new backup encrypted data. Through the above settings, when modifying the input data, there is no need to re - execute the copy encryption algorithm, which improves the data processing efficiency and reduces the resource usage rate. In addition, a cryptographic accumulator (hereinafter referred to as the accumulator) is used to generate a membership proof for each log - domain data block in the log domain. Since the accumulator can efficiently generate a membership proof for dynamically changing log data, it can be applied to both users who entrust long - term stored unchanged data and users who frequently update data.

[0092] Secondly, the copy proof of this application uses zero - knowledge proof information. The verification calculation of the Merkle proof and the verification calculation of encryption correctness are unified to construct a circuit, and the consensus node generates a zero - knowledge proof. The verifier or user only needs to use the public parameters to verify this zero - knowledge proof to achieve verifying the encryption correctness of the input data and verifying the Merkle proof of the encrypted data block, which simplifies the verification process. The public input of the zero - knowledge proof algorithm only includes the public parameters and the identifier of the corresponding data, and does not disclose the data itself, ensuring the reliability of the verification.

[0093] Correspondingly, the proof - of - space - time only needs to use the zero - knowledge proof algorithm for the verification calculations of the Merkle proof of the verified encrypted data block and the membership proof of the log data block to generate zero - knowledge proof information. That is, each alternative data in the consensus node corresponds to a zero - knowledge proof information, and the zero - knowledge proof information of multiple alternative data in the consensus node forms the proof - of - space - time. The consensus node can also recursively aggregate all the zero - knowledge proofs in the proof - of - space - time to obtain a root proof, and store the root proof on the blockchain through the consensus algorithm. That is, the final proof - of - space - time only contains the root proof, but in terms of effectiveness, it is equivalent to verifying the zero - knowledge proof of each backup encrypted data, which simplifies the verification process of the proof - of - space - time.

[0094] Accordingly, in the present application, a recursive node 30 is provided. The recursive node 30 communicates with each consensus node in the blockchain system. The recursive node 30 collects the zero-knowledge proof information made by all consensus nodes, then recursively aggregates to obtain a root proof, and stores the root proof on the blockchain through a consensus algorithm, further simplifying the verification process.

[0095] Finally, when the present application performs replicated encryption on input data, for input data of any length, after doubling and supplementing according to the encryption boundary length, it is then cut and subjected to replicated encryption processing to obtain backup encrypted data. It is possible to perform replicated encryption on input data of any length.

[0096] As Figure 3 shown, an embodiment of the present application provides a blockchain-based data processing method. This data processing method is applied to a blockchain system. The data processing method specifically includes the following steps:

[0097] S101. The client obtains a first input data identifier and operation information, and generates a data modification request according to the first input data identifier and the operation information.

[0098] In this step, the data storage structure is first described. The consensus node has two storage areas, a data domain and a log domain. As Figure 4 shown, the data domain is marked as the R domain, and the log domain is marked as the H domain. If the client requests to back up a piece of data d times, since the result of each encrypted replication is different, the consensus node will store d backup encrypted data with the same size but different contents in the R domain. However, these backup encrypted data share the log data in the same H domain. That is, the H domain is only related to the identity identifier of the input data (File Identity, abbreviated as: FID), while the R domain is related to the identity identifier (BID) of each backup encrypted data of the input data.

[0099] In the R domain, the backup encrypted data after replicated encryption of the input data D is stored. They are data blocks. Due to the Perderson hash algorithm used, the length of each data block is also 32 bytes. These data blocks are managed by constructing a Merkle hash tree and generating Merkle proof information. To facilitate quickly proving the recoverability of the data later, the R domain should also store all node data of the entire Merkle tree. Or, only store partial node data and calculate it when generating Merkle proof information. Since the Merkle tree is a complete tree, the number of node data of the Merkle tree should satisfy

[0100] In the H domain, there is a log domain data block for the client to operate on the backup encrypted data, which is also stored in the form of data blocks, but its length is not limited. A data block is a set of operations submitted by the client each time, including the data block serial number of the input data involved in the operation and the corresponding operation content. For example, modifying the content of the data block with serial number k, deleting the data block with serial number k, and adding a new data block. The log domain data blocks updated at the same time also include the operation submission time.

[0101] The client obtains the input data identifier FID to be modified, marks it as the first input data identifier, and obtains the operation information for the input data D. The operation information includes modifying the content of the data block with serial number k, deleting the data block with serial number k, adding a new data block at the end, and adding a data block between serial number k and serial number k + 1. Then, a data modification request is generated based on the first input data identifier and the operation information.

[0102] S102. The consensus node receives the data modification request sent by the client.

[0103] In this step, the consensus node can be any consensus node in the blockchain.

[0104] S103. The consensus node processes the first input data identifier and the operation information in the data modification request to obtain the log domain data block and the membership proof of the log domain data block.

[0105] In this step, the consensus node parses the first input data identifier and the operation information from the data modification request, obtains the log domain data block by packing the first input data identifier and the operation information, and generates the membership proof of the log domain data block in the log domain (H domain). This membership proof is used to prove that the consensus node modifies the input data according to the operation information.

[0106] The accumulator is similar to the vector proof and can generate a membership proof, that is, an element belongs to a set, without binding the element and the position order, and can simultaneously prove that multiple elements belong to a set. Commonly used is the accumulator designed by Dan Boneh et al., which modifies the construction conditions of the original accumulator, adopts a short non-interactive proof, and greatly improves the verification efficiency. It can also generate a non-membership proof, that is, an element does not belong to a set, which is more flexible and convenient. General accumulators are all dynamic accumulators, and when an element is added or removed, the proof can be dynamically updated. Therefore, an accumulator is used to generate the membership proof for each log domain data block in the log domain.

[0107] In an embodiment, the H domain also stores the prime number vector S of the accumulator at time t tis formed by mapping all log domain data blocks at time t to a prime number respectively using a prime number mapping function, and the prime number mapping function is denoted as H primes This solution uses the prime number mapping function designed by Fouque and Tibouchi, which can efficiently complete the mapping within O(λ) time, where O(λ) represents the linear time of λ

[0108] The value A of the accumulator t is obtained by processing the elements in the prime number vector S at time t t The value A of the accumulator t and the prime number vector S t are used to generate the membership proofs of each log domain data block in the log domain

[0109] Obtaining the membership proof of the log domain data block specifically includes: obtaining the elements of the accumulator at the first update time according to the add element method of the accumulator for the log domain data, and processing the elements of the accumulator at the first update time according to the generate membership proof method of the accumulator to obtain the membership proof of the log domain data block

[0110] For example: The consensus node packs the first input data identifier and operation information into one or more log domain data blocks, then adds the log domain data blocks to the H domain, and updates the prime number vector of the accumulator, that is, the accumulator updates the element set of the accumulator at time t - 1 to obtain the prime number vector S at the first update time t t and based on the prime number vector S at the first update time t t obtain the value A of the accumulator at the first update time t and then execute the method for generating the membership proof of the log domain data block added at the addition time t make a membership proof for the prime number corresponding to the newly added log data block in the accumulator prime number vector

[0111] S104. The consensus node performs zero-knowledge proof processing on the membership proof of the log domain data block to obtain the zero-knowledge proof information of the membership proof and the first public parameter

[0112] In this step, first construct a zero-knowledge proof algorithm based on Plonk for verifying the membership proof of the log domain data block

[0113] Initialization sub - algorithm, whose expression is DSetup(λ, T) → pp, A0: It is mainly used for initializing the zero - knowledge proof algorithm and the accumulator. Taking the security parameter λ and the response delay parameter T as inputs, it outputs the global public parameter pp and the initial element set A0 of the accumulator. Among them, pp = (crs, G, g, l). G represents a group of arbitrary order, g represents the generator of the group of arbitrary order, and crs represents the set of invariant parameters.

[0114] The security parameter λ and the response delay parameter T are set according to requirements and stored on the blockchain. All consensus nodes and recursive nodes can execute the initialization sub - algorithm with these two parameters to obtain the same global public parameter pp and the initial value of the accumulator.

[0115] Proof sub - algorithm, whose expression is, or π u : The zero - knowledge proof information π for generating the membership proof of the log domain data block w or the zero - knowledge proof information π for non - membership proof u . The verification node needs to verify the correctness of the membership proof or non - membership proof of the log domain data block. Verifying the correctness of the membership proof or non - membership proof is also a computational process, which can be calculated using the proof sub - algorithm in the zero - knowledge proof algorithm. When it is necessary to verify the membership proof or non - membership proof of the log domain data block within the H domain, the membership proof or non - membership proof of the log domain data block needs to be used as the secret input to generate the zero - knowledge proof information of the membership proof or non - membership proof.

[0116] The process of verifying the correctness of the membership proof of the accumulator is shown in formulas (1) and (2), and the process of verifying the correctness of the non - membership proof of the accumulator is shown in formulas (3) and (24):

[0117]

[0118]

[0119]

[0120]

[0121]

[0122] Among them, ":" means explanation, represents the prime number vector S tMultiply all members except the member x to be proven. On the right side of equation (1), the power is taken on the generator g of group G. Equation (1) indicates that the result of the multiplication corresponds to an element in group G, that is, corresponding to member proof. Equation (2) indicates whether the result of taking the power on the member proof is the element vector of the accumulator. Equation (3) represents non-member proof Consisting of a and g b The Bezout function is the Bezout's identity, and two values a and b are obtained through the Bezout formula. Equation (4) represents judging A t a g bx Whether the calculation result of is the generator g of group G.

[0123] Verification sub-algorithm, whose expression is DVerify(pp, π w , A t ), which is used to verify the correctness of the zero-knowledge proof information of the member proof. If the verification sub-algorithm outputs 0, it means rejecting the zero-knowledge proof information. If the verification sub-algorithm outputs 1, it means accepting the zero-knowledge proof information.

[0124] Use the proof sub-algorithm in the zero-knowledge proof algorithm described above to prove the member proof of the log domain data block, so as to obtain the zero-knowledge proof information of the member proof and the first common parameter. The first common parameter is used by the verifier to verify the zero-knowledge proof information of the member proof. The prover is used to execute the proof sub-algorithm in the zero-knowledge proof algorithm to output the zero-knowledge proof information of the member proof and the first common parameter.

[0125] In one embodiment, when the member proof of the log domain data block is obtained by executing the member proof algorithm in the accumulator, the member proof of the log domain data block, the element set of the accumulator at the first update moment, and the value of the accumulator at the first update moment are processed according to the global common parameter and the proof algorithm to obtain the zero-knowledge proof information of the member proof and the first common parameter.

[0126] For example: When the consensus node makes a member proof for the prime number corresponding to the newly added log data block in the accumulator prime vector After that, execute the algorithm Make a zero-knowledge proof π w For the correctness of the member proof. Among them, pp represents the global common parameter, S t Represents the prime vector at the first update moment t, A t Represents the value of the accumulator at the first update moment, and π w Represents the member proof of the log domain data block.

[0127] S105. The consensus node generates a first transaction request according to the zero-knowledge proof information of the member proof and the first common parameter.

[0128] In this step, the first common parameter is the value A of the accumulator at the first update moment. t , and the consensus node encapsulates the zero-knowledge proof information π of the membership proof w and the first common parameter A t into the transaction content and sends it to the client.

[0129] S106. The consensus node sends a first transaction request to the client.

[0130] S107. The client verifies the zero-knowledge proof information of the membership proof according to the first common parameter.

[0131] In this step, the client extracts the zero-knowledge proof information π of the membership proof w and the first common parameter A t from the first transaction request, and then executes the verification sub-algorithm DVerify(pp, π w , A t ), and determines the verification result according to the output result of the verification sub-algorithm.

[0132] In the above technical solution, a data domain and a log domain are set in the consensus node. The log domain is used to store the log domain data blocks for modifying the backup encrypted data. Through the above settings, when modifying the input data, there is no need to re-execute the replication encryption algorithm, which improves the data processing efficiency and reduces the resource usage rate. In addition, an accumulator is used to generate a membership proof for each log domain data block in the log domain. Since the accumulator can efficiently generate a membership proof for the dynamically changing log data, it can not only be applicable to users who entrust data that does not change for a long time, but also meet the needs of users who frequently update data, with a wide range of adaptability. And zero-knowledge proof processing is performed on the membership proofs of each element in the accumulator to obtain the zero-knowledge proof information of the membership proof. The client only needs to verify the zero-knowledge proof information of the membership proof to realize the verification of the encrypted storage of the log domain data blocks and simplify the verification process.

[0133] As Figure 5 shown, an embodiment of the present application provides a blockchain-based data processing method. The data processing method is applied to a blockchain system, and the data processing method specifically includes the following steps:

[0134] S201. The client obtains input data and generates a data storage request according to the input data.

[0135] In this step, as one implementation method, after the user reaches a data storage transaction with a certain consensus node, the client obtains the input data and generates a data storage request based on the input data. As another implementation method, when the newly added data in the log domain data block in the log domain reaches the replication encryption limit length, the newly added data and the input data corresponding to the log domain data block are merged to generate the updated input data. By setting it like this, after converting the user's modification operation on the input data into the storage of the log domain data block in the log domain, the replication encryption algorithm is re-executed on the updated input data through the mechanism of updating the input data.

[0136] S202. The consensus node receives the data storage request sent by the client.

[0137] S203. The consensus node performs doubling and supplementing processing on the input data according to the preset replication encryption limit length to obtain the processed input data, and performs segmentation processing on the processed input data to obtain multiple data blocks.

[0138] In this step, after receiving the data storage request, the consensus node parses the input data from the data storage request, generates the identifier FID of the input data, and uploads the identifier FID of the input data to the blockchain. The consensus node is also used to perform doubling and supplementing processing on the input data according to the preset replication encryption limit length to obtain the processed input data. Among them, the doubling and supplementing processing is used to make the length of the processed input data a multiple of the replication encryption limit length, and the supplemented data blocks are invalid data.

[0139] After performing the doubling and supplementing processing on the input data, perform segmentation processing on the processed input data to obtain multiple data blocks.

[0140] Suppose the length of the input data D is 31G and the replication encryption limit length is 32G, then add 0bit to make the overall length reach an integer multiple of the replication encryption limit length, that is, the length of the input data D reaches 32G. Then the input data is split into 2 10 data blocks with a length of 32 bytes.

[0141] S204. The consensus node performs replication encryption processing on multiple data blocks to obtain backup encrypted data and proof auxiliary data corresponding to the backup encrypted data.

[0142] In this step, the consensus node uses the replication encryption algorithm to perform replication encryption processing on multiple data blocks to obtain backup encrypted data and proof auxiliary data corresponding to the backup encrypted data. Among them, the proof auxiliary data is used to generate zero-knowledge proof information for the correctness of the encryption process and the correctness of the Merkle proof of the encrypted data block.

[0143] The Stacked Depth-Robust-Graph (abbreviated as Stacked DRGs) is also extended based on the depth-robust graph and the bipartite graph, as shown in Figure 4 as follows. Each layer of the Stacked Depth-Robust-Graph is a depth-robust graph. The relationship between the nodes in each layer, in addition to the dependencies of the depth-robust graph itself, also includes the bipartite expansion dependencies between layers. Only the last layer of the Stacked Depth-Robust-Graph performs encryption on the original data. The calculation processes of the previous layers are to obtain the label data required for encrypting each node in the last layer. The calculation of these label data also follows the dependency relationships between the nodes. Finally, each node is encrypted together with the label data corresponding to its dependencies respectively.

[0144] In one embodiment, when performing replicated encryption processing on multiple data blocks, the initial label data τ D of each data block is processed using the Stacked Depth-Robust-Graph algorithm to obtain the label data of each data block at the l d -1 layer. Each data block is encrypted based on the label data of each data block at the l d -1 layer to obtain backup encrypted data, and the Merkle proof of the backup encrypted data is used as proof auxiliary data. Here, l d represents the total number of layers of the Stacked Depth-Robust-Graph.

[0145] For example: The 2 10 data blocks with a length of 32 bytes obtained by splitting in S203 are used as the nodes of the last layer of the Stacked Depth-Robust-Graph. The nodes of the first layer are the initial labels τ D of each data block. The values of the nodes of each layer are calculated in sequence according to the dependency relationships of the nodes as label data in the previous l d -1 layers. The length of the label data of each node is also 32 bytes. Therefore, the number of nodes in each layer can be kept unchanged, and the input data D after splitting is encrypted in the last layer.

[0146] In the above technical solution, for data D of any length, after doubling and supplementing, and cutting according to the replicated encryption boundary length and then respectively performing the replicated encryption algorithm, due to the non-twisted reverse bipartite depth-robust graph, data needs to be encrypted in each layer, and the encryption process is complex. Moreover, a verifiable delay function is used as the data encryption function, resulting in a very long overall replicated encryption time. If a malicious person can find a fast replicated encryption method, the security of the entire mechanism will be reduced. Therefore, this solution adopts the Stacked Depth-Robust-Graph, which does not require encrypting data in each layer, and can shorten the encryption time. And, all the label data needs to be calculated layer by layer first, and then the data in the last layer is encrypted or decrypted. It cannot be calculated in parallel and can only be calculated node by node from top to bottom and from left to right. The reliability of the data encryption process is high.

[0147] S205. The consensus node performs zero - knowledge proof processing on the backup encrypted data according to the proof auxiliary data to obtain the zero - knowledge proof information of the backup encrypted data and the second common parameter.

[0148] In this step, a zero - knowledge proof algorithm based on Plonk for verifying the backup encrypted data is constructed:

[0149] Initialization sub - algorithm, whose expression is DSetup(λ, T) → ppA0: It is mainly used for initializing the zero - knowledge proof algorithm, initializing the replication encryption algorithm, and initializing the accumulator. Taking the security parameter λ and the response delay parameter T as inputs, it outputs the global common parameter pp and the initial element set A0 of the accumulator. Among them, pp = (crs, G, g, l). G represents a group of unknown order, g represents the generator of the group of unknown order, and crs represents the set of invariant parameters. The response delay parameter T is used to set the number of layers l of the multi - layer bipartite depth - robust graph d and the parameters of each layer of the depth - robust graph. The number of layers of the multi - layer bipartite depth - robust graph and the parameters of each layer of the depth - robust graph affect the time of replication encryption calculation, so as to realize the setting of the replication encryption calculation time.

[0150] Replication encryption sub - algorithm, whose expression is DReplicate(BID, τ D , D) → R, aux, which is constructed based on the multi - layer bipartite depth - robust graph and is used for replicating and encrypting the input data D. Taking the input data D, the identity identifier BID of each backup encrypted data, and the initial label τ of the segmented data block D as inputs, each execution generates a backup encrypted data R and the corresponding proof auxiliary data aux. If multiple backups are required, the replication encryption algorithm is repeatedly executed with different identity identifiers BID of the backup encrypted data.

[0151] As Figure 6 shown below, the replication encryption algorithm is specifically described. First, calculate the identity identifier of the backup encrypted data according to formula (5):

[0152] BID = H ped (FID||CID||n) (5)

[0153] Among them, BID represents the identity identifier of the backup encrypted data, n represents the nth backup encrypted data, n is an integer, FID represents the identity identifier of the input data, CID represents the identity representation of the consensus node, a||b represents concatenating the two strings a and b, and H ped (y) represents performing the Pederson hash function on y, and the output result is 32 bytes.

[0154] Starting from the second layer, calculate the label data of each node layer by layer. For a certain node i in any layer, find the parent node of the i-th node according to the depth-robust graph. The specific calculation process is represented by formula (6):

[0155] Parent(N, i, d) → (v1, v2,..., v d ) (6)

[0156] Parent(N, i, d) is used to find the dependent nodes, that is, the parent nodes, of the i-th node according to the depth-robust graph, including the parent nodes in the same layer and the upper layer. v1, v2,..., v d represents the label data of the parent node of node i.

[0157] Then, after concatenating the parent node of node i with the identity identifier of the backup encrypted data, perform a hash calculation to obtain the label data of this node. The specific calculation process is represented by formula (7):

[0158] H ped (v1||...||v d ||BID) → v i (7)

[0159] Among them, v i represents the label data of node i.

[0160] Starting from the second layer, through recursive calculation according to formulas (5), (6), and (7), the label data of each node in the l d -1 layer can be calculated. The relationship between each data block after being segmented according to the dependency relationship and the label data of each node in the l d -1 layer is used to perform a large number addition calculation to obtain the encrypted data block R i . More specifically, calculate the parent nodes of each data block according to formula (6). The parent nodes include the label data of each node in the l d -1 layer and the data blocks in the same layer, and then use formula (8) to calculate and obtain the encrypted data block.

[0161] Bigadd(v1, v2,..., v d , D i ) → R i (8)

[0162] The backup encrypted data R is (R1, R2,..., R N ), and construct a Merkle tree of the backup encrypted data R.

[0163] DExtract(BID, τ D, R, aux) → D: The data decryption sub - algorithm is used to decrypt and restore the backup encrypted data R to the input data D. The decryption algorithm also needs to first calculate the label data of each node in the l d -1 layer, and then use

[0164] DPoll(N) → r: The random challenge algorithm is used to select the encrypted data blocks for verification from multiple encrypted data blocks R of any backup encrypted data R i . As one implementation, this algorithm essentially randomly selects l challenge serial numbers from the integer set of length N to generate the challenge vector r = (r1,..., r l ). As another implementation, the challenge serial numbers can be generated by a common pseudo - random function or hash function. For example, the consensus node uses the hash value of the current block as the seed and hashes out l integers less than N through the hash algorithm. After obtaining the challenge vector, according to the elements r1,..., r l in the challenge vector, select the encrypted data blocks for verification from multiple encrypted data blocks R i . This can achieve non - interactive dynamic replication proof. Without the need for the client to synchronously execute with the consensus node, it can also ensure that the consensus node cannot forge the challenge vector r.

[0165] The proof sub - algorithm, whose expression is DProve(pp, R, aux, BID, S t , r) → π R : It is used to generate the zero - knowledge proof information of the backup encrypted data. It is necessary to prove the computational correctness of the replication encryption process and the correctness of the Merkle proof of the data blocks selected based on the challenge vector. The correctness verification of these proofs is also a computational process, which can be calculated using the proof sub - algorithm. Generate the zero - knowledge proof information of the backup encrypted data with the challenge vector, backup encrypted data, and segmented data blocks as inputs.

[0166] In one embodiment, when performing zero - knowledge proof processing on the backup encrypted data, a target serial number is randomly generated, verification data blocks are selected from the backup encrypted data according to the target serial number, and the Merkle proof of the verification data blocks is obtained. Use the proof sub - algorithm in the zero - knowledge proof algorithm to process the elements of the accumulator at the current moment and the Merkle proof of the verification data blocks to obtain the zero - knowledge proof information of the backup encrypted data and the second public parameter.

[0167] For example: Execute the random challenge generation algorithm DPoll(N) to obtain l challenge serial numbers, the l challenge serial numbers form the challenge vector r, and then execute the proof sub - algorithm DProve(pp, R, aux, BID, S t , r), and output the zero - knowledge proof information π of the backup encrypted data RThis proof sub-algorithm is used to prove the computational correctness of the replicated encryption process and the correctness of the Merkle proof of the encrypted data block R selected based on the challenge vector, where j ∈ r. j where j ∈ r.

[0168] where pp represents the global public parameters, R represents a backup encrypted data, aux represents auxiliary data, specifically the Merkle proof of the encrypted data blocks in the backup encrypted data, BID represents the identity identifier of the assigned encrypted data, and S t represents the prime vector in the accumulator when executing the proof sub-algorithm.

[0169] S206. The consensus node generates a second transaction request based on the zero-knowledge proof information of the backup encrypted data and the second public parameters.

[0170] In this step, the second public parameters include the identity identifier BID of the backup encrypted data and the challenge vector r. The consensus node encapsulates the zero-knowledge proof information π of the backup encrypted data, R the identity identifier BID of the backup encrypted data, and the challenge vector r into the transaction content and sends it to the client.

[0171] S207. The consensus node sends the second transaction request to the client.

[0172] S208. The client verifies the zero-knowledge proof information of the backup encrypted data according to the second public parameters.

[0173] In this step, the user extracts the zero-knowledge proof information π of the backup encrypted data, R the identity identifier BID of the backup encrypted data, and the challenge vector r from the second transaction request, and then executes the verification sub-algorithm DVerify(pp, π R , BID, r), and determines the verification result according to the output result of the verification sub-algorithm.

[0174] In the above technical solution, before performing replicated encryption on the input data, the input data is first lengthened so that the processed input data can be segmented according to the replicated encryption boundary length, and then the non-twisted reverse binary depth robust graph algorithm can be used to encrypt each data block of the same size to obtain the backup encrypted data, which can realize the encryption of input data of any length. When verifying the correctness of the encryption process and the Merkle proof of the encrypted data block, the zero-knowledge proof algorithm is constructed, and the zero-knowledge proof information of the backup data is generated. By verifying the zero-knowledge proof information, the correctness verification of the encryption process and the Merkle proof of the encrypted data block can be realized without verifying the Merkle proof, and the verification process is simplified, which is applicable to the expansion of the number of consensus nodes and the expansion of the stored data volume.

[0175] Such asFigure 7 As shown in the figure, an embodiment of the present application provides a data processing method based on a blockchain. This data processing method is applied to a blockchain system, and the data processing method specifically includes the following steps:

[0176] S301. The client obtains the return time and the first input data identifier, and generates a version return request according to the return time and the first input data identifier.

[0177] In this step, when the user modifies the input data, the user can choose which modified version to roll back to. The client receives the first input data identifier of the data to be rolled back input by the user, and generates a version return request by packaging the first input data identifier of the data to be rolled back and the return time.

[0178] S302. The consensus node receives the version return request sent by the client.

[0179] S303. The consensus node deletes the log domain data blocks associated with the first input data identifier and after the return time, and generates a non-membership proof of the deleted log domain data blocks.

[0180] In this step, the consensus node extracts the return time and the first input data identifier from the version return request. Determines the relevant log domain data blocks in the log domain according to the first input data identifier, and determines the log domain data blocks to be deleted according to the addition time of the log domain data blocks, that is, takes the log domain data blocks with the addition time after the return time as the log domain data blocks to be deleted, deletes the log domain data blocks to be deleted in the log domain, and generates a non-membership proof of the deleted log domain data blocks.

[0181] Among them, when generating the non-membership proof of the deleted log domain data blocks, the delete element method of the accumulator is executed according to the deleted log domain data to obtain the element of the accumulator at the second update time, so as to update the prime number vector S t of the accumulator. The non-membership proof of the deleted log domain data blocks is obtained by processing the element of the accumulator at the second update time and the element corresponding to the deleted log domain data blocks according to the non-membership proof generation method of the accumulator. That is, a non-membership proof is made for the prime number corresponding to the deleted log domain data blocks in the prime number vector of the accumulator and takes the non-membership proof of this prime number as the non-membership proof of the deleted log domain data blocks

[0182] S304. The consensus node performs zero-knowledge proof processing on the non-membership proof to obtain the zero-knowledge proof information of the non-membership proof and the third public parameter.

[0183] In this step, the zero-knowledge proof algorithm for the non-membership proof of the log domain data block has been described in S104, and the proof sub-algorithm described in S104 is directly referenced. By executing the proof sub-line algorithm Output the zero-knowledge proof information π of the non-membership proof u .

[0184] S305. The consensus node generates a third transaction request according to the zero-knowledge proof information of the non-membership proof and the third public parameter.

[0185] In this step, the third public parameter is the value A of the accumulator at the second update moment t , and the consensus node packs the zero-knowledge proof information π of the non-membership proof u and the third public parameter A t into the transaction content and sends it to the client.

[0186] S306. The consensus node sends the third transaction request to the client.

[0187] S307. The client verifies the zero-knowledge proof information of the non-membership proof according to the third public parameter.

[0188] In this step, the client extracts the zero-knowledge proof information π of the non-membership proof u and the third public parameter A t from the third transaction request, and then executes the verification sub-algorithm DVerify(pp, π u , A t ), and determines the verification result according to the output result of the verification sub-algorithm.

[0189] In the above technical solution, when the user needs to roll back to the previous data modification version, a version rollback request is initiated, so that the consensus node deletes the corresponding log domain data block in the log domain, updates the prime vector of the accumulator, and generates a non-membership proof according to the updated prime vector and the prime number corresponding to the deleted log domain data block, and generates the zero-knowledge proof information of the non-membership proof, which can be used to verify the correctness of the non-membership proof only by verifying the zero-knowledge proof information, simplifying the verification process, and since the modification operation of the input data is stored in the log domain, the data version rollback can be realized without re-copying and encrypting the input data, simplifying the data processing process.

[0190] As Figure 8 shown, an embodiment of the present application provides a blockchain-based data processing method, which is applied to a blockchain system, and the data processing method specifically includes the following steps:

[0191] S401. The client obtains the second input data identifier and generates a data reading request according to the second input data identifier.

[0192] In this step, when the user needs to read or download data from the consensus nodes, the second input data identifier FID for the data to be read is obtained, and the second input data identifier is encapsulated to generate a data reading request.

[0193] S402. The consensus node receives the data reading request sent by the client.

[0194] S403. The consensus node obtains the initial tag data of any backup encrypted data corresponding to the second input data identifier, and decrypts the backup encrypted data according to the decryption algorithm and the initial tag data of the backup encrypted data to obtain the input data.

[0195] In this step, after receiving the data reading request, the consensus node parses the second input data identifier from the data reading request, searches for the backup encrypted data corresponding to the second input data identifier, selects any backup encrypted data, obtains the initial tag data corresponding to the backup encrypted data, and uses the calculations involved in Formulas (5) to (7) to obtain the tag data of the l d -1 layer, and then determines the parent nodes of each encrypted data block according to the relationship between the tag data of the l d -1 layer and each encrypted data block in the backup encrypted data, and obtains the input data for the parent nodes of each encrypted data block and each encrypted data block. Specifically, it is calculated using Formula (9).

[0196] Bigmin(v1, v2,..., v d , R i ) → D i (9)

[0197] v1, v2,..., v d represents the parent node of the encrypted data block R i , D i represents the decrypted data block corresponding to the encrypted data block R i , and the input data D is (D1, D2,..., D i ,..., D N ). Bigmin(·) represents big number subtraction.

[0198] S404a. When there is a log domain data block associated with the second input data identifier in the operation domain, the consensus node parses the associated log domain data block to obtain the operation information and the operation time.

[0199] In this step, the log domain is searched using the second input data identifier. If there is a log domain data block associated with the second input data identifier in the operation domain, all the obtained log domain data blocks are parsed to obtain the operation information and the operation time of the input data.

[0200] S405a. The consensus node updates the third input data according to the operation information and operation time to obtain the updated input data, and sends the updated input data to the client.

[0201] In this step, the operation information is sorted in the order of operation time, and the input data is updated in sequence according to the sorted operation information. The updated input data is used as the updated input data, and the updated input data is sent to the client.

[0202] S404b. If there is no log domain data block associated with the second input data identifier in the operation domain, the consensus node directly sends the input data to the client.

[0203] In the above technical solution, when reading the input data stored in the consensus node, it is necessary to read the backup encrypted data and the initial tag data from the data domain, and use the initial tag data to decrypt the backup encrypted data to output the input data. It is also necessary to read the log domain data block associated with the second input data identifier from the log domain, and update the input data based on the operation information in the log domain data block, so as to provide the modified input data to the user, thereby realizing the operation of reading the data.

[0204] As Figure 9 shown, an embodiment of the present application provides a blockchain-based data processing method, which is applied to a blockchain system. The data processing method specifically includes the following steps:

[0205] S501. The recursive node receives the zero-knowledge proof information sent by each consensus node in the blockchain system and the status information of the consensus node when generating each zero-knowledge proof information.

[0206] In this step, the zero-knowledge proof information includes any one or a combination of zero-knowledge proof information of member proof, zero-knowledge proof information of non-member proof, and zero-knowledge proof information of backup encrypted data.

[0207] For each consensus node, when providing data replication storage services, it is necessary to generate zero-knowledge proof information such as zero-knowledge proof information of member proof for each element in the accumulator, zero-knowledge proof information of non-member proof for each element in the accumulator, and zero-knowledge proof information of backup encrypted data. The consensus node sends the generated zero-knowledge proof information to the recursive node, and sends the status information of the consensus node when generating the zero-knowledge proof information to the recursive node, so that the recursive node can generate the root proof and the root status information.

[0208] S502. The recursive node performs recursive aggregation processing on each zero - knowledge proof information and the status information of the consensus nodes when generating each zero - knowledge proof information, to obtain the root zero - knowledge proof information and the root status information.

[0209] In this step, since all consensus nodes use the same zero - knowledge proof circuit, the zero - knowledge proof information they generate can be collected by a recursive node and recursively aggregated. As Figure 10 shown, the recursive aggregation specifically includes the following steps:

[0210] S5021. Pairwise combine each zero - knowledge proof information to obtain multiple sub - combinations. For each sub - combination, process the status of the consensus nodes corresponding to the two zero - knowledge proof information in the sub - combination to obtain the combined status of each sub - combination.

[0211] The node status includes status information such as the storage consumption and block height of the consensus node. The role of the status conversion sub - algorithm is to link the entire recursive process together. Specifically, use the status conversion sub - algorithm to process the status of the consensus nodes corresponding to the two zero - knowledge proof information in each sub - combination to obtain the combined status of each sub - combination. And take the combined status of this sub - combination as each combination in the first layer.

[0212] Taking the first combination in the first layer as an example, use the formula to obtain the combined status of the first combination in the first layer. st1 represents the node status corresponding to one of the zero - knowledge proof information in the first combination, st2 represents the node corresponding to the other zero - knowledge proof information in the first combination, represents the combined status of the first combination.

[0213] S5022. For each sub - combination, perform zero - knowledge proof on the two zero - knowledge proof information in the sub - combination, the status of the consensus nodes corresponding to the two zero - knowledge proof information in the sub - combination, and the combined status of the sub - combination, to obtain the zero - knowledge proof information of each sub - combination.

[0214] Specifically, use the recursive proof algorithm to obtain the zero - knowledge proof information of each sub - combination. This recursive proof algorithm is used to verify the correctness of one zero - knowledge proof and another zero - knowledge proof in the sub - combination, as well as the correctness of converting the node status to the combined status.

[0215] The recursive proof algorithm is the verification sub - algorithm DVerify(pp, π, BID, r, A described in the above - mentioned embodiment for verifying zero - knowledge proof information for backing up encrypted data t)Convert it into an arithmetic circuit. Use the two zero - knowledge proof messages (π1, π2), the common inputs (x1, x2) required to verify these two zero - knowledge proof messages, and the node states (st1, st2) when generating these two zero - knowledge proof messages as the secret input w. After recursive state conversion, the combined state is the common input x, and finally output the zero - knowledge proof message of the sub - combination. The expression of the recursive proof algorithm is:

[0216]

[0217] S5023. Group the zero - knowledge proof messages of each sub - combination in pairs to obtain multiple parent combinations. For each parent combination, process the combined states corresponding to the two zero - knowledge proof messages in the parent combination to obtain the combined state of each parent combination.

[0218] After grouping the zero - knowledge proof messages of each sub - combination in pairs to obtain multiple parent combinations, specifically use the state - conversion sub - algorithm to process the consensus node states of the two sub - combinations in the parent combination to obtain the combined state of each parent combination.

[0219] For example: Combine the zero - knowledge proof message of the first combination in the first layer and the zero - knowledge proof message of the second combination to obtain the combined state of the first combination in the second layer. Specifically, calculate according to the following formula:

[0220]

[0221] Among them, represents the combined state of the first combination in the first layer, represents the combined state of the second combination in the first layer, represents the combined state of the first combination in the second layer.

[0222] The combined states of other combinations in the second layer can also be calculated with reference to formula (10), which will not be elaborated here.

[0223] S5024. For each parent combination, perform zero - knowledge proof on the two zero - knowledge proof messages in the parent combination, the combined state of the sub - combinations in the parent combination, and the combined state of the parent combination to obtain the zero - knowledge proof message of each parent combination.

[0224] Use the recursive proof algorithm to perform zero - knowledge proof on the two zero - knowledge proof messages in the parent combination, the combined state of the sub - combinations in the parent combination, and the combined state of the parent combination to obtain the zero - knowledge proof message of each parent combination.

[0225] Continue to illustrate formula (10) for calculating the zero-knowledge proof information of the first combination in the second layer using the example in S5023:

[0226]

[0227] Among them, represents the zero-knowledge proof information of the first combination in the first layer, represents the zero-knowledge proof information of the second combination in the first layer, and represent public parameters, the zero-knowledge proof information of the first combination in the second layer.

[0228] The zero-knowledge proof information of other combinations in the second layer can also be calculated with reference to formula (11), which will not be elaborated here.

[0229] S5025. Check if the number of parent combinations is 1. If so, go to S5026; otherwise, go to S5021.

[0230] In this step, when the number of parent combinations is 1, it means the recursion is completed. When the number of parent combinations is greater than 1, further grouping is required and the combined states and zero-knowledge proof information of the grouped combinations need to be calculated, that is, continue the recursive aggregation until the number of parent combinations is 1.

[0231] S5026. Use the zero-knowledge proof information of the parent combination obtained in the last loop as the root zero-knowledge proof, and use the combined state of the parent combination obtained in the last loop as the root state information.

[0232] In this step, after recursive aggregation, use the zero-knowledge proof information of the parent combination obtained in the last loop as the root zero-knowledge proof π root , and use the combined state of the parent combination obtained in the last loop as the root state information st root .

[0233] S503. The recursive node generates a fourth transaction request based on the root zero-knowledge proof information and the root state information.

[0234] In this step, the recursive node packages the zero-knowledge proof information and the root state information to generate a fourth transaction request.

[0235] S504. The recursive node sends the fourth transaction request to the consensus nodes in the blockchain system.

[0236] Among them, the fourth transaction request is used to enable the blockchain system to store the root zero-knowledge proof according to the root state information. When storing the root zero-knowledge proof, by executing the verification algorithm RDVerify(π root , st root) Generate a root zero-knowledge proof, and determine whether to upload to the blockchain based on the verification result.

[0237] In the above technical solution, the recursive zero-knowledge proof is a recursive aggregation of the zero-knowledge proof itself. Since the verification calculation of the zero-knowledge proof is also a program that satisfies NP, it is also possible to further prove the construction of the circuit for this calculation. By using multiple zero-knowledge proofs as common inputs, a recursive zero-knowledge proof is obtained. After layer-by-layer recursion, a root zero-knowledge proof is obtained.

[0238] In addition, the recursive node recursively clusters the zero-knowledge proof information. The blockchain system uses the consensus algorithm to maintain the state of the data storage system composed of all consensus nodes, and verifies the root proof of the proof of space-time and the root proof of the proof of dynamic replication, which can ensure that the consensus nodes and recursive nodes cannot act maliciously.

[0239] An embodiment of the present application provides a data processing method based on the blockchain. This data processing method is applied to the blockchain system. The data processing method specifically includes the following steps:

[0240] S601. The consensus node obtains the generated zero-knowledge proof information and the state information of the consensus node when each zero-knowledge proof information is generated.

[0241] In this step, each consensus node obtains the zero-knowledge proof information generated by itself and the state information of the consensus node when each zero-knowledge proof information is generated.

[0242] S602. The consensus node performs recursive aggregation processing on each zero-knowledge proof information and the state information of the consensus node when each zero-knowledge proof information is generated, and obtains the root zero-knowledge proof information and the root state information.

[0243] Among them, the consensus node performs recursive aggregation processing on the zero-knowledge proof information it generates to obtain the root zero-knowledge proof information and the root state information. The root zero-knowledge proof information is used as part of the proof of space-time, and the root state information is used to verify the correctness of the root zero-knowledge proof information.

[0244] The recursive aggregation processing process is the same as that in S502 and will not be elaborated here.

[0245] S603. The consensus node generates a fifth transaction request according to the root zero-knowledge proof information and the root state information.

[0246] In this step, the consensus node packages the zero-knowledge proof information and the root state information to generate a fifth transaction request.

[0247] S604. The consensus node sends the fifth transaction request to other consensus nodes.

[0248] Among them, the fifth transaction request is used to upload the root zero-knowledge proof information and the root status information to the blockchain system.

[0249] In the above technical solution, the number of proofs can be greatly reduced, thereby reducing the bandwidth pressure on the blockchain, and the verification calculation pressure on the verifier can also be reduced, increasing the scalability of the system without reducing security.

[0250] As Figure 11 shown, an embodiment of the present application provides an electronic device 700, and the electronic device 700 includes a memory 701 and a processor 702.

[0251] Among them, the memory 701 is used to store computer instructions executable by the processor.

[0252] When the processor executes the computer instructions, it implements each step in the method in the above embodiment. Specifically, reference can be made to the relevant descriptions in the foregoing method embodiment.

[0253] Optionally, the above memory 701 can be either independent or integrated with the processor 702. When the memory 701 is independently provided, the electronic device further includes a bus for connecting the memory 701 and the processor 702.

[0254] An embodiment of the present application further provides a computer-readable storage medium, in which computer instructions are stored. When the processor executes the computer instructions, it implements each step in the method in the above embodiment.

[0255] An embodiment of the present application further provides a computer program product, including computer instructions, which implement each step in the method in the above embodiment when executed by the processor.

[0256] Those skilled in the art will readily think of other implementation schemes of the present application after considering the specification and practicing the invention disclosed herein. The present application is intended to cover any variations, uses, or adaptations of the present application, which follow the general principles of the present application and include common general knowledge or conventional technical means in the technical field not disclosed in the present application. The specification and embodiments are only regarded as exemplary, and the true scope and spirit of the present application are pointed out by the following claims.

[0257] It should be understood that the present application is not limited to the exact structure already described and shown in the drawings, and various modifications and changes can be made without departing from its scope. The scope of the present application is only limited by the appended claims.

Claims

1. A blockchain-based data processing method, characterized in that, The method is applied to consensus nodes in a blockchain. The consensus nodes include a data domain storage area and a log domain storage area. The log domain storage area is used to store log domain data blocks for modifying backup encrypted data. The method includes: Receiving a data modification request sent by a client. The data modification request includes a first input data identifier and operation information. The operation information includes the content of the data block with modification sequence number k, deleting the data block with sequence number k, adding a new data block at the end, and adding a data block between sequence number k and sequence number k + 1; Processing the first input data identifier and the operation information to obtain a log domain data block and a membership proof of the log domain data block. Specifically, it includes: executing the add element method of the accumulator according to the log domain data to obtain the elements of the accumulator at the first update moment; processing the elements of the accumulator at the first update moment according to the membership proof generation method of the accumulator to obtain the membership proof of the log domain data block. The membership proof is used to prove that the consensus node modifies the input data according to the operation information; Performing zero-knowledge proof processing on the membership proof of the log domain data block to obtain zero-knowledge proof information of the membership proof and a first common parameter; Generating a first transaction request according to the zero-knowledge proof information of the membership proof and the first common parameter, and sending the first transaction request to the client. The first transaction request is used to enable the client to verify the zero-knowledge proof information of the membership proof according to the first common parameter.

2. The data processing method according to claim 1, wherein Performing zero-knowledge proof processing on the membership proof of the log domain data block to obtain zero-knowledge proof information of the membership proof and a first common parameter, specifically including: Using the proof sub-algorithm in the zero-knowledge proof algorithm to process the global common parameter, the membership proof of the log domain data block, the elements of the accumulator at the first update moment, and the value of the accumulator at the first update moment to obtain the zero-knowledge proof information of the membership proof and the first common parameter.

3. The data processing method according to claim 1 or 2, characterized in that, The method further includes: Receiving a data storage request sent by a client. The data storage request includes input data; Performing doubling and supplementing processing on the input data according to a preset replication encryption boundary length to obtain processed input data, and performing segmentation processing on the processed input data to obtain multiple data blocks; Performing replication encryption processing on the multiple data blocks to obtain backup encrypted data and proof auxiliary data corresponding to the backup encrypted data; Performing zero-knowledge proof processing on the backup encrypted data according to the proof auxiliary data to obtain zero-knowledge proof information of the backup encrypted data and a second common parameter; Generating a second transaction request according to the zero-knowledge proof information of the backup encrypted data and the second common parameter, and sending the second transaction request to the client. The second transaction request is used to enable the client to verify the zero-knowledge proof information of the backup encrypted data according to the second common parameter.

4. The data processing method according to claim 3, wherein Perform zero-knowledge proof processing on the backup encrypted data according to the proof auxiliary data to obtain zero-knowledge proof information of the backup encrypted data and a second common parameter, specifically including: Randomly generate a target serial number, select verification data blocks from the backup encrypted data according to the target serial number, and obtain the Merkle proof of the verification data blocks according to the proof auxiliary data; Use the proof sub-algorithm in the zero-knowledge proof algorithm to process the elements of the accumulator at the current moment and the Merkle proof of the verification data blocks to obtain zero-knowledge proof information of the backup encrypted data and a second common parameter; wherein, the second common parameter includes the target serial number and the identifier of the backup encrypted data.

5. The data processing method according to claim 3, characterized in that, Perform replication encryption processing on the multiple data blocks to obtain backup encrypted data and proof auxiliary data corresponding to the backup encrypted data, specifically including: Process the initial label data of each data block using the multi-layer binary depth robust graph algorithm to obtain the label data of each data block at layer; According to the label data of each data block in each layer, encrypt each data block to obtain backup encrypted data; and use the Merkle proof of the backup encrypted data as the proof auxiliary data; Among them, represents the total number of layers of the multi-layer bipartite depth robust graph.

6. The data processing method according to claim 1 or 2, characterized in that, The method further includes: Receive a version rollback request sent by the client, wherein the version rollback request includes a rollback time and a first input data identifier; Delete the log domain data blocks after the rollback time associated with the first input data identifier, and generate a non-membership proof of the deleted log domain data blocks; Perform zero-knowledge proof processing on the non-membership proof to obtain zero-knowledge proof information of the non-membership proof and a third common parameter; Generate a third transaction request according to the zero-knowledge proof information of the non-membership proof and the third common parameter, and send the third transaction request to the client, where the third transaction request is used to enable the client to verify the zero-knowledge proof information of the non-membership proof according to the third common parameter.

7. The data processing method according to claim 6, characterized in that, The step of generating a non-membership proof of the deleted log domain data blocks specifically includes: Execute the delete element method of the accumulator according to the deleted log domain data to obtain the elements of the accumulator at the second update time; Process the elements of the accumulator at the second update time and the elements corresponding to the deleted log domain data blocks according to the non-membership proof generation method of the accumulator to obtain a non-membership proof of the deleted log domain data blocks.

8. The data processing method according to claim 1 or 2, characterized in that, The method further includes: Receive a data reading request sent by the client, wherein the data reading request includes a second input data identifier; Obtain the initial label data of any backup encrypted data corresponding to the second input data identifier, and perform decryption processing on the backup encrypted data according to the decryption algorithm and the initial label data of the backup encrypted data to obtain input data; When there is a log domain data block associated with the second input data identifier in the operation domain, parse the log domain data block to obtain operation information and an operation time; Update the input data according to the operation information and the operation time to obtain updated input data, and send the updated input data to the client.

9. A data processing method based on blockchain, characterized in that, The method is used for a client, and the method includes: Obtain a first input data identifier and operation information, and generate a data modification request according to the first input data identifier and the operation information; the operation information includes modifying the content of the data block with the modification serial number k, deleting the data block with the serial number k, adding a new data block at the end, and adding a data block between the serial number k and the serial number k + 1; Send the data modification request to a consensus node in the blockchain system, where the data modification request is used to enable the consensus node to process the first input data identifier and the operation information, obtain a log domain data block and a membership proof of the log domain data block, perform zero-knowledge proof processing on the membership proof of the log domain data block, obtain zero-knowledge proof information of the membership proof and a first common parameter; and generate a first transaction request according to the zero-knowledge proof information of the membership proof and the first common parameter; where the consensus node includes a data domain storage area and a log domain storage area, and the log domain storage area is used to store log domain data blocks for modifying backup encrypted data; the consensus node processes the first input data identifier and the operation information to obtain the membership proof of the log domain data block, including: executing the add element method of the accumulator according to the log domain data to obtain the elements of the accumulator at the first update moment; processing the elements of the accumulator at the first update moment according to the generate membership proof method of the accumulator to obtain the membership proof of the log domain data block; the membership proof is used to prove that the consensus node modifies the input data according to the operation information; Receive the first transaction request sent by the consensus node, and verify the zero-knowledge proof information of the membership proof according to the first common parameter.

10. The data processing method according to claim 9, characterized in that, The method further includes: Obtain input data, and generate a data storage request according to the input data; Send the data storage request to the consensus node, where the data storage request is used to enable the consensus node to perform doubling supplement processing on the input data according to a preset replication encryption limit length to obtain processed input data, and perform segmentation processing on the processed input data to obtain a plurality of data blocks; perform replication encryption processing on the plurality of data blocks to obtain backup encrypted data and proof auxiliary data corresponding to the backup encrypted data; perform zero-knowledge proof processing on the backup encrypted data according to the proof auxiliary data to obtain zero-knowledge proof information of the backup encrypted data and a second common parameter; and generate a second transaction request according to the zero-knowledge proof information of the backup encrypted data and the second common parameter; Receive the second transaction request sent by the consensus node, and verify the zero-knowledge proof information of the backup encrypted data according to the second common parameter.

11. The data processing method according to claim 9 or 10, characterized in that, The method further includes: Obtain a return moment and a first input data identifier, and generate a version return request according to the return moment and the first input data identifier; Send a version rollback request to the consensus node, where the version rollback request is used to cause the consensus node to delete the log domain data blocks after the rollback time and generate a non-member proof of the deleted log domain data blocks; perform zero-knowledge proof processing on the non-member proof to obtain zero-knowledge proof information of the non-member proof and a third public parameter; and generate a third transaction request according to the zero-knowledge proof information of the non-member proof and the third public parameter. Receive the third transaction request sent by the consensus node and verify the zero-knowledge proof information of the non-member proof according to the third public parameter.

12. The data processing method according to claim 9 or 10, characterized in that The method further includes: Obtain a second input data identifier and generate a data reading request according to the second input data identifier. Send the data reading request to the consensus node, where the data reading request is used to cause the consensus node to obtain the initial tag data of the backup encrypted data corresponding to the second input data identifier, decrypt the backup encrypted data according to the decryption algorithm and the initial tag data of the backup encrypted data to obtain the input data; and when there is a log domain data block associated with the second input data identifier in the operation domain, parse the associated log domain data block to obtain operation information and an operation time; process the input data according to the operation information and the time to obtain updated input data. Receive the updated input data sent by the consensus node.

13. A data processing method based on blockchain, characterized in that, The method is applied to a proof node, and the method includes: Receive zero-knowledge proof information sent by each consensus node in the blockchain system and the status information of the consensus node when each zero-knowledge proof information is generated; where the consensus node includes a data domain storage area and a log domain storage area, and the log domain storage area is used to store log domain data blocks for modifying backup encrypted data; the consensus node receives a data modification request sent by a client, where the data modification request includes a first input data identifier and operation information, and the operation information includes the content of the data block with the modification serial number k, deleting the data block with the serial number k, adding a new data block at the end, and adding a data block between the serial numbers k and k + 1; process the first input data identifier and the operation information to obtain a log domain data block and a member proof of the log domain data block; specifically including: execute the add element method of the accumulator according to the log domain data to obtain the element of the accumulator at the first update time; process the element of the accumulator at the first update time according to the generate member proof method of the accumulator to obtain the member proof of the log domain data block; the member proof is used to prove that the consensus node modifies the input data according to the operation information; perform zero-knowledge proof processing on the member proof of the log domain data block to obtain zero-knowledge proof information of the member proof. Perform recursive aggregation processing on each zero-knowledge proof information and the status information of the consensus node when each zero-knowledge proof information is generated to obtain root zero-knowledge proof information and root status information. Generate a fourth transaction request based on the root zero-knowledge proof information and the root status information; Send the fourth transaction request to the consensus nodes in the blockchain system, where the fourth transaction request is used to enable the blockchain system to store the root zero-knowledge proof according to the root status information; Among them, the zero-knowledge proof information includes any one or a combination of zero-knowledge proof information of member proof, zero-knowledge proof information of non-member proof, and zero-knowledge proof information of backup encrypted data.

14. The data processing method according to claim 13, wherein The recursive aggregation process of the respective zero-knowledge proof information and the status information of the consensus nodes when generating the respective zero-knowledge proof information to obtain the root zero-knowledge proof information and the root status information specifically includes: Pairwise combine the respective zero-knowledge proof information to obtain a plurality of sub-combinations; for each sub-combination, process the statuses of the consensus nodes corresponding to the two zero-knowledge proof information in the sub-combination to obtain the combined status of each sub-combination; For each sub-combination, perform zero-knowledge proof on the two zero-knowledge proof information in the sub-combination, the statuses of the consensus nodes corresponding to the two zero-knowledge proof information in the sub-combination, and the combined status of the sub-combination to obtain the zero-knowledge proof information of each sub-combination; Repeat the steps of pairwise grouping the zero-knowledge proof information of each sub-combination to obtain a plurality of parent combinations, for each parent combination, process the statuses of the consensus nodes corresponding to the two zero-knowledge proof information in the parent combination to obtain the combined status of each parent combination; for each parent combination, perform zero-knowledge proof on the two zero-knowledge proof information in the parent combination, the combined status of the sub-combinations in the parent combination, and the combined status of the parent combination to obtain the zero-knowledge proof information of each parent combination; until the number of parent combinations is 1, take the zero-knowledge proof information of the last parent combination obtained in the last loop as the root zero-knowledge proof information, and take the combined status of the last parent combination obtained in the last loop as the root status information.

15. An electronic device, comprising: A processor and a memory communicatively connected to the processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory to implement the blockchain-based data processing method according to any one of claims 1 to 8, any one of claims 9 to 12, or claim 13 or 14.

16. A computer-readable storage medium, characterized in that, Computer-executable instructions are stored in the computer-readable storage medium, and when the computer-executable instructions are executed by the processor, they are used to implement the blockchain-based data processing method according to any one of claims 1 to 8, any one of claims 9 to 12, or claim 13 or 14.

Images