Blockchain state mapping method, system, computer device and storage medium

Abstract

The present invention discloses a blockchain state mapping method, system, computer equipment and storage medium, and relates to blockchain technology. When a second blockchain receives state change proof data sent by a second type of node device, it calls a locally stored smart contract, verifies the state change proof data through the smart contract, and obtains a verification result. If the verification result is passed, the state change data of the first blockchain is obtained, and the state change data is mapped locally, ensuring that the state on the first blockchain can be correctly mapped to the second blockchain. Any user and application on the second blockchain can access the trusted state data of the first blockchain through the smart contract. The first blockchain can merge multiple state changes together each time, and the data submitted to the second blockchain only includes the increment of the state data and a zero-knowledge proof value, which not only reduces the state mapping cost but also improves the mapping efficiency.

Description

Technical Field

[0001] The present invention relates to the technical field of blockchain security mechanisms, and in particular to a blockchain state mapping method, system, computer device and storage medium. Background Art

[0002] Blockchain is a decentralized protocol system based on a variety of cryptography, P2P peer-to-peer network, consensus mechanism and other technologies. Blockchain has designed a decentralized trust mechanism, so that the data on it has the characteristics of high credibility, non-tampering and non-forgeability. At present, there are thousands of public chains in the world. Each blockchain is equivalent to an independent system cluster. Systems of different blockchains cannot interact directly, and the state databases are also isolated from each other, just like isolated islands of users and data.

[0003] There are currently multiple initiatives around the world trying to increase the connectivity of different blockchains.

[0004] The first is based on the intermediary agent mechanism, where the intermediary agent builds the bridge between chains, and monitors and operates the state through the blockchain API to achieve state mapping between different chains. A serious problem with this solution is that it must rely on a reliable intermediary agent, which brings centralized trust risks and stability risks. If the chain bridge operator does evil, the service system is abnormal or attacked, it will lead to bridge failure and economic losses.

[0005] The second is to use hash time lock technology or modify the bottom layer of the two chains at the same time to customize the binding, and realize the mapping of the amount or transaction status between the two blockchains. This solution is targeted at a single scenario (it can only realize the mapping of the amount of a specific customized chain), the infrastructure cost is high (it is necessary to establish an exchange service for each usage scenario), and the usage cost is also high (each time the amount status mapping of an account requires a pairing, waiting, and interaction process).

[0006] The third method is to let all validators of one chain vote on the mapped chain, and then the smart contract verifies the vote. This solution brings a lot of work to each validator, and each on-chain vote consumes a lot of on-chain resources, which is very costly and inefficient. Summary of the invention

[0007] The embodiments of the present invention provide a blockchain state mapping method, system, computer device and storage medium, which are intended to solve the problems in the prior art that the state mapping of different blockchains requires a reliable bridge operator, or the bottom layers of the two chains are customized and bound, or all validators of one of the chains are required to vote on the mapped chain, and then the votes are verified by a smart contract, resulting in high implementation costs and low mapping efficiency.

[0008] In a first aspect, an embodiment of the present invention provides a blockchain state mapping method, which is applied to a second type of node device, where the second type of node device is any node device, and includes:

[0009] Receiving state change data sent by the first blockchain, and obtaining the verifier signature data and zero-knowledge circuit on the first blockchain;

[0010] Generate state change proof data from the state change data through the zero-knowledge circuit; and

[0011] The state change proof data is sent to a second blockchain; wherein the second blockchain and the first blockchain are different blockchains.

[0012] In a second aspect, an embodiment of the present invention provides a blockchain state mapping method, which is applied to a second blockchain and includes:

[0013] Receiving state change proof data sent by the second type node device, and calling the locally stored smart contract; wherein the second type node device is used to generate state change proof data according to the received state change data sent by the first blockchain and the zero-knowledge circuit, and send the state change proof data to the second blockchain; the second blockchain and the first blockchain are different blockchains;

[0014] Verifying the state change proof data through a smart contract to obtain a verification result; and

[0015] If the verification result is passed, the state transformation data of the first blockchain is obtained, and the state transformation data is mapped locally.

[0016] In a third aspect, an embodiment of the present invention provides a blockchain state mapping method, which is applied to a first type of node device, where the first type of node device is any node device and is not the same node device as the second type of node device, and includes:

[0017] Receiving parameter generator code data sent by the first blockchain, generating random parameters according to the parameter generator code data, and sending the random parameters to the first blockchain; wherein the parameter generator code data is constructed by the logic of generating random numbers by a zero-knowledge circuit in the first blockchain; and

[0018] If a zero-knowledge proof trusted start notification corresponding to the random parameter is received from the first blockchain, a first type of verifier marking is performed and the corresponding first type of signature data is sent to the first blockchain.

[0019] In a fourth aspect, an embodiment of the present invention provides a blockchain state mapping method, which is applied to a first blockchain and includes:

[0020] Sending the parameter generator code data to a randomly selected first type of node device; wherein the first type of node device is used to generate random parameters according to the parameter generator code data sent by the first blockchain and send the random parameters to the first blockchain for trusted startup;

[0021] If a random parameter sent by a first type of node device is received and the receiving time and the total number of received random parameters meet the preset valid data receiving conditions, a zero-knowledge circuit corresponding to the parameter generator code data is trusted started;

[0022] If a data state change is detected, the corresponding state transformation data is obtained, and the state transformation data is sent to a randomly selected second type of node device; wherein the second type of node device is used to generate state transformation proof data based on the received state transformation data sent by the first blockchain and the zero-knowledge circuit, and send the state transformation proof data to the second blockchain;

[0023] If a mapping instruction sent by the second blockchain is detected, the state transformation data is mapped to the second blockchain.

[0024] In a fifth aspect, an embodiment of the present invention provides a blockchain state mapping system, comprising: a first type of node device, a second type of node device, a first blockchain and a second blockchain, the second type of node device is used to execute the blockchain state mapping method described in the first aspect above, the second blockchain is used to execute the blockchain state mapping method described in the second aspect above, the first type of node device is used to execute the blockchain state mapping method described in the third aspect above, and the first blockchain is used to execute the blockchain state mapping method described in the fourth aspect above.

