Privacy protection method in blockchain and communication device

Abstract

A privacy protection method in a blockchain and a communication device, relating to the technical field of blockchains. In the method, by designing specific zero-knowledge proof NP statements, when generating an asset proof, an asset owner can perform asset proof in an anonymized mode, so that other parties cannot know the real identity of the asset owner. A verifier can perform ownership verification upon obtaining the proof. If the verification succeeds, it indicates that a certain type of assets owned by a proof presenter is greater than a certain threshold, and it is confirmed that the proof presenter is one of a plurality of users who own this batch of similar assets. However, it is impossible to determine which specific user among these users is the proof presenter, and it is also impossible to determine the amount of assets specifically owned by the proof presenter.

Description

A method and communication device for privacy protection in blockchain

[0001] This application claims priority to Russian Federal Patent Application No. 2025106780, filed on March 21, 2025, with the Russian Federal Intellectual Property Office, entitled "A method and communication device for privacy protection in a blockchain," the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of blockchain technology, and more specifically, to a method and communication device for privacy protection in a blockchain. Background Technology

[0003] Real-world assets (RWAs) can be understood as assets with real value tokenized using blockchain technology. Owning a token signifies ownership of that asset in the real world. By mapping real-world assets to the crypto world using blockchain technology, this tokenization can break down a traditional asset into many smaller shares, making asset ownership more flexible and easier to trade. Digitizing real-world assets effectively reduces transaction costs and improves their liquidity, allowing users to engage in lending, renting, buying, and selling on the blockchain. The underlying assets that underpin their value are typically real estate, stocks, and bonds.

[0004] While mapping real-world assets to on-chain assets can effectively solve asset liquidity issues, current technical solutions for on-chain asset verification in applications such as real estate transactions, stock and bond tokenization, collectibles trading, and asset management present a problem: after providing asset verification, the on-chain identity completely locks up the real-world assets, exposing the user to the public eye and potentially revealing the user's identity on the blockchain.

[0005] Therefore, protecting user privacy is a technical problem that needs to be solved when conducting asset transactions on the blockchain. Summary of the Invention

[0006] This application provides a method for privacy protection in blockchain, which enables users to protect their privacy when conducting asset transactions on the blockchain.

[0007] Firstly, a privacy protection method is provided in a blockchain that includes blockchain assets held by multiple clients, including a first client and a second client. The first client conducts asset transactions with the second client through the blockchain. Both the first and second clients support running a zero-knowledge proof algorithm, which is used to prove a nondeterministic polynomial-time NP statement, wherein the NP statement includes the following:

[0008] The first NP statement indicates that the verification of the actual balance of the blockchain assets of the client needs to be greater than the target balance, which is determined based on the blockchain assets to be traded in the asset transaction; the second NP statement indicates that the proof of the first target hash value needs to be obtained based on the random number generated by the client, the actual balance of the client's blockchain assets, the identifier of the contract to which the client's blockchain assets belong, the block height where the asset transaction takes place, and the client's public key; the third NP statement indicates that the proof of the address of the client needs to be included in the address list of multiple clients, and the blockchain assets of each client in the address list are greater than the target balance; the fourth NP statement indicates that the verification of the digital signature generated by the client needs to be performed based on the client's public key, the method of which includes: the first client generating a first proof based on the NP statements and a zero-knowledge proof algorithm.

[0009] This application provides NP statements, enabling asset owners to anonymize their asset proofs, preventing others from knowing the true identity of the asset owner. Verifiers can then use this proof to demonstrate ownership. Successful proof indicates that the presenter owns more than a certain threshold of a particular type of asset and confirms that the presenter is one of multiple users owning this type of asset. However, it does not determine which specific user the presenter is, nor the exact amount of assets owned by the presenter.

[0010] In conjunction with the first aspect, in one possible implementation, the first client generates a first proof based on the NP statement and the zero-knowledge proof algorithm, including: the first client obtaining first private information and first public information based on the NP statement; the first private information includes a first random number generated by the first client, the first client's public key, the first digital signature generated by the first client, and the real balance of the first client's blockchain assets; the first public information includes a first hash value, a first address list, the asset exchange at the first block height, the first balance, and the identifier of the first contract to which the first client's blockchain assets belong; the first client generates the first proof based on the zero-knowledge proof algorithm, the first private information, and the first public information.

[0011] In conjunction with the first aspect, in one possible implementation, each client in the first address list has blockchain assets greater than a first balance, which is determined based on the blockchain assets to be traded in the asset transaction.

[0012] In conjunction with the first aspect, in one possible implementation, the method further includes: the first client obtaining a first hash value based on a first random number, a first balance, the first client's public key, a contract identifier, and a first block height; and the first client obtaining a first digital signature based on the first client's private key and the first random number.

[0013] Based on the above technical solution, secure and anonymous asset proof can be achieved when verifying assets on the blockchain. For example, in scenarios such as loans and financial asset proof, when asset owners perform RWA asset proof, they can complete the asset proof without actually exposing their personal identity on the blockchain using the solution provided in this application. Anonymous asset proof can effectively resist the association of on-chain and off-chain identities, protecting user privacy in this scenario.

[0014] In conjunction with the first aspect, in one possible implementation, the method further includes: a first client sending a first proof message to a second client via a blockchain, the first proof message carrying a first proof; the second client receiving the first proof message from the first client; and the second client verifying the NP statement based on a zero-knowledge proof algorithm and the first proof.

[0015] In conjunction with the first aspect, in one possible implementation, the proof message also carries first disclosure information, which includes a first digital signature, a first random number, and the public key of the first client. The method further includes: a second client verifying whether the first disclosure information is correct.

[0016] In conjunction with the first aspect, in one possible implementation, the second client verifies whether the first disclosure information is correct by: the second client obtaining the disclosed balance of the first client's blockchain assets based on the first block height, the identifier of the first contract, and the public key of the first client; the second client obtaining the first disclosure hash value based on the first digital signature, the first random number, the public key of the first client, and the disclosed balance of the first client's blockchain assets in the first disclosure information; and the second client determining whether the first disclosure information is correct based on the first disclosure hash value and the first hash value.

[0017] In conjunction with the first aspect, in one possible implementation, if the first hash value is equal to the first disclosure hash value, the method further includes: the second client verifying the first digital signature based on the first client's public key and the first random number in the first disclosure information; and the second client determining whether the first disclosure information is correct based on whether the first digital signature is successfully verified.

[0018] Based on the above implementation method, in this application, the purpose of verifying the first disclosure information is to see whether the information given in the first disclosure information is consistent with the relevant parameters verified when the first proof was verified using the zero-knowledge proof algorithm. For example, it can be verified whether the first digital signature, the first random number, and the public key of the first client in the first disclosure information given by the first client are consistent with the first digital signature, the first random number, and the public key of the first client that have been verified by the zero-knowledge proof algorithm.

[0019] In conjunction with the first aspect, in one possible implementation, if the first digital signature verification is successful, the method further includes: the second client obtaining the real balance of the first client's blockchain assets based on the first block height, the identifier of the first contract, and the public key of the first client in the first disclosure information.

[0020] Based on the above implementation, the method provided in this application can protect user privacy, enabling users to pass verification without exposing their identity or assets. However, anonymous asset proof scenarios also present the problem of asset owners subsequently denying ownership. For example, in mortgage loan scenarios, when trust issues arise or assets need to be liquidated, it is necessary to accurately locate the assets previously verified by the user. Using this solution can protect the rights of the verifier and achieve accurate disclosure afterward. That is, when trust issues arise or assets need to be liquidated, the assets previously verified can be accurately located, thus protecting the rights of the verifier.

[0021] In conjunction with the first aspect, in one possible implementation, the method is applied to a cloud system, which includes infrastructure providing cloud services, in which the blockchain is deployed.

[0022] Secondly, a privacy protection method in a blockchain is provided, wherein the blockchain includes blockchain assets of multiple clients, including a first client and a second client. The first client conducts asset transactions with the second client through the blockchain. Both the first client and the second client support running a zero-knowledge proof algorithm. The zero-knowledge proof algorithm is used to prove a nondeterministic polynomial-time NP statement, wherein the NP statement includes the following:

[0023] The fifth NP statement indicates that it is necessary to prove that the second target hash value is obtained based on the random number generated by the proving client, the asset identifier corresponding to the blockchain asset of the proving client, the block height where the asset transaction is located, and the public key of the proving client; the sixth NP statement indicates that it is necessary to prove that the asset identifier list of multiple clients' blockchain assets includes the asset identifier of the proving client, and the value of the blockchain asset corresponding to each asset identifier included in the asset identifier list is the same; the seventh NP statement indicates that it is necessary to verify the digital signature generated by the proving client based on the public key of the proving client, the method of which includes: the first client generating the second proof according to the NP statement and the zero-knowledge proof algorithm.

[0024] Based on the above scheme, asset owners can anonymize their asset certificates, preventing others from knowing their true identity. Verifiers can then use this certificate to prove ownership; a successful verification indicates that the certificate issuer owns one of the assets of the same type, but it doesn't reveal which specific user the issuer is or which assets the issuer actually owns.

[0025] In conjunction with the second aspect, in one possible implementation, the first client generates a second proof based on NP statements and a zero-knowledge proof algorithm, including: the first client obtaining second private information and second public information based on NP statements; the second private information includes the first client's public key, a second random number generated by the first client, a second digital signature generated by the first client, and the asset identifier of the first client's blockchain assets; the second public information includes a second hash value, a list of first asset identifiers, and the second block height where the asset is traded; the first client generates the second proof based on the zero-knowledge proof algorithm, the second private information, and the second public information.

[0026] In conjunction with the second aspect, in one possible implementation, the value of the blockchain asset corresponding to each asset identifier in the first asset identifier list is the same.

