CN111340494B

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

Info

Publication number: CN111340494B
Application number: CN202010409786.8A
Authority: CN
Inventors: 张文彬
Original assignee: Alipay Hangzhou Information Technology Co Ltd
Current assignee: Alipay Hangzhou Information Technology Co Ltd
Priority date: 2020-05-15
Filing date: 2020-05-15
Publication date: 2020-08-28
Anticipated expiration: 2040-05-15
Also published as: CN111340494A; WO2021228239A1

Abstract

Embodiments in the present specification provide asset type consistency evidence generation, transaction verification methods and systems. The equipment of the transaction initiator generates a reference ciphertext of the target asset type, a first private key is used for generating a first digital signature for a message containing the reference ciphertext and a first verification ciphertext of the transaction initiator, a second private key is used for obtaining a second digital signature generated for a message containing the reference ciphertext and a second verification ciphertext of the transaction receiver, and asset type consistency evidence containing the first verification ciphertext, the second verification ciphertext, the reference ciphertext, the first digital signature and the second digital signature is obtained. 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 based on the same asset type. Based on the zero-knowledge proof, on the premise of protecting the privacy of the transaction party, the zero-knowledge proof which can be used for publicly verifying whether the verification ciphertext corresponding to the transaction party is obtained based on the same asset type is provided.

Description

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

Technical Field

The embodiment of the specification relates to the technical field of information, in particular to asset type consistency evidence generation, transaction and transaction verification methods and systems.

Background

The type of asset (e.g., RMB, USD, securities, etc.) that an entity (e.g., organization, company, etc.) uses to conduct a business may be a commercial secret of the entity for which privacy protection is desired from disclosure to the outside (e.g., a competitor). In addition, the leakage of the asset type may result in more private information of the entity being obtained. For example, in cross-border remittance or in the supply chain, it is possible to infer the region where the entity is located, and thus the identity of the entity, by asset type. To prevent privacy disclosure, the entity links the asset type cryptogram during the transaction. Due to stricter privacy protection requirements, even if the entities encrypt the identification information of the same asset type by using a common encryption algorithm, the cryptograph of the asset type is generated by using different secret values (such as random numbers) by each entity, so that the cryptographs of the entities are different for the same asset type.

In view of the above, it is desirable to provide a scheme capable of publicly verifying whether asset type ciphertexts of both trading parties are generated based on the same asset type on the premise of protecting data privacy, so as to ensure that both trading parties trade for the same asset type.

Disclosure of Invention

One of the embodiments of the present specification provides an asset type consistency evidence generation method, wherein the method is performed by a device of a transaction initiator, and comprises: generating a reference ciphertext of the target asset type; generating a first private key, wherein a result of performing a target operation on a first verification ciphertext of the target asset type and the reference ciphertext is a first public key matched with the first private 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 is a public key matched with a private key, and the private key is obtained by a private value used for generating the ciphertext of the same object; generating a first digital signature on a first signature message using the first private key, wherein the first signature message comprises the first verification ciphertext and the reference ciphertext; obtaining a second digital signature generated by a second signature message by using a second private key, wherein the second signature message comprises a second verification ciphertext of the target asset type and the reference ciphertext, the second verification ciphertext corresponds to a transaction receiver, and a result of performing the target operation on the second verification ciphertext and the reference ciphertext is a second public key matched with the second private key; and obtaining evidence including the first verification ciphertext, the second verification ciphertext, the reference ciphertext, the first digital signature and the second digital signature so as 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 the present specification provides an asset type consistency evidence generation system, wherein the system is implemented on a device of a transaction initiator, and comprises: the reference ciphertext generating module is used for generating a reference ciphertext of the target asset type; a first private key generation module, configured to generate a first private key, where a result of performing a target operation on a first verification ciphertext of the target asset type and the reference ciphertext is a first public key matched with the first private 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 is a public key matched with a private key, and the private key is obtained by a private value used for generating the ciphertext of the same object; a first digital signature module configured to generate a first digital signature for a first signature message using the first private key, wherein the first signature message includes the first verification ciphertext and the reference ciphertext; a second digital signature obtaining module, configured to obtain a second digital signature generated by using a second private key to a second signature message, where the second signature message includes a second verification ciphertext of the target asset type and the reference ciphertext, the second verification ciphertext corresponds to a transaction recipient, and a result of performing the target operation on the second verification ciphertext and the reference ciphertext is a second public key matched with the second private key; and the asset type consistency evidence obtaining module is used for obtaining an evidence containing the first verification ciphertext, the second verification ciphertext, the reference ciphertext, the first digital signature and the second digital signature so as 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 the present specification provides an asset type consistency evidence generating apparatus, which includes a processor and a storage device, where the storage device is configured to store instructions, and when the processor executes the instructions, the asset type consistency evidence generating method performed by a device of a transaction initiator according to any one of the embodiments of the present specification is implemented.

One of the embodiments of the present specification provides an asset type consistency evidence generation method, wherein the method is performed by a device of a transaction recipient, and comprises: receiving a reference ciphertext of a target asset type from a transaction initiator; generating a second private key, wherein a result of performing a target operation on a second verification ciphertext of the target asset type and the reference ciphertext is a second public key matched with the second private key, the second verification ciphertext corresponds to the transaction receiver, and the target operation satisfies: the result of the target operation on the reference ciphertext and the verification ciphertext of the same object is a public key matched with a private key, and the private key is obtained by a private value used for generating the ciphertext of the same object; generating a second digital signature on a second signature message using the second private key, wherein the second signature message comprises the second verification ciphertext and the reference ciphertext; and sending the second verification ciphertext and the second digital signature to the transaction initiator so that the transaction initiator obtains a first verification ciphertext, a second verification ciphertext, the reference ciphertext, a first digital signature and an 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 to a first signature message, the first signature message comprises the second verification ciphertext and the reference ciphertext, and the evidence is used for proving 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 the present specification provides an asset type consistency evidence generation system, wherein the system is implemented on a device of a transaction recipient, and comprises: the reference ciphertext receiving module is used for receiving a reference ciphertext of the target asset type from the transaction initiator; a second private key generation module, configured to generate a second private key, where a result of performing a target operation on a second verification ciphertext of the target asset type and the reference ciphertext is a second public key matched with the second private key, the second verification ciphertext corresponds to the transaction recipient, and the target operation satisfies: the result of the target operation on the reference ciphertext and the verification ciphertext of the same object is a public key matched with a private key, and the private key is obtained by a private value used for generating the ciphertext of the same object; a second digital signature module, configured to generate a second digital signature for a second signature message using the second private key, where the second signature message includes the second verification ciphertext and the reference ciphertext; a sending module, configured to send the second verification ciphertext and the second digital signature to the transaction initiator device, so that the transaction initiator device obtains an evidence including a first verification ciphertext, the second verification ciphertext, the reference ciphertext, a first digital signature, and the second digital signature of the target asset type, where the first verification ciphertext corresponds to the transaction initiator, the first digital signature is generated by using a first private key to a first signature message, the first signature message 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 the present specification provides an asset type consistency evidence generating apparatus, which includes a processor and a storage device, where the storage device is used to store instructions, and when the processor executes the instructions, the asset type consistency evidence generating method performed by a device of a transaction recipient according to any one of the embodiments of the present specification is implemented.

One embodiment of the present specification provides a transaction method, including: by using the asset type consistency evidence generation method according to any embodiment of the specification, evidence for proving that a verification ciphertext and a reference ciphertext corresponding to both transaction parties are obtained based on the same asset type is obtained; generating a third digital signature for a third signature message by using a private key of the transaction initiator or the transaction receiver, wherein the third message to be signed comprises identification information of accounts of both transaction parties and the evidence; uploading the third signed message and the third digital signature to a blockchain network.

One of the embodiments of the present specification provides a transaction system, including: an obtaining module, configured to obtain, by using the asset type consistency evidence generating method according to any embodiment of the present specification, an evidence for proving that a verification ciphertext and a reference ciphertext corresponding to both transaction parties are obtained based on the same asset type; the third digital signature module is used for generating a third digital signature for a third signature message by using a private key of the transaction initiator or the transaction receiver, wherein the third message to be signed comprises the identification information of the accounts of the transaction two parties and the evidence; and the uploading module is used for uploading the third signature message and the third digital signature to a blockchain network.