[0025] In the sixth aspect, an embodiment of the present invention further provides a computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, the blockchain state mapping method described in the first aspect is implemented, or the blockchain state mapping method described in the second aspect is implemented, or the blockchain state mapping method described in the third aspect is implemented, or the blockchain state mapping method described in the fourth aspect is implemented.

[0026] In the seventh aspect, an embodiment of the present invention further provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the processor causes the processor to execute the blockchain state mapping method described in the first aspect above, or execute the blockchain state mapping method described in the second aspect above, or execute the blockchain state mapping method described in the third aspect above, or execute the blockchain state mapping method described in the fourth aspect above.

[0027] The embodiment of the present invention provides a blockchain state mapping method, system, computer device and storage medium, wherein when the second blockchain receives the state change proof data sent by the second type node device, it calls the locally stored smart contract, verifies the state change proof data through the smart contract, and obtains the verification result. If the verification result is passed, the state change data of the first blockchain is obtained, and the state change data is mapped locally, ensuring that the state on the first blockchain can be correctly mapped to the second blockchain. Any user and application on the second blockchain can access the trusted state data of the first blockchain through the smart contract. The first blockchain can merge multiple state changes together each time, and the data submitted to the second blockchain only includes the increment of the state data and a zero-knowledge proof value, which not only reduces the cost of state mapping, but also improves the mapping efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other accompanying drawings can be obtained based on these accompanying drawings without paying any creative work.

[0029] Figure 1 A schematic diagram of an application scenario of the blockchain state mapping method provided by an embodiment of the present invention;

[0030] Figure 2 A flowchart of a blockchain state mapping method provided by an embodiment of the present invention;

[0031] Figure 3 Another schematic diagram of the process of the blockchain state mapping method provided by an embodiment of the present invention;

[0032] Figure 4 Another schematic diagram of the process of the blockchain state mapping method provided by an embodiment of the present invention;

[0033] Figure 5 Another schematic diagram of the process of the blockchain state mapping method provided by an embodiment of the present invention;

[0034] Figure 6 A schematic block diagram of a blockchain state mapping system provided by an embodiment of the present invention;

[0035] Figure 7 A schematic block diagram of a computer device provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0036] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0037] It should be understood that when used in this specification and the appended claims, the terms "include" and "comprises" indicate the presence of described features, integers, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or combinations thereof.

[0038] It should also be understood that the terms used in this specification of the present invention are only for the purpose of describing specific embodiments and are not intended to limit the present invention. As used in the specification of the present invention and the appended claims, unless the context clearly indicates otherwise, the singular forms "a", "an" and "the" are intended to include plural forms.

[0039] It should be further understood that the term "and / or" used in the present description and the appended claims refers to any and all possible combinations of one or more of the associated listed items, and includes these combinations.

[0040] In order to more clearly understand the technical solution of this application, the following is a detailed introduction to the execution entities involved. The following is a description of the technical solution from four execution entities.

[0041] The first type of node device may be a node device on the first blockchain, or a node device on the second blockchain, or may be neither a node device on the first blockchain nor a node device on the second blockchain. The first type of node device is any node device, and the first type of node device is used to generate random parameters according to the parameter generator code data sent by the first blockchain and send it to the first blockchain for trusted startup. That is, multiple first type node devices can receive the unified program code provided by the operator corresponding to the first blockchain, and after running locally, upload the running results (the running result is a string containing many numbers) to the first blockchain to trigger the zero-knowledge circuit in the first blockchain for trusted startup.

[0042] The second type of node device may be a node device on the first blockchain, or a node device on the second blockchain, or may be neither a node device on the first blockchain nor a node device on the second blockchain. The second type of node device is another arbitrary node device and is not the same node device as the first type of node device; the second type of node device is used to generate state change proof data based on the state change data and zero-knowledge circuit received and sent by the first blockchain and send it to the second blockchain. That is, assuming that any second type of node device obtains state change data and verifier signature data from the first blockchain, it can be uploaded to the second blockchain for smart contract verification.

[0043] A first blockchain has a zero-knowledge circuit deployed thereon (the first type of node device, the second type of node device, and the second blockchain can all obtain the zero-knowledge circuit from the first blockchain), wherein the state change data therein can be transmitted across the chain to the second blockchain, so as to realize the cross-chain mapping of the state data from the first blockchain to the second blockchain.

[0044] The second blockchain can receive and verify the state change data and zero-knowledge proof sent by the second type of node device, and receive the state data from the cross-chain mapping of the first blockchain after the state change data and zero-knowledge proof are verified.

[0045] See also Figure 1 and Figure 2 , Figure 1 A schematic diagram of an application scenario of the blockchain state mapping method provided by an embodiment of the present invention; Figure 2 A flowchart of a blockchain state mapping method provided in an embodiment of the present invention is provided. The blockchain state mapping method is applied to a first type of node device, and the method is executed by application software installed in the first type of node device.

[0046] like Figure 2 As shown, the method includes steps S101 to S102.

[0047] S101. Receive parameter generator code data sent by the first blockchain, generate random parameters according to the parameter generator code data, and send the random parameters to the first blockchain; wherein the parameter generator code data is constructed by the logic of generating random numbers by a zero-knowledge circuit in the first blockchain.

[0048] In this embodiment, when the project party of the first blockchain enables the first blockchain to quickly perform zero-knowledge proof trusted startup, the first blockchain can first open the code of the zero-knowledge circuit and the parameter generator code data. After that, the project party of the first blockchain randomly selects some first-type node devices (for example, randomly selects 100 first-type node devices), and the selected first-type node devices download and receive the parameter generator code data sent by the first blockchain from the first blockchain.

[0049] At this time, the selected first type node devices receive the parameter generator code data and run it locally to generate random parameters. These first type node devices will send the random parameters to the first blockchain.

[0050] The parameter generator code data is a set of algorithms that include the logic for generating random numbers at the startup stage, while the zero-knowledge circuit includes not only the parameter generator code data but also the logic for generating proof data at the proof stage.

[0051] In one embodiment, step S101 includes:

[0052] Generate private data and public data according to the parameter generator code data;

[0053] The private data and the private data in the public data are deleted to obtain a random parameter.

[0054] That is to say, more specifically, after each first-type node device runs the parameter generator code data locally, it generates private data and public data. At this time, each parameter generator code data deletes the private data and the private data in the public data and sends it to the first blockchain as a random parameter.