[0027] In conjunction with the second aspect, in one possible implementation, the method further includes: the first client obtaining a second hash value based on a second random number, the asset identifier of the first client's blockchain asset, a second block height, and the first client's public key; and the first client obtaining a second digital signature based on the first client's private key and the second random number.

[0028] Based on the above scheme, when a user needs to perform on-chain RWA asset proof, the user can collect several assets of equal value or assets with similar attributes on the blockchain (e.g., collectibles, artworks), and generate an asset ownership proof through the scheme provided in this application. This asset ownership proof will not expose a specific asset owned by the user, but can only determine that the user is the owner of one of several similar assets, thus protecting user privacy.

[0029] In conjunction with the second aspect, in one possible implementation, the method further includes: a first client sending a second proof message to a second client via a blockchain, the second proof message carrying a second proof; the second client receiving the second proof message from the first client; and the second client verifying the NP statement based on a zero-knowledge proof algorithm and the second proof.

[0030] In conjunction with the second aspect, in one possible implementation, the second proof message also carries second disclosure information, which includes a second digital signature, a second random number, the public key of the first client, and the asset identifier of the first client's blockchain asset. The method further includes: the second client verifying whether the second disclosure information is correct.

[0031] In conjunction with the second aspect, in one possible implementation, the first client verifies whether the second disclosure information is correct by: the second client obtaining the second disclosure hash value based on the second block height, the asset identifier of the first client's blockchain asset, the first client's public key, and the second random number; and the second client determining whether the second disclosure information is correct based on the second hash value and the second disclosure hash value.

[0032] In conjunction with the second aspect, in one possible implementation, if the second reveal hash value is equal to the second hash value, the method further includes: the second client verifying the second digital signature based on the first client's public key and the second random number in the second reveal information; and the second client determining whether the second reveal information is correct based on whether the second digital signature is successfully verified.

[0033] In conjunction with the second aspect, in one possible implementation, if the second digital signature verification is successful, the method further includes: the second client obtaining the blockchain asset corresponding to the asset identifier of the first client's blockchain asset based on the second block height, the asset identifier of the first client's blockchain asset, and the public key of the first client.

[0034] Based on the above solutions, the method provided in this application can protect user privacy, enabling users to pass verification without exposing their identity or assets. However, anonymous asset proof scenarios also present the problem of asset owners subsequently denying ownership. For example, in the case of collectibles or artworks, when trust issues arise or assets need to be liquidated, it is necessary to accurately locate the assets for which the user provided proof beforehand. Using this solution can protect the rights of the verifier and achieve accurate disclosure afterward. That is, when trust issues arise or assets need to be liquidated, the assets for which proof was provided beforehand can be accurately located, thus protecting the rights of the verifier.

[0035] In conjunction with the second aspect, in one possible implementation, the method is applied to a cloud system, which includes infrastructure providing cloud services, in which the blockchain is deployed.

[0036] Thirdly, this application proposes a communication device for performing the method executed by the first client in the first or second aspect described above. Specifically, the device may include units and / or modules for performing the method proposed in this application, such as a transceiver module and a processing module.

[0037] For example, the device can be a computing device, a server, or a server cluster.

[0038] For example, the device can be a virtual instance, such as a virtual machine, a container bare metal server, etc.

[0039] Fourthly, this application proposes a communication device for performing the method executed by the second client in the first or second aspect described above. Specifically, the device may include units and / or modules for performing the method proposed in this application, such as a transceiver module and a processing module.

[0040] For example, the device can be a computing device, a server, or a server cluster.

[0041] For example, the device can be a virtual instance, such as a virtual machine, a container bare metal server, etc.

[0042] Fifthly, this application provides a communication device, comprising: at least one processor for executing a computer program or instructions stored in a memory to perform the method executed by the first communication device in the first or second aspect described above. Optionally, the device further comprises a memory for storing the computer program or instructions. Optionally, the device further comprises a communication interface through which the processor reads the computer program or instructions stored in the memory.

[0043] In one implementation, the device is a device for implementing the functions of the above-described method in a chip.

[0044] In another implementation, the device is a chip, chip system, or circuit used to implement the functions described above in a chip.

[0045] Sixthly, this application provides a communication device, comprising: at least one processor for executing a computer program or instructions stored in a memory to perform the method executed by the second communication device in the first or second aspect described above. Optionally, the device further comprises a memory for storing the computer program or instructions. Optionally, the device further comprises a communication interface through which the processor reads the computer program or instructions stored in the memory.

[0046] In one implementation, the device is a device for implementing the functions of the above-described method in a chip.

[0047] In another implementation, the device is a chip, chip system, or circuit used to implement the functions described above in a chip.

[0048] In a seventh aspect, this application provides a processor, comprising: an input circuit, an output circuit, and a processing circuit. The processing circuit is configured to receive signals through the input circuit and transmit signals through the output circuit, causing the processor to execute the method of the first communication device in the first or second aspect described above, or to cause the processor to execute the method of the second communication device in the first or second aspect described above.

[0049] In specific implementation, the processor can be one or more chips, the input circuit can be input pins, the output circuit can be output pins, and the processing circuit can be transistors, gate circuits, flip-flops, and various logic circuits. The input signal received by the input circuit can be received and input by, for example, but not limited to, a transceiver, and the signal output by the output circuit can be, for example, but not limited to, output to and transmitted by a transmitter. Furthermore, the input circuit and the output circuit can be the same circuit, which is used as both the input circuit and the output circuit at different times. This application does not limit the specific implementation of the processor and various circuits.

[0050] Unless otherwise specified, or if it does not contradict its actual function or internal logic in the relevant description, the transmission and acquisition / reception operations involved in the processor can be understood as processor output and reception, input and other operations, or as transmission and reception operations performed by radio frequency circuits and antennas. This application does not limit them in this regard.

[0051] Eighthly, a processing apparatus is provided, including a processor and a memory. The processor is configured to read instructions stored in the memory and to receive signals via a transceiver and transmit signals via a transmitter to execute the method of a first client in the first or second aspect described above, or to execute the method of a second client in the first or second aspect described above.

[0052] Optionally, the processor may be one or more, and the memory may be one or more.

[0053] Optionally, the memory may be integrated with the processor, or the memory may be separated from the processor.

[0054] In specific implementation, the memory can be a non-transitory memory, such as read-only memory (ROM), which can be integrated with the processor on the same chip or set on different chips. The embodiments of this application do not limit the type of memory or the way the memory and processor are set.

[0055] It should be understood that the relevant data interaction process, such as sending the first information, can be the process of the processor outputting the first information, and the receiving capability information can be the process of the processor receiving input capability information. Specifically, the data output by the processor can be sent to the transmitter, and the input data received by the processor can come from the transceiver. Here, the transmitter and the transceiver can be collectively referred to as the transceiver.

[0056] The processing device mentioned in the eighth aspect above can be one or more chips. The processor in the processing device can be implemented in hardware or software. When implemented in hardware, the processor can be a logic circuit, integrated circuit, etc.; when implemented in software, the processor can be a general-purpose processor that reads software code stored in memory. This memory can be integrated into the processor or located outside the processor and exist independently.

[0057] A ninth aspect provides a computing cluster including at least one computing device, each computing device including a processor and a memory; the processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device to cause the computing device cluster to perform a method of a first client in the first aspect or a second aspect, or to cause the computing device cluster to perform a method of a second client in the first aspect or a second aspect, or to cause the computing device cluster to perform a method of a first client and a second client in the first aspect, or to cause the computing device cluster to perform a method of a first client and a second client in the second aspect.

[0058] Optionally, the processor can be a general-purpose processor, which can be implemented in hardware or software. When implemented in hardware, the processor can be a logic circuit, integrated circuit, etc.; when implemented in software, the processor can be a general-purpose processor that reads software code stored in memory. This memory can be integrated into the processor or located outside the processor and exist independently.

[0059] In a tenth aspect, a computer-readable storage medium is provided, comprising computer program instructions that, when executed by a cluster of computing devices, perform the method described in the first or second aspect.

[0060] Eleventhly, a computer program product containing instructions is provided, which, when run by a cluster of computing devices, causes the cluster of computing devices to perform the method described in the first or second aspect above.

[0061] In a twelfth aspect, a chip system is provided for performing the method of a first client in the first or second aspect described above, or for performing the method of a second client in the first or second aspect described above.

[0062] In a thirteenth aspect, a communication system is provided, comprising a first client and a second client, wherein the first client and the second client respectively execute the method described in the first aspect, or the first client and the second client respectively execute the method described in the second aspect. Attached Figure Description

[0063] Figure 1 is a schematic diagram of a blockchain provided in an embodiment of this application.

[0064] Figure 2 is a schematic flowchart of a privacy protection method 200 in a blockchain provided in an embodiment of this application.

[0065] Figure 3 is another schematic flowchart of a privacy protection method 200 in a blockchain provided in an embodiment of this application.

[0066] Figure 4 is a schematic diagram of a cloud service system architecture applicable to an embodiment of this application.

[0067] Figure 5 is a schematic block diagram of the communication device 500 provided in an embodiment of this application.

[0068] Figure 6 is a schematic block diagram of a communication device 600 provided in an embodiment of this application.

[0069] Figure 7 is a schematic diagram of the architecture of a computing device cluster provided in an embodiment of this application.

[0070] Figure 8 is a schematic diagram of the connection between computing devices 700A and 700B via a network provided in an embodiment of this application. Detailed Implementation

[0071] The technical solutions in this application will now be described with reference to the accompanying drawings.

[0072] To facilitate understanding of the technical solutions provided in the embodiments of this application, the technical terms involved in this application are briefly introduced below. It should be noted that the introduction of technical terms in this application is only for the purpose of helping to understand the technical solutions and should not be construed as limiting the application.

[0073] 1. Digital Signature