One of the embodiments of the present specification provides a transaction apparatus, which includes a processor and a storage device, where the storage device is used to store instructions, and when the processor executes the instructions, the transaction apparatus implements a transaction method according to any one of the embodiments of the present specification.

One of the embodiments of the present specification provides a transaction verification method, including: receiving a third signature message and a third digital signature, wherein the third signature message comprises a reference ciphertext, a first verification ciphertext and a first digital signature which correspond to a transaction initiator, and a second verification ciphertext and a second digital signature which correspond to a transaction receiver; verifying the third digital signature based on a public key of a transaction initiator or a transaction receiver and the third signature message; when the third digital signature is verified: performing target operation on the reference ciphertext and the first verification ciphertext to obtain a first public key for verifying the first digital signature, obtaining a first signature message for verifying the first digital signature based on the reference ciphertext and the first verification ciphertext, and verifying the first digital signature based on the first public key and the first signature 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, obtaining a second signature message for verifying the second digital signature based on the reference ciphertext and the second verification ciphertext, and verifying the second digital signature based on the second public key and the second signature message; and if the first digital signature and the second digital signature pass the verification, determining that the first verification ciphertext, the second verification ciphertext and the reference ciphertext are obtained based on the same asset type.

One embodiment of the present specification provides a transaction verification system, including: the receiving module is used for receiving a third signature message and a third digital signature, wherein the third signature message comprises a reference ciphertext, a first verification ciphertext and a first digital signature which correspond to a transaction initiator, and a second verification ciphertext and a second digital signature which correspond to a transaction receiver; the first verification module is used for verifying the third digital signature based on the public key of the transaction initiator or the transaction receiver and the third signature message; a second verification module for, when the third digital signature is verified: performing target operation on the reference ciphertext and the first verification ciphertext to obtain a first public key for verifying the first digital signature, obtaining a first signature message for verifying the first digital signature based on the reference ciphertext and the first verification ciphertext, and verifying the first digital signature based on the first public key and the first signature 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, obtaining a second signature message for verifying the second digital signature based on the reference ciphertext and the second verification ciphertext, and verifying the second digital signature based on the second public key and the second signature message; a determination module to: and if the first digital signature and the second digital signature pass the verification, determining 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 the present specification provides a transaction verification apparatus, which includes a processor and a storage device, where the storage device is used to store instructions, and when the processor executes the instructions, the transaction verification method according to any one of the embodiments of the present specification is implemented.

One of the embodiments of the present specification provides an object consistency evidence generating method, wherein the method is performed by a device of any party of a transaction, and includes: obtaining a reference ciphertext of the target object; generating a target private key, wherein a result of performing target operation on the verification ciphertext of the target object and the reference ciphertext is a target public key matched with the target private key, and the target operation satisfies the following conditions: the result of the target operation on the reference ciphertext and the verification ciphertext of the same object is a public key matched with a private key, and the private key is obtained by a private value used for generating the ciphertext of the same object; generating a target digital signature for a target signature message using the target private key, wherein the target signature message comprises the verification ciphertext and the reference ciphertext; and obtaining evidence at least comprising the verification ciphertext, the reference ciphertext and the target digital signature so as to prove that at least the verification ciphertext and the reference ciphertext are obtained based on the same object.

One of the embodiments of the present specification provides an object consistency evidence generation system, wherein the system is implemented on a device of any party of a transaction, and comprises: the reference ciphertext obtaining module is used for obtaining a reference ciphertext of the target object; a private key generation module, configured to generate a target private key, where a result of performing a target operation on the verification ciphertext of the target object and the reference ciphertext is a target public key matched with 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 is a public key matched with a private key, and the private key is obtained by a private value used for generating the ciphertext of the same object; a digital signature module, configured to generate a target digital signature for a target signature message using the target private key, where the target signature message includes the verification ciphertext and the reference ciphertext; and the object consistency evidence obtaining module is used for obtaining the evidence at least comprising the verification ciphertext, 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.

One of the embodiments of the present specification provides an object consistency evidence generating apparatus, which includes a processor and a storage device, where the storage device is configured to store instructions, and when the processor executes the instructions, the object consistency evidence generating method according to any embodiment of the present specification is implemented.

Drawings

The present description will be further explained by way of exemplary embodiments, which will be described in detail by way of the accompanying drawings. These embodiments are not intended to be limiting, and in these embodiments like numerals are used to indicate like structures, wherein:

FIG. 1 is a schematic diagram of an application scenario of a blockchain system according to some embodiments of the present disclosure;

FIG. 2 is an exemplary flow diagram of an asset type consistency evidence generation method according to some embodiments of the present description;

FIG. 3 is an exemplary flow diagram of an asset type consistency evidence generation method according to some embodiments of the present description;

FIG. 4 is an exemplary flow diagram of a transaction method according to some embodiments of the present description;

FIG. 5 is an exemplary flow diagram of a transaction verification method according to some embodiments of the present description;

FIG. 6 is an exemplary flow diagram of a method of object-consistent evidence generation, shown in some embodiments herein;

FIG. 7 is an exemplary block diagram of an asset type consistency evidence generation system shown in accordance with some embodiments of the present description;

FIG. 8 is an exemplary block diagram of an asset type consistency evidence generation system shown in accordance with some embodiments of the present description;

FIG. 9 is an exemplary block diagram of a transaction system shown in accordance with some embodiments of the present description;

FIG. 10 is an exemplary block diagram of a transaction verification system, shown in accordance with some embodiments of the present description;

FIG. 11 is an exemplary block diagram of an object-consistent evidence generation system shown in some embodiments in accordance with the present description.

Detailed Description

In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the drawings used in the description of the embodiments will be briefly described below. It is obvious that the drawings in the following description are only examples or embodiments of the present description, and that for a person skilled in the art, the present description can also be applied to other similar scenarios on the basis of these drawings without inventive effort. Unless otherwise apparent from the context, or otherwise indicated, like reference numbers in the figures refer to the same structure or operation.

It should be understood that "system", "device", "unit" and/or "module" as used herein is a method for distinguishing different components, elements, parts, portions or assemblies at different levels. However, other words may be substituted by other expressions if they accomplish the same purpose.

As used in this specification, the terms "a", "an" and/or "the" are not intended to be inclusive of the singular, but rather are intended to be inclusive of the plural, unless the context clearly dictates otherwise. In general, the terms "comprises" and "comprising" merely indicate that steps and elements are included which are explicitly identified, that the steps and elements do not form an exclusive list, and that a method or apparatus may include other steps or elements.

Flow charts are used in this description to illustrate operations performed by a system according to embodiments of the present description. It should be understood that the preceding or following operations are not necessarily performed in the exact order in which they are performed. Rather, the various steps may be processed in reverse order or simultaneously. Meanwhile, other operations may be added to the processes, or a certain step or several steps of operations may be removed from the processes.

Embodiments in the present description may provide zero-knowledge proof of asset type consistency in an electronic trading scenario relying on blockchains. That is, the transaction initiator may ensure that the block link point obtains the asset type ciphertext (i.e., the verification ciphertext in the following text) corresponding to both transaction parties based on the same asset type without providing any useful information (e.g., the secret value for generating the asset type ciphertext and the identification information of the asset type corresponding to the transaction asset) to the block link point as the verifier.

Fig. 1 is a schematic diagram of an application scenario of a blockchain system according to some embodiments of the present disclosure. As shown in fig. 1, the blockchain system 100 may include a blockchain client 110 (which may be referred to as a client), a blockchain network 120 and a network 130, wherein the blockchain network 120 includes more than one blockchain node (which may be referred to as a "node"), such as blockchain nodes 120-1, 120-2, 120-3 … 120-n, and the like.

The block-chain ue 110 can be connected to the block-chain network 120 through the network 130. Entities may access the blockchain network 120 through the blockchain client 110, and entities joining the blockchain network 120 may also be referred to as blockchain members. In some embodiments, the blockchain client 110 may upload information and/or data to one or more blockchain nodes in the blockchain network 120, such as to upload transaction records. In some embodiments, the transaction record may include transaction information (which may be referred to simply as "transactions") written into 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 data, such as transactions, stored in the blockchain (i.e., the distributed ledger, linked by persistently generated blocks).

