WO2021228239A1

WO2021228239A1 - Asset type consistency evidence generation method and system, transaction method and system, and transaction verification method and system

Info

Publication number: WO2021228239A1
Application number: PCT/CN2021/093889
Authority: WO
Inventors: 张文彬
Original assignee: 支付宝(杭州)信息技术有限公司
Priority date: 2020-05-15
Filing date: 2021-05-14
Publication date: 2021-11-18
Also published as: CN111340494B; CN111340494A

Abstract

An asset type consistency evidence generation method and system, a transaction method and system, and a transaction verification method and system. The asset type consistency evidence generation method comprises: a device of a transaction initiator generating reference ciphertext of a target asset type (210); using a first private key to generate a first digital signature for a message that includes the reference ciphertext, and first verification ciphertext of the transaction initiator (230); obtaining a second digital signature, which is generated by using a second private key, for a message that includes the reference ciphertext, and second verification ciphertext of a transaction receiver (240); and obtaining asset type consistency evidence that includes the first verification ciphertext, the second verification ciphertext, the reference ciphertext, the first digital signature and the second digital signature (250). The asset type consistency evidence can be used for proving that the first verification ciphertext, the second verification ciphertext and the reference ciphertext are obtained on the basis of the same asset type. On this basis, insofar as the privacy of transaction parties is protected, zero-knowledge proof which is capable of publicly verifying whether verification ciphertext corresponding to both parties of the transaction is obtained on the basis of the same asset type can be provided.

Description

Asset type consistency evidence generation, transaction, transaction verification method and system

Technical field

The embodiments of this specification relate to the field of information technology, and in particular to methods and systems for generating, transaction, and transaction verification of asset type consistency evidence.

Background technique

The type of assets (such as RMB, US dollars, securities, etc.) used by an entity (such as an institution, company, etc.) to conduct business may be the entity's business secrets, and privacy protection is required to prevent external (such as competitors) from leaking. In addition, the leakage of asset types may result in more private information of the entity being obtained. For example, in cross-border remittances or in the supply chain, it is possible to infer the entity's location based on the asset type, and then infer the entity's identity information. In order to prevent privacy leakage, the entity will upload the ciphertext of the asset type to the chain during the transaction. Due to stricter privacy protection requirements, even if entities use public encryption algorithms to encrypt the identification information of the same asset type, each entity will use different private values (such as random numbers) to generate ciphertexts for that asset type, so Entities have different ciphertexts for the same asset type.

In view of this, it is hoped that under the premise of protecting data privacy, a solution that can publicly verify whether the ciphertext of the asset type of both parties in the transaction is generated based on the same asset type is expected to ensure that both parties to the transaction conduct transactions for the same asset type.

Summary of the invention

One of the embodiments of this specification provides a method for generating an asset type consistency evidence, wherein the method is executed by a device of a transaction initiator, which includes: generating a reference ciphertext of the target asset type; generating a first private key, wherein, The result of performing the target operation on the first verification ciphertext of the target asset type and the reference ciphertext is the first public key matching the first private key, and the first verification ciphertext is initiated with the transaction Corresponding to the party, the target operation satisfies: the result of the target operation on the reference ciphertext and the verification ciphertext of the same object is the public key matching the private key, and the private key is used to generate the ciphertext of the same object. The secret value is obtained; the first private key is used to generate a first digital signature on a first signed message, wherein the first signed message includes the first verification ciphertext and the reference ciphertext; the second private key is used to obtain A second digital signature generated by a key on a second signed message, wherein the second signed message includes a second verification ciphertext of the target asset type and the reference ciphertext, and the second verification ciphertext is related to the transaction receiving Corresponding to the party, the result of performing the target operation on the second verification ciphertext and the reference ciphertext is a second public key matching the second private key; obtaining the first verification ciphertext, the second public key The second verification ciphertext, the reference ciphertext, the first digital signature, and the evidence of the second digital signature to prove that the first verification ciphertext, the second verification ciphertext and the reference The ciphertext is obtained based on the same asset type.

One of the embodiments of this specification provides an asset type consistency evidence generation system, wherein the system is implemented on the device of the transaction initiator and includes: a reference ciphertext generation module for generating a reference ciphertext of the target asset type The first private key generation module is used to generate a first private key, wherein the result of performing a target operation on the first verification ciphertext of the target asset type and the reference ciphertext is a match with the first private key The first public key of the first verification ciphertext corresponds to the transaction initiator, and the target operation satisfies: the result of performing the target operation on the reference ciphertext and the verification ciphertext of the same object matches the private key The private key is obtained from the private value used to generate the ciphertext of the same object; the first digital signature module is used to generate a first digital signature on the first signed message using the first private key, wherein, The first signed message includes the first verification ciphertext and the reference ciphertext; a second digital signature obtaining module is configured to obtain a second digital signature generated on a second signed message using a second private key, wherein, The second signature message includes a second verification ciphertext of the target asset type and the reference ciphertext, the second verification ciphertext corresponds to the transaction receiver, and the second verification ciphertext and the reference ciphertext are The result of performing the target operation on the ciphertext is the second public key that matches the second private key; the asset type consistency evidence obtaining module is used to obtain the first verification ciphertext and the second verification secret. Evidence of the text, the reference ciphertext, the first digital signature and the second digital signature to prove that the first verification ciphertext, the second verification ciphertext and the reference ciphertext are based on the same asset Type get.

One of the embodiments of this specification provides a device for generating evidence of asset type consistency, which includes a processor and a storage device. The storage device is used to store instructions. When the processor executes the instructions, the implementation is as follows: The method for generating asset type consistency evidence executed by the device of the transaction initiator described in the embodiment.

One of the embodiments of this specification provides a method for generating an asset type consistency evidence, wherein the method is executed by a device of a transaction receiver, which includes: receiving a reference ciphertext of a target asset type from the transaction initiator; and generating a second A private key, wherein the result of performing a target operation on the second verification ciphertext of the target asset type and the reference ciphertext is a second public key matching the second private key, and the second verification ciphertext Corresponding to the transaction receiver, the target operation satisfies: the result of performing the target operation on the reference ciphertext and verification ciphertext of the same object is a public key that matches a private key, and the private key is used to generate the same Obtain the private value of the ciphertext of the object; use the second private key to generate a second digital signature on a second signed message, where the second signed message includes the second verification ciphertext and the reference ciphertext; The second verification ciphertext and the second digital signature are sent to the device of the transaction initiator, so that the device of the transaction initiator obtains the first verification ciphertext containing the target asset type, the The second verification ciphertext, the reference ciphertext, the first digital signature, and the evidence of the second digital signature, wherein the first verification ciphertext corresponds to the transaction initiator, and the first digital signature is A first signed message is generated using a first private key, and the first signed message includes the second verification ciphertext and the reference ciphertext, and the evidence is used to prove that the first verification ciphertext, the The second verification ciphertext and the reference ciphertext are obtained based on the same asset type.

One of the embodiments of this specification provides an asset type consistency evidence generation system, wherein the system is implemented on the device of the transaction receiver, and includes: a reference ciphertext receiving module for receiving target assets from the transaction initiator Type of reference ciphertext; a second private key generation module for generating a second private key, wherein the result of performing a target operation on the second verification ciphertext of the target asset type and the reference ciphertext is the same as the The second public key matched by the second private key, the second verification ciphertext corresponds to the transaction recipient, and the target operation satisfies: the result of the target operation performed on the reference ciphertext and the verification ciphertext of the same object Is a public key that matches the private key, and the private key is derived from the private value of the ciphertext used to generate the same object; the second digital signature module is used to generate a second signature message for the second signature using the second private key Digital signature, wherein the second signature message includes the second verification ciphertext and the reference ciphertext; a sending module is configured to send the second verification ciphertext and the second digital signature to the The device of the transaction initiator, so that the device of the transaction initiator obtains the first verification ciphertext, the second verification ciphertext, the reference ciphertext, the first digital signature, and the target asset type. Evidence of the second digital signature, wherein the first verification ciphertext corresponds to the transaction initiator, the first digital signature is generated by using a first private key on a first signed message, and the first signed message It includes the second verification ciphertext and the reference ciphertext, and the evidence is used to prove that the first verification ciphertext, the second verification ciphertext, and the reference ciphertext are obtained based on the same asset type.

One of the embodiments of this specification provides a device for generating evidence of asset type consistency, which includes a processor and a storage device. The storage device is used to store instructions. When the processor executes the instructions, the implementation is as follows: The method for generating the asset type consistency evidence executed by the device of the transaction receiver described in the embodiment.

One of the embodiments of this specification provides a transaction method, which includes: obtaining the verification ciphertext and reference ciphertext corresponding to both parties to the transaction through the method for generating evidence of consistency of asset type as described in any embodiment of this specification Evidence obtained based on the same asset type; use the private key of the transaction initiator or the transaction receiver to generate a third digital signature on the third signature message, the third message to be signed includes the identification information of the accounts of both parties to the transaction and the evidence; The third signature message and the third digital signature are uploaded to the blockchain network.

One of the embodiments of this specification provides a transaction system, which includes: an obtaining module, which is used to obtain the verification secret used to prove that the transaction parties correspond to the asset type consistency evidence generation method as described in any embodiment of this specification. The text and the reference ciphertext are based on the evidence obtained from the same asset type; the third digital signature module is used to generate a third digital signature on the third signature message using the private key of the transaction initiator or the transaction receiver, the third message to be signed Including the identification information of the accounts of both parties to the transaction and the evidence; the upload module is used to upload the third signature message and the third digital signature to the blockchain network.