[0074] A digital signature is an application of asymmetric key encryption and digital digest technology. It is a digital string containing information about an electronic document and the sender's identity, capable of verifying the sender's identity and whether the sent information has been tampered with. A digital signature string contains three parts: a digital digest generated by hashing the electronic document (i.e., a hash function value), the sender's public key, and private key. The sender encrypts the document using their private key and sends it to the recipient. The recipient decrypts the document using their public key and compares the decrypted hash function value to determine whether the data message has been tampered with.

[0075] 2. Blockchain

[0076] Blockchain technology is a novel distributed infrastructure and computing paradigm that utilizes a block-chain data structure to verify and store data, distributed node consensus algorithms to generate and update data, cryptography to ensure the security of data transmission and access, and smart contracts composed of automated script code to program and manipulate data. Blockchain nodes can be understood as computers running blockchain software; these nodes collectively maintain the operation of the blockchain. Nodes are diverse, with functions including storing data, verifying transactions, generating blocks, participating in consensus, and disseminating information. Nodes ensure the decentralization, security, reliability, and trustworthiness of the blockchain.

[0077] A blockchain is a decentralized, distributed database that maintains a continuous record of transactions, each piece of data called a block. A block consists of two parts: a block header and a block body. The block header stores the block's header information, including the prehash of the previous block's header, the root of the hash tree for the current block's body, and a timestamp. The block body stores the detailed data of the block, such as transaction information or other types of information. Each block can contain more than one transaction, and each block is linked to other blocks. Each block contains the hash value of the previous block, and all linked blocks are called a chain.

[0078] Typically, "block height" is a number used to identify the position of a specific block within the blockchain. The first block in a blockchain is called the genesis block, and its block height is usually 0 or 1 (different blockchain implementations may vary, but it's generally numbered starting from 0 or 1). Starting with the genesis block, the block height increases by 1 for each new block. For example, the genesis block has a block height of 0 (or 1), the second block has a block height of 1 (or 2), the third block has a block height of 2 (or 3), and so on. Block height represents the current length of the blockchain, that is, the total number of blocks from the genesis block to the latest block. Block height provides a unique way to locate a block in the blockchain. When a new node joins the blockchain network, it needs to synchronize the blockchain data. Block height is an important reference indicator in the synchronization process. Nodes can use block height to determine which blocks they need to download and whether they have already synchronized to the latest block.

[0079] 3. Zero-knowledge proof (ZKP)

[0080] Zero-knowledge proofs are a type of verification method that allows one party (e.g., the prover) to prove a statement to another party (e.g., the verifier) ​​that it is true without revealing any information other than the truth or falsity of the statement. That is, the verifier only knows the truth or falsity of the statement and is completely unaware of any details behind it.

[0081] In zero-knowledge proof algorithms, an NP statement is a statement about a problem that is relatively easy to prove and verify. It belongs to the nondeterministic polynomial time (NP) problem category. NP problems do not necessarily have a polynomial-time algorithm to solve them. However, if a solution to the problem is given (also called "proof" or "witness"), then a polynomial-time algorithm exists to verify the correctness of that solution. In other words, the key to NP problems lies in the efficiency of verifying the solution, not the efficiency of finding the solution. Simply put, an NP statement is a statement whose truth can be efficiently verified, even if finding a proof may be difficult. In zero-knowledge proof algorithms, the prover wants to prove to the verifier that a statement (usually an NP statement) is true, but without revealing any secret information (witness) needed to prove the statement.

[0082] Here are some characteristics of NP statements: (1) Existence proof: There must exist "evidence" (also called "witness") that proves the NP statement is true; (2) Efficient verification: Even if finding this evidence may be very difficult, for any given evidence, there exists an efficient algorithm (in polynomial time) to verify whether the evidence is indeed a valid proof of the statement; (3) Statementality: It must be a definite statement that can be determined to be true or false. For example, an NP statement could be: Given a hash value H, there exists a value x such that hash(x) = H. For example, given g and y = g^x mod p, the prover claims to know x but does not want to reveal the value of x. In this case, an NP statement could be "There exists an x ​​such that y = g^x mod p". In zero-knowledge proofs, the prover attempts to prove to the verifier that an NP statement is true, but at the same time does not reveal any information about the witness. The prover's goal: to prove the NP statement is true, but not to reveal the witness. The verifier's goal: to verify the truth of the NP statement without gaining any knowledge about the witness.

[0083] Zero-knowledge proof algorithms include "interactive zero-knowledge proof algorithms" and "non-interactive zero-knowledge proof algorithms." The following mainly introduces "non-interactive zero-knowledge proof algorithms." Non-interactive zero-knowledge proof algorithms do not require real-time interaction between the prover and the verifier. The prover can generate a proof once, and anyone possessing this proof can independently verify its validity without any communication with the prover.

[0084] To facilitate understanding of the technical solution provided in this application, a simple example of "non-interactive zero-knowledge proof" is given below.

[0085] Suppose that the prover knows a number w such that x = g^w (where x and g are public). The respective execution processes of the prover and the verifier are as follows:

[0086] (1) Proofreader:

[0087] Choose a random number r;

[0088] Calculate A = g^r ("^" can be understood as exponentiation);

[0089] Calculate c = H(x, A);

[0090] Calculate s = r + c * w ("*" can be understood as a multiplication operation);

[0091] Generate a proof that π = (A, s);

[0092] (2) Verifier:

[0093] Receive proof π = (A, s);

[0094] Calculate c = H(x, A);

[0095] Check if g^s == A*x^c is true;

[0096] (3) Verification principle:

[0097] If the prover is honest, then g^s = g^(r + c*w) = g^r * g^(c*w) = A*(g^w)^c = A*x^c, verifying the equation. If the prover does not know w, then it is difficult for him to construct A and s such that the equation holds (unless he can solve the discrete logarithm problem).

[0098] As can be seen from the above example, although the verifier does not know what w is, they can determine whether they know w by verifying whether the equation holds true.

[0099] 4. Real-world assets (RWA)

[0100] "Real-world assets" can be understood as assets with real value that are tokenized using blockchain technology. Owning a token represents ownership of that asset in the real world. By mapping real-world assets to the crypto world using blockchain technology, this tokenization can break down a traditional asset into many smaller shares, making asset ownership more flexible and easier to trade. Digitizing real-world assets can effectively reduce transaction costs and improve their liquidity, allowing users to conduct lending, renting, buying, and selling transactions on the blockchain. The underlying assets that support their value are typically real estate, stocks, and bonds. Figure 1 is a schematic diagram of a blockchain as illustrated in this application. As shown in Figure 1, the blockchain includes multiple nodes, recording the blockchain assets of multiple clients. For example, the ledger of this blockchain stores that client #1's blockchain asset corresponds to real estate in the real world, client #2's blockchain asset corresponds to financial products such as bonds and stocks in the real world, and client #3's blockchain asset corresponds to a deposit in the real world. Specifically, how to tokenize real-world assets to obtain blockchain assets can be found in existing publicly available methods, which will not be elaborated upon in this application.

[0101] Typically, a client can be understood as an end-user of the blockchain, capable of initiating transactions and owning assets. The nodes in the blockchain are its maintainers, verifying transactions, packaging blocks, and maintaining the blockchain's security and stability. In the RWA scenario, clients own real-world assets, and the nodes in the blockchain ensure that RWA token transactions are genuine, valid, and immutable. Transactions between clients require node participation to ensure transaction validity, maintain the blockchain's decentralization, and provide a foundation of trust.

[0102] While mapping real-world assets to blockchain assets can effectively solve asset liquidity issues, current technologies for on-chain asset proof in applications such as real estate transactions, stock and bond tokenization, collectibles trading, and asset management present a challenge. The verification of this proof, through on-chain identity verification, completely locks down the real-world assets, exposing the user to public scrutiny and potentially revealing their identity on the blockchain. For example, one existing solution involves the asset prover generating a random number and signing it with their private key to create an asset proof. Others can then view the address of a specific asset through publicly available on-chain data and verify their identity using the proof and the random number. This process exposes the identity, allowing the on-chain identity to be locked, and subsequently linked to multiple on-chain Real-World Asset Verification (RWAs) associated with that identity, thereby locking down all real-world assets owned by the individual. Therefore, protecting user privacy during asset transactions on the blockchain becomes a critical technical challenge.

[0103] In view of this, this application provides a privacy protection method in a blockchain. Since both the first and second clients support running zero-knowledge proof algorithms, an NP statement is designed so that the first client obtains a first proof based on the NP statement and the zero-knowledge proof algorithm. Based on the first proof generated by the NP statement provided in this application, when the second client verifies the second proof, the second client can determine that the first client is one of multiple clients, but cannot determine which specific client among the multiple clients, and therefore cannot determine the specific assets of the first client on the blockchain.

[0104] The blockchain in this embodiment includes blockchain assets of multiple clients, such as a first client and a second client. In this embodiment, the first and second clients support running a zero-knowledge proof algorithm used to prove a nondeterministic polynomial-time NP statement. For example, the NP statement can be pre-configured in the "zero-knowledge proof algorithm".

[0105] It should be understood that the terms "proof client" and "verification client" in the NP statement of this application embodiment can be interpreted as generic terms. When a client conducts an asset transaction and needs to prove the asset, it will become the "proof client" in the NP statement, and the other party in the corresponding asset transaction can be understood as the "verification client." Therefore, the proof conditions in each statement of this NP statement can also be understood as generic terms, or as an abstract description. In actual proof, these parameters will become specific numerical values.

[0106] In this embodiment of the application, the first client can be understood as a "proof client" and the second client can be understood as a "verification client". In other words, the first client can be understood as an example of a proof client and the second client can be understood as an example of a verification client.

[0107] Typically, the design of NP statements is related to the design of algorithmic operations in zero-knowledge proof algorithms. In this application, the specific design and implementation of zero-knowledge proof algorithms are not limited. Any algorithm that can implement the NP statements provided in this application is within the scope of protection of this application.

[0108] In this embodiment, multiple clients can access the blockchain to obtain certain proof or verification information (e.g., public information from the blockchain). For example, clients can access the blockchain by connecting to a blockchain node or using an application programming interface (API) gateway.

[0109] The method 200 shown in Figures 2 and 3 below is mainly for scenarios where tokens have no value difference, i.e., fungible tokens, and users on the blockchain can exchange their tokens with each other. For example, method 200 is applicable to ERC20 and ERC3643 protocols, in which tokens have no value difference and are interchangeable, emphasizing universality and interchangeability.

[0110] The following section, with reference to Figure 2, will first introduce the specific content of each NP statement designed in method 200. In this embodiment of method 200, the NP statement includes the following four statements, namely the first NP statement, the second NP statement, the third NP statement, and the fourth NP statement.

[0111] In this embodiment, the "first NP statement" is used to indicate that the client's blockchain asset real balance needs to be verified to be greater than the target balance.

[0112] For example, the first NP statement can be represented as: token>balance target Where "token" represents proof of the client's actual blockchain asset balance, and "balance" represents the actual balance of the blockchain assets held by the client. target "Represents the target balance."

[0113] In this application embodiment, "proof client" can be understood as a client that needs to prove assets. For example, when various clients conduct transactions on the blockchain, they first need to prove their assets before they can conduct the transaction. "Verification client" can be understood as a client that needs to verify the blockchain assets of the proof client.

[0114] In this embodiment, the "target balance" can be understood as the balance of the blockchain assets that the client needs to prove. For example, the target balance is determined based on the blockchain assets to be traded in the asset transaction, or it can be understood as being related to the client's current trading situation. Assuming client #A's actual blockchain asset balance is 100 tokens, and client #A currently needs to trade 30 tokens, the target balance can be understood as 30 tokens. Alternatively, it can be understood that client #A only needs to prove that its blockchain assets are greater than 30 tokens when conducting this transaction.

[0115] For example, combining the proof logic of the zero-knowledge proof algorithm introduced above, when proving the first NP statement, the zero-knowledge proof algorithm can be designed as follows: Prove that the client provides a calculation result related to the true balance of its blockchain assets, that is, it performs some calculations on the true balance to hide the true balance (for example, the value of the calculation result is smaller than the original true balance). Verify that the client uses the zero-knowledge proof algorithm to verify that the given calculation result is greater than the target balance, thereby inferring that the true balance must be greater than the target balance, but it cannot know the specific value of the true balance.

[0116] In this embodiment, the "second NP statement" is used to indicate that it is necessary to prove that the first target hash value is obtained based on the random number generated by the client, the actual balance of the client's blockchain assets, the identifier of the contract to which the client's blockchain assets belong, the block height where the asset transaction is located, and the client's public key.

[0117] For example, the contract could be based on ERC20 or ERC3643 protocols. In such protocols, tokens have no value difference and are interchangeable, emphasizing universality and interchangeability. This embodiment does not limit the specific type of contract; any protocol where tokens have no value difference and are interchangeable can be understood as the contract in this embodiment.

[0118] For example, the second NP statement can be represented as: h target1 ==Hash(nonce||token||id) contract ||height block ||pk a In this embodiment, "nonce" represents the random number generated by the client, "token" represents the actual balance of the client's blockchain assets, and "id" represents the actual balance of the client's blockchain assets. contract "The height" represents the identifier of the contract to which the blockchain asset belongs, proving the client's identity. block "Represents the block height where the asset transaction is located, "pk a The symbol "" represents the public key of the client, and "||" can be understood as a concatenation operator, indicating that two strings or numbers are concatenated together.

[0119] For example, combining the proof logic of the zero-knowledge proof algorithm introduced above, when proving the second NP statement, the zero-knowledge proof algorithm can be designed as follows: The proof client provides the calculation result related to the random number, the target balance, the identifier of the contract to which the blockchain asset belongs, the block height where the asset transaction is located, and the public key of the proof client. That is, some calculations are performed on these parameters to obtain the calculation result, thereby hiding the true value of the parameters. The verification client uses the zero-knowledge proof algorithm to verify that the calculation result is correct, thereby inferring that the calculation result is related to these parameters. However, it can only infer that they are related, and cannot know what the specific values ​​of these parameters are.

[0120] In this embodiment, the "third NP statement" is used to indicate that it is necessary to prove that the address list of multiple clients includes the address of the proving client, and that the blockchain assets of each client included in the address list are greater than the target balance.

[0121] For example, a third NP statement can be represented as: one of List addr ==Computer(pk) a ), where "List addr This can be understood as proof of the address list collected by the client, "pk a This can be understood as proof of the client's public key.