In some embodiments, the user side of the transaction initiator may attach evidence for proving asset type consistency (i.e., verification ciphertext of both transaction parties is obtained based on the same asset type) to the transaction and upload to blockchain network 120, so that the nodes perform expected subsequent processes after at least passing verification of asset type consistency, e.g., writing the transaction to a block, updating accounts of both transaction parties, and so on.

In some embodiments, the user terminal may include various devices having information receiving and/or transmitting functions. In some embodiments, the user side may include a smart phone, a tablet computer, a personal computer, a server, and the like, or any combination thereof.

Each node in the blockchain network 120 needs to validate and confirm the transaction and generate a new block (this process may be referred to as "accounting"), and at the same time, each node may maintain consistency of the distributed ledger stored at each node through a consensus mechanism. It should be noted that the blocklink points can also be regarded as the ue of the blocklink network 120, and different from other ues, the blocklink points need to participate in billing. In addition, the entity may join the blockchain network 120 through a ue that does not participate in billing, or may join the blockchain network 120 through a blockchain node that participates in billing.

In some embodiments, the node may verify evidence in the transaction to confirm whether the verification ciphertext corresponding to both parties of the transaction is derived based on the same asset type. If the verification on the asset type consistency fails, that is, it is determined that the verification ciphertext corresponding to the two transaction parties is not obtained based on the same asset type, the node may refuse to execute the expected subsequent processes, for example, write the transaction into a block, update the accounts of the two transaction parties, and the like. It should be understood that in addition to verification of asset type compliance, verification of the transaction may include other verifications such as verification of the legitimacy of the amount, etc. In some embodiments, the node may perform the expected follow-up flow after passing multiple verifications of the transaction. For more details on transaction verification, reference may be made to fig. 5 and its associated description.

In some embodiments, a node may comprise various types of computing devices, such as a server.

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

The network 130 connects the various components of the system so that communication can occur between the various components. The network between the various parts in the system may include wired networks and/or wireless networks. For example, network 130 may include a cable network, a wired network, a fiber optic network, a telecommunications network, an intranet, the internet, a Local Area Network (LAN), a Wide Area Network (WAN), a Wireless Local Area Network (WLAN), a Metropolitan Area Network (MAN), a Public Switched Telephone Network (PSTN), a bluetooth network, a ZigBee network (ZigBee), Near Field Communication (NFC), an intra-device bus, an intra-device line, a cable connection, and the like, or any combination thereof. The network connection between each two parts may be in one of the above-mentioned ways, or in a plurality of ways. It is understood that the network 130 and the blockchain network 120 do not have to have a distinct boundary, and in a more general application scenario, blockchain nodes and common network nodes may be accessed together into the same physical network, wherein the blockchain nodes logically form the blockchain network.

FIG. 2 is an exemplary flow diagram of an asset type consistency evidence generation method shown in some embodiments in accordance with the present description. The process 200 may be performed by a device of a transaction initiator of a transaction, which may be connected to the blockchain network 120 as a user terminal (blockchain user terminal 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 may be implemented by reference ciphertext generation module 710.

It should be appreciated that a user terminal in the blockchain network 120 may employ a common encryption algorithm to generate the asset type verification ciphertext and the reference ciphertext.

Step 220, a first private key is generated. In some embodiments, step 220 may be implemented by first private key generation module 720.

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

The objective operation mentioned in this specification satisfies: the result of the target operation on the reference ciphertext and the verification ciphertext of the same object is a public key matched with a private key, and the private key is obtained by a private value used for generating the ciphertext of the same object. Based on this, if the private key is used to generate the digital signature, the signature verification can be successfully performed only by using the matched public key, that is, the precondition that the target operation limits the obtaining of the public key which can be successfully verified is as follows: the verification ciphertext and the reference ciphertext are derived based on the same object (asset type).

In step 220, a first private key is derived from the private value used to generate the first verification ciphertext and/or the reference ciphertext of the target asset type, and the first digital signature generated using the first private key in step 230 is successfully verified only using the first public key that matches the first private key. It should be understood that the private value may refer to a value that any transaction party (transaction initiator or transaction receiver) uses to generate ciphertext of the asset type and is not exposed to the outside, because leakage of the private value risks leakage of plaintext corresponding to the ciphertext (i.e., identification information of the asset type).

For example only, the verification ciphertext and the reference ciphertext may be derived based on the Pedersen commitment protocol. Below isIntroduction of relevant knowledge of the Pedersen commitment agreement: ciphertext meeting C = r based on Pedersen acceptance protocol₁*G+r₂H, wherein G, H is a generator (also called a base point) on the elliptic curve, r₁、r₂Are all integers, r₁*G、r₂H and C are still points on the elliptic curve.

It should be noted that the operation involving elliptic curves in this specification has similar properties to the four fundamental operations, and therefore, reference is made to the expression methods of the four fundamental operations (e.g., addition, subtraction, multiplication, plus, minus, plus, minus. In addition, in the embodiment of the present specification, the clients in the blockchain network 120 may have some common parameters, such as parameters of elliptic curve equations, G, H, and so on. Any of G, H may be used as the generation parameter of the public key, and the generation parameter of the public key is not 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 one of the transaction parties (the transaction initiator or the transaction recipient) respectively include a first portion corresponding to G and a second portion corresponding to H, wherein the first portion of the first verification ciphertext is derived based on the first generator and the secret value corresponding to the transaction initiator, the first portion of the second verification ciphertext is derived based on the first generator and the secret value corresponding to the transaction recipient, and the second portions of the first verification ciphertext, the second verification ciphertext, and the reference ciphertext are equal and are derived based on the second generator and the identification information of the target asset type, respectively. Accordingly, the target operation may be a difference. In this way, the public key for signature verification can be obtained only by calculating the difference between the verification ciphertext and the reference ciphertext of the same asset type to offset the second part of the two (the expansion form includes the public key generation parameter G).

For example, the verification ciphertext of any counterparty (transaction initiator or transaction receiver) may be calculated as C _ X = r _ X × Pk _ X + sn × H, where C _ X represents the verification ciphertext of the counterparty, r _ X represents a random number (considered as a private value of the counterparty), Pk _ X represents the public key of the counterparty, and sn represents identification information of the target asset type. It is noted that whereas Pk _ X = Pr _ X G, where Pr _ X represents the private key of the counterparty (being another private value of the counterparty), the authentication ciphertext computed as C _ X = r _ X Pk _ X + sn H is essentially a ciphertext based on the Pedersen commitment protocol.

It can be seen that the first verification secret C _ a = r _ a × Pk _ a + sn × H of the transaction initiator, where r _ a represents the first random number (regarded 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 as C _ X = r _ X × Pk _ X + sn × H, the reference ciphertext may be calculated as C₀=r₀G + sn H, where C₀Representing a reference ciphertext, r₀Represents a third random number, r₀May be viewed as limiting the secret value shared between the transaction initiator and the transaction recipient. Based on this, the target operation may refer to differencing 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 derived based on the same asset type, sn X H contained in both may be cancelled in the process of differencing, and C _ X-C may be derived₀=(r_X*Pr_X-r₀) G or C₀-C_X =(r₀-r _ X Pr _ X) G, wherein r _ X Pr _ X-r₀(or r)₀-r _ X Pr _ X) can be considered as 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 may be C _ A-C₀(or C)₀-C _ a), the device of the transaction initiator may calculate r _ a x Pr _ a-r₀(or r)₀-r _ a × Pr _ a) to obtain the first private key.

Step 230 generates a first digital signature for the first signed message using the first private key. The first signature message comprises a first verification ciphertext and a reference ciphertext. In some embodiments, step 230 may be implemented by first digital signature module 730.

At step 240, a second digital signature generated for the second signed message using the second private key is obtained. The second signature message comprises a second verification ciphertext and a reference ciphertext, the second verification ciphertext corresponds to the transaction receiver, and the result of the target operation performed on the second verification ciphertext and the reference ciphertext is a second public key matched with the second private key. In some embodiments, step 240 may be implemented by the second digital signature acquisition module 740.