[0055] By deleting private data, it is also to ensure that there are no security risks in zero-knowledge, so as to ensure that zero-knowledge proof trusted startup is safe.

[0056] S102: If a zero-knowledge proof trusted start notification corresponding to the random parameter is received from the first blockchain, a first type of verifier marking is performed and the corresponding first type of signature data is sent to the first blockchain.

[0057] In this embodiment, after the selected first type node device sends the generated random parameters to the first blockchain, it is necessary to detect whether the first blockchain has received the zero-knowledge proof trusted startup notification corresponding to the random parameters. If it is detected that the first blockchain has received the zero-knowledge proof trusted startup notification corresponding to the random parameters, the first type verifier mark is performed in the selected first type node device and the corresponding first type signature data is sent to the first blockchain. That is, the role of the above-mentioned selected first type node device is to participate in the zero-knowledge proof trusted startup and upload it to the first blockchain after signing, and does not participate in other processes. When the first blockchain receives the first type signature data generated by multiple first type node devices according to the local signature algorithm, it can count how many valid first type node devices have participated in the zero-knowledge proof trusted startup process. Among them, the local signature algorithm of the first type of node device can specifically be the Bls signature algorithm (the Bls signature algorithm is a signature scheme originally proposed by Stanford University professor Dan Boneh and others in 2001) or the Schnorr signature algorithm (the Schnorr signature algorithm was originally proposed by German cryptographer Claus Schnorr in 2008). The device unique identification code of the first type of node device can be used as the input of the signature algorithm to obtain the first type of signature data.

[0058] Please continue reading Figure 1 and Figure 3 , Figure 3 Another flowchart of a blockchain state mapping method provided in an embodiment of the present invention is provided. The blockchain state mapping method is applied to a first blockchain, and the method is executed by application software installed in the first blockchain.

[0059] like Figure 3 As shown, the method includes steps S201 to S204.

[0060] S201. Send parameter generator code data to a randomly selected first type node device.

[0061] In this embodiment, the project party of the first blockchain randomly selects some first-type node devices to send parameter generator code data, and after completing the random selection of the first-type node devices, the parameter generator code data is sent to the randomly selected first-type node devices. Among them, the parameter generator code data is a set of algorithms that include the logic of generating random numbers in the startup phase.

[0062] S202: If a random parameter sent by a first type of node device is received and the receiving time and the total number of received random parameters meet the preset valid data receiving conditions, a zero-knowledge circuit corresponding to the parameter generator code data is trusted started.

[0063] In this embodiment, after the first type of node device receives the parameter generator code data and runs it locally to generate random parameters and send them to the first blockchain, the first blockchain will determine whether the reception time and the total number of received random parameters meet the pre-set valid data reception conditions, thereby determining whether the zero-knowledge circuit corresponding to the parameter generator code data has been trusted started.

[0064] For example, if 100 first-type node devices are randomly selected, the receiving time can be set to within 2 days of the corresponding sending time of the parameter generator code data sent by the first blockchain, and the total number of random parameters received in the first blockchain exceeds 1 / 2 of the total number of selected first-type node devices (that is, at least 51 selected first-type node devices have fed back random parameters). When at least 51 selected first-type node devices have fed back random parameters within 2 days starting from the receiving time corresponding to the sending time of the parameter generator code data sent by the first blockchain, it can be determined that the valid data reception condition is met, and the zero-knowledge circuit corresponding to the parameter generator code data in the first blockchain can be trusted to start. In this way, cheating behavior of the project issued by the first blockchain can be effectively avoided, ensuring that the first blockchain is trusted to start.

[0065] S203: If a data state change is detected, obtain corresponding state change data, and send the state change data to a randomly selected second type node device.

[0066] In this embodiment, once the data state changes in the first blockchain, in order to quickly map it to the second blockchain, it is necessary to randomly select some second-type node devices (these second-type node devices are different from the first-type node devices, some users may be repeated, or the two may not be repeated at all), and the state change data is processed through the zero-knowledge circuit on the second-type node device to obtain a state change proof data corresponding to the state change data to be delivered to the second blockchain for verification to prove the validity of the state change data.

[0067] Specifically, the state change data on the first blockchain is recorded as MapData, which mainly includes data items such as StateDiff (indicating the state difference value), PreStateHash (indicating the initial state hash value), and ProStatehash (indicating the final state hash value). If the state change includes changes to the verifier itself, MapData also needs to include new PubKeysRoot data (PubKeysRoot represents the Merkle tree root constructed by the public keys of all verifiers).

[0068] S204. If a mapping instruction sent by the second blockchain is detected, the state transformation data is mapped to the second blockchain.

[0069] In this embodiment, when the first blockchain detects the mapping instruction sent by the second blockchain, the state transformation data is accurately mapped to the second blockchain, and any user and application on the second blockchain can access the trusted state transformation data of the first blockchain through the smart contract.

[0070] Please continue reading Figure 1 and Figure 4 , Figure 4 Another flow chart of the blockchain state mapping method provided for an embodiment of the present invention, wherein the blockchain state mapping method is applied to a second type of node device, and the method is executed by application software installed in the second type of node device.

[0071] like Figure 4 As shown, the method includes steps S301 to S303.

[0072] S301. Receive state change data sent by the first blockchain, and obtain the verifier signature data and zero-knowledge circuit on the first blockchain.

[0073] In this embodiment, after the second type of node device receives the state change data sent by the first blockchain, it also needs to obtain the zero-knowledge circuit and verifier signature data on the first blockchain, and use a dedicated zero-knowledge circuit to generate state change proof data.

[0074] S302: Generate state change proof data from the state change data through the zero-knowledge circuit.

[0075] In this embodiment, when the state change proof data is generated by inputting the state change data into the zero-knowledge circuit, the state change data includes the following data items in addition to the above-mentioned data items such as StateDiff, PreStateHash, and ProStatehash:

[0076] MapDataHash (which is a public input), which represents the hash value of the state transformation data (MapData);

[0077] PubKeysRoot (which is a public input) represents the Merkle root of all validator public keys on the first blockchain;

[0078] AggSig (which is a privacy input) represents the aggregate signature of the validator on the first blockchain on the state transformation data (MapData);

[0079] SignerBits (a privacy input) that identifies which validators participated in the aggregate signature;