One of the embodiments of this specification provides a transaction device, which includes a processor and a storage device. The storage device is used to store instructions. Trading method.

One of the embodiments of this specification provides a transaction verification method, which includes: receiving a third signature message and a third digital signature, where the third signature message includes a reference ciphertext and a first verification ciphertext corresponding to the transaction initiator And the first digital signature, the second verification ciphertext and the second digital signature corresponding to the transaction receiver; verify the third digital signature based on the public key of the transaction initiator or transaction receiver and the third signature message; When the third digital signature passes the verification: perform a target operation on the reference ciphertext and the first verification ciphertext to obtain a first public key for verifying the first digital signature, based on the reference ciphertext And the first verification ciphertext to obtain a first signed message for verifying the first digital signature, and verify the first digital signature based on the first public key and the first signed message; and/or , Performing the target operation on the reference ciphertext and the second verification ciphertext to obtain a second public key for verifying the second digital signature, based on the reference ciphertext and the second verification ciphertext The text obtains a second signature message for verifying the second digital signature, and verifies the second digital signature based on the second public key and the second signature message; if the first digital signature and the first digital signature If the second digital signature is verified, it is determined that the first verification ciphertext, the second verification ciphertext, and the reference ciphertext are obtained based on the same asset type.

One of the embodiments of this specification provides a transaction verification system, which includes: a receiving module for receiving a third signature message and a third digital signature. The third signature message includes a reference ciphertext and a first corresponding to the transaction initiator. The verification ciphertext and the first digital signature, the second verification ciphertext and the second digital signature corresponding to the transaction receiver; the first verification module is used to verify the public key based on the transaction initiator or the transaction receiver and the third signature Message, verifying the third digital signature; a second verification module, when the third digital signature is verified: perform target operations on the reference ciphertext and the first verification ciphertext to obtain a verification The first public key of the first digital signature obtains a first signed message for verifying the first digital signature based on the reference ciphertext and the first verification ciphertext, based on the first public key and Verifying the first digital signature by the first signature message; and/or performing the target operation on the reference ciphertext and the second verification ciphertext to obtain the first digital signature for verifying the second digital signature A second public key, based on the reference ciphertext and the second verification ciphertext, to obtain a second signature message for verifying the second digital signature, and verifying the second signature message based on the second public key and the second signature message The second digital signature; a determining module, configured to: if the first digital signature and the second digital signature pass verification, determine the first verification ciphertext, the second verification ciphertext, and the reference The ciphertext is obtained based on the same asset type.

One of the embodiments of this specification provides a transaction verification device, which includes a processor and a storage device. The storage device is used to store instructions. The transaction verification method.

One of the embodiments of this specification provides a method for generating object consistency evidence, wherein the method is executed by a device of any participant in a transaction, which includes: obtaining a reference ciphertext of a target object; generating a target private key, wherein, The result of performing a target operation on the verification ciphertext of the target object and the reference ciphertext is the target public key matching the target private key, and the target operation satisfies: the reference ciphertext and the verification ciphertext of the same object The result of the target operation is a public key that matches the private key, which is obtained from the private value of the ciphertext used to generate the same object; the target private key is used to generate a target digital signature on the target signed message, where , The target signature message includes the verification ciphertext and the reference ciphertext; obtaining evidence containing at least the verification ciphertext, the reference ciphertext, and the target digital signature to at least prove the verification ciphertext Obtained based on the same object as the reference ciphertext.

One of the embodiments of the present specification provides an object consistency evidence generation system, wherein the system is implemented on the device of any participant in the transaction, and includes: a reference ciphertext obtaining module for obtaining the reference cipher of the target object The private key generation module is used to generate a target private key, wherein the result of the target operation on the verification ciphertext of the target object and the reference ciphertext is the target public key that matches the target private key, so The target operation satisfies: the result of performing the target operation on the reference ciphertext and the verification ciphertext of the same object is a public key matching the private key, and the private key is obtained from the private value used to generate the ciphertext of the same object; A digital signature module for generating a target digital signature on a target signature message using the target private key, wherein the target signature message includes the verification ciphertext and the reference ciphertext; an object consistency evidence obtaining module is used for Obtaining evidence including at least the verification ciphertext, the reference ciphertext, and the target digital signature to at least prove that the verification ciphertext and the reference ciphertext are obtained based on the same object.

One of the embodiments of this specification provides a device for generating object consistency evidence, which includes a processor and a storage device. The storage device is used to store instructions. When the processor executes the instructions, the implementation can be implemented as in any implementation of this specification. The method for generating object consistency evidence described in the example.

Description of the drawings

This specification will be further described in the form of exemplary embodiments, and these exemplary embodiments will be described in detail with the accompanying drawings. These embodiments are not restrictive. In these embodiments, the same number represents the same structure, in which:

Fig. 1 is a schematic diagram of an application scenario of a blockchain system according to some embodiments of this specification;

Fig. 2 is an exemplary flow chart of a method for generating evidence of consistency of asset types according to an embodiment of the present specification;

Fig. 3 is an exemplary flowchart of a method for generating evidence of consistency of asset types according to an embodiment of the present specification;

Fig. 4 is an exemplary flowchart of a transaction method according to some embodiments of the present specification;

Fig. 5 is an exemplary flowchart of a transaction verification method according to some embodiments of the present specification;

Fig. 6 is an exemplary flowchart of a method for generating object consistency evidence according to some embodiments of the present specification;

Fig. 7 is an exemplary block diagram of an asset type consistency evidence generating system according to some embodiments of the present specification;

Fig. 8 is an exemplary block diagram of an asset type consistency evidence generating system according to some embodiments of the present specification;

Fig. 9 is an exemplary block diagram of a transaction system according to some embodiments of the present specification;

Fig. 10 is an exemplary block diagram of a transaction verification system according to some embodiments of the present specification;

Fig. 11 is an exemplary block diagram of an object consistency evidence generating system according to some embodiments of the present specification.

Detailed ways

In order to more clearly describe the technical solutions of the embodiments of the present specification, the following will briefly introduce the accompanying drawings used in the description of the embodiments. Obviously, the drawings in the following description are only some examples or embodiments of this specification. For those of ordinary skill in the art, this specification can also be applied to these drawings without creative work. Other similar scenarios. Unless it is obvious from the language environment or otherwise stated, the same reference numerals in the figures represent the same structure or operation.

It should be understood that the “system”, “device”, “unit” and/or “module” used herein is a method for distinguishing different components, elements, parts, parts, or assemblies of different levels. However, if other words can achieve the same purpose, the words can be replaced by other expressions.

As shown in this specification and claims, unless the context clearly indicates exceptions, the words "a", "an", "an" and/or "the" do not specifically refer to the singular, but may also include the plural. Generally speaking, the terms "include" and "include" only suggest that the clearly identified steps and elements are included, and these steps and elements do not constitute an exclusive list, and the method or device may also include other steps or elements.

In this specification, a flowchart is used to illustrate the operations performed by the system according to the embodiment of this specification. It should be understood that the preceding or following operations are not necessarily performed exactly in order. Instead, the individual steps can be processed in reverse order or simultaneously. At the same time, other operations can be added to these processes, or a certain step or several operations can be removed from these processes.

The embodiments in this specification can provide a zero-knowledge proof of the consistency of asset types in an electronic transaction scenario that relies on the blockchain. That is, the transaction initiator can use any useful information (for example, the private value used to generate the ciphertext of the asset type, the identification information of the asset type corresponding to the transaction asset) to the blockchain node as the verifier, so that The blockchain node is sure that the ciphertext of the asset type corresponding to both parties to the transaction (that is, the verification ciphertext in the following text) is obtained based on the same asset type.

Fig. 1 is a schematic diagram of an application scenario of a blockchain system according to some embodiments of this specification. As shown in FIG. 1, the blockchain system 100 may include a blockchain client 110 (may be referred to as a client for short), a blockchain network 120, and a network 130, where the blockchain network 120 includes more than one blockchain node (Can be referred to as "node" for short), such as blockchain node-1, 120-2, 120-3...120-n, etc.

The blockchain client 110 can be connected to the blockchain network 120 through the network 130. Entities can access the blockchain network 120 through the blockchain client 110, and entities that join the blockchain network 120 can also be referred to as blockchain members. In some embodiments, the blockchain client 110 can upload information and/or data to one or more blockchain nodes in the blockchain network 120, such as uploading transaction records. In some embodiments, the transaction record may include transaction information (may be simply referred to as "transaction") written in the block. In some embodiments, the blockchain client 110 may initiate a query to one or more blockchain nodes in the blockchain network 120 to obtain the area stored in the blockchain (i.e., distributed ledger, which is continuously generated). The data in the block chained), such as transactions.

In some embodiments, the user terminal of the transaction initiator may attach evidence used to prove the consistency of the asset type (that is, the verification ciphertext of both parties to the transaction is obtained based on the same asset type) to the transaction and upload it to the blockchain network 120 , So that the node performs the expected follow-up process after at least passing the verification of the consistency of the asset type, for example, writing the transaction to the block, updating the accounts of both parties to the transaction, and so on.