And step 250, obtaining an evidence comprising the first verification ciphertext, the second verification ciphertext, the reference ciphertext, the first digital signature and the second digital signature so as to prove that the first verification ciphertext, the second verification ciphertext and the reference ciphertext are obtained based on the same asset type. In some embodiments, step 250 may be implemented by asset type compliance evidence acquisition module 750.

It should be appreciated that the first verification secret may be used to update the account of the transaction initiator and the second verification secret may be used to update the account of the transaction recipient.

The first digital signature is associated with the reference ciphertext and the first verification ciphertext, and when the first digital signature passes the verification, the associated first verification ciphertext and the reference ciphertext can be proved to be not tampered and are obtained based on the same asset type. Similarly, the second digital signature is associated with the reference ciphertext and the second verification ciphertext, and when the second digital signature is verified, the associated second verification ciphertext and the reference ciphertext can be proved to be not tampered and are obtained based on the same asset type. Further, evidence including the first verification ciphertext, the second verification ciphertext, the reference ciphertext, the first digital signature, and the second digital signature (hereinafter referred to as asset type consistency evidence) may prove that the first verification ciphertext, the second verification ciphertext, and the reference ciphertext are obtained based on the same asset type. When the first digital signature and the second digital signature both pass verification (namely the asset type consistency evidence passes verification), the first verification ciphertext, the second verification ciphertext and the reference ciphertext can be confirmed to be obtained based on the same asset type.

After obtaining the asset type consistency evidence, the device of the transaction initiator may attach the asset type consistency evidence 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 obtained based on the same asset type.

For more details on verifying evidence of asset type consistency, reference may be made to FIG. 5 and its associated description.

In some embodiments, the device of the transaction initiator may generate a second verification secret for the transaction recipient, taking into account that the transaction recipient's account may not have registered a target asset type. Of course, the device of the transaction initiator may send the second verification secret and the secret value used to generate the second verification secret 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 derived 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 recipient to cause the device of the transaction recipient to generate a second digital signature to prove that the second verification ciphertext and the reference ciphertext are based on the same asset type.

In some embodiments, the device of the transaction recipient may verify the received reference cryptogram. Based on this, when the reference ciphertext is generated based on at least the third random number (e.g., as C)₀= r₀G + sn H calculation), the transaction initiator's device may send the third random number to the transaction recipient's device. The equipment 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, if the received reference ciphertext and the comparison reference ciphertext are the same, the verification is passed, otherwise, the verification is not passed. When the received reference ciphertext is not verified, the device of the transaction recipient may refuse to perform subsequent processes, e.g., to not generate the second private key.

For example, an attacker may try to substitute identification information of multiple asset types into the calculation formulas of the reference ciphertexts respectively under the condition that the attacker knows the third random number (especially under the condition that the attacker also knows an asset type list containing the target asset type), and if a certain calculated result is found to be consistent with the publicly available reference ciphertexts, the asset type corresponding to the result, that is, the target asset type, may be determined. In view of this, the device of the transaction initiator may encrypt the third random number for transmission to the device of the transaction recipient. Specifically, the device of the transaction initiator may encrypt a message containing the third random number using the public key of the transaction receiver and send the encrypted message to the device of the transaction receiver, so that the device of the transaction receiver may decrypt the third random number using the private key of the transaction initiator.

In some embodiments, the device of the transaction initiator may transmit the identification information of the target asset type encrypted to the device of the transaction recipient. Although the device of the transaction recipient may filter out the target asset type by encrypting the identification information of one or more asset types, it is clear that informing the transaction recipient of the identification information of the target asset type by the transaction initiator is a more direct and efficient way.

The foregoing embodiments may be suitably combined, for example, the transaction initiator's device may sequence messages (C)₀，r₀Sn; c _ A, P _ A) to a device of the transaction recipient, wherein C₀Representing a reference ciphertext, r₀Representing a third random number, sn representing identification information of the target asset type, ca representing a first verification secret, and pa representing a first digital signature. Wherein, at least r₀And sn, e.g., the sequence of messages may be encrypted with the public key of the transaction recipient and sent to the transaction recipient's device.

FIG. 3 is an exemplary flow diagram of an asset type consistency evidence generation method shown in some embodiments in accordance with the present description. The process 300 may be performed by a transaction recipient device that may 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:

at step 310, a reference cryptogram of the target asset type is received from the transaction initiator. In some embodiments, step 310 may be implemented by reference ciphertext receiving module 810.

In some embodiments, the device of the transaction recipient may verify the received reference ciphertext and, if not, perform no further processing, e.g., no further generation of the second private key. In particular, in combination with the aforementioned embodiments, the device of the transaction recipient may be based on the third random number r₀And identification information sn of the target asset type (e.g., as C' = r)₀G + sn H computation) to obtain the comparison reference ciphertext C'. And further, the equipment of the transaction receiver compares the reference ciphertext with the reference ciphertext, if the reference ciphertext and the reference ciphertext are the same, the verification is passed, otherwise, the verification is not passed.

Step 320, a second private key is generated. In some embodiments, step 320 may be implemented by second private key generation module 820.

And the result of performing target operation on the second verification ciphertext and the reference ciphertext of the target asset type is a second public key matched with the second private key, and the second verification ciphertext corresponds to the transaction receiving party. For more details on the target operation, reference may be made to the relevant description in flow 200.

Referring to the previous 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 may be C _ B-C₀(or C)₀-C _ B), the device of the transaction recipient can calculate r _ B by Pr _ B-r₀(or r)₀-r _ B × Pr _ B) to derive a second private key. Where r _ B represents the second random number (considered as the private value of the transaction recipient), and Pk _ B represents the public key of the transaction recipient (Pk _ B = Pr _ B × G is satisfied, where Pr _ B represents the private key of the transaction recipient).

Step 330 generates a second digital signature for the second signed message using the second private key. And the second signature message comprises a second verification ciphertext and a reference ciphertext. In some embodiments, step 330 may be implemented by second digital signature module 830.

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

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

Further details regarding evidence of asset type correspondence may be found in relation to the description of flow 200 and will not be repeated herein.

In some embodiments, a device of a transaction recipient may receive a sequence of messages (C) from a transaction initiator₀，r₀Sn; c _ A, P _ A), wherein C₀Representing a reference ciphertext, r₀Representing a third random number used to generate the reference ciphertext, sn representing identification information of the target asset type, ca representing the first verification ciphertext, pa the first digital signature. Further, the device of the transaction recipient may press C' = r₀And G + sn H is calculated to obtain a comparison reference ciphertext C'. If C' = C₀Then the device of the transaction receiver can calculate r _ B and r₀And obtaining a second private key by using the difference value, and generating a second digital signature for the second signature message by using the second private key.

Further details regarding the process 300 can be found in the process 200 and its related description, and are not repeated herein.

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

Fig. 4 is an exemplary flow diagram of a transaction method according to some embodiments of the present description. The process 400 may be performed by the device of the transaction initiator or the transaction recipient in the process 200 (or the process 300). It should be appreciated that when the flow 400 is performed by the device of the transaction recipient in the flow 200 (or the flow 300), the transaction recipient in the flow 200 (or the flow 300) is the party who re-initiates the transaction for the target asset type. As shown in fig. 4, the process 400 may include:

and step 410, obtaining an asset type consistency evidence for proving that the verification ciphertext corresponding to both transaction parties and the reference ciphertext are obtained based on the same asset type. In some embodiments, step 410 may be implemented by obtaining module 910.

Further details regarding evidence of asset type correspondence may be found in fig. 2, 3, and related descriptions, and will not be repeated here.

At step 420, a third digital signature is generated for the third signed message using the private key of the transaction initiator or the transaction receiver. And the third message to be signed comprises identification information of accounts of both transaction parties and asset type consistency evidence. In some embodiments, step 420 may be implemented by a third digital signature module 920.

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

In some embodiments, the third signed message may include more content. For example, the third signed message may also include the transaction amount (which may be in encrypted form), an amount legitimacy proof, and the like, wherein the amount legitimacy proof is used to prove the legitimacy of the amount value. Situations that would cause the transaction to be abnormal are not allowed (i.e., illegal), such as the following: 1. the balance of the account of the transaction initiator is less than the transaction amount, and the account of the transaction initiator does not have payment capacity at the moment; 2. the value of the transaction amount is negative, which causes the account amount to increase or decrease contrary to the expectation, i.e., the account amount does not increase or decrease.