[0080] AllPubKeys (which is a privacy input) represents the set of all validator public keys on the first blockchain.

[0081] When the state change data composed of the above-listed data items are input into the zero-knowledge circuit, the state change proof data can be quickly obtained.

[0082] In one embodiment, step S302 includes:

[0083] Obtain the Merkle tree root constructed by all validator public keys on the first blockchain and the set of all validator public keys, and assert the set of all validator public keys through the Merkle tree root to determine whether the Merkle tree root is correct;

[0084] If the Merkle tree root is correct, obtain the aggregate signature on the first blockchain, and determine whether the proportion of signatories corresponding to the signature mark in the aggregate signature exceeds a preset proportion threshold;

[0085] If the proportion of signatories in the aggregate signature exceeds the threshold, all validator public keys are aggregated to obtain an aggregate public key;

[0086] Obtaining the aggregate signature, combining the aggregate public key, the aggregate signature and the hash value of the state change data, and performing signature verification to obtain a verification result;

[0087] If the verification result corresponds to passing the signature verification, the state change proof data is generated according to the hash value of the state change data, the Merkle tree root, the aggregate signature, the aggregate signature, the signature mark and the aggregate public key.

[0088] In this embodiment, the role of the zero-knowledge circuit is to generate a proof data according to the input parameters without generating an output result to verify the validity of the data. The specific process of generating the state change proof data by the zero-knowledge circuit in each selected second type node device is as follows:

[0089] 1) Verify the correctness of PubKeysRoot: Assert(MerkleRoot(AllpubKeys) == PubKeysRoot)

[0090] 2) Determine whether the number of signers meets the consensus requirement: Assert(Count(SignerBits)>Count(AllPubKeys)*(2 / 3));

[0091] 3) Calculate the aggregate public key: AggKey = BuildAggKey (AllPubKeys, SignerBits);

[0092] 4) Aggregate signature verification: Assert(VerifySig(MapDataHash,AggSig,AggKey)).

[0093] Among them, the calculation of the aggregate public key in step 3) can adopt the Bls signature algorithm (the Bls signature algorithm is a signature scheme originally proposed by Stanford University professor Dan Boneh and others in 2001) or the Schnorr signature algorithm (the Schnorr signature algorithm was originally proposed by German cryptographer Claus Schnorr in 2008).

[0094] The VerifySig() operation used in the aggregate signature verification in step 4) also corresponds to a signature algorithm, for example, the Bls signature algorithm or the Schnorr signature algorithm used in step 3).

[0095] At this time, each selected second-type node device obtains the above-mentioned proof data based on the zero-knowledge circuit, and then sends it to the second blockchain for smart contract verification. That is, after any user terminal is selected, it can generate zero-knowledge proof data (Proof = GenerateProof (MapDataHash, PubKeyRoot, AggSig, SignerBits, AllPubKeys)) based on the public data of the first blockchain (such as the data corresponding to the zero-knowledge circuit) and the state transformation data on the first blockchain. The zero-knowledge circuit can ensure that the input data is correct and is the state transformation data that has been signed and authenticated by most of the verifiers (more than 2 / 3) on the first blockchain and reached a consensus.

[0096] S303. Send the state change proof data to the second blockchain.

[0097] In this embodiment, after obtaining the state change proof data, the second type of node device sends the state change proof data to the second blockchain for smart contract verification.

[0098] Please continue reading Figure 1 and Figure 5 , Figure 5 Another flowchart of a blockchain state mapping method provided in an embodiment of the present invention is provided. The blockchain state mapping method is applied to a second blockchain, and the method is executed by application software installed in the second blockchain.

[0099] like Figure 5As shown, the method includes steps S401 to S403.

[0100] S401. Receive state change proof data sent by the second type of node device and call the locally stored smart contract.

[0101] In this embodiment, the project of the first blockchain will also deploy the smart contract corresponding to the zero-knowledge circuit on the second blockchain in the initial stage, and perform the following initialization actions:

[0102] ZkpParams, which represents the random parameters generated by the Trust Setup phase of the zero-knowledge circuit;

[0103] InitStates, representing the initial state data of the first blockchain;

[0104] StateHash, representing the state hash value of the first blockchain;

[0105] PubKeysRoot represents the Merkle tree root constructed by the public keys of all validators on the first blockchain.

[0106] When the second blockchain receives the state change proof data sent by the second type of node device, it can call the locally stored smart contract to perform subsequent verification process.

[0107] S402: Verify the state change proof data through a smart contract to obtain a verification result.

[0108] In one embodiment, step S402 includes:

[0109] Obtaining a state hash value corresponding to the state change proof data, and determining whether the state hash value passes verification;

[0110] If the state hash value passes the verification, obtain the state change data hash value corresponding to the state change proof data;

[0111] Determining whether the state change proof data passes zero-knowledge verification;

[0112] If the state change proof data passes the zero-knowledge verification, a verification result of passing the verification is obtained;

[0113] If the state change proof data fails the zero-knowledge verification, a verification result indicating that the verification failed is obtained.

[0114] In this embodiment, the specific process of verifying the state change proof data through the smart contract is as follows:

[0115] 11) State hash verification: Require(MapData.PreStateHash == StateHash);

[0116] 12) Calculate the hash value of MapData: Require(MapDataHash == Hash(MapData));

[0117] 13) Zero-knowledge verification: Require(VerifyProof(Proof,MapDataHash,PubKeysRoot)).

[0118] That is, first obtain the state hash value corresponding to the state change proof data for state hash verification. If the state hash verification passes, continue to obtain the state change data hash value corresponding to the state change proof data. Finally, perform zero-knowledge verification based on the state change proof data, the state change data hash value and the Merkle tree root. If the state change proof data passes the zero-knowledge verification, a verification result of passing the verification is obtained; if the state change proof data fails the zero-knowledge verification, a verification result of failing the verification is obtained.

[0119] S403: If the verification result is passed, obtain the state transformation data of the first blockchain, and map the state transformation data to the local.

[0120] In this embodiment, if the verification result is passed, it is necessary to execute state mapping and update the state hash. Specifically, the state transformation data of the first blockchain is mapped to the local through the ApplyState(MapData) instruction, and then the state hash of the state transformation data is updated through the stateHash=MapData.ProStateHash operation.