In some embodiments, the user terminal may include various types of devices with information receiving and/or sending functions. In some embodiments, the user terminal may include a smart phone, a tablet computer, a personal computer, a server, etc., or any combination thereof.

Each node in the blockchain network 120 needs to verify and confirm the transaction, and then generate a new block (this process can be called "accounting"). At the same time, each node can maintain the data stored in each node through a consensus mechanism. Consistency of distributed ledgers. It is worth noting that the blockchain node can also be regarded as the client terminal of the blockchain network 120. Unlike other client terminals, the blockchain node needs to participate in accounting. In addition, the entity can join the blockchain network 120 through a user terminal that does not participate in accounting, and can also join the blockchain network 120 through a blockchain node that participates in accounting.

In some embodiments, the node may verify the evidence in the transaction to confirm whether the verification ciphertext corresponding to both parties to the transaction is obtained based on the same asset type. If the verification of the consistency of the asset type is not passed, that is, it is determined that the verification ciphertext corresponding to the transaction parties is not based on the same asset type, the node may refuse to perform the expected follow-up process, for example, write the transaction to the block and update the transaction of both parties. Account and so on. It should be understood that in addition to the verification of the consistency of the asset type, the verification of the transaction may also include other verifications, such as verification of the legality of the amount. In some embodiments, the node may execute the expected subsequent process after passing multiple verifications of the transaction. For more details about transaction verification, please refer to Figure 5 and its related descriptions.

In some embodiments, nodes may include various types of computing devices, such as servers.

In some embodiments, the server may be an independent server or a server group, and the server group may be centralized or distributed. In some embodiments, the server may be regional or remote. In some embodiments, the server may be executed on a cloud platform. For example, the cloud platform may include one or any combination of private cloud, public cloud, hybrid cloud, community cloud, decentralized cloud, internal cloud, etc.

The network 130 connects the various components of the system so that communication between the various components can be carried out. The network between the various parts in the system may include a wired network and/or a wireless network. For example, the network 130 may include a cable network, a wired network, an optical fiber network, a telecommunication network, an internal network, the Internet, a local area network (LAN), a wide area network (WAN), a wireless local area network (WLAN), a metropolitan area network (MAN), public Switched telephone network (PSTN), Bluetooth network, ZigBee network (ZigBee), near field communication (NFC), device bus, device line, cable connection, etc. or any combination thereof. The network connection between each two parts can adopt one of the above-mentioned methods, or it can adopt multiple methods. It is understandable that the network 130 and the blockchain network 120 do not have to have a clear boundary. In a more general application scenario, the blockchain node and the ordinary network node can be connected to the same physical network, and the blockchain node is in the logical The above constitutes a blockchain network.

Fig. 2 is an exemplary flow chart of a method for generating evidence of consistency of asset types according to some embodiments of the present specification. The process 200 can be executed by the device of the transaction initiator of the transaction, and the device of the transaction initiator can be connected to the blockchain network 120 as a client (blockchain client 110 or blockchain node). As shown in FIG. 2, the process 200 may include: step 210, generating a reference ciphertext of the target asset type. In some embodiments, step 210 can be implemented by the reference ciphertext generation module 710.

It should be understood that the user end in the blockchain network 120 may use a public encryption algorithm to generate the verification ciphertext and the reference ciphertext of the asset type.

Step 220: Generate a first private key. In some embodiments, step 220 may be implemented by the first private key generation module 720.

Wherein, the result of performing the target operation on the first verification ciphertext and the reference ciphertext of the target asset type is the first public key matching the first private key, and the first verification ciphertext corresponds to the transaction initiator.

The target operation mentioned in this manual satisfies: the result of the target operation on the reference ciphertext and verification ciphertext of the same object is the public key matching the private key, and the private key is used to generate the ciphertext of the same object. It's worth getting. Based on this, if the private key is used to generate a digital signature, only the matching public key can be used to successfully verify the signature. That is, the target operation limits the public key that can be successfully verified. The premise is: verify ciphertext and reference ciphertext Based on the same object (asset type).

In step 220, the first private key can be obtained from the private value of the first verification ciphertext and/or the reference ciphertext used to generate the target asset type, and only the first public key that matches it can be successfully verified. Step 230 Use the first private key to generate the first digital signature. It should be understood that the private value can refer to the value used by any transaction party (transaction initiator or transaction receiver) to generate the ciphertext of the asset type and not publicly disclosed, because the leakage of the private value will cause the disclosure of the plaintext corresponding to the ciphertext ( That is, the identification information of the asset type) risk.

Just as an example, the verification ciphertext and the reference ciphertext are obtained based on the Pedersen commitment protocol. The following introduces the relevant knowledge of the Pedersen commitment protocol: the ciphertext based on the Pedersen commitment protocol satisfies C=r ₁ *G+r ₂ *H, where G and H are generators (also called base points) on the elliptic curve, r ₁ and r ₂ are integers, and r ₁ *G, r ₂ *H and C are still points on the elliptic curve.

It should be noted that the operations involving elliptic curves in this manual have similar properties to the four arithmetic operations, so the representation methods of the four arithmetic operations (such as addition, subtraction, multiplication, +, -, *) are borrowed, but this does not mean These operations involving elliptic curves can be equivalent to the four arithmetic operations. In addition, in the embodiment of this specification, the user end in the blockchain network 120 may have some common parameters, for example, the parameters of the elliptic curve equation, G, H, and so on. Among them, any one of G and H can be used as a public key generation parameter, and the public key generation parameter may be denoted as G, that is, if the private key is r, then r*G is the public key matching the private key r.

In some embodiments, the verification ciphertext and the reference ciphertext of any transaction party (transaction initiator or transaction recipient) respectively include a first part corresponding to G and a second part corresponding to H, wherein the first verification secret The first part of the text is obtained based on the first generator and the private value corresponding to the transaction initiator. The first part of the second verification ciphertext is obtained based on the first generator and the private value corresponding to the transaction receiver. The first verification ciphertext, The second verification ciphertext and the second part of the reference ciphertext are equal and are respectively obtained based on the identification information of the second generator and the target asset type. Correspondingly, the target operation can be the difference. In this way, only by calculating the difference between the verification ciphertext and the reference ciphertext of the same asset type, so that the second part of the two is offset, can the public key for verification be obtained (the expanded form includes the public key generation parameter G).

For example, the verification ciphertext of any transaction party (transaction initiator or transaction receiver) can be calculated as C_X=r_X*Pk_X+sn*H, where C_X represents the verification cipher text of the transaction party, and r_X represents a random number (depending on Is the private value of the transaction party), Pk_X represents the public key of the transaction party, and sn represents the identification information of the target asset type. It is worth noting that, given that Pk_X=Pr_X*G, where Pr_X represents the private key of the transaction party (another private value of the transaction party), the essence of the verification ciphertext calculated by C_X=r_X*Pk_X+sn*H The above is a ciphertext based on the Pedersen commitment protocol.

It can be seen that the first verification ciphertext of the transaction initiator C_A=r_A*Pk_A+sn*H, where r_A represents the first random number (considered as the private value of the transaction initiator), and Pk_A represents the public key of the transaction initiator (Pk_A=Pr_A*G is satisfied, where Pr_A represents the private key of the transaction initiator).

When the verification ciphertext is calculated according to C_X=r_X*Pk_X+sn*H, the reference ciphertext can be calculated according to C ₀ ＝r ₀ *G+sn*H, where C ₀ means the reference ciphertext, and r ₀ means the third random R ₀ can be regarded as a private value that is restricted to be shared between the transaction initiator and the transaction receiver. Based on this, the target operation can refer to the difference between the verification ciphertext and the reference ciphertext (C_X-C ₀ or C ₀ -C_X). It should be understood that since the verification ciphertext and the reference ciphertext are obtained based on the same asset type, the sn*H contained in the two will be offset in the process of calculating the difference, and C_X-C ₀ =(r_X*Pr_X-r ₀ ) *G or C ₀ -C_X=(r ₀ -r_X*Pr_X)*G, where r_X*Pr_X-r ₀ (or r ₀ -r_X*Pr_X) can be regarded as a private key. For example, if the first verification ciphertext C_A=r_A*Pk_A+sn*H and the reference ciphertext C ₀ =r ₀ *G+sn*H, the first public key can be C_A-C ₀ (or C ₀ -C_A ), the device of the transaction initiator can calculate r_A*Pr_A-r ₀ (or r ₀ -r_A*Pr_A) to obtain the first private key.

Step 230: Use the first private key to generate a first digital signature on the first signed message. Wherein, the first signature message includes the first verification ciphertext and the reference ciphertext. In some embodiments, step 230 may be implemented by the first digital signature module 730.

Step 240: Obtain a second digital signature generated by using the second private key on the second signed message. Wherein, the second signature message includes a second verification ciphertext and a reference ciphertext, the second verification ciphertext corresponds to the transaction receiver, and the result of performing the target operation on the second verification ciphertext and the reference ciphertext is the same as the second private The second public key that the key matches. In some embodiments, step 240 may be implemented by the second digital signature obtaining module 740.

Step 250: Obtain evidence including the first verification ciphertext, the second verification ciphertext, the reference ciphertext, the first digital signature, and the second digital signature to prove the first verification ciphertext, the second verification ciphertext, and the reference ciphertext Obtained based on the same asset type. In some embodiments, step 250 may be implemented by the asset type consistency evidence obtaining module 750.