In some embodiments, the transaction amount may be encrypted using various encryption algorithms that support zero knowledge proof, such as, for example, an encryption algorithm based on the Pedersen commitment protocol, a hash algorithm encryption, a homomorphic encryption algorithm, and so forth. In some embodiments, when encrypting the transaction amount using the Pedersen-based commitment agreement, proof of legitimacy of the amount may be generated using zero knowledge proof techniques "Ring signed confidential transactions" and "Bulletprofo". In some embodiments, when the transaction amount is encrypted using a hashing algorithm, the amount legitimacy evidence may be generated using the zero knowledge proof technique "zksnark".

FIG. 5 is an exemplary flow diagram of a transaction verification method according to some embodiments of the present description. The process 500 may be performed by block chain nodes. As shown in fig. 5, the process 500 may include:

step 510, receiving a third signature message and a third digital signature, where 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 ciphertext and a second digital signature corresponding to the transaction receiver. In some embodiments, step 510 may be implemented by receiving module 1010.

The third digital signature is verified 520 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 authentication module 1020.

By verifying the third digital signature it can be determined that: 1. whether the signer is the transaction party (the transaction initiator or the transaction recipient in flow 200/300); 2. whether the third signed message was tampered with.

When the third digital signature is verified, indicating that the signer is indeed the transaction party and that the third signed message has not been tampered with, the blockchain node may proceed to step 530. When the third digital signature fails to verify, the block node may refuse to perform subsequent processes (step 530), i.e., consider the transaction verification failed.

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

The second verification module 1030 may perform target operation on the reference ciphertext and the first verification ciphertext to obtain a first public key for verifying the first digital signature, and may obtain a first signature message for verifying the first digital signature based on the reference ciphertext and the first verification ciphertext. Similarly, the second verification module 1030 may perform a target operation on the reference ciphertext and the second verification ciphertext to obtain a second public key for verifying the second digital signature, and may obtain a second signature message for verifying the second digital signature based on the reference ciphertext and the second verification ciphertext.

If the first digital signature and the second digital signature are verified, block chain node may perform step 540. If either the first digitally signed or the second digitally signed message is not verified, then block chain node may perform step 550. In some embodiments,

steps

540 and 550 may be implemented by determination module 1040.

It should be understood that the specific implementation manner of step 530 is not limited, and for example, one may default to verify either one of the first digital signature and the second digital signature, and if the previously verified digital signature is not verified, the other one of the first digital signature and the second digital signature is not verified.

And 540, determining that the first verification ciphertext, the second verification ciphertext and the reference ciphertext are obtained based on the same asset type.

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

If the first digital signature and the second digital signature received by the block link point both pass the verification, the verification ciphertext corresponding to both transaction parties and the reference ciphertext are obtained based on the same asset type, namely the first verification ciphertext and the second verification ciphertext are obtained based on the same asset type. Otherwise, the first verification ciphertext and the second verification ciphertext are not obtained based on the same asset type.

The transaction is verified if both the first digital signature and the second digital signature (and, of course, the third digital signature) are verified. If the block link point passes the transaction verification, the expected subsequent processes can be continuously executed. For example, a transaction including a third signed message and a third digital signature may be written to the block. For another example, the accounts of the two transaction parties are updated based on the verification ciphertexts corresponding to the two transaction parties, specifically, the transaction amount e (t) may be determined from the third signature message, and the balance in the account of the transaction initiator corresponding to the first verification ciphertext is decreased by e (t) and the balance in the account of the transaction initiator corresponding to the second verification ciphertext is increased by e (t). Otherwise, execution of the intended subsequent flow may be denied.

According to the related content in the process 400, the third signed message may further include an amount validity proof, and accordingly, the block link point may further verify the amount validity proof after verifying the third digital signature. It should be understood that the order of verification of the monetary legality proof and the first/second digital signature is optional, and when any one of the monetary legality proof, the first digital signature, and the second digital signature fails to verify, the blockchain node may refuse to perform 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, indicating that the first verification ciphertext and the second verification ciphertext are obtained based on the same asset type (i.e., the target asset type), the block link point may 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 an associated manner. As such, when any counterparty in the verified historical transaction again initiates a transaction for the target asset type, the first verification ciphertext and the second verification ciphertext may be provided to the block link point. After confirming that the identities of the transaction initiator and the transaction receiver are correct, the block link points locally search whether the association record containing the identification information of the transaction initiator, the identification information of the transaction receiver, the first verification ciphertext and the second verification ciphertext is stored. If the association record exists, which indicates that the consistency between the first verification ciphertext and the second verification ciphertext is successfully verified in the historical transaction, the verification of the first digital signature and the second digital signature can be omitted when the transaction is verified by the block chain node, and certainly, the party who initiates the transaction again does not need to provide the first digital signature and the second digital signature to the block chain node any more.

In some embodiments, the association record maintained by the tile link point may include more content. For example, block chain nodes may hold message sequences (A, B; C)₀C _ A, C _ B; p _ a, P _ B), where a represents identification information of the transaction initiator, C _ a represents a first verification ciphertext, P _ B represents a first digital signature, B represents identification information of the transaction recipient, C _ B represents a second verification ciphertext, P _ B represents a second digital signature, C _ B represents a second digital signature₀Representing the reference cipher text.

In some embodiments, a block link point may generate a corresponding ID for the stored association record and feed that ID back to the transaction party. In this way, when the two parties of the transaction perform new transaction again according to the target asset type, the device of the party initiating the new transaction can provide the ID to the block chain node, the block chain node searches the recorded verification ciphertext of the two parties of the transaction according to the received ID, and updates the accounts of the two parties of the transaction based on the searched verification ciphertext.

It is worth noting that one or more of the steps in this specification can also be implemented by invoking an intelligent contract. Due to the characteristics of necessary execution, non-tampering, traceability and the like, the intelligent contract can ensure that the corresponding steps are executed as expected and leave traceable evidence.

Although the present description is primarily described in the context of transactions for the same asset type, the principles of the present description may be more generally applied to multi-party transactions for the same object. A multi-party transaction herein may refer to a transaction having the following features: 1. more than two parties are required to participate in a transaction together; 2. each participant needs to participate in a transaction for the same object (called a target object); 3. for any party, transaction information related to a target object needs to be recorded publicly based on an object ciphertext corresponding to the party, so that privacy disclosure is prevented. By way of example only, multi-party transactions herein may include the exchange of the same type of data, the coordinated updating of the same type of data, and the like.

FIG. 6 is an exemplary flow diagram of a method for generating evidence of object correspondence, shown in some embodiments in accordance with the present description. The process 600 may be performed by a device of any party to a multi-party transaction (hereinafter party X), and in particular, party X may refer to a transaction initiator or a transaction recipient in a transaction. As shown in fig. 6, the process 600 may include:

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

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

The result of the target operation on the verification ciphertext and the reference ciphertext of the target object is a target public key matched with the target private key, and the target operation meets the following requirements: the result of the target operation on the reference ciphertext and the verification ciphertext of the same object is a public key matched with a private key, and the private key is obtained by a private value used for generating the ciphertext of the same object. It should be appreciated that the verification secret (which may be designated as C _ X) corresponds to party X and may be used to publicly record transaction information related to the target object corresponding to party X.

Step 630, generate a target digital signature for the target signature message using the target private key, the target signature message including the verification ciphertext (C _ X) and the reference ciphertext. In some embodiments, step 630 may be implemented by digital signature module 1130.

And step 640, obtaining an evidence at least comprising the verification ciphertext (C _ X), the reference ciphertext and the target digital signature, so as to prove that at least 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 object consistency evidence obtaining module 1140.

The target digital signature corresponding to any party can be used for proving that the verification ciphertext corresponding to the party and the reference ciphertext are obtained based on the same object. Therefore, the evidence (hereinafter, referred to as object consistency evidence) which can be used for proving that the verification ciphertext corresponding to each participant and the reference ciphertext are obtained based on the same object comprises the reference ciphertext, the verification ciphertext corresponding to each participant and the target digital signature corresponding to each participant.