[0121] Since any second type node device can submit (MapData, Proof) to the smart contract, the smart contract will verify the validity of the submitted state transformation data and perform the state mapping operation.

[0122] The technical solution of this application has the following technical benefits:

[0123] A1) This solution is decentralized because it does not require any trusted third party to perform state mapping operations. Anyone can collect information from the first blockchain and submit it to the second blockchain. The zero-knowledge proof ensures that the data used to generate the proof must be correct, and the smart contract ensures that the submitted state data is proven to be correct.

[0124] A2) The state mapping of this scheme is universal because the mapped state data (MapData) can contain any state transformation information, such as account balance, account type, application status, validator set, etc., which can be mapped as part of the state data without changing the proof and verification logic.

[0125] A3) This solution is highly scalable. After implementing the state mapping of the first blockchain -> the second blockchain, it can be directly applied to any number of scenarios such as the first blockchain -> the third blockchain, the first blockchain -> the fourth blockchain, etc. The consensus logic of the first blockchain itself does not need to be changed. It only needs to deploy a smart contract on other blockchains such as the third blockchain and the fourth blockchain to realize the mapping of the state of the first blockchain to any other blockchain. At the same time, there is no strict restriction on the type of each chain. Heterogeneous blockchains and blockchains with different consensus mechanisms can be mapped.

[0126] A4) This solution is low-cost and efficient, because the first blockchain can merge multiple state changes together each time, and the data submitted to the second blockchain is only the increment of state data and a zero-knowledge proof value, which greatly reduces the number of operations and saves the resource consumption of the second blockchain for verification and mapping operations. At the same time, anyone can automate the entire mapping process to greatly improve the efficiency of execution.

[0127] This method ensures that the state on the first blockchain can be correctly mapped to the second blockchain. Any user and application on the second blockchain can access the trusted state data of the first blockchain through the smart contract. The first blockchain can merge multiple state changes together each time, and the data submitted to the second blockchain only includes the increment of the state data and a zero-knowledge proof value, which not only reduces the cost of state mapping, but also improves the mapping efficiency.

[0128] The embodiment of the present invention also provides a blockchain state mapping system, which includes a first type of node device, a second type of node device, a first blockchain and a second blockchain, the first type of node device is used to execute the embodiment recorded in steps S101 to S102 of the aforementioned blockchain state mapping method, the first blockchain is used to execute the embodiment recorded in steps S201 to S204 of the aforementioned blockchain state mapping method, the second type of node device is used to execute the embodiment recorded in steps S301 to S303 of the aforementioned blockchain state mapping method, and the second blockchain is used to execute the embodiment recorded in steps S401 to S403 of the aforementioned blockchain state mapping method. Specifically, please refer to Figure 6 , Figure 6 It is a schematic block diagram of a blockchain state mapping system provided by an embodiment of the present invention.

[0129] like Figure 6 As shown, the blockchain state mapping system 10 includes: a first type node device 100, a first blockchain 200, a second type node device 300 and a second blockchain 400.

[0130] The first type node device 100 includes: a random parameter sending unit 101 and a process end control unit 102.

[0131] The random parameter sending unit 101 is used to receive the parameter generator code data sent by the first blockchain, generate random parameters according to the parameter generator code data, and send the random parameters to the first blockchain; wherein the parameter generator code data is constructed by the logic of generating random numbers by the zero-knowledge circuit in the first blockchain.

[0132] In this embodiment, when the project party of the first blockchain enables the first blockchain to quickly perform zero-knowledge proof trusted startup, the first blockchain can first open the code of the zero-knowledge circuit and the parameter generator code data. After that, the project party of the first blockchain randomly selects some first-type node devices (for example, randomly selects 100 first-type node devices), and the selected first-type node devices download and receive the parameter generator code data sent by the first blockchain from the first blockchain.

[0133] At this time, the selected first type node devices receive the parameter generator code data and run it locally to generate random parameters. These first type node devices will send the random parameters to the first blockchain.

[0134] The parameter generator code data is a set of algorithms that include the logic for generating random numbers at the startup stage, while the zero-knowledge circuit includes not only the parameter generator code data but also the logic for generating proof data at the proof stage.

[0135] In one embodiment, the random parameter sending unit 101 includes:

[0136] A multi-type data generation unit, used to generate private data and public data according to the parameter generator code data;

[0137] A designated data deletion unit is used to delete the private data and the private data in the public data to obtain a random parameter.

[0138] That is to say, more specifically, after each first-type node device runs the parameter generator code data locally, it generates private data and public data. At this time, each parameter generator code data deletes the private data and the private data in the public data and sends it to the first blockchain as a random parameter.

[0139] By deleting private data, it is also to ensure that there are no security risks in zero-knowledge, so as to ensure that zero-knowledge proof trusted startup is safe.

[0140] The process ends and the control unit 102 is used to perform a first type of verifier marking and send the corresponding first type of signature data to the first blockchain if a zero-knowledge proof trusted start notification corresponding to the random parameter is received from the first blockchain.

[0141] In this embodiment, after the selected first type node device sends the generated random parameters to the first blockchain, it is necessary to detect whether the first blockchain has received the zero-knowledge proof trusted startup notification corresponding to the random parameters. If it is detected that the first blockchain has received the zero-knowledge proof trusted startup notification corresponding to the random parameters, the first type verifier mark is performed in the selected first type node device and the corresponding first type signature data is sent to the first blockchain. That is, the role of the above-mentioned selected first type node device is to participate in the zero-knowledge proof trusted startup and not to participate in other processes.

[0142] Among them, the first blockchain 200 includes: a generator code sending unit 201, a trusted startup unit 202, a state change data sending unit 203 and a mapping unit 204.

[0143] The generator code sending unit 201 is used to send parameter generator code data to a randomly selected first type node device.

[0144] In this embodiment, the project party of the first blockchain randomly selects some first-type node devices to send parameter generator code data, and after completing the random selection of the first-type node devices, the parameter generator code data is sent to the randomly selected first-type node devices. Among them, the parameter generator code data is a set of algorithms that include the logic of generating random numbers in the startup phase.

[0145] The trusted startup unit 202 is used to perform a trusted startup of the zero-knowledge circuit corresponding to the parameter generator code data if a random parameter sent by the first type of node device is received and the reception time and the total number of received random parameters meet the preset valid data reception conditions.