It should be understood that the first verification ciphertext can be used to update the account of the transaction initiator, and the second verification ciphertext can be used to update the account of the transaction receiver.

The first digital signature and the reference ciphertext and the first verification ciphertext are related to each other. When the first digital signature is verified, it can be proved that the associated first verification ciphertext and the reference ciphertext have not been tampered with and both are based on the same asset type get. Similarly, the second digital signature and the reference ciphertext and the second verification ciphertext are related to each other. When the second digital signature is verified, it can be proved that the associated second verification ciphertext and the reference ciphertext have not been tampered with and both are based on Get the same asset type. Furthermore, the evidence containing the first verification ciphertext, the second verification ciphertext, the reference ciphertext, the first digital signature, and the second digital signature (hereinafter referred to as the asset type consistency evidence) can prove that the first verification ciphertext, the second verification ciphertext, and the second The verification ciphertext and the reference ciphertext are obtained based on the same asset type. When both the first digital signature and the second digital signature pass the verification (that is, the asset type consistency evidence is verified), it can be confirmed that the first verification ciphertext, the second verification ciphertext, and the reference ciphertext are obtained based on the same asset type.

After obtaining the proof of asset type consistency, the device of the transaction initiator can attach the proof of asset type consistency to the transaction and upload the transaction to the blockchain network 120 to prove that the first verification ciphertext and the second verification ciphertext are based on Get the same asset type.

For more details on verifying the proof of asset type consistency, please refer to Figure 5 and its related description.

In some embodiments, considering that the account of the transaction receiver may not have registered the target asset type, the device of the transaction initiator may generate the second verification ciphertext of the transaction receiver. Of course, the device of the transaction initiator may send the second verification ciphertext and the private value used to generate the second verification ciphertext to the device of the transaction receiver. In some embodiments, the device of the transaction initiator may also generate a second digital signature based on the generated second verification ciphertext and the reference ciphertext to prove that the second verification ciphertext and the reference ciphertext are obtained based on the same asset type.

In some embodiments, the device of the transaction initiator may send the reference ciphertext to the device of the transaction receiver, so that the device of the transaction receiver can generate a certificate for proving that the second verification ciphertext and the reference ciphertext are based on the same asset type. The second digital signature.

In some embodiments, the device of the transaction recipient may verify the received reference ciphertext. Based on this, when the reference ciphertext is generated based on at least the third random number (for example, calculated by C ₀ =r ₀ *G+sn*H), the device of the transaction initiator can send the third random number to the transaction receiver device of. The device of the transaction receiver can generate a comparison reference ciphertext based on the third random number and the identification information of the target asset type, and compare the received reference ciphertext with the comparison reference ciphertext. approved. When the verification of the received reference ciphertext is not passed, the device of the transaction receiver may refuse to perform the subsequent process, for example, no longer generate the second private key.

The leakage of the third random number may lead to the leakage of the target asset type. For example, when the attacker knows the third random number (especially when he also knows the asset type list containing the target asset type), he can try to combine multiple The identification information of the asset type is respectively substituted into the calculation formula of the reference ciphertext. If a calculated result is found to be consistent with the publicly available reference ciphertext, the asset type corresponding to the result can be determined, that is, the target asset type. In view of this, the device of the transaction initiator can encrypt the third random number and transmit it to the device of the transaction receiver. Specifically, the device of the transaction initiator can use the public key of the transaction receiver to encrypt the message containing the third random number, and send the encrypted message to the device of the transaction receiver, so that the device of the transaction receiver can use the transaction initiator The private key decrypts the third random number.

In some embodiments, the device of the transaction initiator may encrypt and transmit the identification information of the target asset type to the device of the transaction recipient. Although the device of the transaction receiver can filter out the target asset type by encrypting the identification information of one or more asset types, it is clear that it is a more direct and effective way for the transaction initiator to inform the transaction receiver of the target asset type's identification information.

The foregoing embodiments can be appropriately combined. For example, the device of the transaction initiator can send a message sequence (C ₀ , r ₀ , sn; C_A, P_A) to the device of the transaction receiver, where C ₀ represents the reference ciphertext, r ₀ represents the third random number, sn represents the identification information of the target asset type, C_A represents the first verification cipher text, and P_A represents the first digital signature. Among them, at least r ₀ and sn can be encrypted to prevent the leakage of the target asset type. For example, the message sequence can be encrypted using the public key of the transaction receiver, and the encrypted message sequence can be sent to the transaction receiver’s equipment.

Fig. 3 is an exemplary flow chart of a method for generating an asset type consistency evidence according to some embodiments of the present specification. The process 300 can be executed by the device of the transaction receiver, and the device of the transaction receiver can be connected to the blockchain network 120 as a client (blockchain client 110 or blockchain node). As shown in FIG. 3, the process 300 may include:

Step 310: Receive a reference ciphertext of the target asset type from the transaction initiator. In some embodiments, step 310 may be implemented by the reference ciphertext receiving module 810.

In some embodiments, the device of the transaction receiver may verify the received reference ciphertext. If the verification fails, the subsequent process is not executed, for example, the second private key is not generated. Specifically, in combination with the foregoing embodiments, the device of the transaction receiver can _{calculate based on the third random number r 0} and the identification information sn of the target asset type (for example, calculate by C'=r ₀ *G+sn*H) to obtain a comparison reference The ciphertext C'. Furthermore, the device of the transaction receiver compares the reference ciphertext and the reference ciphertext of the comparison text, and if the two are the same, the verification is passed, otherwise the verification is not passed.

Step 320: Generate a second private key. In some embodiments, step 320 may be implemented by the second private key generation module 820.

Wherein, the result of performing the target operation on the second verification ciphertext and the reference ciphertext of the target asset type is a second public key matching the second private key, and the second verification ciphertext corresponds to the transaction receiver. For more details about the target calculation, please refer to the related description in the process 200.

With reference to the foregoing embodiment, when the second verification ciphertext C_B=r_B*Pk_B+sn*H and the reference ciphertext C ₀ =r ₀ *G+sn*H, the second public key can be C_B-C ₀ (or C ₀ -C_B), the device of the transaction receiver can calculate r_B*Pr_B-r ₀ (or r ₀ -r_B*Pr_B) to obtain the second private key. Among them, r_B represents the second random number (considered as the private value of the transaction receiver), and Pk_B represents the public key of the transaction receiver (satisfies Pk_B=Pr_B*G, where Pr_B represents the private key of the transaction receiver).

Step 330: Use the second private key to generate a second digital signature on the second signed message. Wherein, the second signature message includes the second verification ciphertext and the reference ciphertext. In some embodiments, step 330 may be implemented by the second digital signature module 830.

When the second digital signature passes the verification, it can be proved that the associated second verification ciphertext and the reference ciphertext have not been tampered with and they are obtained based on the same asset type.

Step 340: Send the second verification ciphertext and the second digital signature to the device of the transaction initiator, so that the device of the transaction initiator obtains the asset type consistency evidence. In some embodiments, step 340 may be implemented by the sending module 840.

More details about the evidence of asset type consistency can be found in the relevant description of the process 200, and will not be repeated here.

In some embodiments, the device of the transaction recipient may receive a message sequence (C ₀ , r ₀ , sn; C_A, P_A) _{from the transaction initiator, where C 0} represents the reference ciphertext, and r ₀ represents the reference The third random number of the cipher text, sn represents the identification information of the target asset type, C_A represents the first verification cipher text, and P_A the first digital signature. Furthermore, the device of the transaction receiver can calculate the comparison reference ciphertext C'according to _{C'=r 0 *G+sn*H.} If C'=C ₀ , the device of the transaction receiver can calculate _{the difference between r_B*Pr_B and r 0} to obtain the second private key, and use the second private key to generate a second digital signature on the second signed message.

More details about the process 300 can be found in the process 200 and its related description, and will not be repeated here.

In some embodiments, the device of the transaction recipient may also receive the first verification ciphertext and the first digital signature from the transaction initiator to obtain proof of asset type consistency.

Fig. 4 is an exemplary flowchart of a transaction method according to some embodiments of the present specification. The process 400 may be executed by the device of the transaction initiator or the transaction receiver in the process 200 (or the process 300). It should be understood that when the process 400 is executed by the device of the transaction receiver in the process 200 (or the process 300), the transaction receiver in the process 200 (or the process 300) is the party that re-initiates the transaction for the target asset type. As shown in FIG. 4, the process 400 may include: Step 410: Obtain asset type consistency evidence that is used to prove that the verification ciphertext and the reference ciphertext corresponding to both parties to the transaction are based on the same asset type. In some embodiments, step 410 may be implemented by the obtaining module 910.

More information about the evidence of asset type consistency can be found in Figure 2, Figure 3 and related descriptions, so I won’t repeat them here.

Step 420: Use the private key of the transaction initiator or the transaction receiver to generate a third digital signature on the third signature message. Among them, the third message to be signed includes identification information of the accounts of both parties to the transaction and proof of asset type consistency. In some embodiments, step 420 may be implemented by the third digital signature module 920.

Step 430, upload the third signature message and the third digital signature to the blockchain network 120. In some embodiments, step 430 can be implemented by the upload module 930.