Any party can send a message containing the object consistency evidence to the equipment of the verifier, so that the equipment of the verifier confirms whether the verification ciphertext corresponding to each party is obtained 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 can be recorded based on the verification ciphertext corresponding to each participant.

It should be appreciated that more details regarding flow 600 may be found in reference to flow 200, flow 300, and related description thereof. For example, for more details about the target private key (public key), reference may be made to the relevant description of the first/second private key (public key). For another example, for more details regarding the target signed message and the target digital signature, reference may be made to the associated description of the first/second signed message and the first/second digital signature. As another example, for more details on object consistency evidence, reference may be made to a related description of asset type consistency evidence.

It should be noted that the above description of the flow is for illustration and description only and does not limit the scope of the application of the present specification. Various modifications and alterations to the flow may occur to those skilled in the art, given the benefit of this description. However, such modifications and variations are intended to be within the scope of the present description.

FIG. 7 is an exemplary block diagram of an asset type consistency evidence generation system shown in accordance with some embodiments of the present description. The system 700 may be implemented on a device of a transaction initiator. As shown in fig. 7, system 700 may include a reference ciphertext generation module 710, a first private key generation module 720, a first digital signature module 730, a second digital signature acquisition module 740, and an asset type compliance evidence acquisition module 750.

Reference ciphertext generation module 710 may be configured to generate a reference ciphertext of the target asset type.

First private key generation module 720 may be used to generate a first private key.

First digital signature module 730 may be configured to generate a first digital signature for a first signed message using the first private key.

The second digital signature obtaining module 740 may be configured to obtain a second digital signature generated for the second signed message using a second private key.

The asset type consistency evidence obtaining module 750 may be configured to obtain an evidence including a first verification ciphertext, a second verification ciphertext, a reference ciphertext, a first digital signature, and a 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.

For more details on the system 700 and its modules, reference may be made to fig. 2 and its associated description.

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

The reference ciphertext receiving module 810 may be configured to receive a reference ciphertext of the target asset type from the transaction initiator.

Second private key generation module 820 may be used to generate a second private key.

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

The sending module 840 may be configured to send the second verification secret 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 on the system 800 and its modules, reference may be made to fig. 3 and its associated description.

Fig. 9 is an exemplary block diagram of a transaction system, shown in accordance with some embodiments of the present description. The system 900 may be implemented on the device of the transaction initiator or the transaction recipient 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 may be configured to obtain an asset type consistency evidence for proving that the verification ciphertext corresponding to the two transaction parties and the reference ciphertext are obtained based on the same asset type.

The third digital signature module 920 may be configured to generate a third digital signature for the third signed message using a private key of the transaction initiator or the transaction recipient.

The upload module 930 may be configured to upload the third signed message and the third digital signature to the blockchain network 120.

For more details of the system 900 and its modules, reference may be made to FIG. 4 and its associated description.

FIG. 10 is an exemplary block diagram of a transaction verification system according to some embodiments of the present description. 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 determining module 1040.

The receiving module 1010 may be configured to receive a third signature message and a third digital signature, where the third signature message includes a reference ciphertext, a first verification ciphertext and a first digital signature that correspond to a transaction initiator, and a second verification ciphertext and a second digital signature that correspond to a transaction receiver.

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

The second verification module 1030 may be configured to, when the third digital signature is verified: verifying the first digital signature based on the first public key and the first signature message; and/or verifying the second digital signature based on the second public key and the second signed message.

The determination module 1040 may be configured to: if the first digital signature and the second digital signature pass the verification, determining that a first verification ciphertext, a second verification ciphertext and a reference ciphertext are obtained based on the same asset type; and if the first digital signature or the second digital signature fails to pass the verification, determining that the first verification ciphertext, the second verification ciphertext and the reference ciphertext are not obtained based on the same asset type and refusing to execute the subsequent flow.

For more details of the system 1000 and its modules, reference may be made to fig. 5 and its associated description.

FIG. 11 is an exemplary block diagram of an object-consistent evidence generation system shown in some embodiments in accordance with the present description. The system 1100 can be implemented on a device of any party to a multi-party transaction (hereinafter party X). As shown in fig. 11, system 1100 may include a reference ciphertext obtaining module 1110, a private key generation module 1120, a digital signature module 1130, and an object-consistent evidence obtaining module 1140.

The reference ciphertext obtaining module 1110 may be configured to obtain a reference ciphertext of the target object.

Private key generation module 1120 can be used to generate a target private key.

The digital signature module 1130 may be used to generate a target digital signature for a target signature message using a target private key, the target signature message including a verification ciphertext (C _ X) and a reference ciphertext.

The object consistency evidence obtaining module 1140 may be configured to obtain an evidence at least including the verification ciphertext (C _ X), the reference ciphertext, and the target digital signature, so as to prove that at least the verification ciphertext and the reference ciphertext are obtained based on the same object.

For more details of the system 1100, reference may be made to FIG. 6 and its associated description.

It should be understood that the systems and modules thereof shown in FIGS. 7-11 can be implemented in a variety of ways. For example, in some embodiments, the system and its modules may be implemented in hardware, software, or a combination of software and hardware. Wherein the hardware portion may be implemented using dedicated logic; the software portions may be stored in a memory for execution by a suitable instruction execution system, such as a microprocessor or specially designed hardware. Those skilled in the art will appreciate that the methods and systems described above may be implemented using computer executable instructions and/or embodied in processor control code, such code being provided, for example, on a carrier medium such as a diskette, CD-or DVD-ROM, a programmable memory such as read-only memory (firmware), or a data carrier such as an optical or electronic signal carrier. The system and its modules in this specification may be implemented not only by hardware circuits such as very large scale integrated circuits or gate arrays, semiconductors such as logic chips, transistors, or programmable hardware devices such as field programmable gate arrays, programmable logic devices, etc., but also by software executed by various types of processors, for example, or by a combination of the above hardware circuits and software (e.g., firmware).

It should be noted that the above description of the system and its modules is for convenience only and should not limit the present disclosure to the illustrated embodiments. It will be appreciated by those skilled in the art that, given the teachings of the system, any combination of modules or sub-system configurations may be used to connect to other modules without departing from such teachings. 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 may be a module that implements the functionality of both modules. Such variations are within the scope of the present disclosure.

The beneficial effects that may be brought by the embodiments of the present description include, but are not limited to: (1) on the premise of protecting the private value of a transaction party for generating a verification ciphertext, a scheme for verifying whether the verification ciphertext corresponding to the transaction party is obtained based on the same asset type publicly and zero-knowledge is designed by introducing a reference ciphertext; (2) after one verification on the asset type consistency is completed, the related information of the verification is recorded, so that repeated verification can be avoided; (3) one or more steps may be implemented by smart contracts to ensure that the respective steps perform as intended and leave a traceable deposit. It is to be noted that different embodiments may produce different advantages, and in different embodiments, any one or combination of the above advantages may be produced, or any other advantages may be obtained.

Having thus described the basic concept, it will be apparent to those skilled in the art that the foregoing detailed disclosure is to be considered merely illustrative and not restrictive of the embodiments herein. Various modifications, improvements and adaptations to the embodiments described herein may occur to those skilled in the art, although not explicitly described herein. Such modifications, improvements and adaptations are proposed in the embodiments of the present specification and thus fall within the spirit and scope of the exemplary embodiments of the present specification.

Also, the description uses specific words to describe embodiments of the description. Reference throughout this specification to "one embodiment," "an embodiment," and/or "some embodiments" means that a particular feature, structure, or characteristic described in connection with at least one embodiment of the specification is included. Therefore, it is emphasized and should be appreciated that two or more references to "an embodiment" or "one embodiment" or "an alternative embodiment" in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, some features, structures, or characteristics of one or more embodiments of the specification may be combined as appropriate.

Moreover, those skilled in the art will appreciate that aspects of the embodiments of the present description may be illustrated and described in terms of several patentable species or situations, including any new and useful combination of processes, machines, manufacture, or materials, or any new and useful improvement thereof. Accordingly, aspects of embodiments of the present description may be carried out entirely by hardware, entirely by software (including firmware, resident software, micro-code, etc.), or by a combination of hardware and software. The above hardware or software may be referred to as "data block," module, "" engine, "" unit, "" component, "or" system. Furthermore, aspects of the embodiments of the present specification may be represented as a computer product, including computer readable program code, embodied in one or more computer readable media.

