WO2021228239A1 - 资产类型一致性证据生成、交易、交易验证方法及*** - Google Patents

资产类型一致性证据生成、交易、交易验证方法及*** Download PDF

Info

Publication number
WO2021228239A1
WO2021228239A1 PCT/CN2021/093889 CN2021093889W WO2021228239A1 WO 2021228239 A1 WO2021228239 A1 WO 2021228239A1 CN 2021093889 W CN2021093889 W CN 2021093889W WO 2021228239 A1 WO2021228239 A1 WO 2021228239A1
Authority
WO
WIPO (PCT)
Prior art keywords
ciphertext
verification
digital signature
transaction
target
Prior art date
Application number
PCT/CN2021/093889
Other languages
English (en)
French (fr)
Inventor
张文彬
Original Assignee
支付宝(杭州)信息技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 支付宝(杭州)信息技术有限公司 filed Critical 支付宝(杭州)信息技术有限公司
Publication of WO2021228239A1 publication Critical patent/WO2021228239A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825—Use of electronic signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification

Definitions

  • the embodiments of this specification relate to the field of information technology, and in particular to methods and systems for generating, transaction, and transaction verification of asset type consistency evidence.
  • the type of assets (such as RMB, US dollars, securities, etc.) used by an entity (such as an institution, company, etc.) to conduct business may be the entity's business secrets, and privacy protection is required to prevent external (such as competitors) from leaking.
  • the leakage of asset types may result in more private information of the entity being obtained. For example, in cross-border remittances or in the supply chain, it is possible to infer the entity's location based on the asset type, and then infer the entity's identity information. In order to prevent privacy leakage, the entity will upload the ciphertext of the asset type to the chain during the transaction.
  • One of the embodiments of this specification provides a method for generating an asset type consistency evidence, wherein the method is executed by a device of a transaction initiator, which includes: generating a reference ciphertext of the target asset type; generating a first private key, wherein, The result of performing the target operation on the first verification ciphertext of the target asset type and the reference ciphertext is the first public key matching the first private key, and the first verification ciphertext is initiated with the transaction
  • the target operation satisfies: the result of the target operation on the reference ciphertext and the verification ciphertext of the same object is the public key matching the private key, and the private key is used to generate the ciphertext of the same object.
  • the secret value is obtained; the first private key is used to generate a first digital signature on a first signed message, wherein the first signed message includes the first verification ciphertext and the reference ciphertext; the second private key is used to obtain A second digital signature generated by a key on a second signed message, wherein the second signed message includes a second verification ciphertext of the target asset type and the reference ciphertext, and the second verification ciphertext is related to the transaction receiving Corresponding to the party, the result of performing the target operation on the second verification ciphertext and the reference ciphertext is a second public key matching the second private key; obtaining the first verification ciphertext, the second public key The second verification ciphertext, the reference ciphertext, the first digital signature, and the evidence of the second digital signature to prove that the first verification ciphertext, the second verification ciphertext and the reference The ciphertext is obtained based on the same asset type.
  • One of the embodiments of this specification provides an asset type consistency evidence generation system, wherein the system is implemented on the device of the transaction initiator and includes: a reference ciphertext generation module for generating a reference ciphertext of the target asset type
  • the first private key generation module is used to generate a first private key, wherein the result of performing a target operation on the first verification ciphertext of the target asset type and the reference ciphertext is a match with the first private key
  • the first public key of the first verification ciphertext corresponds to the transaction initiator, and the target operation satisfies: the result of performing the target operation on the reference ciphertext and the verification ciphertext of the same object matches the private key
  • the private key is obtained from the private value used to generate the ciphertext of the same object
  • the first digital signature module is used to generate a first digital signature on the first signed message using the first private key, wherein,
  • the first signed message includes the first verification ciphertext and the reference ciphertext
  • One of the embodiments of this specification provides a device for generating evidence of asset type consistency, which includes a processor and a storage device.
  • the storage device is used to store instructions.
  • the processor executes the instructions, the implementation is as follows: The method for generating asset type consistency evidence executed by the device of the transaction initiator described in the embodiment.
  • One of the embodiments of this specification provides a method for generating an asset type consistency evidence, wherein the method is executed by a device of a transaction receiver, which includes: receiving a reference ciphertext of a target asset type from the transaction initiator; and generating a second A private key, wherein the result of performing a target operation on the second verification ciphertext of the target asset type and the reference ciphertext is a second public key matching the second private key, and the second verification ciphertext Corresponding to the transaction receiver, the target operation satisfies: the result of performing the target operation on the reference ciphertext and verification ciphertext of the same object is a public key that matches a private key, and the private key is used to generate the same Obtain the private value of the ciphertext of the object; use the second private key to generate a second digital signature on a second signed message, where the second signed message includes the second verification ciphertext and the reference ciphertext; The second verification ciphertext and the second digital signature are sent to the
  • One of the embodiments of this specification provides an asset type consistency evidence generation system, wherein the system is implemented on the device of the transaction receiver, and includes: a reference ciphertext receiving module for receiving target assets from the transaction initiator Type of reference ciphertext; a second private key generation module for generating a second private key, wherein the result of performing a target operation on the second verification ciphertext of the target asset type and the reference ciphertext is the same as the The second public key matched by the second private key, the second verification ciphertext corresponds to the transaction recipient, and the target operation satisfies: the result of the target operation performed on the reference ciphertext and the verification ciphertext of the same object Is a public key that matches the private key, and the private key is derived from the private value of the ciphertext used to generate the same object; the second digital signature module is used to generate a second signature message for the second signature using the second private key Digital signature, wherein the second signature message includes the second verification ciphertext and the reference cipher
  • the first verification ciphertext corresponds to the transaction initiator
  • the first digital signature is generated by using a first private key on a first signed message
  • the first signed message It includes the second verification ciphertext and the reference ciphertext, and the evidence is used to prove that the first verification ciphertext, the second verification ciphertext, and the reference ciphertext are obtained based on the same asset type.
  • One of the embodiments of this specification provides a device for generating evidence of asset type consistency, which includes a processor and a storage device.
  • the storage device is used to store instructions.
  • the processor executes the instructions, the implementation is as follows: The method for generating the asset type consistency evidence executed by the device of the transaction receiver described in the embodiment.
  • One of the embodiments of this specification provides a transaction method, which includes: obtaining the verification ciphertext and reference ciphertext corresponding to both parties to the transaction through the method for generating evidence of consistency of asset type as described in any embodiment of this specification Evidence obtained based on the same asset type; use the private key of the transaction initiator or the transaction receiver to generate a third digital signature on the third signature message, the third message to be signed includes the identification information of the accounts of both parties to the transaction and the evidence; The third signature message and the third digital signature are uploaded to the blockchain network.
  • One of the embodiments of this specification provides a transaction system, which includes: an obtaining module, which is used to obtain the verification secret used to prove that the transaction parties correspond to the asset type consistency evidence generation method as described in any embodiment of this specification.
  • the text and the reference ciphertext are based on the evidence obtained from the same asset type;
  • the third digital signature module is used to generate a third digital signature on the third signature message using the private key of the transaction initiator or the transaction receiver, the third message to be signed Including the identification information of the accounts of both parties to the transaction and the evidence;
  • the upload module is used to upload the third signature message and the third digital signature to the blockchain network.
  • One of the embodiments of this specification provides a transaction device, which includes a processor and a storage device.
  • the storage device is used to store instructions. Trading method.
  • One of the embodiments of this specification provides a transaction verification method, which includes: receiving a third signature message and a third digital signature, where the third signature message includes a reference ciphertext and a first verification ciphertext corresponding to the transaction initiator And the first digital signature, the second verification ciphertext and the second digital signature corresponding to the transaction receiver; verify the third digital signature based on the public key of the transaction initiator or transaction receiver and the third signature message;
  • the third digital signature passes the verification: perform a target operation on the reference ciphertext and the first verification ciphertext to obtain a first public key for verifying the first digital signature, based on the reference ciphertext And the first verification ciphertext to obtain a first signed message for verifying the first digital signature, and verify the first digital signature based on the first public key and the first signed message; and/or , Performing the target operation on the reference ciphertext and the second verification ciphertext to obtain a second public key for verifying the second digital signature, based on the reference cipher
  • One of the embodiments of this specification provides a transaction verification system, which includes: a receiving module for receiving a third signature message and a third digital signature.
  • the third signature message includes a reference ciphertext and a first corresponding to the transaction initiator.
  • the first verification module is used to verify the public key based on the transaction initiator or the transaction receiver and the third signature Message, verifying the third digital signature;
  • a second verification module when the third digital signature is verified: perform target operations on the reference ciphertext and the first verification ciphertext to obtain a verification
  • the first public key of the first digital signature obtains a first signed message for verifying the first digital signature based on the reference ciphertext and the first verification ciphertext, based on the first public key and Verifying the first digital signature by the first signature message; and/or performing the target operation on the reference ciphertext and the second verification cipher
  • One of the embodiments of this specification provides a transaction verification device, which includes a processor and a storage device.
  • the storage device is used to store instructions.
  • the transaction verification method is used to verify the transaction verification method.
  • One of the embodiments of this specification provides a method for generating object consistency evidence, wherein the method is executed by a device of any participant in a transaction, which includes: obtaining a reference ciphertext of a target object; generating a target private key, wherein, The result of performing a target operation on the verification ciphertext of the target object and the reference ciphertext is the target public key matching the target private key, and the target operation satisfies: the reference ciphertext and the verification ciphertext of the same object
  • the result of the target operation is a public key that matches the private key, which is obtained from the private value of the ciphertext used to generate the same object; the target private key is used to generate a target digital signature on the target signed message, where ,
  • the target signature message includes the verification ciphertext and the reference ciphertext; obtaining evidence containing at least the verification ciphertext, the reference ciphertext, and the target digital signature to at least prove the verification ciphertext Obtained based on the
  • One of the embodiments of the present specification provides an object consistency evidence generation system, wherein the system is implemented on the device of any participant in the transaction, and includes: a reference ciphertext obtaining module for obtaining the reference cipher of the target object
  • the private key generation module is used to generate a target private key, wherein the result of the target operation on the verification ciphertext of the target object and the reference ciphertext is the target public key that matches the target private key, so
  • the target operation satisfies: the result of performing the target operation on the reference ciphertext and the verification ciphertext of the same object is a public key matching the private key, and the private key is obtained from the private value used to generate the ciphertext of the same object;
  • a digital signature module for generating a target digital signature on a target signature message using the target private key, wherein the target signature message includes the verification ciphertext and the reference ciphertext;
  • an object consistency evidence obtaining module is used for Obtaining evidence including at least the verification cipher
  • One of the embodiments of this specification provides a device for generating object consistency evidence, which includes a processor and a storage device.
  • the storage device is used to store instructions.
  • the processor executes the instructions, the implementation can be implemented as in any implementation of this specification.
  • Fig. 1 is a schematic diagram of an application scenario of a blockchain system according to some embodiments of this specification
  • Fig. 2 is an exemplary flow chart of a method for generating evidence of consistency of asset types according to an embodiment of the present specification
  • Fig. 3 is an exemplary flowchart of a method for generating evidence of consistency of asset types according to an embodiment of the present specification
  • Fig. 4 is an exemplary flowchart of a transaction method according to some embodiments of the present specification.
  • Fig. 5 is an exemplary flowchart of a transaction verification method according to some embodiments of the present specification.
  • Fig. 6 is an exemplary flowchart of a method for generating object consistency evidence according to some embodiments of the present specification
  • Fig. 7 is an exemplary block diagram of an asset type consistency evidence generating system according to some embodiments of the present specification.
  • Fig. 8 is an exemplary block diagram of an asset type consistency evidence generating system according to some embodiments of the present specification.
  • Fig. 9 is an exemplary block diagram of a transaction system according to some embodiments of the present specification.
  • Fig. 10 is an exemplary block diagram of a transaction verification system according to some embodiments of the present specification.
  • Fig. 11 is an exemplary block diagram of an object consistency evidence generating system according to some embodiments of the present specification.
  • system is a method for distinguishing different components, elements, parts, parts, or assemblies of different levels.
  • the words can be replaced by other expressions.
  • the embodiments in this specification can provide a zero-knowledge proof of the consistency of asset types in an electronic transaction scenario that relies on the blockchain. That is, the transaction initiator can use any useful information (for example, the private value used to generate the ciphertext of the asset type, the identification information of the asset type corresponding to the transaction asset) to the blockchain node as the verifier, so that The blockchain node is sure that the ciphertext of the asset type corresponding to both parties to the transaction (that is, the verification ciphertext in the following text) is obtained based on the same asset type.
  • any useful information for example, the private value used to generate the ciphertext of the asset type, the identification information of the asset type corresponding to the transaction asset
  • the blockchain node is sure that the ciphertext of the asset type corresponding to both parties to the transaction (that is, the verification ciphertext in the following text) is obtained based on the same asset type.
  • Fig. 1 is a schematic diagram of an application scenario of a blockchain system according to some embodiments of this specification.
  • the blockchain system 100 may include a blockchain client 110 (may be referred to as a client for short), a blockchain network 120, and a network 130, where the blockchain network 120 includes more than one blockchain node (Can be referred to as "node” for short), such as blockchain node-1, 120-2, 120-3...120-n, etc.
  • the blockchain client 110 can be connected to the blockchain network 120 through the network 130. Entities can access the blockchain network 120 through the blockchain client 110, and entities that join the blockchain network 120 can also be referred to as blockchain members.
  • the blockchain client 110 can upload information and/or data to one or more blockchain nodes in the blockchain network 120, such as uploading transaction records.
  • the transaction record may include transaction information (may be simply referred to as "transaction" written in the block.
  • the blockchain client 110 may initiate a query to one or more blockchain nodes in the blockchain network 120 to obtain the area stored in the blockchain (i.e., distributed ledger, which is continuously generated). The data in the block chained), such as transactions.
  • the user terminal of the transaction initiator may attach evidence used to prove the consistency of the asset type (that is, the verification ciphertext of both parties to the transaction is obtained based on the same asset type) to the transaction and upload it to the blockchain network 120 , So that the node performs the expected follow-up process after at least passing the verification of the consistency of the asset type, for example, writing the transaction to the block, updating the accounts of both parties to the transaction, and so on.
  • evidence used to prove the consistency of the asset type that is, the verification ciphertext of both parties to the transaction is obtained based on the same asset type
  • the user terminal may include various types of devices with information receiving and/or sending functions.
  • the user terminal may include a smart phone, a tablet computer, a personal computer, a server, etc., or any combination thereof.
  • Each node in the blockchain network 120 needs to verify and confirm the transaction, and then generate a new block (this process can be called "accounting"). At the same time, each node can maintain the data stored in each node through a consensus mechanism. Consistency of distributed ledgers. It is worth noting that the blockchain node can also be regarded as the client terminal of the blockchain network 120. Unlike other client terminals, the blockchain node needs to participate in accounting. In addition, the entity can join the blockchain network 120 through a user terminal that does not participate in accounting, and can also join the blockchain network 120 through a blockchain node that participates in accounting.
  • the node may verify the evidence in the transaction to confirm whether the verification ciphertext corresponding to both parties to the transaction is obtained based on the same asset type. If the verification of the consistency of the asset type is not passed, that is, it is determined that the verification ciphertext corresponding to the transaction parties is not based on the same asset type, the node may refuse to perform the expected follow-up process, for example, write the transaction to the block and update the transaction of both parties. Account and so on. It should be understood that in addition to the verification of the consistency of the asset type, the verification of the transaction may also include other verifications, such as verification of the legality of the amount. In some embodiments, the node may execute the expected subsequent process after passing multiple verifications of the transaction. For more details about transaction verification, please refer to Figure 5 and its related descriptions.
  • nodes may include various types of computing devices, such as servers.
  • the server may be an independent server or a server group, and the server group may be centralized or distributed. In some embodiments, the server may be regional or remote. In some embodiments, the server may be executed on a cloud platform.
  • the cloud platform may include one or any combination of private cloud, public cloud, hybrid cloud, community cloud, decentralized cloud, internal cloud, etc.
  • the network 130 connects the various components of the system so that communication between the various components can be carried out.
  • the network between the various parts in the system may include a wired network and/or a wireless network.
  • the network 130 may include a cable network, a wired network, an optical fiber network, a telecommunication network, an internal network, the Internet, a local area network (LAN), a wide area network (WAN), a wireless local area network (WLAN), a metropolitan area network (MAN), public Switched telephone network (PSTN), Bluetooth network, ZigBee network (ZigBee), near field communication (NFC), device bus, device line, cable connection, etc. or any combination thereof.
  • LAN local area network
  • WAN wide area network
  • WLAN wireless local area network
  • MAN metropolitan area network
  • PSTN public Switched telephone network
  • Bluetooth network ZigBee network
  • ZigBee ZigBee network
  • NFC near field communication
  • the network connection between each two parts can adopt one of the above-mentioned methods, or it can adopt multiple methods. It is understandable that the network 130 and the blockchain network 120 do not have to have a clear boundary. In a more general application scenario, the blockchain node and the ordinary network node can be connected to the same physical network, and the blockchain node is in the logical The above constitutes a blockchain network.
  • Fig. 2 is an exemplary flow chart of a method for generating evidence of consistency of asset types according to some embodiments of the present specification.
  • the process 200 can be executed by the device of the transaction initiator of the transaction, and the device of the transaction initiator can be connected to the blockchain network 120 as a client (blockchain client 110 or blockchain node).
  • the process 200 may include: step 210, generating a reference ciphertext of the target asset type.
  • step 210 can be implemented by the reference ciphertext generation module 710.
  • the user end in the blockchain network 120 may use a public encryption algorithm to generate the verification ciphertext and the reference ciphertext of the asset type.
  • Step 220 Generate a first private key.
  • step 220 may be implemented by the first private key generation module 720.
  • the result of performing the target operation on the first verification ciphertext and the reference ciphertext of the target asset type is the first public key matching the first private key, and the first verification ciphertext corresponds to the transaction initiator.
  • the target operation mentioned in this manual satisfies: the result of the target operation on the reference ciphertext and verification ciphertext of the same object is the public key matching the private key, and the private key is used to generate the ciphertext of the same object. It's worth getting. Based on this, if the private key is used to generate a digital signature, only the matching public key can be used to successfully verify the signature. That is, the target operation limits the public key that can be successfully verified.
  • the premise is: verify ciphertext and reference ciphertext Based on the same object (asset type).
  • the first private key can be obtained from the private value of the first verification ciphertext and/or the reference ciphertext used to generate the target asset type, and only the first public key that matches it can be successfully verified.
  • Step 230 Use the first private key to generate the first digital signature.
  • the private value can refer to the value used by any transaction party (transaction initiator or transaction receiver) to generate the ciphertext of the asset type and not publicly disclosed, because the leakage of the private value will cause the disclosure of the plaintext corresponding to the ciphertext ( That is, the identification information of the asset type) risk.
  • the verification ciphertext and the reference ciphertext are obtained based on the Pedersen commitment protocol.
  • the operations involving elliptic curves in this manual have similar properties to the four arithmetic operations, so the representation methods of the four arithmetic operations (such as addition, subtraction, multiplication, +, -, *) are borrowed, but this does not mean These operations involving elliptic curves can be equivalent to the four arithmetic operations.
  • the user end in the blockchain network 120 may have some common parameters, for example, the parameters of the elliptic curve equation, G, H, and so on. Among them, any one of G and H can be used as a public key generation parameter, and the public key generation parameter may be denoted as G, that is, if the private key is r, then r*G is the public key matching the private key r.
  • the verification ciphertext and the reference ciphertext of any transaction party respectively include a first part corresponding to G and a second part corresponding to H, wherein the first verification secret
  • the first part of the text is obtained based on the first generator and the private value corresponding to the transaction initiator.
  • the first part of the second verification ciphertext is obtained based on the first generator and the private value corresponding to the transaction receiver.
  • the first verification ciphertext, The second verification ciphertext and the second part of the reference ciphertext are equal and are respectively obtained based on the identification information of the second generator and the target asset type.
  • the target operation can be the difference. In this way, only by calculating the difference between the verification ciphertext and the reference ciphertext of the same asset type, so that the second part of the two is offset, can the public key for verification be obtained (the expanded form includes the public key generation parameter G).
  • the target operation can refer to the difference between the verification ciphertext and the reference ciphertext (C_X-C 0 or C 0 -C_X).
  • the first public key can be C_A-C 0 (or C 0 -C_A )
  • the device of the transaction initiator can calculate r_A*Pr_A-r 0 (or r 0 -r_A*Pr_A) to obtain the first private key.
  • Step 230 Use the first private key to generate a first digital signature on the first signed message.
  • the first signature message includes the first verification ciphertext and the reference ciphertext.
  • step 230 may be implemented by the first digital signature module 730.
  • Step 240 Obtain a second digital signature generated by using the second private key on the second signed message.
  • the second signature message includes a second verification ciphertext and a reference ciphertext
  • the second verification ciphertext corresponds to the transaction receiver
  • the result of performing the target operation on the second verification ciphertext and the reference ciphertext is the same as the second private
  • step 240 may be implemented by the second digital signature obtaining module 740.
  • Step 250 Obtain evidence including the first verification ciphertext, the second verification ciphertext, the reference ciphertext, the first digital signature, and the second digital signature to prove the first verification ciphertext, the second verification ciphertext, and the reference ciphertext Obtained based on the same asset type.
  • step 250 may be implemented by the asset type consistency evidence obtaining module 750.
  • first verification ciphertext can be used to update the account of the transaction initiator
  • second verification ciphertext can be used to update the account of the transaction receiver
  • the first digital signature and the reference ciphertext and the first verification ciphertext are related to each other.
  • the first digital signature is verified, it can be proved that the associated first verification ciphertext and the reference ciphertext have not been tampered with and both are based on the same asset type get.
  • the second digital signature and the reference ciphertext and the second verification ciphertext are related to each other.
  • the second digital signature is verified, it can be proved that the associated second verification ciphertext and the reference ciphertext have not been tampered with and both are based on Get the same asset type.
  • the evidence containing the first verification ciphertext, the second verification ciphertext, the reference ciphertext, the first digital signature, and the second digital signature (hereinafter referred to as the asset type consistency evidence) can prove that the first verification ciphertext, the second verification ciphertext, and the second The verification ciphertext and the reference ciphertext are obtained based on the same asset type.
  • the first digital signature and the second digital signature pass the verification (that is, the asset type consistency evidence is verified)
  • it can be confirmed that the first verification ciphertext, the second verification ciphertext, and the reference ciphertext are obtained based on the same asset type.
  • the device of the transaction initiator can attach the proof of asset type consistency to the transaction and upload the transaction to the blockchain network 120 to prove that the first verification ciphertext and the second verification ciphertext are based on Get the same asset type.
  • the device of the transaction initiator may generate the second verification ciphertext of the transaction receiver.
  • the device of the transaction initiator may send the second verification ciphertext and the private value used to generate the second verification ciphertext to the device of the transaction receiver.
  • the device of the transaction initiator may also generate a second digital signature based on the generated second verification ciphertext and the reference ciphertext to prove that the second verification ciphertext and the reference ciphertext are obtained based on the same asset type.
  • the device of the transaction initiator may send the reference ciphertext to the device of the transaction receiver, so that the device of the transaction receiver can generate a certificate for proving that the second verification ciphertext and the reference ciphertext are based on the same asset type.
  • the second digital signature may be used to verify that the second verification ciphertext and the reference ciphertext are based on the same asset type.
  • the device of the transaction receiver may refuse to perform the subsequent process, for example, no longer generate the second private key.
  • the leakage of the third random number may lead to the leakage of the target asset type.
  • the attacker knows the third random number (especially when he also knows the asset type list containing the target asset type)
  • he can try to combine multiple
  • the identification information of the asset type is respectively substituted into the calculation formula of the reference ciphertext. If a calculated result is found to be consistent with the publicly available reference ciphertext, the asset type corresponding to the result can be determined, that is, the target asset type.
  • the device of the transaction initiator can encrypt the third random number and transmit it to the device of the transaction receiver.
  • the device of the transaction initiator can use the public key of the transaction receiver to encrypt the message containing the third random number, and send the encrypted message to the device of the transaction receiver, so that the device of the transaction receiver can use the transaction initiator
  • the private key decrypts the third random number.
  • the device of the transaction initiator may encrypt and transmit the identification information of the target asset type to the device of the transaction recipient.
  • the device of the transaction receiver can filter out the target asset type by encrypting the identification information of one or more asset types, it is clear that it is a more direct and effective way for the transaction initiator to inform the transaction receiver of the target asset type's identification information.
  • the device of the transaction initiator can send a message sequence (C 0 , r 0 , sn; C_A, P_A) to the device of the transaction receiver, where C 0 represents the reference ciphertext, r 0 represents the third random number, sn represents the identification information of the target asset type, C_A represents the first verification cipher text, and P_A represents the first digital signature.
  • C 0 represents the reference ciphertext
  • r 0 represents the third random number
  • sn represents the identification information of the target asset type
  • C_A represents the first verification cipher text
  • P_A represents the first digital signature.
  • at least r 0 and sn can be encrypted to prevent the leakage of the target asset type.
  • the message sequence can be encrypted using the public key of the transaction receiver, and the encrypted message sequence can be sent to the transaction receiver’s equipment.
  • Fig. 3 is an exemplary flow chart of a method for generating an asset type consistency evidence according to some embodiments of the present specification.
  • the process 300 can be executed by the device of the transaction receiver, and the device of the transaction receiver can be connected to the blockchain network 120 as a client (blockchain client 110 or blockchain node). As shown in FIG. 3, the process 300 may include:
  • Step 310 Receive a reference ciphertext of the target asset type from the transaction initiator.
  • step 310 may be implemented by the reference ciphertext receiving module 810.
  • Step 320 Generate a second private key.
  • step 320 may be implemented by the second private key generation module 820.
  • the result of performing the target operation on the second verification ciphertext and the reference ciphertext of the target asset type is a second public key matching the second private key, and the second verification ciphertext corresponds to the transaction receiver.
  • the target calculation please refer to the related description in the process 200.
  • the second public key can be C_B-C 0 (or C 0 -C_B)
  • the device of the transaction receiver can calculate r_B*Pr_B-r 0 (or r 0 -r_B*Pr_B) to obtain the second private key.
  • r_B represents the second random number (considered as the private value of the transaction receiver)
  • Step 330 Use the second private key to generate a second digital signature on the second signed message.
  • the second signature message includes the second verification ciphertext and the reference ciphertext.
  • step 330 may be implemented by the second digital signature module 830.
  • the second digital signature passes the verification, it can be proved that the associated second verification ciphertext and the reference ciphertext have not been tampered with and they are obtained based on the same asset type.
  • Step 340 Send the second verification ciphertext and the second digital signature to the device of the transaction initiator, so that the device of the transaction initiator obtains the asset type consistency evidence.
  • step 340 may be implemented by the sending module 840.
  • the device of the transaction recipient may receive a message sequence (C 0 , r 0 , sn; C_A, P_A) from the transaction initiator, where C 0 represents the reference ciphertext, and r 0 represents the reference
  • C 0 represents the reference ciphertext
  • r 0 represents the reference
  • sn represents the identification information of the target asset type
  • C_A represents the first verification cipher text
  • P_A the first digital signature.
  • the device of the transaction recipient may also receive the first verification ciphertext and the first digital signature from the transaction initiator to obtain proof of asset type consistency.
  • Fig. 4 is an exemplary flowchart of a transaction method according to some embodiments of the present specification.
  • the process 400 may be executed by the device of the transaction initiator or the transaction receiver in the process 200 (or the process 300). It should be understood that when the process 400 is executed by the device of the transaction receiver in the process 200 (or the process 300), the transaction receiver in the process 200 (or the process 300) is the party that re-initiates the transaction for the target asset type.
  • the process 400 may include: Step 410: Obtain asset type consistency evidence that is used to prove that the verification ciphertext and the reference ciphertext corresponding to both parties to the transaction are based on the same asset type.
  • step 410 may be implemented by the obtaining module 910.
  • Step 420 Use the private key of the transaction initiator or the transaction receiver to generate a third digital signature on the third signature message.
  • the third message to be signed includes identification information of the accounts of both parties to the transaction and proof of asset type consistency.
  • step 420 may be implemented by the third digital signature module 920.
  • Step 430 upload the third signature message and the third digital signature to the blockchain network 120.
  • step 430 can be implemented by the upload module 930.
  • the third signed message may include more content.
  • the third signature message may also include the transaction amount (in encrypted form), proof of legality of the amount, etc., where the legality of the amount of money is used to prove the legality of the value of the amount.
  • Circumstances that will cause abnormal transactions are not allowed (ie illegal), such as the following situations: 1. The account balance of the transaction initiator is less than the transaction amount, and the account of the transaction initiator does not have the ability to pay at this time; 2. The value of the transaction amount is negative, which will cause the increase or decrease of the account amount to be contrary to the expected, that is, the account amount does not increase but decreases or does not decrease but increases.
  • various encryption algorithms that support zero-knowledge proofs can be used to encrypt the transaction amount, for example, encryption algorithms based on the Pedersen commitment protocol, hash algorithm encryption, homomorphic encryption algorithms, and so on.
  • the zero-knowledge proof technology "ring signature confidential transaction” and “Bulletproof” can be used to generate proof of the legality of the amount.
  • the zero-knowledge proof technology "zksnark” can be used to generate proof of the legality of the amount.
  • Fig. 5 is an exemplary flowchart of a transaction verification method according to some embodiments of the present specification.
  • the process 500 may be executed by a blockchain node. As shown in FIG. 5, the process 500 may include:
  • Step 510 Receive a third signature message and a third digital signature.
  • the third signature message includes a reference ciphertext, a first verification ciphertext and a first digital signature corresponding to the transaction initiator, and a second verification corresponding to the transaction receiver.
  • the ciphertext and the second digital signature may be implemented by the receiving module 1010.
  • Step 520 Verify the third digital signature based on the public key of the transaction initiator or the transaction receiver and the third signature message.
  • step 520 may be implemented by the first verification module 1020.
  • the signer is the transaction party (transaction initiator or transaction receiver in the process 200/300); 2. Whether the third signature message has been tampered with.
  • the blockchain node can continue to perform step 530.
  • the blockchain node may refuse to perform the subsequent process (such as step 530), that is, consider that the transaction verification fails.
  • Step 530 verify the first digital signature based on the first public key and the first signed message; and/or verify the second digital signature based on the second public key and the second signed message.
  • step 530 may be implemented by the second verification module 1030.
  • the second verification module 1030 can perform target operations on the reference ciphertext and the first verification ciphertext to obtain the first public key used to verify the first digital signature, and can be used based on the reference ciphertext and the first verification ciphertext. To verify the first signed message of the first digital signature. Similarly, the second verification module 1030 can perform target operations on the reference ciphertext and the second verification ciphertext to obtain the second public key used to verify the second digital signature, and can obtain the reference ciphertext and the second verification ciphertext based on the target operation. A second signed message used to verify the second digital signature.
  • step 540 If the first digital signature and the second digital signature are verified, the blockchain node may perform step 540. If the first digital signature or the second signature message fails the verification, the blockchain node may perform step 550. In some embodiments, step 540 and step 550 may be implemented by the determining module 1040.
  • step 530 is not limited.
  • any one of the first digital signature and the second digital signature can be verified by default. If the first digital signature fails the verification, the first digital signature is not verified any more. The other of the signature and the second digital signature.
  • Step 540 Determine that the first verification ciphertext, the second verification ciphertext, and the reference ciphertext are obtained based on the same asset type.
  • Step 550 Determine that the first verification ciphertext, the second verification ciphertext, and the reference ciphertext are not obtained based on the same asset type and refuse to execute the subsequent process.
  • the verification ciphertext and the reference ciphertext corresponding to both parties of the transaction are obtained based on the same asset type, that is, the first verification ciphertext and the second verification
  • the ciphertext is obtained based on the same asset type. Otherwise, it means that the first verification ciphertext and the second verification ciphertext are not obtained based on the same asset type.
  • the prerequisite for passing the transaction verification is that both the first digital signature and the second digital signature (and of course, the third digital signature) pass the verification.
  • the expected follow-up process can be continued. For example, a transaction including a third signature message and a third digital signature can be written into the block.
  • the accounts of both parties to the transaction will be updated based on the verification ciphertext corresponding to both parties to the transaction.
  • the transaction amount E(t) can be determined from the third signature message, and then the account of the transaction initiator is compared with the first verification ciphertext. The corresponding balance is reduced by E(t) and the balance corresponding to the second verification ciphertext in the account of the transaction initiator is increased by E(t). Otherwise, you can refuse to perform the expected follow-up process.
  • the third signature message may also include proof of legality of the amount of money. Accordingly, the blockchain node can also verify the proof of legality of the amount of money after verifying the third digital signature. It should be understood that the verification order of the amount legality evidence and the first digital signature/second digital signature is optional. When any one of the amount legality evidence, the first digital signature and the second digital signature fails the verification, Blockchain nodes can refuse to execute subsequent processes.
  • the blockchain node can record the identification information of the transaction initiator, the identification information of the transaction receiver, the first verification ciphertext and the second verification ciphertext in association with each other. In this way, when any transaction party in the verified historical transaction initiates a transaction for the target asset type again, the first verification ciphertext and the second verification ciphertext can be provided to the blockchain node.
  • the blockchain node After the blockchain node confirms that the identities of the transaction initiator and the transaction receiver are correct, it searches locally whether it contains the identification information of the transaction initiator, the identification information of the transaction receiver, the first verification ciphertext and the second verification ciphertext. Associate records. If there are associated records, it means that the consistency of the first verification ciphertext and the second verification ciphertext has been successfully verified in the historical transaction, and the blockchain node can save the first digital signature and the second digital signature when verifying the transaction. The verification of the signature, of course, the party who initiates the transaction again does not need to provide the first digital signature and the second digital signature to the blockchain node.
  • the associated record kept by the blockchain node may include more content.
  • a blockchain node can store a message sequence (A, B; C 0 , C_A, C_B; P_A, P_B), where A represents the identification information of the transaction initiator, C_A represents the first verification ciphertext, and P_B represents the first Digital signature, B represents the identification information of the transaction recipient, C_B represents the second verification cipher text, P_B represents the second digital signature, and C 0 represents the reference cipher text.
  • the blockchain node may generate a corresponding ID for the saved association record, and feed the ID back to the transaction party.
  • the device of the party initiating the new transaction can provide the ID to the blockchain node, and the blockchain node searches for the recorded verification ciphertext of both parties based on the received ID. , And update the accounts of both parties to the transaction based on the found verification ciphertext.
  • one or more steps in this specification can also be implemented by calling smart contracts. Because the smart contract has the characteristics of mandatory execution, non-tampering, and traceability, it can ensure that the corresponding steps are executed as expected and leave traceable evidence.
  • the multi-party transaction here can refer to the transaction with the following characteristics: 1. It requires more than two participants to participate in the transaction; 2. Each participant needs to participate in the transaction for the same object (referred to as the target object); 3. For any participant, It is necessary to publicly record transaction information related to the target object based on the ciphertext of the object corresponding to the participant to prevent privacy leakage.
  • the multi-party transaction here may include the exchange of the same type of data, the collaborative update of the same type of data, and so on.
  • Fig. 6 is an exemplary flowchart of a method for generating object consistency evidence according to some embodiments of the present specification.
  • the process 600 can be executed by the device of any participant of a multiparty transaction (hereinafter referred to as participant X).
  • participant X may refer to the transaction initiator or the transaction receiver.
  • the process 600 may include:
  • Step 610 Obtain the reference ciphertext of the target object.
  • step 610 may be implemented by the reference ciphertext obtaining module 1110.
  • Step 620 Generate a target private key.
  • step 620 may be implemented by the private key generation module 1120.
  • the result of the target operation on the verification ciphertext and the reference ciphertext of the target object is the target public key matching the target private key, and the target operation satisfies: the result of the target operation on the reference ciphertext and the verification ciphertext of the same object It is a public key that matches the private key, and the private key is derived from the private value used to generate the ciphertext of the same object.
  • the verification ciphertext (which can be marked as C_X) corresponds to the participant X and can be used to publicly record the transaction information related to the target object corresponding to the participant X.
  • Step 630 Use the target private key to generate a target digital signature on the target signature message, the target signature message including the verification ciphertext (C_X) and the reference ciphertext.
  • step 630 may be implemented by the digital signature module 1130.
  • Step 640 Obtain evidence including at least the verification ciphertext (C_X), the reference ciphertext, and the target digital signature, so as to at least prove that the verification ciphertext (C_X) and the reference ciphertext are obtained based on the same object.
  • step 640 may be implemented by the object consistency evidence obtaining module 1140.
  • the target digital signature corresponding to any participant can be used to prove that the verification ciphertext and the reference ciphertext corresponding to the participant are based on the same object. Therefore, it can be used to prove that the verification ciphertext and reference ciphertext corresponding to each participant are based on the same object.
  • the evidence (hereinafter referred to as the object consistency evidence) includes: reference ciphertext, verification ciphertext corresponding to each participant, and each participant The corresponding target digital signature.
  • Any participant can send a message containing object consistency evidence to the verifier's device, so that the verifier's device can confirm whether the verification ciphertext corresponding to each participant is based on the same object through the verification object consistency evidence. If the device of the verifier confirms that the verification ciphertext corresponding to each participant is obtained based on the same object, the transaction information related to the target object corresponding to each participant may be recorded based on the verification ciphertext corresponding to each participant.
  • the process 600 reference may be made to the process 200, the process 300 and related descriptions thereof.
  • the target private key please refer to the description of the first/second private key (public key).
  • the target signature message and the target digital signature please refer to the description of the first/second signature message and the first/second digital signature.
  • the object consistency evidence please refer to the related description of the asset type consistency evidence.
  • Fig. 7 is an exemplary block diagram of an asset type consistency evidence generating system according to some embodiments of the present specification.
  • the system 700 may be implemented on the device of the transaction initiator. As shown in FIG. 7, the system 700 may include a reference ciphertext generating module 710, a first private key generating module 720, a first digital signature module 730, a second digital signature obtaining module 740, and an asset type consistency evidence obtaining module 750.
  • the reference ciphertext generating module 710 may be used to generate a reference ciphertext of the target asset type.
  • the first private key generation module 720 may be used to generate the first private key.
  • the first digital signature module 730 may be configured to use the first private key to generate a first digital signature on the first signed message.
  • the second digital signature obtaining module 740 may be used to obtain the second digital signature generated by using the second private key on the second signed message.
  • the asset type consistency evidence obtaining module 750 can be used to obtain evidence including the first verification ciphertext, the second verification ciphertext, the reference ciphertext, the first digital signature, and the second digital signature to prove that the first verification ciphertext, the second verification ciphertext, and the second digital signature are included.
  • the verification ciphertext and the reference ciphertext are obtained based on the same asset type.
  • Fig. 8 is an exemplary block diagram of an asset type consistency evidence generating system according to some embodiments of the present specification.
  • the system 800 may be implemented on the device of the transaction recipient. As shown in FIG. 8, the system 800 may include a reference ciphertext receiving module 810, a second private key generating module 820, a second digital signature module 830, and a sending module 840.
  • the reference ciphertext receiving module 810 can be used to receive the reference ciphertext of the target asset type from the transaction initiator.
  • the second private key generation module 820 can be used to generate a second private key.
  • the second digital signature module 830 may be used to generate a second digital signature on the second signed message using the second private key.
  • the sending module 840 may be used to send the second verification ciphertext and the second digital signature to the device of the transaction initiator, so that the device of the transaction initiator obtains the asset type consistency evidence.
  • Fig. 9 is an exemplary block diagram of a transaction system according to some embodiments of the present specification.
  • the system 900 can be implemented on the device of the transaction initiator or the transaction receiver in the process 200 (or the process 300). As shown in FIG. 9, the system 900 may include an obtaining module 910, a third digital signature module 920, and an uploading module 930.
  • the obtaining module 910 can be used to obtain the asset type consistency evidence that is used to prove that the verification ciphertext and the reference ciphertext corresponding to both parties to the transaction are based on the same asset type.
  • the third digital signature module 920 may be used to generate a third digital signature on the third signature message using the private key of the transaction initiator or the transaction receiver.
  • the upload module 930 can be used to upload the third signature message and the third digital signature to the blockchain network 120.
  • Fig. 10 is an exemplary block diagram of a transaction verification system according to some embodiments of the present specification.
  • the system 1000 can be implemented on a blockchain node.
  • the system 1000 may include a receiving module 1010, a first verification module 1020, a second verification module 1030, and a determination module 1040.
  • the receiving module 1010 can be used to receive a third signature message and a third digital signature.
  • the third signature message includes a reference ciphertext, a first verification ciphertext corresponding to the transaction initiator, and a first digital signature, and a first digital signature corresponding to the transaction receiver. 2. Verify the ciphertext and the second digital signature.
  • the first verification module 1020 may be used to verify the third digital signature based on the public key of the transaction initiator or the transaction receiver and the third signature message.
  • the second verification module 1030 may be used to verify the first digital signature based on the first public key and the first signed message when the third digital signature is verified; and/or verify the second digital based on the second public key and the second signed message sign.
  • the determining module 1040 can be used to: if the first digital signature and the second digital signature pass the verification, determine that the first verification ciphertext, the second verification ciphertext and the reference ciphertext are obtained based on the same asset type; if the first digital signature or the second digital signature If the digital signature fails the verification, it is determined that the first verification ciphertext, the second verification ciphertext, and the reference ciphertext are not obtained based on the same asset type and the subsequent process is rejected.
  • Fig. 11 is an exemplary block diagram of an object consistency evidence generating system according to some embodiments of the present specification.
  • the system 1100 can be implemented on the device of any participant (hereinafter referred to as participant X) of a multi-party transaction.
  • the system 1100 may include a reference ciphertext obtaining module 1110, a private key generating module 1120, a digital signature module 1130, and an object consistency evidence obtaining module 1140.
  • the reference ciphertext obtaining module 1110 can be used to obtain the reference ciphertext of the target object.
  • the private key generation module 1120 can be used to generate the target private key.
  • the digital signature module 1130 can be used to use the target private key to generate a target digital signature on a target signed message, the target signed message including a verification ciphertext (C_X) and a reference ciphertext.
  • C_X verification ciphertext
  • the object consistency evidence obtaining module 1140 can be used to obtain evidence containing at least the verification ciphertext (C_X), the reference ciphertext, and the target digital signature, so as to at least prove that the verification ciphertext and the reference ciphertext are obtained based on the same object.
  • the systems and modules shown in FIGS. 7-11 can be implemented in various ways.
  • the system and its modules can be implemented by hardware, software, or a combination of software and hardware.
  • the hardware part can be implemented using dedicated logic;
  • the software part can be stored in a memory and executed by an appropriate instruction execution system, such as a microprocessor or dedicated design hardware.
  • an appropriate instruction execution system such as a microprocessor or dedicated design hardware.
  • the above-mentioned methods and systems can be implemented using computer-executable instructions and/or included in processor control codes, for example on a carrier medium such as a disk, CD or DVD-ROM, such as a read-only memory (firmware)
  • Such codes are provided on a programmable memory or a data carrier such as an optical or electronic signal carrier.
  • the system and its modules in this specification can not only be implemented by hardware circuits such as very large-scale integrated circuits or gate arrays, semiconductors such as logic chips, transistors, etc., or programmable hardware devices such as field programmable gate arrays, programmable logic devices, etc. It can also be implemented by, for example, software executed by various types of processors, or can be implemented by a combination of the foregoing hardware circuit and software (for example, firmware).
  • the above description of the system and its modules is only for convenience of description, and does not limit this specification within the scope of the examples mentioned. It can be understood that for those skilled in the art, after understanding the principle of the system, it is possible to arbitrarily combine various modules, or form a subsystem to connect with other modules without departing from this principle.
  • the second verification module 1030 and the determination module 1040 disclosed in FIG. 10 may be different modules in a system, or one module may implement the functions of the two modules. Such deformations are all within the protection scope of this specification.
  • the possible beneficial effects of the embodiments of this specification include, but are not limited to: (1) Under the premise of protecting the privacy value of the transaction party for generating the verification ciphertext, a publicly and zero-knowledgeable ciphertext is designed by introducing the reference ciphertext. Locally verify whether the verification ciphertexts corresponding to the transaction parties are based on the same asset type; (2) After completing a verification of the consistency of the asset type, record the relevant information of this verification to avoid repeated verification; (3) Pass The smart contract implements one or more steps to ensure that the corresponding steps are executed as expected and leave traceable evidence. It should be noted that different embodiments may have different beneficial effects. In different embodiments, the possible beneficial effects may be any one or a combination of the above, or any other beneficial effects that may be obtained.
  • the computer storage medium may contain a propagated data signal containing a computer program code, for example on a baseband or as part of a carrier wave.
  • the propagated signal may have multiple manifestations, including electromagnetic forms, optical forms, etc., or a suitable combination.
  • the computer storage medium may be any computer-readable medium other than the computer-readable storage medium, and the medium may be connected to an instruction execution system, device, or device to realize communication, dissemination, or transmission of the program for use.
  • the program code located on the computer storage medium can be transmitted through any suitable medium, including radio, cable, fiber optic cable, RF, or similar medium, or any combination of the above medium.
  • the computer program codes required for the operations of the various parts of the embodiments of this specification can be written in any one or more programming languages, including object-oriented programming languages such as Java, Scala, Smalltalk, Eiffel, JADE, Emerald, C++, C#, VB.NET, Python, etc., conventional programming languages such as C language, VisualBasic, Fortran2003, Perl, COBOL2002, PHP, ABAP, dynamic programming languages such as Python, Ruby and Groovy, or other programming languages, etc.
  • the program code can run entirely on the user's computer, or as an independent software package on the user's computer, or partly on the user's computer and partly on a remote computer, or entirely on the remote computer or processing equipment.
  • the remote computer can be connected to the user's computer through any network form, such as a local area network (LAN) or a wide area network (WAN), or connected to an external computer (for example, via the Internet), or in a cloud computing environment, or as a service Use software as a service (SaaS).
  • LAN local area network
  • WAN wide area network
  • SaaS service Use software as a service

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Computer Security & Cryptography (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

一种资产类型一致性证据生成、交易、交易验证方法及***。交易发起方的设备生成目标资产类型的参考密文（210），使用第一私钥对包含参考密文以及交易发起方的第一验证密文的消息生成第一数字签名（230），获得使用第二私钥对包含参考密文以及交易接收方的第二验证密文的消息生成的第二数字签名（240），获得包含第一验证密文、第二验证密文、参考密文、第一数字签名和第二数字签名的资产类型一致性证据（250）。该资产类型一致性证据可用于证明第一验证密文、第二验证密文与参考密文基于同一资产类型得到。基于此，能在保护交易方的隐私的前提下，提供可公开验证交易双方对应的验证密文是否基于同一资产类型得到的零知识证明。

Description

资产类型一致性证据生成、交易、交易验证方法及*** 技术领域
本说明书实施例涉及信息技术领域，特别涉及资产类型一致性证据生成、交易、交易验证方法及***。
背景技术
实体(如，机构、公司等)开展业务使用的资产类型(如，人民币、美元、证券等)，可能是该实体的商业机密，需要针对其做隐私保护，避免对外(如竞争对手)泄露。另外，资产类型的泄露可能导致该实体的更多私密信息被获取。比如，在跨境汇款或者在供应链中，通过资产类型有可能推断出实体所在的地区，进而推断出该实体的身份信息。为了防止隐私泄露，实体在交易过程中会将资产类型的密文上链。出于更严格的隐私保护要求，即便实体采用公共的加密算法加密同一资产类型的标识信息，也会因各实体使用不同的私密值(如，随机数)来生成该资产类型的密文，使得各实体针对同一资产类型的密文有所不同。
有鉴于此，希望在保护数据隐私的前提下提供一种能够公开验证交易双方的资产类型密文是否基于同一资产类型生成的方案，以确保交易双方针对同一资产类型进行交易。
发明内容
本说明书实施例之一提供一种资产类型一致性证据生成方法，其中，所述方法由交易发起方的设备执行，其包括：生成目标资产类型的参考密文；生成第一私钥，其中，对所述目标资产类型的第一验证密文和所述参考密文进行目标运算的结果为与所述第一私钥匹配的第一公钥，所述第一验证密文与所述交易发起方对应，所述目标运算满足：对同一对象的参考密文和验证密文进行所述目标运算的结果为与私钥匹配的公钥，该私钥由用于生成该同一对象的密文的私密值得到；使用所述第一私钥对第一签名消息生成第一数字签名，其中，所述第一签名消息包括所述第一验证密文和所述参考密文；获得使用第二私钥对第二签名消息生成的第二数字签名，其中，所述第二签名消息包括所述目标资产类型的第二验证密文和所述参考密文，所述第二验证密文与交易接收方对应，对所述第二验证密文和所述参考密文进行所述目标运算的结果为与所述第二私钥匹配的第二公钥；获得包含所述第一验证密文、所述第二验证密文、所述参考密文、所述第一数字签名和所述第二数字签名的证据，以证明所述第一验证密文、所述第二验证密文与所述参考密文基于同一资产类型得到。
本说明书实施例之一提供一种资产类型一致性证据生成***，其中，所述***在交易发起方的设备上实现，其包括：参考密文生成模块，用于生成目标资产类型的参考密文；第一私钥生成模块，用于生成第一私钥，其中，对所述目标资产类型的第一验证密文和所述参考密文进行目标运算的结果为与所述第一私钥匹配的第一公钥，所述第一验证密文与所述交易发起方对应，所述目标运算满足：对同一对象的参考密文和验证密文进行所述目标运算的结果为与私钥匹配的公钥，该私钥由用于生成该同一对象的密文的私密值得到；第一数字签名模块，用于使用所述第一私钥对第一签名消息生成第一数字签名，其中，所述第一签名消息包括所述第一验证密文和所述参考密文；第二数字签名 获得模块，用于获得使用第二私钥对第二签名消息生成的第二数字签名，其中，所述第二签名消息包括所述目标资产类型的第二验证密文和所述参考密文，所述第二验证密文与交易接收方对应，对所述第二验证密文和所述参考密文进行所述目标运算的结果为与所述第二私钥匹配的第二公钥；资产类型一致性证据获得模块，用于获得包含所述第一验证密文、所述第二验证密文、所述参考密文、所述第一数字签名和所述第二数字签名的证据，以证明所述第一验证密文、所述第二验证密文与所述参考密文基于同一资产类型得到。
本说明书实施例之一提供一种资产类型一致性证据生成装置，其中，包括处理器和存储设备，所述存储设备用于存储指令，当所述处理器执行指令时，实现如本说明书任一实施例所述的由交易发起方的设备执行的资产类型一致性证据生成方法。
本说明书实施例之一提供一种资产类型一致性证据生成方法，其中，所述方法由交易接收方的设备执行，其包括：接收来自交易发起方的目标资产类型的参考密文；生成第二私钥，其中，对所述目标资产类型的第二验证密文和所述参考密文进行目标运算的结果为与所述第二私钥匹配的第二公钥，所述第二验证密文与所述交易接收方对应，所述目标运算满足：对同一对象的参考密文和验证密文进行所述目标运算的结果为与私钥匹配的公钥，该私钥由用于生成该同一对象的密文的私密值得到；使用所述第二私钥对第二签名消息生成第二数字签名，其中，所述第二签名消息包括所述第二验证密文和所述参考密文；将所述第二验证密文和所述第二数字签名发送给所述交易发起方的设备，以使所述交易发起方的设备获得包含所述目标资产类型的第一验证密文、所述第二验证密文、所述参考密文、第一数字签名和所述第二数字签名的证据，其中，所述第一验证密文与所述交易发起方对应，所述第一数字签名是使用第一私钥对第一签名消息生成的，所述第一签名消息包括所述第二验证密文和所述参考密文，所述证据用于证明所述第一验证密文、所述第二验证密文与所述参考密文基于同一资产类型得到。
本说明书实施例之一提供一种资产类型一致性证据生成***，其中，所述***在交易接收方的设备上实现，其包括：参考密文接收模块，用于接收来自交易发起方的目标资产类型的参考密文；第二私钥生成模块，用于生成第二私钥，其中，对所述目标资产类型的第二验证密文和所述参考密文进行目标运算的结果为与所述第二私钥匹配的第二公钥，所述第二验证密文与所述交易接收方对应，所述目标运算满足：对同一对象的参考密文和验证密文进行所述目标运算的结果为与私钥匹配的公钥，该私钥由用于生成该同一对象的密文的私密值得到；第二数字签名模块，用于使用所述第二私钥对第二签名消息生成第二数字签名，其中，所述第二签名消息包括所述第二验证密文和所述参考密文；发送模块，用于将所述第二验证密文和所述第二数字签名发送给所述交易发起方的设备，以使所述交易发起方的设备获得包含所述目标资产类型的第一验证密文、所述第二验证密文、所述参考密文、第一数字签名和所述第二数字签名的证据，其中，所述第一验证密文与所述交易发起方对应，所述第一数字签名是使用第一私钥对第一签名消息生成的，所述第一签名消息包括所述第二验证密文和所述参考密文，所述证据用于证明所述第一验证密文、所述第二验证密文与所述参考密文基于同一资产类型得到。
本说明书实施例之一提供一种资产类型一致性证据生成装置，其中，包括处理器和存储设备，所述存储设备用于存储指令，当所述处理器执行指令时，实现如本说明书任一实施例所述的由交易接收方的设备执行的资产类型一致性证据生成方法。
本说明书实施例之一提供一种交易方法，其中，包括：通过如本说明书任一实施例所述的资产类型一致性证据生成方法，获得用于证明交易双方对应的验证密文与参考密文基于同一资产类型得到的证据；利用交易发起方或交易接收方的私钥对第三签名消息生成第三数字签名，所述第三待签名消息包括交易双方账户的标识信息和所述证据；将所述第三签名消息和所述第三数字签名上传至区块链网络。
本说明书实施例之一提供一种交易***，其中，包括：获得模块，用于通过如本说明书任一实施例所述的资产类型一致性证据生成方法，获得用于证明交易双方对应的验证密文与参考密文基于同一资产类型得到的证据；第三数字签名模块，用于利用交易发起方或交易接收方的私钥对第三签名消息生成第三数字签名，所述第三待签名消息包括交易双方账户的标识信息和所述证据；上传模块，用于将所述第三签名消息和所述第三数字签名上传至区块链网络。
本说明书实施例之一提供一种交易装置，其中，包括处理器和存储设备，所述存储设备用于存储指令，当所述处理器执行指令时，实现如本说明书任一实施例所述的交易方法。
本说明书实施例之一提供一种交易验证方法，其中，包括：接收第三签名消息和第三数字签名，所述第三签名消息包括参考密文、与交易发起方对应的第一验证密文及第一数字签名、与交易接收方对应的第二验证密文及第二数字签名；基于交易发起方或交易接收方的公钥和所述第三签名消息，验证所述第三数字签名；当所述第三数字签名通过验证时：将所述参考密文和所述第一验证密文进行目标运算，得到用于验证所述第一数字签名的第一公钥，基于所述参考密文和所述第一验证密文得到用于验证所述第一数字签名的第一签名消息，基于所述第一公钥和所述第一签名消息验证所述第一数字签名；和/或，将所述参考密文和所述第二验证密文进行所述目标运算，得到用于验证所述第二数字签名的第二公钥，基于所述参考密文和所述第二验证密文得到用于验证所述第二数字签名的第二签名消息，基于所述第二公钥和所述第二签名消息验证所述第二数字签名；若所述第一数字签名和所述第二数字签名通过验证，则确定所述第一验证密文、所述第二验证密文与所述参考密文基于同一资产类型得到。
本说明书实施例之一提供交易验证***，其中，包括：接收模块，用于接收第三签名消息和第三数字签名，所述第三签名消息包括参考密文、与交易发起方对应的第一验证密文及第一数字签名、与交易接收方对应的第二验证密文及第二数字签名；第一验证模块，用于基于交易发起方或交易接收方的公钥和所述第三签名消息，验证所述第三数字签名；第二验证模块，用于当所述第三数字签名通过验证时：将所述参考密文和所述第一验证密文进行目标运算，得到用于验证所述第一数字签名的第一公钥，基于所述参考密文和所述第一验证密文得到用于验证所述第一数字签名的第一签名消息，基于所述第一公钥和所述第一签名消息验证所述第一数字签名；和/或，将所述参考密文和所述第二验证密文进行所述目标运算，得到用于验证所述第二数字签名的第二公钥，基于所述参考密文和所述第二验证密文得到用于验证所述第二数字签名的第二签名消息，基于所述第二公钥和所述第二签名消息验证所述第二数字签名；确定模块，用于：若所述第一数字签名和所述第二数字签名通过验证，则确定所述第一验证密文、所述第二验证密文与所述参考密文基于同一资产类型得到。
本说明书实施例之一提供一种交易验证装置，其中，包括处理器和存储设备，所述 存储设备用于存储指令，当所述处理器执行指令时，实现如本说明书任一实施例所述的交易验证方法。
本说明书实施例之一提供一种对象一致性证据生成方法，其中，所述方法由事务的任一参与方的设备执行，其包括：获得目标对象的参考密文；生成目标私钥，其中，对所述目标对象的验证密文和所述参考密文进行目标运算的结果为与所述目标私钥匹配的目标公钥，所述目标运算满足：对同一对象的参考密文和验证密文进行所述目标运算的结果为与私钥匹配的公钥，该私钥由用于生成该同一对象的密文的私密值得到；使用所述目标私钥对目标签名消息生成目标数字签名，其中，所述目标签名消息包括所述验证密文和所述参考密文；获得至少包含所述验证密文、所述参考密文和所述目标数字签名的证据，以至少证明所述验证密文与所述参考密文基于同一对象得到。
本说明书实施例之一提供一种对象一致性证据生成***，其中，所述***在事务的任一参与方的设备上实现，其包括：参考密文获得模块，用于获得目标对象的参考密文；私钥生成模块，用于生成目标私钥，其中，对所述目标对象的验证密文和所述参考密文进行目标运算的结果为与所述目标私钥匹配的目标公钥，所述目标运算满足：对同一对象的参考密文和验证密文进行所述目标运算的结果为与私钥匹配的公钥，该私钥由用于生成该同一对象的密文的私密值得到；数字签名模块，用于使用所述目标私钥对目标签名消息生成目标数字签名，其中，所述目标签名消息包括所述验证密文和所述参考密文；对象一致性证据获得模块，用于获得至少包含所述验证密文、所述参考密文和所述目标数字签名的证据，以至少证明所述验证密文与所述参考密文基于同一对象得到。
本说明书实施例之一提供一种对象一致性证据生成装置，其中，包括处理器和存储设备，所述存储设备用于存储指令，当所述处理器执行指令时，实现如本说明书任一实施例所述的对象一致性证据生成方法。
附图说明
本说明书将以示例性实施例的方式进一步说明，这些示例性实施例将通过附图进行详细描述。这些实施例并非限制性的，在这些实施例中，相同的编号表示相同的结构，其中：
图1是根据本说明书一些实施例所示的区块链***的应用场景示意图；
图2是根据本说明书实施例所示的资产类型一致性证据生成方法的示例性流程图；
图3是根据本说明书实施例所示的资产类型一致性证据生成方法的示例性流程图；
图4是根据本说明书一些实施例所示的交易方法的示例性流程图；
图5是根据本说明书一些实施例所示的交易验证方法的示例性流程图；
图6是根据本说明书一些实施例所示的对象一致性证据生成方法的示例性流程图；
图7是根据本说明书一些实施例所示的资产类型一致性证据生成***的示例性框图；
图8是根据本说明书一些实施例所示的资产类型一致性证据生成***的示例性框图；
图9是根据本说明书一些实施例所示的交易***的示例性框图；
图10是根据本说明书一些实施例所示的交易验证***的示例性框图；
图11是根据本说明书一些实施例所示的对象一致性证据生成***的示例性框图。
具体实施方式
为了更清楚地说明本说明书实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单的介绍。显而易见地，下面描述中的附图仅仅是本说明书的一些示例或实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可根据这些附图将本说明书应用于其它类似情景。除非从语言环境中显而易见或另做说明，图中相同标号代表相同结构或操作。
应当理解，本文使用的“***”、“装置”、“单元”和/或“模组”是用于区分不同级别的不同组件、元件、部件、部分或装配的一种方法。然而，如果其他词语可实现相同的目的，则可通过其他表达来替换所述词语。
如本说明书和权利要求书中所示，除非上下文明确提示例外情形，“一”、“一个”、“一种”和/或“该”等词并非特指单数，也可包括复数。一般说来，术语“包括”与“包含”仅提示包括已明确标识的步骤和元素，而这些步骤和元素不构成一个排它性的罗列，方法或者设备也可能包含其它的步骤或元素。
本说明书中使用了流程图用来说明根据本说明书的实施例的***所执行的操作。应当理解的是，前面或后面操作不一定按照顺序来精确地执行。相反，可按照倒序或同时处理各个步骤。同时，也可将其他操作添加到这些过程中，或从这些过程移除某一步或数步操作。
本说明书中的实施例可在依托区块链的电子交易场景中提供有关资产类型一致性的零知识证明。即，交易发起方可在不向作为验证方的区块链节点提供任何有用信息(如，用于生成资产类型密文的私密值、交易资产对应的资产类型的标识信息)的情况下，使区块链节点确信交易双方对应的资产类型密文(即后文中的验证密文)基于同一资产类型得到。
图1是根据本说明书一些实施例所示的区块链***的应用场景示意图。如图1所示，区块链***100可包括区块链用户端110(可简称为用户端)、区块链网络120及网络130，其中，区块链网络120包括一个以上区块链节点(可简称为“节点”)，如区块链节点-1、120-2、120-3…120-n等。
区块链用户端110可通过网络130连接于区块链网络120。实体可通过区块链用户端110访问区块链网络120，加入区块链网络120的实体也可称为区块链成员。在一些实施例中，区块链用户端110可上传信息和/或数据至区块链网络120中的一个或多个区块链节点，例如上传交易记录。在一些实施例中，交易记录可包括写入区块中的交易信息(可简称为“交易”)。在一些实施例中，区块链用户端110可向区块链网络120中的一个或多个区块链节点发起查询，以获得存储在区块链(即分布式账本，由持续生成的区块链接而成)中的数据，如交易。
在一些实施例中，交易发起方的用户端可将用于证明资产类型一致性(即，交易双方的验证密文基于同一资产类型得到)的证据附在交易中并上传至区块链网络120，以使节点在至少通过对资产类型一致性的验证后执行预期的后续流程，例如，将交易写入区块、更新交易双方的账户等等。
在一些实施例中，用户端可包括各类具有信息接收和/或发送功能的设备。在一些实施例中，用户端可包括智能电话、平板计算机、个人计算机、服务器等或其任意组合。
区块链网络120中的各个节点需要对交易进行验证和确认，进而生成新的区块(此 过程可称为“记账”)，同时，各节点可通过共识机制来维持存储在各节点的分布式账本的一致性。值得说明的是，区块链节点也可视为区块链网络120的用户端，不同于其他用户端，区块链节点需要参与记账。另外，实体可通过不参与记账的用户端加入区块链网络120，也可通过参与记账的区块链节点加入区块链网络120。
在一些实施例中，节点可验证交易中的证据，以确认交易双方对应的验证密文是否基于同一资产类型得到。若未通过有关资产类型一致性的验证，即确定交易双方对应的验证密文不是基于同一资产类型得到，则节点可拒绝执行预期的后续流程，例如，将交易写入区块、更新交易双方的账户等等。应当理解，除了对资产类型一致性的验证外，对交易的验证还可包括其他验证，如对金额合法性的验证等。在一些实施例中，节点可在通过对交易的多项验证后执行预期的后续流程。关于交易验证的更多细节，可参考图5及其相关描述。
在一些实施例中，节点可包括各类计算设备，如服务器。
在一些实施例中，服务器可是独立的服务器或者服务器组，该服务器组可是集中式的或者分布式的。在一些实施例中，服务器可是区域的或者远程的。在一些实施例中，服务器可在云平台上执行。例如，该云平台可包括私有云、公共云、混合云、社区云、分散式云、内部云等中的一种或其任意组合。
网络130连接***的各组成部分，使得各部分之间可进行通讯。在***中各部分之间的网络可包括有线网络和/或无线网络。例如，网络130可包括电缆网络、有线网络、光纤网络、电信网络、内部网络、互联网、局域网络(LAN)、广域网络(WAN)、无线局域网络(WLAN)、城域网(MAN)、公共交换电话网络(PSTN)、蓝牙网络、紫蜂网络(ZigBee)、近场通信(NFC)、设备内总线、设备内线路、线缆连接等或其任意组合。每两个部分之间的网络连接可是采用上述一种方式，也可是采取多种方式。可理解，网络130与区块链网络120不必具有明显的分界，在更一般的应用场景中，区块链节点与普通网络节点可共同接入同一物理网络中，其中的区块链节点在逻辑上构成区块链网络。
图2是根据本说明书一些实施例所示的资产类型一致性证据生成方法的示例性流程图。流程200可由事务的交易发起方的设备执行，交易发起方的设备可作为用户端(区块链用户端110或区块链节点)连接至区块链网络120。如图2所示，流程200可包括：步骤210，生成目标资产类型的参考密文。在一些实施例中，步骤210可由参考密文生成模块710实现。
应当理解，区块链网络120中的用户端可采用公共的加密算法生成资产类型的验证密文以及参考密文。
步骤220，生成第一私钥。在一些实施例中，步骤220可由第一私钥生成模块720实现。
其中，对目标资产类型的第一验证密文和参考密文进行目标运算的结果为与第一私钥匹配的第一公钥，该第一验证密文与交易发起方对应。
本说明书中提及的目标运算满足：对同一对象的参考密文和验证密文进行目标运算的结果为与私钥匹配的公钥，该私钥由用于生成该同一对象的密文的私密值得到。基于此，如果使用该私钥生成数字签名，只有使用与之匹配的公钥才可成功验签，即目标运算限制了获得可成功验签的公钥的前提为：验证密文与参考密文基于同一对象(资产类 型)得到。
在步骤220中，由用于生成目标资产类型的第一验证密文和/或参考密文的私密值可得到第一私钥，只有使用与之匹配的第一公钥才可成功验证步骤230中使用第一私钥生成的第一数字签名。应当理解，私密值可指任一交易方(交易发起方或交易接收方)用于生成资产类型的密文且不对外公开的值，因为私密值的泄露会带来泄露密文对应的明文(即资产类型的标识信息)的风险。
仅作为示例，验证密文以及参考密文可是基于Pedersen承诺协议得到的。下面介绍Pedersen承诺协议的相关知识：基于Pedersen承诺协议的密文满足C＝r 1*G+r 2*H，其中，G、H为椭圆曲线上的生成元(也可称为基点)，r 1、r 2均为整数，r 1*G、r 2*H和C仍然是该椭圆曲线上的一点。
需要说明的是，本说明书中涉及椭圆曲线的运算与四则运算有着类似的性质，因此借鉴了四则运算的表示方法(如，加、减、乘、+、-、*)，但这并不意味着这些涉及椭圆曲线的运算可等同于四则运算。另外，在本说明书实施例中，区块链网络120中的用户端可具有一些公共的参数，例如，椭圆曲线方程的参数、G、H等等。其中，G、H中的任一个可作为公钥的生成参数，不妨将公钥的生成参数记为G，即，若私钥为r，则r*G为与私钥r匹配的公钥。
在一些实施例中，任一交易方(交易发起方或交易接收方)的验证密文以及参考密文分别包括与G对应的第一部分和与H对应的第二部分，其中，第一验证密文的第一部分基于第一生成元以及与交易发起方对应的私密值得到，第二验证密文的第一部分基于第一生成元和与交易接收方对应的私密值得到，第一验证密文、第二验证密文以及参考密文的第二部分相等且分别基于第二生成元和目标资产类型的标识信息得到。相应地，目标运算可是求差值。如此，只有对同一资产类型的验证密文和参考密文求差值，使得两者的第二部分抵消，才能得到验签的公钥(展开形式包含公钥生成参数G)。
例如，任一交易方(交易发起方或交易接收方)的验证密文可按C_X＝r_X*Pk_X+sn*H计算，其中，C_X表示该交易方的验证密文，r_X表示随机数(视为该交易方的私密值)，Pk_X表示该交易方的公钥，sn表示目标资产类型的标识信息。值得注意的是，鉴于Pk_X＝Pr_X*G，其中Pr_X表示该交易方的私钥(为该交易方的另一私密值)，按C_X＝r_X*Pk_X+sn*H计算出的验证密文实质上是一种基于Pedersen承诺协议的密文。
由此可知，交易发起方的第一验证密文C_A＝r_A*Pk_A+sn*H，其中，r_A表示第一随机数(视为交易发起方的私密值)，Pk_A表示交易发起方的公钥(满足Pk_A＝Pr_A*G，其中Pr_A表示交易发起方的私钥)。
当验证密文按C_X＝r_X*Pk_X+sn*H计算时，参考密文可按C 0＝r 0*G+sn*H计算，其中，C 0表示参考密文，r 0表示第三随机数，r 0可视为限制在交易发起方和交易接收方之间共享的私密值。基于此，目标运算可指对验证密文和参考密文求差值(C_X-C 0或C 0-C_X)。应当理解，由于验证密文和参考密文基于同一资产类型得到，两者共同包含的sn*H在求差值的过程中会抵消，可得到C_X-C 0＝(r_X*Pr_X-r 0)*G或C 0-C_X＝(r 0-r_X*Pr_X)*G，其中，r_X*Pr_X-r 0(或r 0-r_X*Pr_X)可视为私钥。举例说明，若第一验证密文C_A＝r_A*Pk_A+sn*H且参考密文C 0＝r 0*G+sn*H，则第一公钥可是C_A-C 0(或C 0-C_A)，交易发起方的设备可计算r_A*Pr_A-r 0(或r 0-r_A*Pr_A)得到第一 私钥。
步骤230，使用第一私钥对第一签名消息生成第一数字签名。其中，第一签名消息包括第一验证密文和参考密文。在一些实施例中，步骤230可由第一数字签名模块730实现。
步骤240，获得使用第二私钥对第二签名消息生成的第二数字签名。其中，第二签名消息包括第二验证密文和参考密文，第二验证密文与交易接收方对应，对第二验证密文和参考密文进行所述目标运算的结果为与第二私钥匹配的第二公钥。在一些实施例中，步骤240可由第二数字签名获得模块740实现。
步骤250，获得包含第一验证密文、第二验证密文、参考密文、第一数字签名和第二数字签名的证据，以证明第一验证密文、第二验证密文与参考密文基于同一资产类型得到。在一些实施例中，步骤250可由资产类型一致性证据获得模块750实现。
应当理解，第一验证密文可用于更新交易发起方的账户，第二验证密文可用于更新交易接收方的账户。
第一数字签名与参考密文、第一验证密文是互相关联的，当第一数字签名通过验证时可证明关联的第一验证密文与参考密文未经过篡改且两者基于同一资产类型得到。类似地，第二数字签名与参考密文、第二验证密文是互相关联的，当第二数字签名通过验证时可证明关联的第二验证密文与参考密文未经过篡改且两者基于同一资产类型得到。进而，包含第一验证密文、第二验证密文、参考密文、第一数字签名和第二数字签名的证据(以下简称为资产类型一致性证据)可证明第一验证密文、第二验证密文与参考密文基于同一资产类型得到。当第一数字签名和第二数字签名均通过验证(即资产类型一致性证据通过验证)时，可确认第一验证密文、第二验证密文与参考密文基于同一资产类型得到。
交易发起方的设备在获得资产类型一致性证据后，可将资产类型一致性证据附加在交易中并将交易上传至区块链网络120，以证明第一验证密文和第二验证密文基于同一资产类型得到。
关于验证资产类型一致性证据的更多细节，可参考图5及其相关描述。
在一些实施例中，考虑到交易接收方的账户可能尚未注册目标资产类型，交易发起方的设备可生成交易接收方的第二验证密文。当然，交易发起方的设备可将第二验证密文以及用于生成第二验证密文的私密值发送给交易接收方的设备。在一些实施例中，交易发起方的设备还可基于生成的第二验证密文以及参考密文生成第二数字签名，以证明第二验证密文与参考密文基于同一资产类型得到。
在一些实施例中，交易发起方的设备可将参考密文发送给交易接收方的设备，以使交易接收方的设备生成用于证明第二验证密文与参考密文基于同一资产类型得到的第二数字签名。
在一些实施例中，交易接收方的设备可对接收到的参考密文进行验证。基于此，当参考密文至少基于第三随机数生成(如，按C 0＝r 0*G+sn*H计算)时，交易发起方的设备可将该第三随机数发送给交易接收方的设备。交易接收方的设备可基于第三随机数和目标资产类型的标识信息生成对比参考密文，并比较接收到的参考密文和该对比参考密文，两者若相同，则通过验证，否则未通过验证。当未通过对接收到的参考密文的验证时，交易接收方的设备可拒绝执行后续流程，例如，不再生成第二私钥。
第三随机数的泄露可能导致目标资产类型的泄密，例如，攻击者在获知第三随机数的情况下(尤其是在还获知包含目标资产类型的资产类型列表的情况下)可尝试将多个资产类型的标识信息分别代入参考密文的计算式，若发现计算出的某个结果与可公开的参考密文一致时，则可确定该结果对应的资产类型即目标资产类型。有鉴于此，交易发起方的设备可将该第三随机数加密传输给交易接收方的设备。具体地，交易发起方的设备可使用交易接收方的公钥加密包含第三随机数的消息，并将经加密的消息发送给交易接收方的设备，使得交易接收方的设备可使用交易发起方的私钥解密出第三随机数。
在一些实施例中，交易发起方的设备可将目标资产类型的标识信息加密传输给交易接收方的设备。尽管交易接收方的设备可通过加密一个或多个资产类型的标识信息筛选出目标资产类型，但显然由交易发起方告知交易接收方目标资产类型的标识信息是更为直接有效的方式。
前述实施例可进行适当的组合，例如，交易发起方的设备可将消息序列(C 0，r 0，sn；C_A，P_A)发送给交易接收方的设备，其中，C 0表示参考密文，r 0表示第三随机数，sn表示目标资产类型的标识信息，C_A表示第一验证密文，P_A表示第一数字签名。其中，可至少对r 0和sn进行加密处理以防止目标资产类型的泄密，例如，可将利用交易接收方的公钥对消息序列进行加密，并将经加密的消息序列发送给交易接收方的设备。
图3是根据本说明书一些实施例所示的资产类型一致性证据生成方法的示例性流程图。流程300可由交易接收方的设备执行，交易接收方的设备可作为用户端(区块链用户端110或区块链节点)连接至区块链网络120。如图3所示，流程300可包括：
步骤310，接收来自交易发起方的目标资产类型的参考密文。在一些实施例中，步骤310可由参考密文接收模块810实现。
在一些实施例中，交易接收方的设备可对接收到的参考密文进行验证，若未通过验证，则不执行后续流程，例如，不再生成第二私钥。具体地，结合前述实施例，交易接收方的设备可基于第三随机数r 0和目标资产类型的标识信息sn计算(如，按C'＝r 0*G+sn*H计算)得到对比参考密文C'。进而，交易接收方的设备比较对比文参考密文和参考密文，两者若相同，则通过验证，否则未通过验证。
步骤320，生成第二私钥。在一些实施例中，步骤320可由第二私钥生成模块820实现。
其中，对目标资产类型的第二验证密文和参考密文进行目标运算的结果为与第二私钥匹配的第二公钥，该第二验证密文与交易接收方对应。关于目标运算的更多细节，可参考流程200中的相关描述。
参考前述实施例，当第二验证密文C_B＝r_B*Pk_B+sn*H且参考密文C 0＝r 0*G+sn*H时，第二公钥可是C_B-C 0(或C 0-C_B)，交易接收方的设备可计算r_B*Pr_B-r 0(或r 0-r_B*Pr_B)得到第二私钥。其中，r_B表示第二随机数(视为交易接收方的私密值)，Pk_B表示交易接收方的公钥(满足Pk_B＝Pr_B*G，其中Pr_B表示交易接收方的私钥)。
步骤330，使用第二私钥对第二签名消息生成第二数字签名。其中，第二签名消息包括第二验证密文和参考密文。在一些实施例中，步骤330可由第二数字签名模块830实现。
当第二数字签名通过验证时可证明关联的第二验证密文与参考密文未经过篡改且两 者基于同一资产类型得到。
步骤340，将第二验证密文和第二数字签名发送给交易发起方的设备，以使交易发起方的设备获得资产类型一致性证据。在一些实施例中，步骤340可由发送模块840实现。
关于资产类型一致性证据的更多细节，可在流程200的相关描述中找到，这里不再赘述。
在一些实施例中，交易接收方的设备可接收来自交易发起方的消息序列(C 0，r 0，sn；C_A，P_A)，其中，C 0表示参考密文，r 0表示用于生成参考密文的第三随机数，sn表示目标资产类型的标识信息，C_A表示第一验证密文，P_A第一数字签名。进而，交易接收方的设备可按C'＝r 0*G+sn*H计算得到对比参考密文C'。若C'＝C 0，则交易接收方的设备可计算r_B*Pr_B与r 0的差值得到第二私钥，利用第二私钥对第二签名消息生成第二数字签名。
关于流程300的更多细节，可在流程200及其相关描述中找到，这里不再赘述。
在一些实施例中，交易接收方的设备还可接收来自交易发起方的第一验证密文和第一数字签名，以获得资产类型一致性证据。
图4是根据本说明书一些实施例所示的交易方法的示例性流程图。流程400可由流程200(或流程300)中交易发起方或交易接收方的设备执行。应当理解，当流程400由流程200(或流程300)中交易接收方的设备的执行时，流程200(或流程300)中的交易接收方是作为再次发起针对目标资产类型的交易的一方。如图4所示，流程400可包括：步骤410，获得用于证明交易双方对应的验证密文与参考密文基于同一资产类型得到的资产类型一致性证据。在一些实施例中，步骤410可由获得模块910实现。
关于资产类型一致性证据的更多内容，可在图2、图3及其相关描述中找到，这里不再赘述。
步骤420，利用交易发起方或交易接收方的私钥对第三签名消息生成第三数字签名。其中，第三待签名消息包括交易双方账户的标识信息和资产类型一致性证据。在一些实施例中，步骤420可由第三数字签名模块920实现。
步骤430，将第三签名消息和第三数字签名上传至区块链网络120。在一些实施例中，步骤430可由上传模块930实现。
在一些实施例中，第三签名消息可包括更多内容。例如，第三签名消息还可包括交易金额(可是加密形式)、金额合法性证据等等，其中，金额合法性证据用于证明金额数值的合法性。会造成交易出现异常的情况是不被允许(即不合法)的，如以下几种情况：1.交易发起方的账户余额小于交易金额，此时交易发起方的账户是不具备支付能力的；2.交易金额的数值为负，此时会造成账户金额的增减与预期的相反，即账户金额不增反减或不减反增。
在一些实施例中，可采用各种支持零知识证明的加密算法加密交易金额，例如，基于Pedersen承诺协议的加密算法、哈希算法加密、同态加密算法等等。在一些实施例中，当采用基于Pedersen承诺协议加密交易金额时，可利用零知识证明技术“环签名机密交易”和“Bulletproof”生成金额合法性证据。在一些实施例中，当采用哈希算法加密交易金额时，可利用零知识证明技术“zksnark”生成金额合法性证据。
图5是根据本说明书一些实施例所示的交易验证方法的示例性流程图。流程500可 由区块链节点执行。如图5所示，流程500可包括：
步骤510，接收第三签名消息和第三数字签名，该第三签名消息包括参考密文、与交易发起方对应的第一验证密文及第一数字签名、与交易接收方对应的第二验证密文及第二数字签名。在一些实施例中，步骤510可由接收模块1010实现。
步骤520，基于交易发起方或交易接收方的公钥和第三签名消息，验证第三数字签名。在一些实施例中，步骤520可由第一验证模块1020实现。
通过验证第三数字签名可确定：1.签名者是否为交易方(流程200/300中的交易发起方或交易接收方)；2.第三签名消息是否经过篡改。
当第三数字签名通过验证时，说明签名者确实为交易方且第三签名消息没有经过篡改，则区块链节点可继续执行步骤530。当第三数字签名未通过验证时，区块链节点可拒绝执行后续流程(如步骤530)，即认为交易验证未通过。
步骤530，基于第一公钥和第一签名消息验证第一数字签名；和/或，基于第二公钥和第二签名消息验证第二数字签名。在一些实施例中，步骤530可由第二验证模块1030实现。
其中，第二验证模块1030可将参考密文和第一验证密文进行目标运算，得到用于验证第一数字签名的第一公钥，以及可基于参考密文和第一验证密文得到用于验证第一数字签名的第一签名消息。类似地，第二验证模块1030可将参考密文和第二验证密文进行目标运算，得到用于验证第二数字签名的第二公钥，以及可基于参考密文和第二验证密文得到用于验证第二数字签名的第二签名消息。
若第一数字签名和第二数字签名通过验证，则区块链节点可执行步骤540。若第一数字签名或第二签名消息未通过验证，则区块链节点可执行步骤550。在一些实施例中，步骤540和步骤550可由确定模块1040实现。
应当理解，步骤530的具体实现方式不受限制，例如，可默认先验证第一数字签名和第二数字签名中的任一个，若先验证的数字签名未通过验证，则不再验证第一数字签名和第二数字签名中的另一个。
步骤540，确定第一验证密文、第二验证密文与参考密文基于同一资产类型得到。
步骤550，确定第一验证密文、第二验证密文与参考密文不是基于同一资产类型得到并拒绝执行后续流程。
若区块链节点接收到的第一数字签名和第二数字签名均通过验证，则说明交易双方对应的验证密文与参考密文基于同一资产类型得到，即第一验证密文和第二验证密文基于同一资产类型得到。否则，说明第一验证密文和第二验证密文不是基于同一资产类型得到。
交易验证通过的前提是第一数字签名和第二数字签名(当然，还有第三数字签名)均通过验证。若区块链节点通过交易验证，则可继续执行预期的后续流程。例如，可将包括第三签名消息和第三数字签名的交易写入区块。又如，将基于交易双方对应的验证密文更新交易双方的账户，具体地，可从第三签名消息中确定交易金额E(t)，进而将交易发起方的账户中与第一验证密文对应的余额减少E(t)且将交易发起方的账户中与第二验证密文对应的余额增加E(t)。否则，可拒绝执行预期的后续流程。
根据流程400中的相关内容，第三签名消息还可包括金额合法性证据，相应地，区块链节点通过对第三数字签名的验证后还可对金额合法性证据进行验证。应当理解， 金额合法性证据和第一数字签名/第二数字签名的验证顺序是可选的，当金额合法性证据、第一数字签名和第二数字签名中的任一项未通过验证时，区块链节点都可拒绝执行后续流程。
在一些实施例中，当第一数字签名和第二数字签名(当然，还有第三数字签名)通过验证时，说明第一验证密文和第二验证密文基于同一资产类型(即目标资产类型)得到，区块链节点可关联记录交易发起方的标识信息、交易接收方的标识信息、第一验证密文和第二验证密文。如此，当通过验证的历史交易中的任一交易方再次针对目标资产类型发起交易时，可向区块链节点提供第一验证密文和第二验证密文。区块链节点确认交易发起方和交易接收方的身份无误后，在本地查找是否保存有包含交易发起方的标识信息、交易接收方的标识信息、第一验证密文和第二验证密文的关联记录。若存有关联记录，说明在历史交易中已经成功验证过第一验证密文和第二验证密文的一致性，则区块链节点验证交易时可省去对第一数字签名和第二数字签名的验证，当然再次发起交易的一方也不必再向区块链节点提供第一数字签名和第二数字签名。
在一些实施例中，区块链节点保存的关联记录可包括更多内容。例如，区块链节点可保存消息序列(A，B；C 0，C_A，C_B；P_A，P_B)，其中，A表示交易发起方的标识信息，C_A表示第一验证密文，P_B表示第一数字签名，B表示交易接收方的标识信息，C_B表示第二验证密文，P_B表示第二数字签名，C 0表示参考密文。
在一些实施例中，区块链节点可为保存的关联记录生成对应的ID，并将该ID反馈给交易方。如此，当交易双方再次针对目标资产类型进行新交易时，发起新交易的一方的设备可将ID提供给区块链节点，区块链节点根据接收到的ID查找记录的交易双方的验证密文，并基于查找到的验证密文更新交易双方的账户。
值得说明的是，本说明书中的一个或多个步骤还可通过调用智能合约实现。由于智能合约具有必须执行、不可篡改、可追溯等特性，可保证相应步骤按预期执行且留下可追溯的存证。
虽然本说明书主要围绕针对同一资产类型的交易进行了描述，但是，本说明书中的原理可更普遍地应用于针对同一对象的多方事务。这里的多方事务可指具备以下特点的事务：1.需要两个以上参与方共同参与事务；2.各参与方需要针对同一对象(称为目标对象)参与事务；3.针对任一参与方，需要基于与该参与方对应的对象密文公开记录目标对象相关的事务信息，以防止发生隐私泄露。仅作为示例，这里的多方事务可包括同类型数据的交换、同类型数据的协同更新等等。
图6是根据本说明书一些实施例所示的对象一致性证据生成方法的示例性流程图。流程600可由多方事务的任一参与方(以下称为参与方X)的设备执行，具体地，在交易中参与方X可指交易发起方或交易接收方。如图6所示，流程600可包括：
步骤610，获得目标对象的参考密文。在一些实施例中，步骤610可由参考密文获得模块1110实现。
步骤620，生成目标私钥。在一些实施例中，步骤620可由私钥生成模块1120实现。
其中，对目标对象的验证密文和参考密文进行目标运算的结果为与目标私钥匹配的目标公钥，该目标运算满足：对同一对象的参考密文和验证密文进行目标运算的结果为与私钥匹配的公钥，该私钥由用于生成该同一对象的密文的私密值得到。应当理解， 该验证密文(可记为C_X)与参与方X对应，可用于公开记录与参与方X对应的目标对象相关的事务信息。
步骤630，使用目标私钥对目标签名消息生成目标数字签名，该目标签名消息包括验证密文(C_X)和参考密文。在一些实施例中，步骤630可由数字签名模块1130实现。
步骤640，获得至少包含验证密文(C_X)、参考密文和目标数字签名的证据，以至少证明验证密文(C_X)与参考密文基于同一对象得到。在一些实施例中，步骤640可由对象一致性证据获得模块1140实现。
任一参与方对应的目标数字签名可用于证明该参与方对应的验证密文与参考密文基于同一对象得到。因此，可用于证明各参与方对应的验证密文与参考密文基于同一对象得到的证据(以下简称为对象一致性证据)包含:参考密文、各参与方对应的验证密文以及各参与方对应的目标数字签名。
任一参与方可将包含对象一致性证据的消息发送给验证方的设备，以使验证方的设备通过验证对象一致性证据确认各参与方对应的验证密文是否基于同一对象得到。若验证方的设备确认各参与方对应的验证密文基于同一对象得到，则可基于各参与方对应的验证密文记录与各参与方对应的目标对象相关的事务信息。
应当理解，关于流程600的更多细节可参考流程200、流程300及其相关描述。例如，关于目标私钥(公钥)的更多细节，可参考第一/第二私钥(公钥)的相关描述。又如，关于目标签名消息和目标数字签名的更多细节，可参考第一/第二签名消息和第一/第二数字签名的相关描述。又如，关于对象一致性证据的更多细节，可参考资产类型一致性证据的相关描述。
应当注意的是，上述有关流程的描述仅仅是为了示例和说明，而不限定本说明书的适用范围。对于本领域技术人员来说，在本说明书的指导下可对流程进行各种修正和改变。然而，这些修正和改变仍在本说明书的范围之内。
图7是根据本说明书一些实施例所示的资产类型一致性证据生成***的示例性框图。***700可在交易发起方的设备上实现。如图7所示，***700可包括参考密文生成模块710、第一私钥生成模块720、第一数字签名模块730、第二数字签名获得模块740和资产类型一致性证据获得模块750。
参考密文生成模块710可用于生成目标资产类型的参考密文。
第一私钥生成模块720可用于生成第一私钥。
第一数字签名模块730可用于使用所述第一私钥对第一签名消息生成第一数字签名。
第二数字签名获得模块740可用于获得使用第二私钥对第二签名消息生成的第二数字签名。
资产类型一致性证据获得模块750可用于获得包含第一验证密文、第二验证密文、参考密文、第一数字签名和第二数字签名的证据，以证明第一验证密文、第二验证密文与参考密文基于同一资产类型得到。
关于***700及其模块的更多细节，可参考图2及其相关描述。
图8是根据本说明书一些实施例所示的资产类型一致性证据生成***的示例性框图。***800可在交易接收方的设备上实现。如图8所示，***800可包括参考密文 接收模块810、第二私钥生成模块820、第二数字签名模块830和发送模块840。
参考密文接收模块810可用于接收来自交易发起方的目标资产类型的参考密文。
第二私钥生成模块820可用于生成第二私钥。
第二数字签名模块830可用于使用第二私钥对第二签名消息生成第二数字签名。
发送模块840可用于将第二验证密文和第二数字签名发送给交易发起方的设备，以使交易发起方的设备获得资产类型一致性证据。
关于***800及其模块的更多细节，可参考图3及其相关描述。
图9是根据本说明书一些实施例所示的交易***的示例性框图。***900可在流程200(或流程300)中交易发起方或交易接收方的设备上实现。如图9所示，***900可包括获得模块910、第三数字签名模块920和上传模块930。
获得模块910可用于获得用于证明交易双方对应的验证密文与参考密文基于同一资产类型得到的资产类型一致性证据。
第三数字签名模块920可用于利用交易发起方或交易接收方的私钥对第三签名消息生成第三数字签名。
上传模块930可用于将第三签名消息和第三数字签名上传至区块链网络120。
关于***900及其模块的更多细节，可参考图4及其相关描述。
图10根据本说明书一些实施例所示的交易验证***的示例性框图。***1000可在区块链节点上实现。如图10所示，***1000可包括接收模块1010、第一验证模块1020、第二验证模块1030和确定模块1040。
接收模块1010可用于接收第三签名消息和第三数字签名，该第三签名消息包括参考密文、与交易发起方对应的第一验证密文及第一数字签名、与交易接收方对应的第二验证密文及第二数字签名。
第一验证模块1020可用于基于交易发起方或交易接收方的公钥和所述第三签名消息，验证第三数字签名。
第二验证模块1030可用于在第三数字签名通过验证时：基于第一公钥和第一签名消息验证第一数字签名；和/或，基于第二公钥和第二签名消息验证第二数字签名。
确定模块1040可用于：若第一数字签名和第二数字签名通过验证，则确定第一验证密文、第二验证密文与参考密文基于同一资产类型得到；若第一数字签名或第二数字签名未通过验证，则确定第一验证密文、第二验证密文与参考密文不是基于同一资产类型得到并拒绝执行后续流程。
关于***1000及其模块的更多细节，可参考图5及其相关描述。
图11是根据本说明书一些实施例所示的对象一致性证据生成***的示例性框图。***1100可在多方事务的任一参与方(以下称为参与方X)的设备上实现。如图11所示，***1100可包括参考密文获得模块1110、私钥生成模块1120、数字签名模块1130和对象一致性证据获得模块1140。
参考密文获得模块1110可用于获得目标对象的参考密文。
私钥生成模块1120可用于生成目标私钥。
数字签名模块1130可用于使用目标私钥对目标签名消息生成目标数字签名，该目标签名消息包括验证密文(C_X)和参考密文。
对象一致性证据获得模块1140可用于获得至少包含验证密文(C_X)、参考密 文和目标数字签名的证据，以至少证明验证密文与参考密文基于同一对象得到。
关于***1100的更多细节，可参考图6及其相关描述。
应当理解，图7～11所示的***及其模块可利用各种方式来实现。例如，在一些实施例中，***及其模块可通过硬件、软件或者软件和硬件的结合来实现。其中，硬件部分可利用专用逻辑来实现；软件部分则可存储在存储器中，由适当的指令执行***，例如微处理器或者专用设计硬件来执行。本领域技术人员可理解上述的方法和***可使用计算机可执行指令和/或包含在处理器控制代码中来实现，例如在诸如磁盘、CD或DVD-ROM的载体介质、诸如只读存储器(固件)的可编程的存储器或者诸如光学或电子信号载体的数据载体上提供了这样的代码。本说明书的***及其模块不仅可有诸如超大规模集成电路或门阵列、诸如逻辑芯片、晶体管等的半导体、或者诸如现场可编程门阵列、可编程逻辑设备等的可编程硬件设备的硬件电路实现，也可用例如由各种类型的处理器所执行的软件实现，还可由上述硬件电路和软件的结合(例如，固件)来实现。
需要注意的是，以上对于***及其模块的描述，仅为描述方便，并不能把本说明书限制在所举实施例范围之内。可理解，对于本领域的技术人员来说，在了解***的原理后，可能在不背离这一原理的情况下，对各个模块进行任意组合，或者构成子***与其他模块连接。例如，在一些实施例中，图10中披露的第二验证模块1030和确定模块1040可是一个***中的不同模块，也可是一个模块实现这两个模块的功能。诸如此类的变形，均在本说明书的保护范围之内。
本说明书实施例可能带来的有益效果包括但不限于：(1)在保护交易方用于生成验证密文的私密值的前提下，通过引入参考密文设计了一种可公开地、零知识地验证交易双方对应的验证密文是否基于同一资产类型得到的方案；(2)在完成一次有关资产类型一致性的验证后记录本次验证的相关信息，可避免重复验证；(3)可通过智能合约实现一个或多个步骤，以保证相应步骤按预期执行且留下可追溯的存证。需要说明的是，不同实施例可能产生的有益效果不同，在不同的实施例里，可能产生的有益效果可是以上任意一种或几种的组合，也可是其他任何可能获得的有益效果。
上文已对基本概念做了描述，显然，对于本领域技术人员来说，上述详细披露仅仅作为示例，而并不构成对本说明书实施例的限定。虽然此处并没有明确说明，本领域技术人员可能会对本说明书实施例进行各种修改、改进和修正。该类修改、改进和修正在本说明书实施例中被建议，所以该类修改、改进、修正仍属于本说明书示范实施例的精神和范围。
同时，本说明书使用了特定词语来描述本说明书的实施例。如“一个实施例”、“一实施例”、和/或“一些实施例”意指与本说明书至少一个实施例相关的某一特征、结构或特点。因此，应强调并注意的是，本说明书中在不同位置两次或多次提及的“一实施例”或“一个实施例”或“一个替代性实施例”并不一定是指同一实施例。此外，本说明书的一个或多个实施例中的某些特征、结构或特点可进行适当的组合。
此外，本领域技术人员可理解，本说明书实施例的各方面可通过若干具有可专利性的种类或情况进行说明和描述，包括任何新的和有用的工序、机器、产品或物质的组合，或对他们的任何新的和有用的改进。相应地，本说明书实施例的各个方面可完全由硬件执行、可完全由软件(包括固件、常驻软件、微码等)执行、也可由硬件和软件组合执行。以上硬件或软件均可被称为“数据块”、“模块”、“引擎”、“单元”、“组件”或“系 统”。此外，本说明书实施例的各方面可能表现为位于一个或多个计算机可读介质中的计算机产品，该产品包括计算机可读程序编码。
计算机存储介质可能包含一个内含有计算机程序编码的传播数据信号，例如在基带上或作为载波的一部分。该传播信号可能有多种表现形式，包括电磁形式、光形式等，或合适的组合形式。计算机存储介质可是除计算机可读存储介质之外的任何计算机可读介质，该介质可通过连接至一个指令执行***、装置或设备以实现通讯、传播或传输供使用的程序。位于计算机存储介质上的程序编码可通过任何合适的介质进行传播，包括无线电、电缆、光纤电缆、RF、或类似介质，或任何上述介质的组合。
本说明书实施例各部分操作所需的计算机程序编码可用任意一种或多种程序语言编写，包括面向对象编程语言如Java、Scala、Smalltalk、Eiffel、JADE、Emerald、C++、C#、VB.NET、Python等，常规程序化编程语言如C语言、VisualBasic、Fortran2003、Perl、COBOL2002、PHP、ABAP，动态编程语言如Python、Ruby和Groovy，或其他编程语言等。该程序编码可完全在用户计算机上运行、或作为独立的软件包在用户计算机上运行、或部分在用户计算机上运行部分在远程计算机运行、或完全在远程计算机或处理设备上运行。在后种情况下，远程计算机可通过任何网络形式与用户计算机连接，比如局域网(LAN)或广域网(WAN)，或连接至外部计算机(例如通过因特网)，或在云计算环境中，或作为服务使用如软件即服务(SaaS)。
此外，除非权利要求中明确说明，本说明书实施例所述处理元素和序列的顺序、数字字母的使用、或其他名称的使用，并非用于限定本说明书实施例流程和方法的顺序。尽管上述披露中通过各种示例讨论了一些目前认为有用的发明实施例，但应当理解的是，该类细节仅起到说明的目的，附加的权利要求并不仅限于披露的实施例，相反，权利要求旨在覆盖所有符合本说明书实施例实质和范围的修正和等价组合。例如，虽然以上所描述的***组件可通过硬件设备实现，但是也可只通过软件的解决方案得以实现，如在现有的处理设备或移动设备上安装所描述的***。
同理，应当注意的是，为了简化本说明书实施例披露的表述，从而帮助对一个或多个发明实施例的理解，前文对本说明书实施例的描述中，有时会将多种特征归并至一个实施例、附图或对其的描述中。但是，这种披露方法并不意味着本说明书实施例对象所需要的特征比权利要求中提及的特征多。实际上，实施例的特征要少于上述披露的单个实施例的全部特征。
针对本说明书引用的每个专利、专利申请、专利申请公开物和其他材料，如文章、书籍、说明书、出版物、文档等，特此将其全部内容并入本说明书作为参考。与本说明书内容不一致或产生冲突的申请历史文件除外，对本申请权利要求最广范围有限制的文件(当前或之后附加于本说明书中的)也除外。需要说明的是，如果本说明书附属材料中的描述、定义、和/或术语的使用与本说明书所述内容有不一致或冲突的地方，以本说明书的描述、定义和/或术语的使用为准。
最后，应当理解的是，本说明书中所述实施例仅用以说明本说明书实施例的原则。其他的变形也可能属于本说明书实施例的范围。因此，作为示例而非限制，本说明书实施例的替代配置可视为与本说明书的教导一致。相应地，本说明书的实施例不仅限于本说明书明确介绍和描述的实施例。

Claims (27)

  1. 一种资产类型一致性证据生成方法，其中，所述方法由交易发起方的设备执行，其包括：
    生成目标资产类型的参考密文；
    生成第一私钥；其中，对所述目标资产类型的第一验证密文和所述参考密文进行目标运算的结果为与所述第一私钥匹配的第一公钥，所述第一验证密文与所述交易发起方对应，所述目标运算满足：对同一对象的参考密文和验证密文进行所述目标运算的结果为与私钥匹配的公钥，该私钥由用于生成该同一对象的密文的私密值得到；
    使用所述第一私钥对第一签名消息生成第一数字签名；其中，所述第一签名消息包括所述第一验证密文和所述参考密文；
    获得使用第二私钥对第二签名消息生成的第二数字签名；其中，所述第二签名消息包括所述目标资产类型的第二验证密文和所述参考密文，所述第二验证密文与交易接收方对应，对所述第二验证密文和所述参考密文进行所述目标运算的结果为与所述第二私钥匹配的第二公钥；
    获得包含所述第一验证密文、所述第二验证密文、所述参考密文、所述第一数字签名和所述第二数字签名的证据，以证明所述第一验证密文、所述第二验证密文与所述参考密文基于同一资产类型得到。
  2. 如权利要求1所述的方法，其中，所述第一验证密文、所述第二验证密文以及所述参考密文分别基于Pedersen承诺协议得到。
  3. 如权利要求2所述的方法，其中，所述第一验证密文、所述第二验证密文以及所述参考密文分别包括与第一生成元对应的第一部分和与第二生成元对应的第二部分，其中，所述第一生成元和所述第二生成元位于同一椭圆曲线上且所述第一生成元为公钥生成参数，所述第一验证密文的第一部分基于所述第一生成元以及与所述交易发起方对应的私密值得到，所述第二验证密文的第一部分基于所述第一生成元和与所述交易接收方对应的私密值得到，所述第一验证密文、所述第二验证密文以及所述参考密文的第二部分相等且分别基于所述第二生成元和所述目标资产类型的标识信息得到；
    所述目标运算为求差值。
  4. 如权利要求1所述的方法，其中，所述获得使用第二私钥对第二签名消息生成的第二数字签名，包括：
    至少将所述参考密文发送给交易接收方的设备，以使所述交易接收方的设备生成所述第二数字签名；
    从所述交易接收方的设备接收所述第二数字签名以及所述第二验证密文，以获得所述证据。
  5. 如权利要求4所述的方法，其中，所述参考密文至少基于第三随机数生成，所述方法还包括：
    将所述第三随机数发送给所述交易接收方的设备。
  6. 如权利要求4所述的方法，其中，还包括：
    将所述目标资产类型的标识信息加密传输给所述交易接收方的设备。
  7. 如权利要求1或4所述的方法，其中，还包括：
    将所述第一验证密文和所述第一数字签名发送给所述交易接收方的设备。
  8. 如权利要求1所述的方法，其中，还包括生成所述第二验证密文；所述获得使用第二私钥对第二签名消息生成的第二数字签名，包括：
    生成第二私钥，其中，对所述第二验证密文和所述参考密文进行所述目标运算的结果为与所述第二私钥匹配的第二公钥；
    使用所述第二私钥对所述第二签名消息生成所述第二数字签名。
  9. 一种资产类型一致性证据生成***，其中，所述***在交易发起方的设备上实现，其包括：
    参考密文生成模块，用于生成目标资产类型的参考密文；
    第一私钥生成模块，用于生成第一私钥；其中，对所述目标资产类型的第一验证密文和所述参考密文进行目标运算的结果为与所述第一私钥匹配的第一公钥，所述第一验证密文与所述交易发起方对应，所述目标运算满足：对同一对象的参考密文和验证密文进行所述目标运算的结果为与私钥匹配的公钥，该私钥由用于生成该同一对象的密文的私密值得到；
    第一数字签名模块，用于使用所述第一私钥对第一签名消息生成第一数字签名；其中，所述第一签名消息包括所述第一验证密文和所述参考密文；
    第二数字签名获得模块，用于获得使用第二私钥对第二签名消息生成的第二数字签名；其中，所述第二签名消息包括所述目标资产类型的第二验证密文和所述参考密文，所述第二验证密文与交易接收方对应，对所述第二验证密文和所述参考密文进行所述目标运算的结果为与所述第二私钥匹配的第二公钥；
    资产类型一致性证据获得模块，用于获得包含所述第一验证密文、所述第二验证密文、所述参考密文、所述第一数字签名和所述第二数字签名的证据，以证明所述第一验证密文、所述第二验证密文与所述参考密文基于同一资产类型得到。
  10. 一种资产类型一致性证据生成装置，其中，包括处理器和存储设备，所述存储设备用于存储指令，当所述处理器执行指令时，实现如权利要求1～8中任一项所述的方法。
  11. 一种资产类型一致性证据生成方法，其中，所述方法由交易接收方的设备执行，其包括：
    接收来自交易发起方的目标资产类型的参考密文；
    生成第二私钥；其中，对所述目标资产类型的第二验证密文和所述参考密文进行目标运算的结果为与所述第二私钥匹配的第二公钥，所述第二验证密文与所述交易接收方对应，所述目标运算满足：对同一对象的参考密文和验证密文进行所述目标运算的结果为与私钥匹配的公钥，该私钥由用于生成该同一对象的密文的私密值得到；
    使用所述第二私钥对第二签名消息生成第二数字签名；其中，所述第二签名消息包括所述第二验证密文和所述参考密文；
    将所述第二验证密文和所述第二数字签名发送给所述交易发起方的设备，以使所述交易发起方的设备获得包含所述目标资产类型的第一验证密文、所述第二验证密文、所述参考密文、第一数字签名和所述第二数字签名的证据；其中，所述第一验证密文与所述交易发起方对应，所述第一数字签名是使用第一私钥对第一签名消息生成的，所述第一签名消息包括所述第二验证密文和所述参考密文，所述证据用于证明所述第一验证密文、所述第二验证密文与所述参考密文基于同一资产类型得到。
  12. 如权利要求11所述的方法，其中，所述第一验证密文、所述第二验证密文以及所述参考密文分别基于Pedersen承诺协议得到。
  13. 如权利要求12所述的方法，其中，所述第一验证密文、所述第二验证密文以及所述参考密文分别包括与第一生成元对应的第一部分和与第二生成元对应的第二部分，其中，所述第一生成元和所述第二生成元位于同一椭圆曲线上且所述第一生成元为公钥生成参数，所述第一验证密文的第一部分基于所述第一生成元以及与所述交易发起方对应的私密值得到，所述第二验证密文的第一部分基于所述第一生成元和与所述交易接收方对应的私密值得到，所述第一验证密文、所述第二验证密文以及所述参考密文的第二部分相等且分别基于所述第二生成元和所述目标资产类型的标识信息得到；
    所述目标运算为求差值。
  14. 如权利要求11或12所述的方法，其中，还包括：
    接收来自所述交易发起方的第三随机数；
    验证接收到的参考密文；所述验证接收到的参考密文包括：
    基于所述第三随机数和所述目标资产类型的标识信息计算对比参考密文；
    比较所述参考密文以及所述对比参考密文，两者若相同，则通过验证，否则未通过验证。
  15. 如权利要求11所述的方法，其中，还包括：
    从所述交易发起方的设备接收所述第一验证密文和所述第一数字签名，以获得所述证据。
  16. 一种资产类型一致性证据生成***，其中，所述***在交易接收方的设备上实现，其包括：
    参考密文接收模块，用于接收来自交易发起方的目标资产类型的参考密文；
    第二私钥生成模块，用于生成第二私钥；其中，对所述目标资产类型的第二验证密文和所述参考密文进行目标运算的结果为与所述第二私钥匹配的第二公钥，所述第二验证密文与所述交易接收方对应，所述目标运算满足：对同一对象的参考密文和验证密文进行所述目标运算的结果为与私钥匹配的公钥，该私钥由用于生成该同一对象的密文的私密值得到；
    第二数字签名模块，用于使用所述第二私钥对第二签名消息生成第二数字签名；其中，所述第二签名消息包括所述第二验证密文和所述参考密文；
    发送模块，用于将所述第二验证密文和所述第二数字签名发送给所述交易发起方的设备，以使所述交易发起方的设备获得包含所述目标资产类型的第一验证密文、所述第二验证密文、所述参考密文、第一数字签名和所述第二数字签名的证据；其中，所述第一验证密文与所述交易发起方对应，所述第一数字签名是使用第一私钥对第一签名消息生成的，所述第一签名消息包括所述第二验证密文和所述参考密文，所述证据用于证明所述第一验证密文、所述第二验证密文与所述参考密文基于同一资产类型得到。
  17. 一种资产类型一致性证据生成装置，其中，包括处理器和存储设备，所述存储设备用于存储指令，当所述处理器执行指令时，实现如权利要求11～15中任一项所述的方法。
  18. 一种交易方法，其中，包括：
    通过如权利要求1～8、11～15中任一项所述的资产类型一致性证据生成方法，获得 用于证明交易双方对应的验证密文与参考密文基于同一资产类型得到的证据；
    利用交易发起方或交易接收方的私钥对第三签名消息生成第三数字签名，所述第三待签名消息包括交易双方账户的标识信息和所述证据；
    将所述第三签名消息和所述第三数字签名上传至区块链网络。
  19. 一种交易***，其中，包括：
    获得模块，用于通过如权利要求1～8、11～15中任一项所述的资产类型一致性证据生成方法，获得用于证明交易双方对应的验证密文与参考密文基于同一资产类型得到的证据；
    第三数字签名模块，用于利用交易发起方或交易接收方的私钥对第三签名消息生成第三数字签名，所述第三待签名消息包括交易双方账户的标识信息和所述证据；
    上传模块，用于将所述第三签名消息和所述第三数字签名上传至区块链网络。
  20. 一种交易装置，其中，包括处理器和存储设备，所述存储设备用于存储指令，当所述处理器执行指令时，实现如权利要求18所述的方法。
  21. 一种交易验证方法，其中，包括：
    接收第三签名消息和第三数字签名，所述第三签名消息包括参考密文、与交易发起方对应的第一验证密文及第一数字签名、与交易接收方对应的第二验证密文及第二数字签名；
    基于交易发起方或交易接收方的公钥和所述第三签名消息，验证所述第三数字签名；
    当所述第三数字签名通过验证时：将所述参考密文和所述第一验证密文进行目标运算，得到用于验证所述第一数字签名的第一公钥，基于所述参考密文和所述第一验证密文得到用于验证所述第一数字签名的第一签名消息，基于所述第一公钥和所述第一签名消息验证所述第一数字签名；和/或，将所述参考密文和所述第二验证密文进行所述目标运算，得到用于验证所述第二数字签名的第二公钥，基于所述参考密文和所述第二验证密文得到用于验证所述第二数字签名的第二签名消息，基于所述第二公钥和所述第二签名消息验证所述第二数字签名；
    若所述第一数字签名和所述第二数字签名通过验证，则确定所述第一验证密文、所述第二验证密文与所述参考密文基于同一资产类型得到。
  22. 如权利要求21所述的方法，其中，当所述第一数字签名和所述第二数字签名通过验证时，所述方法还包括：
    关联记录所述交易发起方的标识信息、所述交易接收方的标识信息、所述第一数字签名、所述第二数字签名、所述第一验证密文、所述第二验证密文和所述参考密文。
  23. 一种交易验证***，其中，包括：
    接收模块，用于接收第三签名消息和第三数字签名，所述第三签名消息包括参考密文、与交易发起方对应的第一验证密文及第一数字签名、与交易接收方对应的第二验证密文及第二数字签名；
    第一验证模块，用于基于交易发起方或交易接收方的公钥和所述第三签名消息，验证所述第三数字签名；
    第二验证模块，用于当所述第三数字签名通过验证时：将所述参考密文和所述第一验证密文进行目标运算，得到用于验证所述第一数字签名的第一公钥，基于所述参考密文和所述第一验证密文得到用于验证所述第一数字签名的第一签名消息，基于所述第一 公钥和所述第一签名消息验证所述第一数字签名；和/或，将所述参考密文和所述第二验证密文进行所述目标运算，得到用于验证所述第二数字签名的第二公钥，基于所述参考密文和所述第二验证密文得到用于验证所述第二数字签名的第二签名消息，基于所述第二公钥和所述第二签名消息验证所述第二数字签名；
    确定模块，用于：若所述第一数字签名和所述第二数字签名通过验证，则确定所述第一验证密文、所述第二验证密文与所述参考密文基于同一资产类型得到。
  24. 一种交易验证装置，其中，包括处理器和存储设备，所述存储设备用于存储指令，当所述处理器执行指令时，实现如权利要求21或22所述的方法。
  25. 一种对象一致性证据生成方法，其中，所述方法由事务的任一参与方的设备执行，其包括：
    获得目标对象的参考密文；
    生成目标私钥；其中，对所述目标对象的验证密文和所述参考密文进行目标运算的结果为与所述目标私钥匹配的目标公钥，所述目标运算满足：对同一对象的参考密文和验证密文进行所述目标运算的结果为与私钥匹配的公钥，该私钥由用于生成该同一对象的密文的私密值得到；
    使用所述目标私钥对目标签名消息生成目标数字签名；其中，所述目标签名消息包括所述验证密文和所述参考密文；
    获得至少包含所述验证密文、所述参考密文和所述目标数字签名的证据，以至少证明所述验证密文与所述参考密文基于同一对象得到。
  26. 一种对象一致性证据生成***，其中，所述***在事务的任一参与方的设备上实现，其包括：
    参考密文获得模块，用于获得目标对象的参考密文；
    私钥生成模块，用于生成目标私钥；其中，对所述目标对象的验证密文和所述参考密文进行目标运算的结果为与所述目标私钥匹配的目标公钥，所述目标运算满足：对同一对象的参考密文和验证密文进行所述目标运算的结果为与私钥匹配的公钥，该私钥由用于生成该同一对象的密文的私密值得到；
    数字签名模块，用于使用所述目标私钥对目标签名消息生成目标数字签名；其中，所述目标签名消息包括所述验证密文和所述参考密文；
    对象一致性证据获得模块，用于获得至少包含所述验证密文、所述参考密文和所述目标数字签名的证据，以至少证明所述验证密文与所述参考密文基于同一对象得到。
  27. 一种对象一致性证据生成装置，其中，包括处理器和存储设备，所述存储设备用于存储指令，当所述处理器执行指令时，实现如权利要求25所述的方法。
PCT/CN2021/093889 2020-05-15 2021-05-14 资产类型一致性证据生成、交易、交易验证方法及*** WO2021228239A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202010409786.8 2020-05-15
CN202010409786.8A CN111340494B (zh) 2020-05-15 2020-05-15 资产类型一致性证据生成、交易、交易验证方法及***

Publications (1)

Publication Number Publication Date
WO2021228239A1 true WO2021228239A1 (zh) 2021-11-18

Family

ID=71182925

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/093889 WO2021228239A1 (zh) 2020-05-15 2021-05-14 资产类型一致性证据生成、交易、交易验证方法及***

Country Status (2)

Country Link
CN (1) CN111340494B (zh)
WO (1) WO2021228239A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115134081A (zh) * 2022-09-01 2022-09-30 建信金融科技有限责任公司 数据关联信息验证方法、装置、设备及存储介质
CN115129297A (zh) * 2022-08-30 2022-09-30 北京象帝先计算技术有限公司 多点乘运算***、方法、图形处理器、电子装置及设备
CN115829754A (zh) * 2023-02-16 2023-03-21 之江实验室 一种面向隐私保护区块链的交易监管方法及装置

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111340494B (zh) * 2020-05-15 2020-08-28 支付宝(杭州)信息技术有限公司 资产类型一致性证据生成、交易、交易验证方法及***
CN113972984B (zh) * 2020-07-24 2024-03-19 ***通信集团浙江有限公司 ElGamal密文等价判断方法及装置
CN112488831A (zh) * 2020-11-20 2021-03-12 东软集团股份有限公司 区块链网络交易方法、装置、存储介质及电子设备

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018185724A1 (en) * 2017-04-07 2018-10-11 nChain Holdings Limited Method and system for secure data record distribution using a blockchain
CN110505046A (zh) * 2019-07-29 2019-11-26 深圳壹账通智能科技有限公司 多数据提供方加密数据跨平台零知识校验方法、装置及介质
CN110730963A (zh) * 2018-11-27 2020-01-24 阿里巴巴集团控股有限公司 用于信息保护的***和方法
CN110933045A (zh) * 2019-11-08 2020-03-27 中国电子科技网络信息安全有限公司 一种基于承诺的区块链数字资产隐私保护方法
CN111340494A (zh) * 2020-05-15 2020-06-26 支付宝(杭州)信息技术有限公司 资产类型一致性证据生成、交易、交易验证方法及***

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103095662B (zh) * 2011-11-04 2016-08-03 阿里巴巴集团控股有限公司 一种网上交易安全认证方法及网上交易安全认证***
CN109035029A (zh) * 2018-07-27 2018-12-18 阿里巴巴集团控股有限公司 基于区块链的资产转移方法及装置、电子设备
CN111768304A (zh) * 2018-08-06 2020-10-13 阿里巴巴集团控股有限公司 区块链交易方法及装置、电子设备
CN109345215B (zh) * 2018-10-18 2021-08-17 上海达家迎信息科技有限公司 数字货币处理方法、装置、计算机设备及存储介质
CN111105236A (zh) * 2020-01-06 2020-05-05 江苏恒为信息科技有限公司 一种非同质化通证的实现算法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018185724A1 (en) * 2017-04-07 2018-10-11 nChain Holdings Limited Method and system for secure data record distribution using a blockchain
CN110730963A (zh) * 2018-11-27 2020-01-24 阿里巴巴集团控股有限公司 用于信息保护的***和方法
CN110505046A (zh) * 2019-07-29 2019-11-26 深圳壹账通智能科技有限公司 多数据提供方加密数据跨平台零知识校验方法、装置及介质
CN110933045A (zh) * 2019-11-08 2020-03-27 中国电子科技网络信息安全有限公司 一种基于承诺的区块链数字资产隐私保护方法
CN111340494A (zh) * 2020-05-15 2020-06-26 支付宝(杭州)信息技术有限公司 资产类型一致性证据生成、交易、交易验证方法及***

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115129297A (zh) * 2022-08-30 2022-09-30 北京象帝先计算技术有限公司 多点乘运算***、方法、图形处理器、电子装置及设备
CN115129297B (zh) * 2022-08-30 2022-12-13 北京象帝先计算技术有限公司 多点乘运算***、方法、图形处理器、电子装置及设备
CN115134081A (zh) * 2022-09-01 2022-09-30 建信金融科技有限责任公司 数据关联信息验证方法、装置、设备及存储介质
CN115134081B (zh) * 2022-09-01 2022-12-06 建信金融科技有限责任公司 数据关联信息验证方法、装置、设备及存储介质
CN115829754A (zh) * 2023-02-16 2023-03-21 之江实验室 一种面向隐私保护区块链的交易监管方法及装置

Also Published As

Publication number Publication date
CN111340494B (zh) 2020-08-28
CN111340494A (zh) 2020-06-26

Similar Documents

Publication Publication Date Title
WO2021228239A1 (zh) 资产类型一致性证据生成、交易、交易验证方法及***
US11936774B2 (en) Determining a common secret for the secure exchange of information and hierarchical, deterministic cryptographic keys
EP3673435B1 (en) Improving integrity of communications between blockchain networks and external data sources
WO2021114819A1 (zh) 生成和执行智能合约交易的方法及装置
US11159307B2 (en) Ad-hoc trusted groups on a blockchain
WO2020259156A1 (zh) 一种区块链的私密交易方法及装置
CN111563261A (zh) 一种基于可信执行环境的隐私保护多方计算方法和***
JP2020507222A (ja) 情報保護のためのシステム及び方法
US8122245B2 (en) Anonymity revocation
WO2019080933A1 (zh) 一种区块链交易隐私保护方法及***
US11405365B2 (en) Method and apparatus for effecting a data-based activity
US20220051314A1 (en) Information processing apparatus, information processing system, member identification method, and non-transitory computer readable medium storing program
WO2021204273A1 (zh) 资产类型注册、交易记录验证
US11374910B2 (en) Method and apparatus for effecting a data-based activity
WO2019174402A1 (zh) 一种群组数字签名的群组成员发布方法和设备
US20210241270A1 (en) System and method of blockchain transaction verification
CN114143062B (zh) 基于区块链的雾计算环境的安全认证***、方法、终端及介质
CN112488682B (zh) 一种区块链的三方转账方法及装置
US11405188B2 (en) Method for secure transferring of information through a network between an origin virtual asset service provider and a destination virtual asset service provider
US11637817B2 (en) Method and apparatus for effecting a data-based activity
CN115203749A (zh) 一种基于区块链的数据交易方法和***
CN113328854B (zh) 基于区块链的业务处理方法及***
US20240187256A1 (en) Systems and methods for enforcing cryptographically secure actions in public, non-permissioned blockchains using bifurcated self-executing programs comprising shared digital signature requirements
CN115868141A (zh) 用于数字签名的单轮多方计算的技术
Zhang Authenticated Key Exchange Protocols with Unbalanced Computational Requirements

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21804025

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21804025

Country of ref document: EP

Kind code of ref document: A1