In some embodiments, the third signed message may include more content. For example, the third signature message may also include the transaction amount (in encrypted form), proof of legality of the amount, etc., where the legality of the amount of money is used to prove the legality of the value of the amount. Circumstances that will cause abnormal transactions are not allowed (ie illegal), such as the following situations: 1. The account balance of the transaction initiator is less than the transaction amount, and the account of the transaction initiator does not have the ability to pay at this time; 2. The value of the transaction amount is negative, which will cause the increase or decrease of the account amount to be contrary to the expected, that is, the account amount does not increase but decreases or does not decrease but increases.

In some embodiments, various encryption algorithms that support zero-knowledge proofs can be used to encrypt the transaction amount, for example, encryption algorithms based on the Pedersen commitment protocol, hash algorithm encryption, homomorphic encryption algorithms, and so on. In some embodiments, when the transaction amount is encrypted based on the Pedersen commitment protocol, the zero-knowledge proof technology "ring signature confidential transaction" and "Bulletproof" can be used to generate proof of the legality of the amount. In some embodiments, when a hash algorithm is used to encrypt the transaction amount, the zero-knowledge proof technology "zksnark" can be used to generate proof of the legality of the amount.

Fig. 5 is an exemplary flowchart of a transaction verification method according to some embodiments of the present specification. The process 500 may be executed by a blockchain node. As shown in FIG. 5, the process 500 may include:

Step 510: Receive a third signature message and a third digital signature. The third signature message includes a reference ciphertext, a first verification ciphertext and a first digital signature corresponding to the transaction initiator, and a second verification corresponding to the transaction receiver. The ciphertext and the second digital signature. In some embodiments, step 510 may be implemented by the receiving module 1010.

Step 520: Verify the third digital signature based on the public key of the transaction initiator or the transaction receiver and the third signature message. In some embodiments, step 520 may be implemented by the first verification module 1020.

By verifying the third digital signature, it can be determined: 1. Whether the signer is the transaction party (transaction initiator or transaction receiver in the process 200/300); 2. Whether the third signature message has been tampered with.

When the third digital signature passes the verification, it means that the signer is indeed the transaction party and the third signature message has not been tampered with, the blockchain node can continue to perform step 530. When the third digital signature fails the verification, the blockchain node may refuse to perform the subsequent process (such as step 530), that is, consider that the transaction verification fails.

Step 530, verify the first digital signature based on the first public key and the first signed message; and/or verify the second digital signature based on the second public key and the second signed message. In some embodiments, step 530 may be implemented by the second verification module 1030.

Among them, the second verification module 1030 can perform target operations on the reference ciphertext and the first verification ciphertext to obtain the first public key used to verify the first digital signature, and can be used based on the reference ciphertext and the first verification ciphertext. To verify the first signed message of the first digital signature. Similarly, the second verification module 1030 can perform target operations on the reference ciphertext and the second verification ciphertext to obtain the second public key used to verify the second digital signature, and can obtain the reference ciphertext and the second verification ciphertext based on the target operation. A second signed message used to verify the second digital signature.

If the first digital signature and the second digital signature are verified, the blockchain node may perform step 540. If the first digital signature or the second signature message fails the verification, the blockchain node may perform step 550. In some embodiments, step 540 and step 550 may be implemented by the determining module 1040.

It should be understood that the specific implementation of step 530 is not limited. For example, any one of the first digital signature and the second digital signature can be verified by default. If the first digital signature fails the verification, the first digital signature is not verified any more. The other of the signature and the second digital signature.

Step 540: Determine that the first verification ciphertext, the second verification ciphertext, and the reference ciphertext are obtained based on the same asset type.

Step 550: Determine that the first verification ciphertext, the second verification ciphertext, and the reference ciphertext are not obtained based on the same asset type and refuse to execute the subsequent process.

If the first digital signature and the second digital signature received by the blockchain node are both verified, it means that the verification ciphertext and the reference ciphertext corresponding to both parties of the transaction are obtained based on the same asset type, that is, the first verification ciphertext and the second verification The ciphertext is obtained based on the same asset type. Otherwise, it means that the first verification ciphertext and the second verification ciphertext are not obtained based on the same asset type.

The prerequisite for passing the transaction verification is that both the first digital signature and the second digital signature (and of course, the third digital signature) pass the verification. If the blockchain node passes the transaction verification, the expected follow-up process can be continued. For example, a transaction including a third signature message and a third digital signature can be written into the block. For another example, the accounts of both parties to the transaction will be updated based on the verification ciphertext corresponding to both parties to the transaction. Specifically, the transaction amount E(t) can be determined from the third signature message, and then the account of the transaction initiator is compared with the first verification ciphertext. The corresponding balance is reduced by E(t) and the balance corresponding to the second verification ciphertext in the account of the transaction initiator is increased by E(t). Otherwise, you can refuse to perform the expected follow-up process.

According to relevant content in the process 400, the third signature message may also include proof of legality of the amount of money. Accordingly, the blockchain node can also verify the proof of legality of the amount of money after verifying the third digital signature. It should be understood that the verification order of the amount legality evidence and the first digital signature/second digital signature is optional. When any one of the amount legality evidence, the first digital signature and the second digital signature fails the verification, Blockchain nodes can refuse to execute subsequent processes.

In some embodiments, when the first digital signature and the second digital signature (and of course, the third digital signature) pass the verification, it indicates that the first verification ciphertext and the second verification ciphertext are based on the same asset type (ie, the target asset). Type) is obtained, and the blockchain node can record the identification information of the transaction initiator, the identification information of the transaction receiver, the first verification ciphertext and the second verification ciphertext in association with each other. In this way, when any transaction party in the verified historical transaction initiates a transaction for the target asset type again, the first verification ciphertext and the second verification ciphertext can be provided to the blockchain node. After the blockchain node confirms that the identities of the transaction initiator and the transaction receiver are correct, it searches locally whether it contains the identification information of the transaction initiator, the identification information of the transaction receiver, the first verification ciphertext and the second verification ciphertext. Associate records. If there are associated records, it means that the consistency of the first verification ciphertext and the second verification ciphertext has been successfully verified in the historical transaction, and the blockchain node can save the first digital signature and the second digital signature when verifying the transaction. The verification of the signature, of course, the party who initiates the transaction again does not need to provide the first digital signature and the second digital signature to the blockchain node.

In some embodiments, the associated record kept by the blockchain node may include more content. For example, a blockchain node can store a message sequence (A, B; C ₀ , C_A, C_B; P_A, P_B), where A represents the identification information of the transaction initiator, C_A represents the first verification ciphertext, and P_B represents the first Digital signature, B represents the identification information of the transaction recipient, C_B represents the second verification cipher text, P_B represents the second digital signature, and C ₀ represents the reference cipher text.

In some embodiments, the blockchain node may generate a corresponding ID for the saved association record, and feed the ID back to the transaction party. In this way, when both parties of the transaction conduct a new transaction for the target asset type again, the device of the party initiating the new transaction can provide the ID to the blockchain node, and the blockchain node searches for the recorded verification ciphertext of both parties based on the received ID. , And update the accounts of both parties to the transaction based on the found verification ciphertext.

It is worth noting that one or more steps in this specification can also be implemented by calling smart contracts. Because the smart contract has the characteristics of mandatory execution, non-tampering, and traceability, it can ensure that the corresponding steps are executed as expected and leave traceable evidence.

Although this specification mainly focuses on transactions for the same asset type, the principles in this specification can be more generally applied to multi-party transactions for the same object. The multi-party transaction here can refer to the transaction with the following characteristics: 1. It requires more than two participants to participate in the transaction; 2. Each participant needs to participate in the transaction for the same object (referred to as the target object); 3. For any participant, It is necessary to publicly record transaction information related to the target object based on the ciphertext of the object corresponding to the participant to prevent privacy leakage. Just as an example, the multi-party transaction here may include the exchange of the same type of data, the collaborative update of the same type of data, and so on.

Fig. 6 is an exemplary flowchart of a method for generating object consistency evidence according to some embodiments of the present specification. The process 600 can be executed by the device of any participant of a multiparty transaction (hereinafter referred to as participant X). Specifically, the participant X in the transaction may refer to the transaction initiator or the transaction receiver. As shown in FIG. 6, the process 600 may include:

Step 610: Obtain the reference ciphertext of the target object. In some embodiments, step 610 may be implemented by the reference ciphertext obtaining module 1110.

Step 620: Generate a target private key. In some embodiments, step 620 may be implemented by the private key generation module 1120.

Among them, the result of the target operation on the verification ciphertext and the reference ciphertext of the target object is the target public key matching the target private key, and the target operation satisfies: the result of the target operation on the reference ciphertext and the verification ciphertext of the same object It is a public key that matches the private key, and the private key is derived from the private value used to generate the ciphertext of the same object. It should be understood that the verification ciphertext (which can be marked as C_X) corresponds to the participant X and can be used to publicly record the transaction information related to the target object corresponding to the participant X.

Step 630: Use the target private key to generate a target digital signature on the target signature message, the target signature message including the verification ciphertext (C_X) and the reference ciphertext. In some embodiments, step 630 may be implemented by the digital signature module 1130.

Step 640: Obtain evidence including at least the verification ciphertext (C_X), the reference ciphertext, and the target digital signature, so as to at least prove that the verification ciphertext (C_X) and the reference ciphertext are obtained based on the same object. In some embodiments, step 640 may be implemented by the object consistency evidence obtaining module 1140.