The computer storage medium may comprise a propagated data signal with the computer program code embodied therewith, for example, on baseband or as part of a carrier wave. The propagated signal may take any of a variety of forms, including electromagnetic, optical, etc., or any suitable combination. A computer storage medium may be any computer-readable medium that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code located on a computer storage medium may be propagated over any suitable medium, including radio, cable, fiber optic cable, RF, or the like, or any combination of the preceding.

Computer program code required for operation of various portions of the embodiments of the present description may be written in any one or more programming languages, including an object oriented programming language such as Java, Scala, Smalltalk, Eiffel, JADE, Emerald, C + +, C #, VB.NET, Python, and the like, a conventional programming language such as C, VisualBasic, Fortran2003, Perl, COBOL2002, PHP, ABAP, a dynamic programming language such as Python, Ruby, and Groovy, or other programming languages, and the like. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or processing device. In the latter scenario, the remote computer may be connected to the user's computer through any network format, such as a Local Area Network (LAN) or a Wide Area Network (WAN), or the connection may be made to an external computer (for example, through the Internet), or in a cloud computing environment, or as a service, such as a software as a service (SaaS).

In addition, unless explicitly stated in the claims, the order of processing elements and sequences, use of numbers and letters, or use of other names in the embodiments of the present specification are not intended to limit the order of the processes and methods in the embodiments of the present specification. While various presently contemplated embodiments of the invention have been discussed in the foregoing disclosure by way of example, it is to be understood that such detail is solely for that purpose and that the appended claims are not limited to the disclosed embodiments, but, on the contrary, are intended to cover all modifications and equivalent arrangements that are within the spirit and scope of the embodiments herein. For example, although the system components described above may be implemented by hardware devices, they may also be implemented by software-only solutions, such as installing the described system on an existing processing device or mobile device.

Similarly, it should be noted that in the preceding description of embodiments of the specification, various features are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure and aiding in the understanding of one or more embodiments of the invention. This method of disclosure, however, is not intended to imply that more features are required than are expressly recited in the claims. Indeed, the embodiments may be characterized as having less than all of the features of a single embodiment disclosed above.

For each patent, patent application publication, and other material, such as articles, books, specifications, publications, documents, etc., cited in this specification, the entire contents of each are hereby incorporated by reference into this specification. Except where the application is inconsistent or conflicting with the present disclosure, as may be the case with the broadest limitation of the claims that follow (whether present or appended to the present specification). It is to be understood that the descriptions, definitions and/or uses of terms in the accompanying materials of this specification shall control if they are inconsistent or contrary to the descriptions and/or uses of terms in this specification.

Finally, it should be understood that the embodiments described herein are merely illustrative of the principles of the embodiments of the present disclosure. Other variations are possible within the scope of the embodiments of the present description. Thus, by way of example, and not limitation, alternative configurations of the embodiments of the specification can be considered consistent with the teachings of the specification. Accordingly, the embodiments of the present description are not limited to only those embodiments explicitly described and depicted herein.

Claims

1. A method of asset type compliance evidence generation, wherein the method is performed by a device of a transaction initiator, comprising:

generating a reference ciphertext of the target asset type;

generating a first private key; wherein a 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 matched with the first private 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 is a public key matched with a private key, and the private key is obtained by a private value used for generating the ciphertext of the same object;

generating a first digital signature for a first signed message using the first private key; wherein the first signature message comprises the first verification ciphertext and the reference ciphertext;

obtaining a second digital signature generated for the second signed message using a second private key; the second signature message comprises a second verification ciphertext of the target asset type and the reference ciphertext, the second verification ciphertext corresponds to a transaction receiving party, and a result of performing the target operation on the second verification ciphertext and the reference ciphertext is a second public key matched with the second private key;

and obtaining evidence including the first verification ciphertext, the second verification ciphertext, the reference ciphertext, the first digital signature and the second digital signature so as to prove that the first verification ciphertext, the second verification ciphertext and the reference ciphertext are obtained based on the same asset type.

2. The method of claim 1, wherein the first verification ciphertext, the second verification ciphertext, and the reference ciphertext are each derived based on a Pedersen commitment protocol.

3. The method of claim 2, wherein the first verification ciphertext, the second verification ciphertext, and the reference ciphertext respectively include a first portion corresponding to a first generator and a second portion corresponding to a second generator, wherein the first generator and the second generator are located on the same elliptic curve and the first generator is a public key generation parameter, a first portion of the first verification ciphertext is derived based on the first generator and a secret value corresponding to the transaction initiator, a first portion of the second verification ciphertext is derived based on the first generator and a privacy value corresponding to the transaction recipient, a second part of the first verification ciphertext, the second verification ciphertext and the reference ciphertext is equal and is respectively obtained based on the second generator and the identification information of the target asset type;

the target operation is a difference calculation.

4. The method of claim 1, wherein the obtaining a second digital signature generated for a second signed message using a second private key comprises:

at least sending the reference ciphertext to a device of a transaction recipient, so that the device of the transaction recipient generates the second digital signature;

receiving the second digital signature and the second verification secret from a device of the transaction recipient to obtain the evidence.

5. The method of claim 4, wherein the reference ciphertext is generated based on at least a third random number, the method further comprising:

and sending the third random number to the equipment of the transaction receiver.

6. The method of claim 4, further comprising:

and encrypting and transmitting the identification information of the target asset type to the equipment of the transaction receiver.

7. The method of claim 1 or 4, further comprising:

and sending the first verification ciphertext and the first digital signature to the equipment of the transaction receiver.

8. The method of claim 1, further comprising generating the second verification secret; the obtaining a second digital signature generated on a second signed message using a second private key, comprising:

generating a second private key, wherein the result of the target operation on the second verification ciphertext and the reference ciphertext is a second public key matched with the second private key;

generating the second digital signature on the second signed message using the second private key.

9. An asset type compliance evidence generation system, wherein the system is implemented on a device of a transaction initiator, comprising:

the reference ciphertext generating module is used for generating a reference ciphertext of the target asset type;

the first private key generation module is used for generating a first private key; wherein a 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 matched with the first private 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 is a public key matched with a private key, and the private key is obtained by a private value used for generating the ciphertext of the same object;

a first digital signature module for generating a first digital signature for a first signed message using the first private key; wherein the first signature message comprises the first verification ciphertext and the reference ciphertext;

a second digital signature obtaining module, configured to obtain a second digital signature generated for the second signed message using a second private key; the second signature message comprises a second verification ciphertext of the target asset type and the reference ciphertext, the second verification ciphertext corresponds to a transaction receiving party, and a result of performing the target operation on the second verification ciphertext and the reference ciphertext is a second public key matched with the second private key;

and the asset type consistency evidence obtaining module is used for obtaining an evidence containing the first verification ciphertext, the second verification ciphertext, the reference ciphertext, the first digital signature and the second digital signature so as to prove that the first verification ciphertext, the second verification ciphertext and the reference ciphertext are obtained based on the same asset type.

10. An asset type consistency evidence generating apparatus comprising a processor and a storage device, the storage device being arranged to store instructions which, when executed by the processor, implement the method of any one of claims 1 to 8.

11. A method of asset type compliance evidence generation, wherein the method is performed by a device of a transaction recipient, comprising:

receiving a reference ciphertext of a target asset type from a transaction initiator;

generating a second private key; wherein a result of performing a target operation on a second verification ciphertext of the target asset type and the reference ciphertext is a second public key matched with the second private key, the second verification ciphertext corresponds to the transaction recipient, and the target operation satisfies: the result of the target operation on the reference ciphertext and the verification ciphertext of the same object is a public key matched with a private key, and the private key is obtained by a private value used for generating the ciphertext of the same object;

generating a second digital signature for a second signed message using the second private key; wherein the second signature message comprises the second verification ciphertext and the reference ciphertext;