[0146] In this embodiment, after the first type of node device receives the parameter generator code data and runs it locally to generate random parameters and send them to the first blockchain, the first blockchain will determine whether the reception time and the total number of received random parameters meet the pre-set valid data reception conditions, thereby determining whether the zero-knowledge circuit corresponding to the parameter generator code data has been trusted started.

[0147] For example, if 100 first-type node devices are randomly selected, the receiving time can be set to within 2 days of the corresponding sending time of the parameter generator code data sent by the first blockchain, and the total number of random parameters received in the first blockchain exceeds 1 / 2 of the total number of selected first-type node devices (that is, at least 51 selected first-type node devices have fed back random parameters). When at least 51 selected first-type node devices have fed back random parameters within 2 days starting from the receiving time corresponding to the sending time of the parameter generator code data sent by the first blockchain, it can be determined that the valid data reception condition is met, and the zero-knowledge circuit corresponding to the parameter generator code data in the first blockchain can be trusted to start. In this way, cheating behavior of the project issued by the first blockchain can be effectively avoided, ensuring that the first blockchain is trusted to start.

[0148] The state change data sending unit 203 is used to obtain corresponding state change data if a data state change is detected, and send the state change data to a randomly selected second type node device.

[0149] In this embodiment, once the data state changes in the first blockchain, in order to quickly map it to the second blockchain, it is necessary to randomly select some second-type node devices (these second-type node devices are different from the first-type node devices, some users may be repeated, or the two may not be repeated at all), and the state change data is processed through the zero-knowledge circuit on the second-type node device to obtain a state change proof data corresponding to the state change data to be delivered to the second blockchain for verification to prove the validity of the state change data.

[0150] Specifically, the state change data on the first blockchain is recorded as MapData, which mainly includes data items such as StateDiff (indicating the state difference value), PreStateHash (indicating the initial state hash value), and ProStatehash (indicating the final state hash value). If the state change includes changes to the verifier itself, MapData also needs to include new PubKeysRoot data (PubKeysRoot represents the Merkle tree root constructed by the public keys of all verifiers).

[0151] The mapping unit 204 is used to map the state transformation data to the second blockchain if a mapping instruction sent by the second blockchain is detected.

[0152] In this embodiment, when the first blockchain detects the mapping instruction sent by the second blockchain, the state transformation data is accurately mapped to the second blockchain, and any user and application on the second blockchain can access the trusted state transformation data of the first blockchain through the smart contract.

[0153] The second type node device 300 includes: a state change data receiving unit 301 , a state change proof data generating unit 302 , and a state change proof data sending unit 303 .

[0154] The state change data receiving unit 301 is used to receive the state change data sent by the first blockchain and obtain the verifier signature data and zero-knowledge circuit on the first blockchain.

[0155] In this embodiment, after the second type of node device receives the state change data sent by the first blockchain, it also needs to obtain the zero-knowledge circuit and verifier signature data on the first blockchain, and use a dedicated zero-knowledge circuit to generate state change proof data.

[0156] The state change proof data generating unit 302 is used to generate state change proof data by passing the state change data through the zero-knowledge circuit.

[0157] In this embodiment, when the state change proof data is generated by inputting the state change data into the zero-knowledge circuit, the state change data includes the following data items in addition to the above-mentioned data items such as StateDiff, PreStateHash, and ProStatehash:

[0158] MapDataHash (which is a public input), which represents the hash value of the state transformation data (MapData);

[0159] PubKeysRoot (which is a public input) represents the Merkle root of all validator public keys on the first blockchain;

[0160] AggSig (which is a privacy input) represents the aggregate signature of the validator on the first blockchain on the state transformation data (MapData);

[0161] SignerBits (a privacy input) that identifies which validators participated in the aggregate signature;

[0162] AllPubKeys (which is a privacy input) represents the set of all validator public keys on the first blockchain.

[0163] When the state change data composed of the above-listed data items are input into the zero-knowledge circuit, the state change proof data can be quickly obtained.

[0164] In one embodiment, the state change proof data generating unit 302 includes:

[0165] A Merkle root judgment unit, used to obtain a Merkle root constructed by all validator public keys on the first blockchain and a set of all validator public keys, and assert the set of all validator public keys through the Merkle root to determine whether the Merkle root is correct;

[0166] A signer quantity ratio determination unit, configured to obtain the aggregate signature on the first blockchain if the Merkle tree root is correct, and determine whether the ratio of the signers corresponding to the signature mark in the aggregate signature exceeds a preset ratio threshold;

[0167] An aggregate public key acquisition unit, configured to aggregate all verifier public keys to obtain an aggregate public key if the proportion of the number of signatories in the aggregate signature exceeds the proportion threshold;

[0168] A verification result acquisition unit, used to obtain the aggregate signature, combine the aggregate public key, the aggregate signature and the hash value of the state change data, and perform signature verification to obtain a verification result;

[0169] A data combination generation unit is used to generate state change proof data according to the hash value, Merkle tree root, aggregate signature, aggregate signature, signature mark and aggregate public key of the state change data if the verification result corresponds to passing the signature verification.

[0170] In this embodiment, the role of the zero-knowledge circuit is to generate a proof data according to the input parameters without generating an output result to verify the validity of the data. The specific process of generating the state change proof data by the zero-knowledge circuit in each selected second type node device is as follows:

[0171] 1) Verify the correctness of PubKeysRoot: Assert(MerkleRoot(AllpubKeys) == PubKeysRoot)

[0172] 2) Determine whether the number of signers meets the consensus requirement: Assert(Count(SignerBits)>Count(AllPubKeys)*(2 / 3));

[0173] 3) Calculate the aggregate public key: AggKey = BuildAggKey (AllPubKeys, SignerBits);

[0174] 4) Aggregate signature verification: Assert(VerifySig(MapDataHash,AggSig,AggKey)).

[0175] Among them, the calculation of the aggregate public key in step 3) can adopt the Bls signature algorithm (the Bls signature algorithm is a signature scheme originally proposed by Stanford University professor Dan Boneh and others in 2001) or the Schnorr signature algorithm (the Schnorr signature algorithm was originally proposed by German cryptographer Claus Schnorr in 2008).

[0176] The VerifySig() operation used in the aggregate signature verification in step 4) also corresponds to a signature algorithm, for example, the Bls signature algorithm or the Schnorr signature algorithm used in step 3).