The target digital signature corresponding to any participant can be used to prove that the verification ciphertext and the reference ciphertext corresponding to the participant are based on the same object. Therefore, it can be used to prove that the verification ciphertext and reference ciphertext corresponding to each participant are based on the same object. The evidence (hereinafter referred to as the object consistency evidence) includes: reference ciphertext, verification ciphertext corresponding to each participant, and each participant The corresponding target digital signature.

Any participant can send a message containing object consistency evidence to the verifier's device, so that the verifier's device can confirm whether the verification ciphertext corresponding to each participant is based on the same object through the verification object consistency evidence. If the device of the verifier confirms that the verification ciphertext corresponding to each participant is obtained based on the same object, the transaction information related to the target object corresponding to each participant may be recorded based on the verification ciphertext corresponding to each participant.

It should be understood that, for more details about the process 600, reference may be made to the process 200, the process 300 and related descriptions thereof. For example, for more details about the target private key (public key), please refer to the description of the first/second private key (public key). For another example, for more details about the target signature message and the target digital signature, please refer to the description of the first/second signature message and the first/second digital signature. For another example, for more details about the object consistency evidence, please refer to the related description of the asset type consistency evidence.

It should be noted that the above description of the related process is only for example and description, and does not limit the scope of application of this specification. For those skilled in the art, various modifications and changes can be made to the process under the guidance of this specification. However, these corrections and changes are still within the scope of this specification.

Fig. 7 is an exemplary block diagram of an asset type consistency evidence generating system according to some embodiments of the present specification. The system 700 may be implemented on the device of the transaction initiator. As shown in FIG. 7, the system 700 may include a reference ciphertext generating module 710, a first private key generating module 720, a first digital signature module 730, a second digital signature obtaining module 740, and an asset type consistency evidence obtaining module 750.

The reference ciphertext generating module 710 may be used to generate a reference ciphertext of the target asset type.

The first private key generation module 720 may be used to generate the first private key.

The first digital signature module 730 may be configured to use the first private key to generate a first digital signature on the first signed message.

The second digital signature obtaining module 740 may be used to obtain the second digital signature generated by using the second private key on the second signed message.

The asset type consistency evidence obtaining module 750 can be used to obtain evidence including the first verification ciphertext, the second verification ciphertext, the reference ciphertext, the first digital signature, and the second digital signature to prove that the first verification ciphertext, the second verification ciphertext, and the second digital signature are included. The verification ciphertext and the reference ciphertext are obtained based on the same asset type.

For more details about the system 700 and its modules, please refer to FIG. 2 and related descriptions.

Fig. 8 is an exemplary block diagram of an asset type consistency evidence generating system according to some embodiments of the present specification. The system 800 may be implemented on the device of the transaction recipient. As shown in FIG. 8, the system 800 may include a reference ciphertext receiving module 810, a second private key generating module 820, a second digital signature module 830, and a sending module 840.

The reference ciphertext receiving module 810 can be used to receive the reference ciphertext of the target asset type from the transaction initiator.

The second private key generation module 820 can be used to generate a second private key.

The second digital signature module 830 may be used to generate a second digital signature on the second signed message using the second private key.

The sending module 840 may be used to send the second verification ciphertext and the second digital signature to the device of the transaction initiator, so that the device of the transaction initiator obtains the asset type consistency evidence.

For more details about the system 800 and its modules, please refer to FIG. 3 and related descriptions.

Fig. 9 is an exemplary block diagram of a transaction system according to some embodiments of the present specification. The system 900 can be implemented on the device of the transaction initiator or the transaction receiver in the process 200 (or the process 300). As shown in FIG. 9, the system 900 may include an obtaining module 910, a third digital signature module 920, and an uploading module 930.

The obtaining module 910 can be used to obtain the asset type consistency evidence that is used to prove that the verification ciphertext and the reference ciphertext corresponding to both parties to the transaction are based on the same asset type.

The third digital signature module 920 may be used to generate a third digital signature on the third signature message using the private key of the transaction initiator or the transaction receiver.

The upload module 930 can be used to upload the third signature message and the third digital signature to the blockchain network 120.

For more details about the system 900 and its modules, please refer to FIG. 4 and related descriptions.

Fig. 10 is an exemplary block diagram of a transaction verification system according to some embodiments of the present specification. The system 1000 can be implemented on a blockchain node. As shown in FIG. 10, the system 1000 may include a receiving module 1010, a first verification module 1020, a second verification module 1030, and a determination module 1040.

The receiving module 1010 can be used to receive a third signature message and a third digital signature. The third signature message includes a reference ciphertext, a first verification ciphertext corresponding to the transaction initiator, and a first digital signature, and a first digital signature corresponding to the transaction receiver. 2. Verify the ciphertext and the second digital signature.

The first verification module 1020 may be used to verify the third digital signature based on the public key of the transaction initiator or the transaction receiver and the third signature message.

The second verification module 1030 may be used to verify the first digital signature based on the first public key and the first signed message when the third digital signature is verified; and/or verify the second digital based on the second public key and the second signed message sign.

The determining module 1040 can be used to: if the first digital signature and the second digital signature pass the verification, determine that the first verification ciphertext, the second verification ciphertext and the reference ciphertext are obtained based on the same asset type; if the first digital signature or the second digital signature If the digital signature fails the verification, it is determined that the first verification ciphertext, the second verification ciphertext, and the reference ciphertext are not obtained based on the same asset type and the subsequent process is rejected.

For more details about the system 1000 and its modules, please refer to FIG. 5 and related descriptions.

Fig. 11 is an exemplary block diagram of an object consistency evidence generating system according to some embodiments of the present specification. The system 1100 can be implemented on the device of any participant (hereinafter referred to as participant X) of a multi-party transaction. As shown in FIG. 11, the system 1100 may include a reference ciphertext obtaining module 1110, a private key generating module 1120, a digital signature module 1130, and an object consistency evidence obtaining module 1140.

The reference ciphertext obtaining module 1110 can be used to obtain the reference ciphertext of the target object.

The private key generation module 1120 can be used to generate the target private key.

The digital signature module 1130 can be used to use the target private key to generate a target digital signature on a target signed message, the target signed message including a verification ciphertext (C_X) and a reference ciphertext.

The object consistency evidence obtaining module 1140 can be used to obtain evidence containing at least the verification ciphertext (C_X), the reference ciphertext, and the target digital signature, so as to at least prove that the verification ciphertext and the reference ciphertext are obtained based on the same object.

For more details about the system 1100, refer to FIG. 6 and related descriptions.

It should be understood that the systems and modules shown in FIGS. 7-11 can be implemented in various ways. For example, in some embodiments, the system and its modules can be implemented by hardware, software, or a combination of software and hardware. Among them, the hardware part can be implemented using dedicated logic; the software part can be stored in a memory and executed by an appropriate instruction execution system, such as a microprocessor or dedicated design hardware. Those skilled in the art can understand that the above-mentioned methods and systems can be implemented using computer-executable instructions and/or included in processor control codes, for example on a carrier medium such as a disk, CD or DVD-ROM, such as a read-only memory (firmware) Such codes are provided on a programmable memory or a data carrier such as an optical or electronic signal carrier. The system and its modules in this specification can not only be implemented by hardware circuits such as very large-scale integrated circuits or gate arrays, semiconductors such as logic chips, transistors, etc., or programmable hardware devices such as field programmable gate arrays, programmable logic devices, etc. It can also be implemented by, for example, software executed by various types of processors, or can be implemented by a combination of the foregoing hardware circuit and software (for example, firmware).

It should be noted that the above description of the system and its modules is only for convenience of description, and does not limit this specification within the scope of the examples mentioned. It can be understood that for those skilled in the art, after understanding the principle of the system, it is possible to arbitrarily combine various modules, or form a subsystem to connect with other modules without departing from this principle. For example, in some embodiments, the second verification module 1030 and the determination module 1040 disclosed in FIG. 10 may be different modules in a system, or one module may implement the functions of the two modules. Such deformations are all within the protection scope of this specification.

The possible beneficial effects of the embodiments of this specification include, but are not limited to: (1) Under the premise of protecting the privacy value of the transaction party for generating the verification ciphertext, a publicly and zero-knowledgeable ciphertext is designed by introducing the reference ciphertext. Locally verify whether the verification ciphertexts corresponding to the transaction parties are based on the same asset type; (2) After completing a verification of the consistency of the asset type, record the relevant information of this verification to avoid repeated verification; (3) Pass The smart contract implements one or more steps to ensure that the corresponding steps are executed as expected and leave traceable evidence. It should be noted that different embodiments may have different beneficial effects. In different embodiments, the possible beneficial effects may be any one or a combination of the above, or any other beneficial effects that may be obtained.

The basic concepts have been described above. Obviously, for those skilled in the art, the above detailed disclosure is only an example, and does not constitute a limitation to the embodiments of this specification. Although it is not explicitly stated here, those skilled in the art may make various modifications, improvements and amendments to the embodiments of this specification. Such modifications, improvements, and corrections are suggested in the embodiments of this specification, so such modifications, improvements, and corrections still belong to the spirit and scope of the exemplary embodiments of this specification.