sending the second verification ciphertext and the second digital signature to the transaction initiator's device, so that the transaction initiator's device obtains evidence including the first verification ciphertext, the second verification ciphertext, the reference ciphertext, the first digital signature, and the second digital signature of the target asset type; the first verification ciphertext corresponds to the transaction initiator, the first digital signature is generated by using a first private key to a first signature message, the first signature message comprises the first verification ciphertext and the reference ciphertext, and the evidence is used for proving that the first verification ciphertext, the second verification ciphertext and the reference ciphertext are obtained based on the same asset type.

12. The method of claim 11, wherein the first verification ciphertext, the second verification ciphertext, and the reference ciphertext are each derived based on a Pedersen commitment protocol.

13. The method of claim 12, wherein the first verification ciphertext, the second verification ciphertext, and the reference ciphertext respectively include a first portion corresponding to a first generator and a second portion corresponding to a second generator, wherein the first generator and the second generator are located on the same elliptic curve and the first generator is a public key generation parameter, a first portion of the first verification ciphertext is derived based on the first generator and a secret value corresponding to the transaction initiator, a first portion of the second verification ciphertext is derived based on the first generator and a privacy value corresponding to the transaction recipient, a second part of the first verification ciphertext, the second verification ciphertext and the reference ciphertext is equal and is respectively obtained based on the second generator and the identification information of the target asset type;

the target operation is a difference calculation.

14. The method of 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 comprises:

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

and comparing the reference ciphertext with the comparison reference ciphertext, if the reference ciphertext and the comparison reference ciphertext are the same, passing the verification, otherwise, failing to pass the verification.

15. The method of claim 11, further comprising:

receiving the first verification cryptogram and the first digital signature from a device of the transaction initiator to obtain the evidence.

16. An asset type compliance evidence generation system, wherein the system is implemented on a device of a transaction recipient, comprising:

the reference ciphertext receiving module is used for receiving a reference ciphertext of the target asset type from the transaction initiator;

the second private key generation module is used for generating a second private key; wherein a result of performing a target operation on a second verification ciphertext of the target asset type and the reference ciphertext is a second public key matched with the second private key, the second verification ciphertext corresponds to the transaction recipient, and the target operation satisfies: the result of the target operation on the reference ciphertext and the verification ciphertext of the same object is a public key matched with a private key, and the private key is obtained by a private value used for generating the ciphertext of the same object;

the second digital signature module is used for generating a second digital signature for the second signature message by using the second private key; wherein the second signature message comprises the second verification ciphertext and the reference ciphertext;

a sending module, 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 an evidence including the first verification ciphertext, the second verification ciphertext, the reference ciphertext, the first digital signature, and the second digital signature of the target asset type; the first verification ciphertext corresponds to the transaction initiator, the first digital signature is generated by using a first private key to a first signature message, the first signature message comprises the first verification ciphertext and the reference ciphertext, and the evidence is used for proving that the first verification ciphertext, the second verification ciphertext and the reference ciphertext are obtained based on the same asset type.

17. An asset type compliance evidence generating apparatus comprising a processor and a storage device for storing instructions which, when executed by the processor, implement the method of any one of claims 11 to 15.

18. A method of trading, comprising:

the asset type consistency evidence generation method according to any one of claims 1 to 8 and 11 to 15, obtaining evidence for proving that a verification ciphertext and a reference ciphertext corresponding to both transaction parties are obtained based on the same asset type;

generating a third digital signature for a third signature message by using a private key of the transaction initiator or the transaction receiver, wherein the third signature message comprises identification information of accounts of both transaction parties and the evidence;

uploading the third signed message and the third digital signature to a blockchain network.

19. A transaction system, comprising:

an obtaining module, configured to obtain, by the asset type consistency evidence generation method according to any one of claims 1 to 8 and 11 to 15, an evidence for proving that a verification ciphertext and a reference ciphertext corresponding to both transaction parties are obtained based on the same asset type;

the third digital signature module is used for generating a third digital signature for a third signature message by using a private key of the transaction initiator or the transaction receiver, wherein the third signature message comprises identification information of accounts of both transaction parties and the evidence;

and the uploading module is used for uploading the third signature message and the third digital signature to a blockchain network.

20. A transaction apparatus comprising a processor and a storage device for storing instructions which, when executed by the processor, carry out the method of claim 18.

21. A transaction verification method, comprising:

receiving a third signature message and a third digital signature, wherein the third signature message comprises a reference ciphertext, a first verification ciphertext and a first digital signature which correspond to a transaction initiator, and a second verification ciphertext and a second digital signature which correspond to a transaction receiver;

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

when the third digital signature is verified: performing target operation on the reference ciphertext and the first verification ciphertext to obtain a first public key for verifying the first digital signature, obtaining a first signature message for verifying the first digital signature based on the reference ciphertext and the first verification ciphertext, and verifying the first digital signature based on the first public key and the first signature message; 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, obtaining a second signature message for verifying the second digital signature based on the reference ciphertext and the second verification ciphertext, and verifying the second digital signature based on the second public key and the second signature message;

and if the first digital signature and the second digital signature pass the verification, determining 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:

and recording the identification information of the transaction initiator, the identification information of the transaction receiver, the first digital signature, the second digital signature, the first verification ciphertext, the second verification ciphertext and the reference ciphertext in an associated manner.

23. A transaction verification system, comprising:

the receiving module is used for receiving a third signature message and a third digital signature, wherein the third signature message comprises a reference ciphertext, a first verification ciphertext and a first digital signature which correspond to a transaction initiator, and a second verification ciphertext and a second digital signature which correspond to a transaction receiver;

the first verification module is used for verifying the third digital signature based on the public key of the transaction initiator or the transaction receiver and the third signature message;

a second verification module for, when the third digital signature is verified: performing target operation on the reference ciphertext and the first verification ciphertext to obtain a first public key for verifying the first digital signature, obtaining a first signature message for verifying the first digital signature based on the reference ciphertext and the first verification ciphertext, and verifying the first digital signature based on the first public key and the first signature message; 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, obtaining a second signature message for verifying the second digital signature based on the reference ciphertext and the second verification ciphertext, and verifying the second digital signature based on the second public key and the second signature message;

a determination module to: and if the first digital signature and the second digital signature pass the verification, determining that the first verification ciphertext, the second verification ciphertext and the reference ciphertext are obtained based on the same asset type.

24. A transaction verification apparatus comprising a processor and a storage device for storing instructions which, when executed by the processor, carry out the method of claim 21 or 22.

25. An object-consistent evidence generation method, wherein the method is performed by a device of any party to a transaction, the transaction including a transaction for the same asset type, an exchange of data of the same type, or an update of data of the same type, the method comprising:

obtaining a reference ciphertext of the target object;

generating a target private key; wherein, the result of the target operation performed on the verification ciphertext of the target object and the reference ciphertext is a target public key matched with the target private key, and the target operation satisfies the following conditions: the result of the target operation on the reference ciphertext and the verification ciphertext of the same object is a public key matched with a private key, and the private key is obtained by a private value used for generating the ciphertext of the same object;

generating a target digital signature for a target signature message by using the target private key; wherein the target signature message comprises the verification ciphertext and the reference ciphertext;

and obtaining evidence at least comprising the verification ciphertext, the reference ciphertext and the target digital signature so as to prove that at least the verification ciphertext and the reference ciphertext are obtained based on the same object.

26. An object-consistent evidence generation system, wherein the system is implemented on a device of any party to a transaction, the transaction including a transaction for the same asset type, an exchange of data of the same type, or an update of data of the same type, the system comprising:

the reference ciphertext obtaining module is used for obtaining a reference ciphertext of the target object;

the private key generation module is used for generating a target private key; wherein, the result of the target operation performed on the verification ciphertext of the target object and the reference ciphertext is a target public key matched with the target private key, and the target operation satisfies the following conditions: the result of the target operation on the reference ciphertext and the verification ciphertext of the same object is a public key matched with a private key, and the private key is obtained by a private value used for generating the ciphertext of the same object;

the digital signature module is used for generating a target digital signature for the target signature message by using the target private key; wherein the target signature message comprises the verification ciphertext and the reference ciphertext;

and the object consistency evidence obtaining module is used for obtaining the evidence at least comprising the verification ciphertext, 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.

27. An object consistency evidence generating apparatus comprising a processor and a storage device for storing instructions which, when executed by the processor, implement the method of claim 25.