[0177] At this time, each selected second-type node device obtains the above-mentioned proof data based on the zero-knowledge circuit, and then sends it to the second blockchain for smart contract verification. That is, after any user terminal is selected, it can generate zero-knowledge proof data (Proof = GenerateProof (MapDataHash, PubKeyRoot, AggSig, SignerBits, AllPubKeys)) based on the public data of the first blockchain (such as the data corresponding to the zero-knowledge circuit) and the state transformation data on the first blockchain. The zero-knowledge circuit can ensure that the input data is correct and is the state transformation data that has been signed and authenticated by most of the verifiers (more than 2 / 3) on the first blockchain and reached a consensus.

[0178] The state change proof data sending unit 303 is used to send the state change proof data to the second blockchain.

[0179] In this embodiment, after obtaining the state change proof data, the second type of node device sends the state change proof data to the second blockchain for smart contract verification.

[0180] Among them, the second blockchain 400 includes: a smart contract calling unit 401, a data verification unit 402, and a state transformation data mapping unit 403.

[0181] The smart contract calling unit 401 is used to receive the state change proof data sent by the second type of node device and call the smart contract stored locally.

[0182] In this embodiment, the project of the first blockchain will also deploy the smart contract corresponding to the zero-knowledge circuit on the second blockchain in the initial stage, and perform the following initialization actions:

[0183] ZkpParams, which represents the random parameters generated by the Trust Setup phase of the zero-knowledge circuit;

[0184] InitStates, representing the initial state data of the first blockchain;

[0185] StateHash, representing the state hash value of the first blockchain;

[0186] PubKeysRoot represents the Merkle tree root constructed by the public keys of all validators on the first blockchain.

[0187] When the second blockchain receives the state change proof data sent by the second type of node device, it can call the locally stored smart contract to perform subsequent verification process.

[0188] The data verification unit 402 is used to verify the state change proof data through a smart contract to obtain a verification result.

[0189] In one embodiment, the data verification unit 402 includes:

[0190] A state hash value verification unit, used to obtain the state hash value corresponding to the state change proof data, and determine whether the state hash value passes the verification;

[0191] A state change data hash value acquisition unit, configured to acquire the state change data hash value corresponding to the state change proof data if the state hash value passes the verification;

[0192] A zero-knowledge verification unit, used to determine whether the state change proof data passes the zero-knowledge verification;

[0193] A first verification result obtaining unit, configured to obtain a verification result of passing the verification if the state change proof data passes the zero-knowledge verification;

[0194] The second verification result obtaining unit is used to obtain a verification result of failure to pass the verification if the state change proof data fails the zero-knowledge verification.

[0195] In this embodiment, the specific process of verifying the state change proof data through the smart contract is as follows:

[0196] 11) State hash verification: Require(MapData.PreStateHash == StateHash);

[0197] 12) Calculate the hash value of MapData: Require(MapDataHash == Hash(MapData));

[0198] 13) Zero-knowledge verification: Require(VerifyProof(Proof,MapDataHash,PubKeysRoot)).

[0199] That is, first obtain the state hash value corresponding to the state change proof data for state hash verification. If the state hash verification passes, continue to obtain the state change data hash value corresponding to the state change proof data. Finally, perform zero-knowledge verification based on the state change proof data, the state change data hash value and the Merkle tree root. If the state change proof data passes the zero-knowledge verification, a verification result of passing the verification is obtained; if the state change proof data fails the zero-knowledge verification, a verification result of failing the verification is obtained.

[0200] The state transformation data mapping unit 403 is used to obtain the state transformation data of the first blockchain if the verification result is passed, and map the state transformation data to the local.

[0201] In this embodiment, if the verification result is passed, it is necessary to execute state mapping and update the state hash. Specifically, the state transformation data of the first blockchain is mapped to the local through the ApplyState(MapData) instruction, and then the state hash of the state transformation data is updated through the stateHash=MapData.ProStateHash operation.

[0202] Since any second type node device can submit (MapData, Proof) to the smart contract, the smart contract will verify the validity of the submitted state transformation data and perform the state mapping operation.

[0203] The system ensures that the state on the first blockchain can be correctly mapped to the second blockchain. Any user and application on the second blockchain can access the trusted state data of the first blockchain through the smart contract. The first blockchain can merge multiple state changes together each time, and the data submitted to the second blockchain only includes the incremental state data and a zero-knowledge proof value, which not only reduces the cost of state mapping, but also improves the mapping efficiency.

[0204] The above blockchain state mapping system can be implemented in the form of a computer program, which can be used in Figure 7 Runs on the computer device shown.

[0205] See also Figure 7 , Figure 7 5 is a schematic block diagram of a computer device provided in an embodiment of the present invention. The computer device 500 is a server, which may be an independent server or a server cluster composed of multiple servers. Alternatively, the computer device 500 is a terminal, which may be an electronic device with communication functions such as a smart phone, a tablet computer, a laptop computer, a desktop computer, a personal digital assistant, and a wearable device.

[0206] See also Figure 7 The computer device 500 includes a processor 502 , a memory and a network interface 505 connected via a system bus 501 , wherein the memory may include a storage medium 503 and an internal memory 504 .

[0207] The storage medium 503 may store an operating system 5031 and a computer program 5032. When the computer program 5032 is executed, the processor 502 may execute a blockchain state mapping method.

[0208] The processor 502 is used to provide computing and control capabilities to support the operation of the entire computer device 500 .

[0209] The internal memory 504 provides an environment for the operation of the computer program 5032 in the storage medium 503. When the computer program 5032 is executed by the processor 502, the processor 502 can execute the blockchain state mapping method.

[0210] The network interface 505 is used for network communication, such as providing data information transmission, etc. Those skilled in the art will understand that Figure 7 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present invention, and does not constitute a limitation on the computer device 500 to which the solution of the present invention is applied. The specific computer device 500 may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0211] The processor 502 is used to run a computer program 5032 stored in a memory to implement the blockchain state mapping method disclosed in an embodiment of the present invention.

[0212] Those skilled in the art will understand that Figure 7 The embodiments of the computer device shown in the figure do not constitute a limitation on the specific composition of the computer device. In other embodiments, the computer device may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently. For example, in some embodiments, the computer device may only include a memory and a processor. In such embodiments, the structure and function of the memory and the processor are the same as those of the embodiment of the present invention. Figure 7 The embodiments shown are consistent and will not be described again here.