Meanwhile, this specification uses specific words to describe the embodiments of this specification. For example, "one embodiment", "an embodiment", and/or "some embodiments" mean a certain feature, structure, or characteristic related to at least one embodiment of this specification. Therefore, it should be emphasized and noted that “one embodiment” or “one embodiment” or “an alternative embodiment” mentioned twice or more in different positions in this specification does not necessarily refer to the same embodiment. . In addition, some features, structures, or characteristics in one or more embodiments of this specification can be appropriately combined.

In addition, those skilled in the art can understand that the various aspects of the embodiments of this specification can be explained and described through a number of patentable categories or situations, including any new and useful process, machine, product or combination of substances, or Any new and useful improvements to them. Correspondingly, various aspects of the embodiments of the present specification can be completely executed by hardware, can be completely executed by software (including firmware, resident software, microcode, etc.), or can be executed by a combination of hardware and software. The above hardware or software can be called "data block", "module", "engine", "unit", "component" or "system". In addition, various aspects of the embodiments of the present specification may be represented as a computer product located in one or more computer-readable media, and the product includes computer-readable program codes.

The computer storage medium may contain a propagated data signal containing a computer program code, for example on a baseband or as part of a carrier wave. The propagated signal may have multiple manifestations, including electromagnetic forms, optical forms, etc., or a suitable combination. The computer storage medium may be any computer-readable medium other than the computer-readable storage medium, and the medium may be connected to an instruction execution system, device, or device to realize communication, dissemination, or transmission of the program for use. The program code located on the computer storage medium can be transmitted through any suitable medium, including radio, cable, fiber optic cable, RF, or similar medium, or any combination of the above medium.

The computer program codes required for the operations of the various parts of the embodiments of this specification can be written in any one or more programming languages, including object-oriented programming languages such as Java, Scala, Smalltalk, Eiffel, JADE, Emerald, C++, C#, VB.NET, Python, etc., conventional programming languages such as C language, VisualBasic, Fortran2003, Perl, COBOL2002, PHP, ABAP, dynamic programming languages such as Python, Ruby and Groovy, or other programming languages, etc. The program code can run entirely on the user's computer, or as an independent software package on the user's computer, or partly on the user's computer and partly on a remote computer, or entirely on the remote computer or processing equipment. In the latter case, the remote computer can be connected to the user's computer through any network form, such as a local area network (LAN) or a wide area network (WAN), or connected to an external computer (for example, via the Internet), or in a cloud computing environment, or as a service Use software as a service (SaaS).

In addition, unless explicitly stated in the claims, the order of processing elements and sequences, the use of numbers and letters, or the use of other names in the embodiments of this specification are not used to limit the order of the processes and methods of the embodiments of this specification. Although the foregoing disclosure uses various examples to discuss some embodiments of the invention that are currently considered useful, it should be understood that such details are only for illustrative purposes, and the appended claims are not limited to the disclosed embodiments. On the contrary, the rights are The requirements are intended to cover all modifications and equivalent combinations that conform to the essence and scope of the embodiments of this specification. For example, although the system components described above can be implemented by hardware devices, they can also be implemented only by software solutions, such as installing the described system on existing processing devices or mobile devices.

For the same reason, it should be noted that, in order to simplify the expressions disclosed in the embodiments of this specification, so as to help the understanding of one or more embodiments of the invention, in the foregoing description of the embodiments of this specification, multiple features are sometimes combined into one implementation. Examples, drawings or descriptions. However, this method of disclosure does not mean that the objects of the embodiments of this specification require more features than those mentioned in the claims. In fact, the features of the embodiment are less than all the features of the single embodiment disclosed above.

For each patent, patent application, patent application publication and other materials cited in this specification, such as articles, books, specifications, publications, documents, etc., the entire contents are hereby incorporated into this specification as a reference. The application history documents that are inconsistent or conflict with the content of this specification are excluded, and the documents that restrict the broadest scope of the claims of this application (currently or later attached to this specification) are also excluded. It should be noted that if there is any inconsistency or conflict between the description, definition, and/or use of terms in the accompanying materials of this manual and the content of this manual, the description, definition and/or use of terms in this manual shall prevail. .

Finally, it should be understood that the embodiments described in this specification are only used to illustrate the principles of the embodiments of this specification. Other variations may also fall within the scope of the embodiments of this specification. Therefore, as an example and not a limitation, the alternative configuration of the embodiment of the present specification can be regarded as consistent with the teaching of the present specification. Accordingly, the embodiments of this specification are not limited to the embodiments explicitly introduced and described in this specification.

Claims

An asset type consistency evidence generation method, wherein the method is executed by the device of the transaction initiator, which includes:

Generate the reference ciphertext of the target asset type;

Generate a first private key; wherein the result of performing a target operation on the first verification ciphertext of the target asset type and the reference ciphertext is a first public key matching the first private key, and the first The verification ciphertext corresponds to the transaction initiator, and the target operation satisfies: the result of performing the target operation on the reference ciphertext and the verification ciphertext of the same object is the public key matching the private key, and the private key is used for Generate the secret value of the ciphertext of the same object;

Generating a first digital signature on a first signed message using the first private key; wherein the first signed message includes the first verification ciphertext and the reference ciphertext;

Obtain a second digital signature generated using a second private key on a second signed message; wherein, the second signed message includes a second verification ciphertext of the target asset type and the reference ciphertext, and the second verification The ciphertext corresponds to the transaction receiver, and the result of performing the target operation on the second verification ciphertext and the reference ciphertext is a second public key matching the second private key;

Obtain evidence including the first verification ciphertext, the second verification ciphertext, the reference ciphertext, the first digital signature, and the second digital signature to prove the first verification ciphertext, The second verification ciphertext and the reference ciphertext are obtained based on the same asset type.
The method of claim 1, wherein the first verification ciphertext, the second verification ciphertext, and the reference ciphertext are respectively obtained based on the Pedersen commitment protocol.
The method according to claim 2, wherein the first verification ciphertext, the second verification ciphertext, and the reference ciphertext respectively comprise a first part corresponding to a first generator and a second part corresponding to a second generator. The second part of the ciphertext, wherein the first generator and the second generator are on the same elliptic curve and the first generator is a public key generation parameter, and the first part of the first verification ciphertext The first generator and the secret value corresponding to the transaction initiator are obtained, the first part of the second verification ciphertext is obtained based on the first generator and the secret value corresponding to the transaction receiver, the The first verification ciphertext, the second verification ciphertext, and the second part of the reference ciphertext are equal and are respectively obtained based on the identification information of the second generator and the target asset type;

The target operation is the difference value.
The method according to claim 1, wherein said obtaining the second digital signature generated by using the second private key on the second signed message comprises:

At least sending the reference ciphertext to the device of the transaction receiver, so that the device of the transaction receiver generates the second digital signature;

Receiving the second digital signature and the second verification ciphertext from the device of the transaction receiver to obtain the evidence.
The method according to claim 4, wherein the reference ciphertext is generated based on at least a third random number, and the method further comprises:

Send the third random number to the device of the transaction recipient.
The method of claim 4, further comprising:

The identification information of the target asset type is encrypted and transmitted to the device of the transaction receiver.
The method of claim 1 or 4, further comprising:

Sending the first verification ciphertext and the first digital signature to the device of the transaction recipient.
The method according to claim 1, further comprising generating the second verification ciphertext; said obtaining a second digital signature generated by using a second private key on a second signed message, comprising:

Generating a second private key, where the result of performing the target operation on the second verification ciphertext and the reference ciphertext is a second public key matching the second private key;

Use the second private key to generate the second digital signature on the second signed message.
An asset type consistency evidence generation system, wherein the system is implemented on the device of the transaction initiator, which includes:

The reference ciphertext generation module is used to generate the reference ciphertext of the target asset type;

The first private key generation module is used to generate a first private key; wherein the result of performing a target operation on the first verification ciphertext of the target asset type and the reference ciphertext is the one that matches the first private key The first public key, the first verification ciphertext corresponds to the transaction initiator, and the target operation satisfies: the result of the target operation on the reference ciphertext and the verification ciphertext of the same object matches the private key Public key, the private key is obtained from the private value used to generate the ciphertext of the same object;

The first digital signature module is configured to use the first private key to generate a first digital signature on a first signed message; wherein, the first signed message includes the first verification ciphertext and the reference ciphertext;

The second digital signature obtaining module is configured to obtain a second digital signature generated by using a second private key to a second signed message; wherein, the second signed message includes the second verification ciphertext of the target asset type and the With reference to the ciphertext, the second verification ciphertext corresponds to the transaction recipient, and the result of performing the target operation on the second verification ciphertext and the reference ciphertext is the second matching the second private key Public key

An asset type consistency evidence obtaining module, configured to obtain evidence including the first verification ciphertext, the second verification ciphertext, the reference ciphertext, the first digital signature, and the second digital signature, To prove that the first verification ciphertext, the second verification ciphertext and the reference ciphertext are obtained based on the same asset type.
An asset type consistency evidence generating device, which includes a processor and a storage device, the storage device is used to store instructions, and when the processor executes the instructions, the implementation of any one of claims 1 to 8 Methods.
An asset type consistency evidence generation method, wherein the method is executed by a device of a transaction receiver, which includes:

Receive the reference ciphertext of the target asset type from the transaction initiator;

Generate a second private key; wherein, the result of performing a target operation on the second verification ciphertext of the target asset type and the reference ciphertext is a second public key matching the second private key, and the second The verification ciphertext corresponds to the transaction recipient, and the target operation satisfies: the result of performing the target operation on the reference ciphertext and the verification ciphertext of the same object is the public key matching the private key, and the private key is used for Generate the secret value of the ciphertext of the same object;