[0122] In this embodiment of the application, there is a correspondence between the public key of each client and the address of the client. In other words, the address of the client can be determined through the public key of the client.

[0123] In this embodiment, the client requiring asset proof can obtain multiple client addresses on the blockchain to form an address list, where each client in the address list has blockchain assets greater than the target balance. Alternatively, in this embodiment, the client can identify multiple clients on the blockchain with the same asset value as its own, allowing it to hide itself among these clients during subsequent verification, thus preventing the exposure of its identity and asset information.

[0124] For example, combining the proof logic of the zero-knowledge proof algorithm introduced above, when proving the third NP statement, the zero-knowledge proof algorithm can be designed with the following idea: For example, the proof client can provide the result of the operation on its public key. If the verification is successful, the verification client can infer that the proof client does indeed belong to this address list, but the verification client cannot obtain what the public key is, so it cannot determine the address of the proof client.

[0125] In this embodiment, the "fourth NP statement" is used to indicate that the digital signature generated by the proof client needs to be verified based on the proof client's public key.

[0126] For example, the fourth NP statement can be represented as: Verify(sign a ,nonce,pk a ) == true, where "sign" a This can be understood as proof of the client's digital signature.

[0127] In this embodiment, it is demonstrated that the client can use its private key sk a Generate signature information (sign) from the nonce of the random number. a =sign(sk a ,nonce).

[0128] Through the third statement above, the verification client can infer that the client peer address corresponding to the public key provided by the proof client does indeed belong to the address list. However, at this point, it is still impossible to be certain whether the public key is the current proof client's public key, because the proof client may very well steal the public keys of other clients in the address list to pass the verification. Therefore, verification through the fourth NP statement is still required.

[0129] As previously introduced regarding "digital signatures," since this digital signature is signed by the current client using its own private key, if someone else's private key is used, under normal circumstances, this public key will be overwritten. a The digital signature cannot be decrypted; that is, if the public key provided by the client in the third statement above is someone else's public key, the verification of the fourth NP statement will fail. Only if the public key provided in the third NP statement above is the client's own public key can the verification of the fourth NP statement be passed.

[0130] In this embodiment, the first client can generate a first proof based on NP statements and zero-knowledge proof algorithms.

[0131] This application provides NP statements, enabling asset owners to anonymize their asset proofs, preventing others from knowing the true identity of the asset owner. Verifiers can then use this proof to demonstrate ownership. Successful proof indicates that the presenter owns more than a certain threshold of a particular type of asset and confirms that the presenter is one of multiple users owning this type of asset. However, it does not determine which specific user the presenter is, nor the exact amount of assets owned by the presenter.

[0132] The above is an introduction to the NP statement provided in method 200 of this embodiment. Figure 3 is another schematic flowchart of a privacy protection method 200 in a blockchain provided by this application. The method 200 shown in Figure 3 can be applied to the blockchain shown in Figure 1. The process of generating and verifying the first proof will be described in detail below with reference to Figure 3.

[0133] 210. The first client obtains the first private information and the first public information based on the NP statement.

[0134] In this embodiment, the first private information includes: a first random number generated by the first client, the public key of the first client, a first digital signature generated by the first client, and the actual balance of the blockchain assets of the first client; the first public information includes: a first hash value, a first address list, the first block height where the asset is exchanged, the first balance, and the identifier of the first contract to which the blockchain assets of the first client belong.

[0135] In this embodiment, the blockchain assets of each of the multiple clients included in the first address list are greater than the first balance. The first balance is determined based on the blockchain assets that need to be traded in the current asset transaction between the first client and the second client. For example, assuming that the actual balance of the first client's blockchain assets is 1000 tokens, and it needs to trade 100 tokens with the second client, the first balance can be understood as 100 tokens.

[0136] For example, the first client can obtain the blockchain addresses of clients with the first balance that satisfy the requirements of the NP statement from the blockchain, thus obtaining a list of first addresses. addr1 (An example of an "address list" in an NP statement), and obtain the current first block height from the blockchain. block1 (An example of "block height where the asset transaction is located" in an NP statement), the identifier ID of the first contract. contract1 (An example of "proving the identity of the contract to which the client's blockchain assets belong" in the NP statement), the true balance of the first client's blockchain assets token1 (an example of "proving the true balance of the client's blockchain assets" in the NP statement).

[0137] For example, the first client can generate the first random number, which is nonce1 (an example of "random number" in NP statements).

[0138] In one possible implementation, the first client obtains a first hash value based on a first random number, a first balance, the first client's public key, the identifier of the first contract, and the first block height where the asset transaction takes place. For example, the first client can calculate the first hash h1 = Hash(nonce1||token1||id) asset1 ||height block1 ||pk a1 (An example of "first target hash" in an NP statement). Where pk a1 It can be understood as the public key of the first client, or as an example of "proving the client's public key" in the NP statement.

[0139] In one possible implementation, the first client obtains the first digital signature based on its private key and a first random number. For example, the first client can use its private key sk a1 (An example of "proving the client's private key" in an NP statement) Sign the first random number to obtain the first digital signature sign. a1 =sign(sk a1 (nonce1)(An example of "digital signature" in NP statements).

[0140] For example, it is proven that the client can determine the first private information u1 = (pk) of the zero-knowledge proof algorithm based on NP statements. a1 ,nonce1,sign a1 ,token1).