[0213] It should be understood that in the embodiment of the present invention, the processor 502 may be a central processing unit (CPU), and the processor 502 may also be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Among them, the general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc.

[0214] In another embodiment of the present invention, a computer-readable storage medium is provided. The computer-readable storage medium may be a non-volatile computer-readable storage medium or a volatile computer-readable storage medium. The computer-readable storage medium stores a computer program, wherein when the computer program is executed by a processor, the blockchain state mapping method disclosed in the embodiment of the present invention is implemented.

[0215] Those skilled in the art can clearly understand that, for the convenience and simplicity of description, the specific working process of the above-described equipment, devices and units can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here. Those of ordinary skill in the art can appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented with electronic hardware, computer software or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in the above description according to the function. Whether these functions are executed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the present invention.

[0216] In the several embodiments provided by the present invention, it should be understood that the disclosed equipment, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. Units with the same function may also be combined into one unit. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interfaces, devices or units, or may be an electrical, mechanical or other form of connection.

[0217] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the embodiments of the present invention.

[0218] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0219] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a storage medium. Based on this understanding, the technical solution of the present invention is essentially or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), disk or optical disk and other media that can store program codes.

[0220] The above is only a specific embodiment of the present invention, but the protection scope of the present invention is not limited thereto. Any technician familiar with the technical field can easily think of various equivalent modifications or replacements within the technical scope disclosed by the present invention, and these modifications or replacements should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention shall be based on the protection scope of the claims.

Claims

1. A blockchain state mapping method, applied to a blockchain state mapping system, wherein the blockchain state mapping system includes a first type of node device, a second type of node device, a first blockchain and a second blockchain, wherein the first type of node device and the second type of node device are both arbitrary node devices, and the first type of node device and the second type of node device are not the same node device, characterized in that: include: The second type node device receives the state change data sent by the first blockchain, and obtains the verifier signature data and the zero-knowledge circuit on the first blockchain; The second type node device generates state change proof data from the state change data through the zero-knowledge circuit; as well as The second-type node device sends the state change proof data to a second blockchain; wherein the second blockchain and the first blockchain are different blockchains; The second blockchain receives the state change proof data sent by the second type node device, and calls the locally stored smart contract; wherein the second type node device is used to generate the state change proof data according to the state change data sent by the first blockchain and the zero-knowledge circuit, and send the state change proof data to the second blockchain; The second blockchain verifies the state change proof data through a smart contract to obtain a verification result; and If the verification result of the second blockchain is that the verification is passed, the second blockchain obtains the state transformation data of the first blockchain and maps the state transformation data to the local; The first type node device receives the parameter generator code data sent by the first blockchain, generates random parameters according to the parameter generator code data, and sends the random parameters to the first blockchain; wherein the parameter generator code data is constructed by the logic of generating random numbers by the zero-knowledge circuit in the first blockchain; and If the first-type node device receives the zero-knowledge proof trusted start notification corresponding to the random parameter sent by the first blockchain, it performs a first-type verifier mark and sends the corresponding first-type signature data to the first blockchain; The first blockchain sends the parameter generator code data to a randomly selected first type of node device; wherein the first type of node device is used to generate random parameters according to the parameter generator code data sent by the first blockchain and send the random parameters to the first blockchain for trusted startup; If the first blockchain receives the random parameters sent by the first type of node device and the receiving time and the total number of received random parameters meet the preset valid data receiving conditions, the zero-knowledge circuit corresponding to the parameter generator code data is trusted started; If the first blockchain detects a data state change, it obtains corresponding state transformation data and sends the state transformation data to a randomly selected second-type node device; wherein the second-type node device is used to generate state transformation proof data based on the received state transformation data sent by the first blockchain and the zero-knowledge circuit and send the state transformation proof data to the second blockchain; If the first blockchain detects a mapping instruction sent by the second blockchain, it maps the state transformation data to the second blockchain.

2. The blockchain state mapping method according to claim 1, characterized in that: The second type node device generates state change proof data from the state change data through the zero-knowledge circuit, including: Obtain the Merkle tree root constructed by all validator public keys on the first blockchain and the set of all validator public keys, and assert the set of all validator public keys through the Merkle tree root to determine whether the Merkle tree root is correct; If the Merkle tree root is correct, obtain the aggregate signature on the first blockchain, and determine whether the proportion of signatories corresponding to the signature mark in the aggregate signature exceeds a preset proportion threshold; If the proportion of signatories in the aggregate signature exceeds the threshold, all validator public keys are aggregated to obtain an aggregate public key; Obtaining the aggregate signature, combining the aggregate public key, the aggregate signature and the hash value of the state change data, and performing signature verification to obtain a verification result; If the verification result corresponds to passing the signature verification, the state change proof data is generated according to the hash value of the state change data, the Merkle tree root, the aggregate public key, the aggregate signature, the signature mark and the aggregate public key.

3. The blockchain state mapping method according to claim 1, characterized in that: The second blockchain verifies the state change proof data through a smart contract to obtain a verification result, including: Obtaining a state hash value corresponding to the state change proof data, and determining whether the state hash value passes verification; If the state hash value passes the verification, obtain the state change data hash value corresponding to the state change proof data; Determining whether the state change proof data passes zero-knowledge verification; If the state change proof data passes the zero-knowledge verification, a verification result of passing the verification is obtained; If the state change proof data fails the zero-knowledge verification, a verification result indicating that the verification failed is obtained.

4. The blockchain state mapping method according to claim 1, characterized in that: The first type node device generates a random parameter corresponding to the parameter generator code data, including: Generate private data and public data according to the parameter generator code data; The private data and the private data in the public data are deleted to obtain a random parameter.

5. A blockchain state mapping system, characterized in that: The blockchain state mapping system comprises a first type node device, a second type node device, a first blockchain and a second blockchain, and the blockchain state mapping system is used to execute the blockchain state mapping method as described in any one of claims 1 to 4.

6. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the blockchain state mapping method according to any one of claims 1 to 4 is implemented.

7. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, which, when executed by a processor, causes the processor to perform the blockchain state mapping method according to any one of claims 1 to 4.

Images