Use the second private key to generate a second digital signature on a second signed message; wherein, the second signed message includes the second verification ciphertext and the reference ciphertext;

The second verification ciphertext and the second digital signature are sent to the device of the transaction initiator, so that the device of the transaction initiator obtains the first verification ciphertext containing the target asset type, the The second verification ciphertext, the reference ciphertext, the first digital signature, and the evidence of the second digital signature; wherein the first verification ciphertext corresponds to the transaction initiator, and the first digital signature is A first signed message is generated using a first private key, and the first signed message includes the second verification ciphertext and the reference ciphertext, and the evidence is used to prove that the first verification ciphertext, the The second verification ciphertext and the reference ciphertext are obtained based on the same asset type.
The method according to claim 11, wherein the first verification ciphertext, the second verification ciphertext, and the reference ciphertext are respectively obtained based on the Pedersen commitment protocol.
The method according to claim 12, wherein the first verification ciphertext, the second verification ciphertext, and the reference ciphertext respectively comprise a first part corresponding to a first generator and a second generator corresponding to The second part of the ciphertext, wherein the first generator and the second generator are on the same elliptic curve and the first generator is a public key generation parameter, and the first part of the first verification ciphertext The first generator and the secret value corresponding to the transaction initiator are obtained, the first part of the second verification ciphertext is obtained based on the first generator and the secret value corresponding to the transaction receiver, the The first verification ciphertext, the second verification ciphertext, and the second part of the reference ciphertext are equal and are respectively obtained based on the identification information of the second generator and the target asset type;

The target operation is the difference value.
The method according to claim 11 or 12, further comprising:

Receiving a third random number from the transaction initiator;

Verifying the received reference ciphertext; the verifying the received reference ciphertext includes:

Calculating a comparison reference ciphertext based on the third random number and the identification information of the target asset type;

The reference ciphertext and the comparison reference ciphertext are compared, and if the two are the same, the verification is passed, otherwise the verification is not passed.
The method of claim 11, further comprising:

Receiving the first verification ciphertext and the first digital signature from the device of the transaction initiator to obtain the evidence.
An asset type consistency evidence generation system, wherein the system is implemented on a device of a transaction receiver, which includes:

The reference ciphertext receiving module is used to receive the reference ciphertext of the target asset type from the transaction initiator;

The second private key generation module is used to generate a second private key; wherein the result of performing a target operation on the second verification ciphertext of the target asset type and the reference ciphertext is the one that matches the second private key The second public key, the second verification ciphertext corresponds to the transaction receiver, and the target operation satisfies: the result of performing the target operation on the reference ciphertext and the verification ciphertext of the same object matches the private key Public key, the private key is obtained from the private value used to generate the ciphertext of the same object;

The second digital signature module is configured to use the second private key to generate a second digital signature on a second signed message; wherein, the second signed message includes the second verification ciphertext and the reference ciphertext;

The sending module is configured to send the second verification ciphertext and the second digital signature to the device of the transaction initiator, so that the device of the transaction initiator obtains the first verification including the target asset type Ciphertext, the second verification ciphertext, the reference ciphertext, the first digital signature, and the evidence of the second digital signature; wherein the first verification ciphertext corresponds to the transaction initiator, the The first digital signature is generated using a first private key on a first signed message, the first signed message includes the second verification ciphertext and the reference ciphertext, and the evidence is used to prove the first verification The ciphertext, the second verification ciphertext, and the reference ciphertext are obtained based on the same asset type.
An asset type consistency evidence generating device, which includes a processor and a storage device, the storage device is used to store instructions, and when the processor executes the instructions, the implementation of any one of claims 11-15 Methods.
A trading method, which includes:

Obtain the evidence that the verification ciphertext and the reference ciphertext corresponding to both parties to the transaction are based on the same asset type through the method for generating evidence of asset type consistency according to any one of claims 1-8 and 11-15;

Use the private key of the transaction initiator or the transaction receiver to generate a third digital signature on the third signature message, where the third message to be signed includes the identification information of the accounts of both parties to the transaction and the evidence;

Upload the third signature message and the third digital signature to a blockchain network.
A trading system, which includes:

The obtaining module is used to obtain the verification ciphertext and the reference ciphertext corresponding to the two parties to the transaction based on the same asset type through the asset type consistency evidence generation method according to any one of claims 1-8 and 11-15 Received evidence

The third digital signature module is configured to use the private key of the transaction initiator or the transaction receiver to generate a third digital signature on the third signature message, where the third message to be signed includes the identification information of the accounts of both parties to the transaction and the evidence;

The upload module is used to upload the third signature message and the third digital signature to the blockchain network.
A transaction device, which includes a processor and a storage device, the storage device is used to store instructions, and when the processor executes the instructions, the method according to claim 18 is implemented.
A transaction verification method, which includes:

Receive a third signature message and a third digital signature, where the third signature message includes a reference ciphertext, a first verification ciphertext corresponding to the transaction initiator and a first digital signature, and a second verification ciphertext corresponding to the transaction receiver And the second digital signature;

Verifying the third digital signature based on the public key of the transaction initiator or the transaction receiver and the third signature message;

When the third digital signature passes the verification: perform a target operation on the reference ciphertext and the first verification ciphertext to obtain a first public key for verifying the first digital signature, based on the reference ciphertext And the first verification ciphertext to obtain a first signed message for verifying the first digital signature, and verify the first digital signature based on the first public key and the first signed message; and/or , Performing the target operation on the reference ciphertext and the second verification ciphertext to obtain a second public key for verifying the second digital signature, based on the reference ciphertext and the second verification ciphertext The document obtains a second signature message used to verify the second digital signature, and verifies the second digital signature based on the second public key and the second signature message;

If the first digital signature and the second digital signature pass the verification, it is determined that the first verification ciphertext, the second verification ciphertext, and the reference ciphertext are obtained based on the same asset type.
22. The method of claim 21, wherein, when the first digital signature and the second digital signature are verified, the method further comprises:

Association records the identification information of the transaction initiator, the identification information of the transaction recipient, the first digital signature, the second digital signature, the first verification ciphertext, the second verification ciphertext, and The reference ciphertext.
A transaction verification system, which includes:

The receiving module is configured to receive a third signature message and a third digital signature, the third signature message including the reference ciphertext, the first verification ciphertext corresponding to the transaction initiator, and the first digital signature, and the corresponding The second verification ciphertext and the second digital signature;

The first verification module is configured to verify the third digital signature based on the public key of the transaction initiator or the transaction receiver and the third signature message;

The second verification module is configured to: when the third digital signature passes verification: perform a target operation on the reference ciphertext and the first verification ciphertext to obtain a first public signature for verifying the first digital signature Key, obtain a first signature message for verifying the first digital signature based on the reference ciphertext and the first verification ciphertext, and verify the first signature message based on the first public key and the first signature message A digital signature; and/or, performing the target operation on the reference ciphertext and the second verification ciphertext to obtain a second public key for verifying the second digital signature, based on the reference ciphertext And the second verification ciphertext to obtain a second signature message used to verify the second digital signature, and verify the second digital signature based on the second public key and the second signature message;

A determining module, configured to: if the first digital signature and the second digital signature pass verification, determine that the first verification ciphertext, the second verification ciphertext, and the reference ciphertext are based on the same asset type get.
A transaction verification device, which includes a processor and a storage device, the storage device is used to store instructions, and when the processor executes the instructions, the method according to claim 21 or 22 is implemented.
A method for generating object consistency evidence, wherein the method is executed by a device of any participant in a transaction, which includes:

Obtain the reference ciphertext of the target object;

Generate a target private key; wherein the result of performing a target operation on the verification ciphertext of the target object and the reference ciphertext is a target public key matching the target private key, and the target operation satisfies: The result of performing the target operation with reference to the ciphertext and the verification ciphertext is a public key matching the private key, and the private key is obtained from the private value of the ciphertext used to generate the same object;

Use the target private key to generate a target digital signature on a target signed message; wherein, the target signed message includes the verification ciphertext and the reference ciphertext;

Obtaining evidence including at least the verification ciphertext, the reference ciphertext, and the target digital signature to at least prove that the verification ciphertext and the reference ciphertext are obtained based on the same object.
An object consistency evidence generation system, wherein the system is implemented on the device of any participant in a transaction, which includes:

The reference ciphertext obtaining module is used to obtain the reference ciphertext of the target object;

The private key generation module is used to generate a target private key; wherein the result of the target operation on the verification ciphertext of the target object and the reference ciphertext is the target public key matching the target private key, and the target The operation satisfies: the result of performing the target operation on the reference ciphertext and the verification ciphertext of the same object is the public key matching the private key, and the private key is obtained from the private value used to generate the ciphertext of the same object;

The digital signature module is configured to use the target private key to generate a target digital signature on a target signature message; wherein, the target signature message includes the verification ciphertext and the reference ciphertext;

The object consistency evidence obtaining module is used to obtain evidence containing at least the verification ciphertext, the reference ciphertext and the target digital signature to at least prove that the verification ciphertext and the reference ciphertext are obtained based on the same object .
An object consistency evidence generation device, which includes a processor and a storage device, the storage device is used to store instructions, and when the processor executes the instructions, the method according to claim 25 is implemented.