[0141] For example, it can be proven that the client can determine the first public information y1 = (h1, List0 ... addr1 height block1 balance target1 ,id contract1 Among them, balance target1 This can be understood as the first balance of the first client, or as an example of the "target balance" in an NP statement.

[0142] 220. The first client generates the first proof based on the zero-knowledge proof algorithm, the first private information, and the first public information.

[0143] For example, the first client can use the proof key pk from the zero-knowledge proof algorithm. proof By combining zero-knowledge proof algorithms, first private information, and first public information, an asset proof π1 = Prove is generated. zk (pk proof (u1,y1)(an example of the first proof).

[0144] Optionally, the method 200 further includes 230, whereby the first client sends a first proof message to the second client via the blockchain, the proof message carrying the first proof.

[0145] Correspondingly, the second client receives the first proof message from the first client.

[0146] For example, the first client can send a first proof message to the second client via the blockchain, the first proof message carrying a first proof π1.

[0147] In this embodiment of the application, within the RWA scenario, the client owns real-world assets, and the various nodes on the blockchain ensure that token transactions on the blockchain are genuine, valid, and immutable. Asset transactions between clients require the participation of blockchain nodes, which ensures transaction validity, maintains the decentralization of the blockchain, and provides a foundation of trust.

[0148] In one possible implementation, the first proof message also carries first disclosure information, which includes a first digital signature, a first random number, and the public key of the first client. For example, the disclosure information can be represented as: revelation1 = (sign... a1 ,nonce1,pk a1 ).

[0149] In one possible implementation, the first proof message also carries first public information y1.

[0150] Based on the method provided in this application, when on-chain RWA asset proof is required, a user can collect several assets on the blockchain with the same value as the assets they own, and generate the asset proof through the scheme provided in this application. The asset proof will not expose the specific assets owned by the user, but can only determine that the user is one of several users corresponding to several similar assets, thus protecting user privacy.

[0151] Optionally, the method 200 also includes 240, whereby the second client verifies the NP statement based on the zero-knowledge proof algorithm, the first public information, and the first proof.

[0152] For example, when the first client needs to prove assets, it can present asset proof π1 to the second client.

[0153] For example, the second client uses the first contract identifier ID in the asset proof. contract1 and the first address list addr1The system uses information on the blockchain to determine whether the blockchain assets RWA of each client in the first address list exist and meet custom requirements, such as whether the balance of each client's blockchain assets is greater than the first balance.

[0154] For example, the second client uses the verification key vk from the zero-knowledge proof algorithm. proof Perform asset verification (b = Verify) zk (vk proof If b = true, then the verification passes. The specific verification process is related to the designed operations in the zero-knowledge proof algorithm, which will not be elaborated here. Those skilled in the art can reasonably design the operations in the zero-knowledge algorithm proof based on the NP statements provided in this application, thereby realizing the proof and verification processes.

[0155] In this embodiment, the proof key and verification key can be generated by a second client, a third party, a first client, or predefined, etc. This embodiment does not limit how the proof key and verification key are specifically generated. The first client can obtain the proof key in various ways, such as obtaining it from the blockchain or from a second client; the second client can also obtain the verification key in various ways, such as obtaining it from the first client or from the blockchain.

[0156] The method provided in this application enables secure and anonymous asset proof during asset verification on the blockchain. For example, in scenarios such as loans and financial asset proof, asset owners can complete asset proof without actually exposing their personal identity on the blockchain using the solution provided in this application. Anonymous asset proof can effectively resist the association of on-chain and off-chain identities, protecting user privacy in such scenarios.

[0157] Optionally, the method 200 also includes 250, whereby the second client verifies whether the first disclosure information is correct.

[0158] In this embodiment of the application, the second client can obtain the first public information. For example, the first proof message can carry the first public information, and the second client can obtain the first public information from the first proof message. Alternatively, the second client can directly obtain the first public information from the blockchain.

[0159] After the zero-knowledge proof algorithm is successfully verified, when asset disclosure is required afterward, the first client can present the first disclosure information, revelation1, to the second client; the second client parses revelation1 to obtain the first digital signature, sign. a The first random number nonce1 and the first client public key pk a1 .

[0160] In this embodiment, the purpose of verifying the first disclosure information is to see if the information given by the first disclosure information revelation1 is consistent with the relevant parameters verified in step 240 when the zero-knowledge proof algorithm is used to verify the first proof. For example, it can be verified whether the first digital signature, the first random number, and the public key of the first client in the first disclosure information given by the first client are consistent with the first digital signature, the first random number, and the public key of the first client that have been verified by the zero-knowledge proof algorithm.

[0161] In one possible implementation, the first client obtains the disclosed balance of its blockchain assets based on the first block height where the asset exchange is located in the first public information, the identifier of the first contract, and the public key of the first client in the first disclosure information.

[0162] For example, the second client, based on the first public information y1 obtained, calculates the height of the first block where the asset transaction is taking place. block1 The first client's blockchain assets are identified by the ID of the first contract. contract1 The first hash value h1 is used to obtain the first client's current balance token′ (an example of revealing the balance) through the first block height, the first contract identifier, and the first client's public key.

[0163] In one possible implementation, the second client obtains the first disclosure hash value based on the first digital signature, the first random number, the first client's public key, and the disclosed balance of the first client's blockchain assets in the first disclosure information. The second client then determines whether the first disclosure information is correct based on the first disclosure hash value and the first hash value in the public information.

[0164] For example, the second client can calculate h′1 = Hash(nonce1||token′||id) contract1 ||height block1 ||pk a1 The system checks whether h′1 is equal to h1. If they are not equal, it means that the first client did not honestly present the asset disclosure (i.e., the content in the first disclosure information is incorrect). If they are equal, the following verification will continue.

[0165] In one possible implementation, if the first hash value is equal to the first disclosure hash value, the method 200 further includes: the second client verifying the first digital signature based on the first client's public key and the first random number in the first disclosure information; and the second client determining whether the first disclosure information is correct based on whether the first digital signature is successfully verified.

[0166] For example, if h′1 equals h1, the second client can then continue with signature verification: l = Verify(sign) a1 ,nonce1,pk a1 If l is not equal to true, the asset revealer has not honestly disclosed the assets; if l is equal to true, the asset disclosure is successful.

[0167] Optionally, if the first digital signature verification passes, method 200 may also include 260, whereby the second client obtains the real balance of the first client's blockchain assets based on the first block height where the asset exchange is located, the identifier of the first contract, and the public key of the first client.

[0168] For example, if the first digital signature verification is successful, the first client can output the first block height. block1 At that time, the contract address is id contract1 The client address is Computer addr (pk a1 RWA assets.

[0169] In this application example, when the second client determines in step 250 that the disclosure information provided by the first client is consistent with the relevant parameters verified in the previous zero-knowledge proof algorithm, the second client can lock the address of the first client based on the public key of the first client in the disclosure information provided by the first client and the asset exchange in the first public information at the first block height and the identifier of the first contract, and obtain the real balance of the first client's blockchain assets.

[0170] The method provided in this application can protect user privacy, enabling users to pass verification without revealing their identity or assets. However, anonymous asset verification scenarios also present the risk of asset owners subsequently denying ownership. For example, in mortgage lending scenarios, when trust issues arise or assets need to be liquidated, it is necessary to accurately locate the assets previously verified by the user. This solution can protect the rights of verifiers, ensuring accurate disclosure afterward. In other words, when trust issues arise or assets need to be liquidated, the assets previously verified can be accurately located, thus protecting the rights of verifiers.

[0171] Method 200 above primarily addresses scenarios where tokens have no inherent value difference, allowing users on the blockchain to exchange their tokens. Method 300, however, focuses on assets where each token in the blockchain possesses a unique token ID, making them neither interchangeable nor divisible, thus possessing uniqueness and scarcity. Examples of such blockchain assets include collectibles, artwork, game items, virtual world assets, music, videos, game accounts, social media accounts, and so on. Method 300 is applicable to ERC721 and ERC1155 protocols.

[0172] It should be noted that Method 300 and Method 200 have many similarities, with slight differences mainly in NP statements, private information, and public information. The overall process of the solution is roughly similar to that of Method 200. Therefore, the parts in Method 300 that are the same as those in Method 200 will not be repeated here. Please refer to Method 200 for understanding. The following mainly explains the differences between the two.

[0173] The specific content of each NP designed in method 300 is introduced below. In this embodiment of method 300, the NP statement includes the following three statements, namely the fifth NP statement, the sixth NP statement and the seventh NP statement.

[0174] In this embodiment, the fifth NP statement is used to indicate that it is necessary to prove that the second target hash value is obtained based on the random number generated by the proof client, the asset identifier corresponding to the blockchain asset of the proof client, the block height where the asset transaction is located, and the public key of the proof client.

[0175] For example, the fifth NP statement can be represented as: h target2 ==Hash(nonce||id) asset ||height block ||pk a In this embodiment, "nonce" represents the proof of the random number generated by the client, and "id" represents the proof of the random number generated by the client. asset "The asset identifier representing the blockchain assets of the client," height block "Represents the block height where the asset transaction is located, "pk a "This represents the public key used to verify the client's identity."

[0176] In this embodiment, the asset is identified as id. asset This can be understood as a unique identifier for an asset, such as being determined by the address of the contract to which the blockchain asset belongs and a unique identifier within the contract. For example, the contract includes identifiers for blockchain assets from multiple clients, each asset having a unique identifier. Therefore, the `id` in this embodiment... assetThis can be understood as proving the address of the contract to which the client's blockchain asset belongs and proving the identifier of the blockchain asset that the client needs to prove.

[0177] Specifically, the proof logic for the fifth NP statement is similar to the proof logic for the second NP statement in method 200. For details, please refer to the introduction of the proof logic for the second NP statement in method 200 to understand the proof logic for the fifth NP statement. This embodiment will not repeat it.

[0178] In this embodiment, the "sixth NP statement" is used to indicate that the asset identifier list of the blockchain assets of multiple clients needs to be proved to include the asset identifier of the client. The asset identifier list includes the asset identifiers of the blockchain assets of each of the multiple clients, and the value of the blockchain assets corresponding to each asset identifier in the asset identifier list is the same.

[0179] In this embodiment, "the same value of blockchain assets" can be understood as the value of blockchain assets being close to or substantially the same. For example, the value of artworks corresponding to asset identifiers is close; for example, the value of collectibles corresponding to asset identifiers is substantially the same.

[0180] For example, the sixth NP statement can be represented as: one of List id ==id asset Among them, "List id This can be understood as a list of asset identifiers proving that the client has collected blockchain assets from multiple clients.

[0181] In this embodiment, the client requiring asset proof can obtain asset identifiers from multiple clients' blockchain assets on the blockchain, thus obtaining an asset identifier list. Each client's blockchain asset identifier in this list meets the requirements. For example, the blockchain asset identifiers of each client in the asset identifier list belong to the same type of asset (e.g., artworks or collectibles of equal value), or assets with similar actual values. Alternatively, in this embodiment, the client can identify multiple clients on the blockchain with similar asset values ​​to its own, allowing it to hide itself among these clients during subsequent verification, preventing the exposure of its identity and asset information.

[0182] Specifically, the proof logic for the sixth NP statement is similar to the proof logic for the third NP statement in method 200. For details, please refer to the introduction of the proof logic for the third NP statement in method 200. This embodiment will not repeat it.

[0183] In this embodiment, the "seventh NP statement" is used to indicate that the digital signature generated by the proof client needs to be verified based on the proof client's public key.

[0184] For example, this seventh statement can be represented as: Verify(sign a ,nonce,pk a )==true, in this embodiment, where "sign" a "This can be understood as proof of the client's digital signature, 'nonce' represents proof of the random number generated by the client, and 'pk'..." a "This represents the public key used to verify the client's identity."

[0185] In this embodiment, it is demonstrated that the client can use its private key sk a Generate signature information (sign) from the random number nonce. a =sign(sk a ,nonce).

[0186] Specifically, the proof logic for the seventh NP statement is similar to the proof logic for the fourth NP statement in method 200. For details, please refer to the introduction of the proof logic for the fourth NP statement in method 200. This embodiment will not repeat it.

[0187] The method provided in this embodiment allows asset owners to anonymize their asset certificates, preventing others from knowing their true identity. Verifiers can use this certificate to prove ownership; successful verification indicates that the certificate issuer owns one of the assets of the same type, but it doesn't determine which specific user the issuer is or which assets the issuer actually owns.

[0188] The above is an introduction to the NP statement provided in method 300 of this embodiment. The flow of method 300 is basically similar to that of method 200 shown in Figures 2 and 3, therefore, no additional flowchart is provided. The flow of method 300 of this embodiment can be understood in conjunction with Figures 2 and 3. Method 300 includes:

[0189] 310. The first client obtains the second private information and the second public information based on the NP statement.

[0190] In this embodiment, the first private information includes: the public key of the first client, the second random number generated by the first client, the second digital signature generated by the first client, and the asset identifier of the blockchain asset of the first client; the second public information includes: the second hash value, the first asset identifier list, and the second block height where the asset is traded.

[0191] For example, the first client can obtain a list of first asset identifiers that meet the proof-of-assets requirements from the blockchain, resulting in a List. id1(An example of "a list of asset identifiers for blockchain assets from multiple clients" in an NP statement), and obtain the height of the second block on which the current asset is traded from the blockchain. block2 (An example of "block height where the asset transaction is located" in an NP statement). In this example, the value of the blockchain asset corresponding to each asset identifier in the first asset identifier list is essentially the same.

[0192] For example, the first client can generate a second random number, resulting in the random number nonce2.

[0193] In one possible implementation, the first client obtains the second hash value from the public information based on the second random number, the asset identifier of the first client's blockchain asset, the second block height where the asset is traded, and the first client's public key. For example, the first client can calculate the second hash value h2 = Hash(nonce2||id). asset1 ||height block2 ||pk a1 ), where id asset1 This can be understood as the asset identifier of the blockchain asset on the first client, PK. a1 This can be understood as the public key of the first client.

[0194] In one possible implementation, the first client obtains the second digital signature based on its private key and a second random number. For example, the first client can use its private key sk a1 Sign the second random number to obtain the second digital signature. a2 =sign(sk a1 ,nonce2).

[0195] For example, the first client can determine the second private information u2 = (pk) of the zero-knowledge proof algorithm based on the NP statement. a1 ,nonce2,sign a2 ,id asset1 ).

[0196] For example, the first client can determine the second public information y2 = (h2, List) of the zero-knowledge proof algorithm based on NP statements. id 1 , height block2 ).

[0197] 320. The first client generates the second proof based on the zero-knowledge proof algorithm, the second private information, and the second public information.

[0198] For example, the first client can use the proof key pk from the zero-knowledge proof algorithm. proofBy combining zero-knowledge proof algorithms, second private information, and second public information, a second asset proof π2 = Prove is generated. zk (pk proof (u2,y2)(an example of the second proof).

[0199] Optionally, the method 300 further includes 330, whereby the first client sends a second proof message to the second client, the second proof message carrying a second proof.

[0200] Correspondingly, the second client receives the second proof message from the first client.

[0201] For example, the first client may send a second proof message to the second client, the second proof message carrying a second proof π2.

[0202] In one possible implementation, the second proof message also carries second disclosure information, which includes a second digital signature, a second random number, the public key of the first client, and the asset identifier of the first client's blockchain asset. For example, the second disclosure information can be represented as: revelation2 = (sign... a2 ,nonce2,pk a1 ,id asset1 ).

[0203] In one possible implementation, the second proof message also carries second public information y2.

[0204] Based on the method provided in this application, when a user needs to perform on-chain RWA asset proof, the user can collect several assets of equal value or assets with similar asset attributes (e.g., collectibles, artworks) on the blockchain, and generate proof of ownership of the asset through the scheme provided in this application. This proof of ownership will not expose a specific asset owned by the user, but can only determine that the user is the owner of one of several similar assets, thus protecting user privacy.

[0205] Optionally, the method 300 also includes 340, whereby the second client verifies the NP statement based on the zero-knowledge proof algorithm and the second proof.

[0206] For example, when the first client needs to prove assets, the second proof π2 is presented to the second client;

[0207] For example, the second client uses the asset list List in the second proof. id The system uses information on the blockchain to determine whether the RWA in the list exists and meets the requirements. For example, it can query the blockchain to see if each asset in the asset list is of the same type or if their actual value is the same.

[0208] The second client uses the verification key vk based on the zero-knowledge proof algorithm. proof Using second public information, perform asset verification (b = Verify) zk (vk proof If b = true, then the verification is successful.

[0209] In this embodiment, the second client can also obtain the second public information. For example, the second client can obtain the second public information from the second proof message. Alternatively, the second client can obtain the second public information from the blockchain.

[0210] This can also be understood as the method provided in this application enabling secure and anonymous asset verification on the blockchain. For example, in scenarios such as loans and financial asset verification, when asset owners perform RWA asset verification, they can complete the asset verification without actually exposing their personal identity on the blockchain using the solution provided in this application. Anonymous asset verification can effectively resist the association of on-chain and off-chain identities, protecting user privacy in this scenario.

[0211] Optionally, the method 300 further includes 350, whereby the second client verifies whether the second disclosure information is correct.

[0212] For example, when asset disclosure is required afterward, the first client presents the second disclosure information, revelation2, to the second client. At this time, the second client parses revelation2 to obtain the second digital signature, sign. a2 The second random number nonce2, and the public key pk of the first client. a1 The asset identifier ID of the blockchain asset on the first client. asset1 .

[0213] For example, the second client obtains the height of the second block where the asset transaction took place, based on publicly available information. block2 The asset identifier ID of the blockchain asset on the first client. asset1 The second reveal hash h2 is used to determine whether the on-chain information matches the second block height, the asset identifier, and the public key of the first client. Specifically, at the current block height, is the owner address of the asset identifier equal to the Computer address? addr (pk a1 This can also be understood as verifying whether the public key of the first client provided in the second disclosure information matches the address of the first client.

[0214] In one possible implementation, the second client obtains the second disclosure hash value based on the second block height where the asset transaction occurs in the second public information, the asset identifier of the first client's blockchain asset in the second disclosure information, the first client's public key, and a second random number. The second client then determines whether the second disclosure information is correct based on the second hash value in the second public information and the second disclosure hash value.

[0215] For example, the second client can calculate h′2 = Hash(nonce2||id) asset1 ||height block2 ||pk a1 ), determine whether h′2 is equal to h2. If they are not equal, it means that the first client did not honestly disclose the assets; if they are equal, continue with the following verification.

[0216] In one possible implementation, if the second hash value is equal to the second disclosure hash value, the method 300 further includes: the second client verifying the second digital signature based on the first client's public key and the second random number in the second disclosure information; and the second client determining whether the second disclosure information is correct based on whether the second digital signature is successfully verified.

[0217] For example, the second client can perform signature verification, l = Verify(sign a2 ,nonce2,pk a1 If l is not equal to true, it means that the first client did not honestly disclose assets; if l is equal to true, it means that asset disclosure was successful.

[0218] If the second digital signature verification is successful, optionally, the method 300 also includes 360, whereby the second client obtains the blockchain asset corresponding to the asset identifier of the first client's blockchain asset based on the second block height where the asset transaction is located, the asset identifier of the first client's blockchain asset, and the public key of the first client.

[0219] For example, the second client outputs the previously proven asset as the height of the second block. block2 At that time, the asset identifier is id. asset1 RWA assets.

[0220] In this application example, when the second client determines in step 350 that the second disclosure information provided by the first client is consistent with the relevant parameters verified in the previous zero-knowledge proof algorithm, the second client can directly obtain the asset identifier as id based on the second block height where the asset transaction is located in the second public information provided by the first client, and the asset identifier of the first client's blockchain asset provided in the second disclosure information. asset1 RWA assets.

[0221] The method provided in this application can protect user privacy, enabling users to pass verification without revealing their identity or assets. However, anonymous asset proof scenarios also present the risk of asset owners subsequently denying ownership. For example, in the case of collectibles or artworks, when trust issues arise or assets need to be liquidated, it is necessary to accurately locate the assets for which the user provided prior proof. This solution can protect the rights of the verifier and ensure accurate disclosure afterward. In other words, when trust issues arise or assets need to be liquidated, the assets for which prior proof was provided can be accurately located, thus protecting the rights of the verifier.

[0222] It should be noted that methods 200 and 300 provided in this application can also be combined, as long as the logic is reasonable. In other words, the first client and the second client can simultaneously deploy two types of protocols, one protocol supporting the operation of method 200 and the other protocol supporting the operation of method 300. Furthermore, the various embodiments in this application (including the various implementations of each embodiment) can also be combined according to their internal logic.

[0223] Figure 4 is a schematic diagram of a cloud scenario applicable to this application. As shown in Figure 4, this cloud scenario may include: a cloud management platform 410, the Internet 420, and a client 430. As shown in Figure 4, the cloud management platform 410 is used to manage the infrastructure providing multiple cloud services. The infrastructure includes multiple cloud data centers, each cloud data center includes at least one server, and each server includes cloud service resources to provide corresponding cloud services to tenants.

[0224] For example, blockchain can be deployed in the infrastructure of cloud systems.

[0225] It is understood that the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0226] It should also be understood that the ordinal numbers such as "first" and "second" mentioned in the embodiments of this application are used to distinguish multiple objects, and are not used to limit the size, content, order, timing, priority or importance of multiple objects.

[0227] It should also be understood that, in this application, "at least one" means one or more, and "more than one" means two or more. "At least one item" or similar expressions mean one or more items, that is, any combination of these items, including any combination of single items or multiple items. For example, at least one of a, b, or c means: a, b, c, a and b, a and c, b and c, or a and b and c.

[0228] It should also be understood that, in the various embodiments of this application, determining B based on A does not mean that B is determined solely based on A; B can also be determined based on A and / or other information.

[0229] It should be understood that the various implementations in this application can be combined with each other according to their internal implementation logic.

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

[0231] This application embodiment can divide the computing device into functional modules according to the above method example. For example, each function can be divided into its own functional modules, or two or more functions can be integrated into one processing module. The integrated modules can be implemented in hardware or as software functional modules. It should be noted that the module division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods. The following description uses the division of functional modules according to each function as an example.

[0232] Figure 5 is a schematic block diagram of a communication device 500 provided in an embodiment of this application. As shown in the figure, the communication device 500 may include: a configuration module 510, a processing module 520; optionally, it may also include a transceiver module 530.

[0233] The modules described above are used to execute the respective steps of the methods mentioned above, which will not be elaborated here.

[0234] It should also be understood that the communication device 500 here is embodied in the form of a functional unit. The term "unit" here may refer to application-specific integrated circuits (ASICs), electronic circuits, processors (e.g., shared processors, proprietary processors, or group processors) and memory for executing one or more software or firmware programs, combined logic circuits, and / or other suitable components that support the described functions.

[0235] The communication device 500 has the function of implementing the corresponding steps of the first client in method 200 or method 300, or the communication device 500 has the function of implementing the corresponding steps of the second client in method 200 or method 300. The function can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions; for example, a processing module can be replaced by a processor to execute the transmit / receive operations and related processing operations in each method embodiment. Furthermore, the processing module can also be a processing circuit.

[0236] It should be noted that the communication device in Figure 5 can be the first communication device or the second communication device in the aforementioned method embodiments, or it can be the chip or chip system corresponding to the relevant communication device, such as a system on a chip (SoC). The processing module is the processor, microprocessor, or integrated circuit integrated on the chip. No limitation is made here.

[0237] In one embodiment, the communication device 500 is the first communication device in the method 200 of the above embodiment. In this case, the configuration module 510 is configured with a zero-knowledge proof algorithm and NP statements, the NP statements including a first NP statement, a second NP statement, a third NP statement, and a fourth NP statement; the processing module 520 is configured to generate a first proof based on the NP statements and the zero-knowledge proof algorithm.

[0238] In one possible implementation, the transceiver module 530 is used to send the first proof message.

[0239] In one embodiment, the communication device 500 is the first communication device in the method 300 of the above embodiment. In this case, the configuration module 510 is configured with a zero-knowledge proof algorithm and NP statements, the NP statements including a fourth NP statement, a fifth NP statement, and a sixth NP statement; the processing module 520 is used to generate a second proof based on the NP statements and the zero-knowledge proof algorithm.

[0240] In one possible implementation, the transceiver module 530 is used to send the second proof message.

[0241] In another embodiment, the communication device 500 is the second communication device in the method 200 of the above embodiment. In this case, the configuration module 510 is configured with a zero-knowledge proof algorithm and NP statements, the NP statements including a first NP statement, a second NP statement, a third NP statement, and a fourth NP statement; the transceiver module 530 is used to receive a first proof message; and the processing module 520 is used to verify the NP statements according to the zero-knowledge proof algorithm and the first proof.

[0242] In another embodiment, the communication device 500 is the second communication device in the method 300 of the above embodiment. In this case, the configuration module 510 is configured with a zero-knowledge proof algorithm and NP statements. The NP statements include a first NP statement, a second NP statement, a third NP statement, and a fourth NP statement. The transceiver module 530 is used to receive a second proof message. The processing module 520 is used to verify the NP statements according to the zero-knowledge proof algorithm and the second proof.

[0243] Figure 6 is a schematic block diagram of another communication device 600 provided in an embodiment of this application. As shown, the device 600 includes at least one processor 620. The processor 620 is coupled to a memory and is used to execute instructions stored in the memory to transmit and / or receive signals. Optionally, the device 600 also includes a memory 630 for storing instructions. Optionally, the device 600 also includes a transceiver 610, and the processor 620 controls the transceiver 610 to transmit and / or receive signals.

[0244] It should be understood that the processor 620 and memory 630 described above can be combined into a single processing device, with the processor 620 executing the program code stored in the memory 630 to achieve the aforementioned functions. In specific implementations, the memory 630 can be integrated into the processor 620 or independent of the processor 620.

[0245] It should also be understood that transceiver 610 may include a transceiver (or receiver) and a transmitter (or transmitter). The transceiver may further include an antenna, and the number of antennas may be one or more. Transceiver 610 may have a communication interface or interface circuitry.

[0246] Bus 640 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, only one line is used in Figure 6, but this does not imply that there is only one bus or one type of bus. Bus 640 can include pathways for transmitting information between various components of computing device 600 (e.g., memory 630, processor 620, transceiver 610).

[0247] The memory 630 stores executable program code, and the processor 620 executes this executable program code to implement the functions of the aforementioned transceiver module and processing module, thereby implementing the methods in the embodiments of this application. That is, the memory 630 stores instructions for executing the aforementioned methods 200 and 300. For example, the processor 620 executes the computer program or instructions stored in the memory 630 to implement the various steps in methods 200 and 300 above.

[0248] Figure 7 is a schematic diagram of the architecture of a computing device cluster provided in an embodiment of this application. The computing device cluster includes at least one computing device. This computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a desktop computer, a laptop computer, or a smartphone, or other terminal device. As shown in Figure 7, the computing device cluster includes at least one computing device 700. The memory 730 in one or more computing devices 700 in the computing device cluster can store the same instructions for performing the actions executed in the above embodiment 200 or method 300.

[0249] In some possible implementations, the memory 730 of one or more computing devices 700 in the computing device cluster may also store partial instructions for performing the actions performed in method 200 or method 300 described in the above embodiments. In other words, a combination of one or more computing devices 700 can jointly execute instructions for performing the actions performed in method 200 or method 300 described in the above embodiments.

[0250] In one possible implementation, one or more computing devices 700 in the computing device cluster can be used to perform the actions of the first client in method 200; or, one or more computing devices 700 in the computing device cluster can be used to perform the actions of the second client in method 200.

[0251] In one possible implementation, some (or one) of the computing devices 700 in the computing device cluster can be used to perform the actions of the first client in method 200, and some (or one) of the computing devices can be used to perform the actions of the second client in method 200.

[0252] In another possible implementation, one or more computing devices 700 in the computing device cluster can be used to perform the actions of the first client in method 300; or, one or more computing devices 700 in the computing device cluster can be used to perform the actions of the second client in method 300.

[0253] In another possible implementation, some (or one) of the computing devices 700 in the computing device cluster can be used to perform the actions of the first client in method 300, and some (or one) of the computing devices can be used to perform the actions of the second client in method 300.

[0254] It should be noted that the memory 730 in different computing devices 700 within the computing device cluster can store different instructions, each used to execute a portion of the functions of the computing device 700. That is, the instructions stored in the memory 730 of different computing devices 700 can implement the functions of one or more of the aforementioned transceiver module and processing module.

[0255] Alternatively, the memories 730 in different computing devices 700 within the computing device cluster can store different instructions, each used to execute a portion of the functions of the devices corresponding to the aforementioned computing devices 500-600. That is, the instructions stored in the memories 730 of different computing devices 700 can implement the functions of one or more modules, such as the transceiver module and the processing module.

[0256] In some possible implementations, one or more computing devices in a computing device cluster can be connected via a network. This network can be a wide area network (WAN) or a local area network (LAN), etc. Figure 8 illustrates one possible implementation, where two computing devices 700A and 700B are connected via a network. Specifically, they are connected to the network through communication interfaces in each computing device.

[0257] It should be understood that the functions of computing device 700A shown in Figure 8 can also be performed by multiple computing devices 700. Similarly, the functions of computing device 700B can also be performed by multiple computing devices 700.

[0258] The connection method between the computing device clusters shown in Figure 8 can be considered in light of the fact that the method provided in this application needs to generate a first proof or you are in the first proof, so the function implemented by the processing module is considered to be executed by the computing device 700B.

[0259] In this embodiment, a computer program product containing instructions is also provided. The computer program product may be software or program products containing instructions capable of running on a computing device cluster or stored on any available medium. When run by the computing device cluster, it causes the computing device cluster to perform the methods provided above, or causes the computing device cluster to implement the functions of the computing devices provided above.

[0260] In this embodiment, a computer-readable storage medium is also provided. This computer-readable storage medium can be any available medium that a computing device can store, or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., digital video disc (DVD)), or a semiconductor medium (e.g., a solid-state drive). The computer-readable storage medium includes instructions that, when executed on a computing device, cause the computing device to perform the method described above.

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

[0262] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

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

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

[0265] In addition, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into one unit.

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

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

Claims

1. A method for privacy protection in blockchain, characterized in that, The blockchain includes blockchain assets from multiple clients, including a first client and a second client. The first client conducts asset transactions with the second client through the blockchain. Both the first client and the second client support running zero-knowledge proof algorithms. These zero-knowledge proof algorithms are used to prove nondeterministic polynomial-time NP statements, wherein the NP statements include the following: The first NP statement indicates that it is necessary to verify that the actual balance of the blockchain assets of the proof client is greater than the target balance, wherein the target balance is determined based on the blockchain assets to be traded in the asset transaction; the second NP statement indicates that it is necessary to prove that the first target hash value is obtained based on the random number generated by the proof client, the actual balance of the blockchain assets of the proof client, the identifier of the contract to which the blockchain assets of the proof client belong, the block height on which the asset transaction takes place, and the public key of the proof client; the third NP statement indicates that it is necessary to prove that the address of the proof client is included in the address list of multiple clients, wherein the blockchain assets of each client in the address list are greater than the target balance; the fourth NP statement indicates that it is necessary to verify the digital signature generated by the proof client based on the public key of the proof client, wherein the method includes: The first client generates a first proof based on the NP statement and the zero-knowledge proof algorithm.

2. The method according to claim 1, characterized in that, The first client generates a first proof based on the NP statement and the zero-knowledge proof algorithm, including: The first client obtains first private information and first public information based on the NP statement. The first private information includes a first random number generated by the first client, the public key of the first client, a first digital signature generated by the first client, and the real balance of the blockchain assets of the first client. The first public information includes a first hash value, a first address list, the asset exchange at the first block height, the first balance, and the identifier of the first contract to which the blockchain assets of the first client belong. The first client generates the first proof based on the zero-knowledge proof algorithm, the first private information, and the first public information.

3. The method according to claim 2, characterized in that, Each client in the first address list has blockchain assets greater than the first balance, which is determined based on the blockchain assets to be traded in the asset transaction.

4. The method according to claim 2 or 3, characterized in that, The method further includes: The first client obtains the first hash value based on the first random number, the first balance, the first client's public key, the identifier of the first contract, and the first block height; The first client obtains the first digital signature based on its private key and the first random number.

5. The method according to any one of claims 1 to 4, characterized in that, The method further includes: The first client sends a first proof message to the second client through the blockchain, the first proof message carrying the first proof; The second client receives the first proof message from the first client; The second client verifies the NP statement based on the zero-knowledge proof algorithm and the first proof.

6. The method according to claim 5, characterized in that, The proof message also carries first disclosure information, which includes the first digital signature, the first random number, and the public key of the first client. The method further includes: The second client verifies whether the first disclosed information is correct.

7. The method according to claim 6, characterized in that, The second client verifies whether the first disclosed information is correct, including: The second client obtains the disclosed balance of the first client's blockchain assets based on the first block height, the identifier of the first contract, and the public key of the first client; The second client obtains the first disclosure hash value based on the first digital signature, the first random number, the first client's public key, and the disclosed balance of the first client's blockchain assets in the first disclosure information; The second client determines whether the first disclosure information is correct based on the first disclosure hash value and the first hash value.

8. The method according to claim 7, characterized in that, If the first hash value is equal to the first revealed hash value, the method further includes: The second client verifies the first digital signature based on the first client's public key and the first random number in the first disclosure information; The second client determines whether the first disclosure information is correct based on whether the first digital signature is successfully verified.

9. The method according to claim 8, characterized in that, If the first digital signature verification is successful, the method further includes: The second client obtains the actual balance of the first client's blockchain assets based on the first block height, the identifier of the first contract, and the public key of the first client in the first disclosure information.

10. The method according to any one of claims 1 to 9, characterized in that, The method is applied to a cloud system, which includes infrastructure that provides cloud services and in which the blockchain is deployed.

11. A method for privacy protection in blockchain, characterized in that, The blockchain includes blockchain assets from multiple clients, including a first client and a second client. The first client conducts asset transactions with the second client through the blockchain. Both the first client and the second client support running zero-knowledge proof algorithms. These zero-knowledge proof algorithms are used to prove nondeterministic polynomial-time NP statements, wherein the NP statements include the following: The fifth NP statement indicates that it needs to be proven that the second target hash value is obtained based on a random number generated by the proving client, the asset identifier corresponding to the blockchain asset of the proving client, the block height where the asset transaction is located, and the public key of the proving client; the sixth NP statement indicates that it needs to be proven that the asset identifier list of multiple clients' blockchain assets includes the asset identifier of the proving client, and the value of the blockchain asset corresponding to each asset identifier included in the asset identifier list is the same; the seventh NP statement indicates that it needs to verify the digital signature generated by the proving client based on the public key of the proving client, the method including: The first client generates a second proof based on the NP statement and the zero-knowledge proof algorithm.

12. The method according to claim 11, characterized in that, The first client generates a second proof based on the NP statement and the zero-knowledge proof algorithm, including: The first client obtains second private information and second public information based on the NP statement. The second private information includes the first client's public key, the second random number generated by the first client, the second digital signature generated by the first client, and the asset identifier of the first client's blockchain asset. The second public information includes the second hash value, the first asset identifier list, and the second block height where the asset is exchanged. The first client generates the second proof based on the zero-knowledge proof algorithm, the second private information, and the second public information.

13. The method according to claim 12, characterized in that, Each asset identifier in the first asset identifier list corresponds to a blockchain asset with the same value.

14. The method according to claim 12 or 13, characterized in that, The method further includes: The first client obtains the second hash value based on the second random number, the asset identifier of the first client's blockchain asset, the second block height, and the first client's public key; The first client obtains the second digital signature based on its private key and the second random number.

15. The method according to any one of claims 11 to 14, characterized in that, The method further includes: The first client sends a second proof message to the second client through the blockchain, the second proof message carrying the second proof; The second client receives the second proof message from the first client; The second client verifies the NP statement based on the zero-knowledge proof algorithm and the second proof.

16. The method according to claim 15, characterized in that, The second proof message also carries second disclosure information, which includes the second digital signature, the second random number, the public key of the first client, and the asset identifier of the blockchain asset of the first client. The method further includes: The second client verifies whether the second disclosed information is correct.

17. The method according to claim 16, characterized in that, The first client verifies whether the second disclosure information is correct, including: The second client obtains the second reveal hash value based on the second block height, the asset identifier of the first client's blockchain asset, the first client's public key, and the second random number; The second client determines whether the second disclosure information is correct based on the second hash value and the second disclosure hash value.

18. The method according to claim 17, characterized in that, If the second revealed hash value is equal to the second hash value, the method further includes: The second client verifies the second digital signature based on the first client's public key and the second random number in the second disclosure information; The second client determines whether the second disclosure information is correct based on whether the second digital signature is successfully verified.

19. The method according to claim 18, characterized in that, If the second digital signature verification is successful, the method further includes: The second client obtains the blockchain asset corresponding to the asset identifier of the first client's blockchain asset based on the second block height, the asset identifier of the first client's blockchain asset, and the public key of the first client.

20. The method according to any one of claims 11 to 19, characterized in that, The method is applied to a cloud system, which includes infrastructure that provides cloud services and in which the blockchain is deployed.

21. A communication device, characterized in that, The communication device includes a module or unit for implementing the method executed by the first client according to any one of claims 1 to 10, or the communication device includes a module or unit for implementing the method executed by the first client according to any one of claims 11 to 20.

22. A communication device, characterized in that, The communication device includes a module or unit for implementing the method executed by the second client according to any one of claims 1 to 10, or the communication device includes a module or unit for implementing the method executed by the second client according to any one of claims 11 to 20.

23. A computer program product containing instructions, characterized in that, When the instruction is executed by the computing device cluster, it causes the computing device cluster to perform the method as described in any one of claims 1 to 10, or causes the computing device cluster to perform the method as described in any one of claims 11 to 20.

24. A computer-readable storage medium, characterized in that, It includes a computer program or instructions that, when executed by a cluster of computing devices, perform the method as described in any one of claims 1 to 10, or the cluster of computing devices performs the method as described in any one of claims 11 to 20.

25. A communication system, characterized in that, The communication system includes a first client and a second client, the first client and the second client being used to execute the method described in any one of 1 to 10 above, or the first client and the second client being used to execute the method described in any one of 11 to 20 above.

Images